Streaming Learning Center Where Streaming Professionals Learn to Excel
Related Articles
I’ve been working on a consulting project involving video on-demand adaptively distributed to Flash and iOS clients via the Adobe Media Server. The job is being run by John Simmer of Web Learning Solutions, and I was brought in by my buddy Stefan Richter of the TheRealTimeWeb.com. I was charged with creating presets for the various frame rates and aspect ratios that the client needed to support, to be encoded by the Adobe Media Encoder, the tool the ultimate client preferred.
I knew that Flash Media Server could accept F4V files and transmux those for iOS delivery, so reflexively chose the F4V presets in the Adobe Media Encoder. Then I got this note from John.
John: So, the question is, once that work is done, are you dead certain beyond any doubt that the .f4v files based on your presets will play in iOS via FMS once http streaming has been properly configured.
Something about that “dead certain” made me want to seek an opinion from someone not already involved with the project, so I emailed AMS-expert David Hassoun, from www.realeyes.com, and asked “I’m encoding files for on-demand distribution to both Flash and iOS via Adobe Media Server. What’s the best input format, .f4v or .mp4, or doesn’t it matter?”
While I was waiting for his answer, I started thinking about general-purpose HTML5 delivery. If the ultimate client wanted to support HTML5 in the next few months, they could distribute a single stream to the player, but not if it was in F4V format. An MP4 file would be the best, if not the only, solution.
Then David replied, “It doesn’t matter but I highly recommend MP4 over F4V in case the file ever wants to be used for http pseudo streaming/progressive via HTML 5 for iOS (possibly as failover). iOS will ignore a valid h.264 file if its any extension other than MP4 or MOV.”
Long story short, the F4V format has several disadvantages compatibility-wise, and, at least in its current iteration, no benefits that I could see. It seems as if the format was created when Adobe had designs of Flash being a long-term, vibrant distribution format for general purpose video. Now, Adobe has ceded the general market to HTML5 while focusing on advanced gaming and premium video.
Certainly the F4M and F4F formats used in HTTP Dynamic Streaming (HDS) will continue to prove useful for producers streaming with HDS. Unless and until Adobe adds some functionality to the F4V format that MP4 files can’t deliver, I’ll avoid F4V.
AME’s Watch Folder Functionality
I’m pretty high on Adobe Media Encoder as a general-purpose H.264 encoding tool; it produces very good quality with the MainConcept codec and is very efficient, particularly when encoding adaptive files, now encoded in parallel in CS6. Can’t beat the price, either, since it’s free with any purchase of Premiere Pro.
This project, however, involved watch folder functionality, which has one glaring deficit – the inability to specify an output file name. If you encode a single file to multiple outputs, the first file is called filename.mp4, the next filename_1.mp4, and so on. As you can see from the screen below, products like Sorenson Squeeze let you customize the file name output to a great degree, which is really useful when creating multiple files for adaptive streaming.
The main programmer on the project, Greg Benson, also from Web Learning Solutions, had requested _SM, _MD, _LG, and _HD extensions to the files depending upon the preset used. I assumed that it could be done, and was surprised when I couldn’t figure out how. Perhaps I missed something; if so, please let me know in a comment.
Configuring Low Bit Rate Adaptive Streams
Another big issue faced on this project was the optimal configuration for low bit rate streams. Typically, it comes down to a choice between lowering the resolution, say to 320×240@30fps, or lowering the frame rate and producing at 640×480@15 fps. I created several sample files for comparison purposes to make an informed decision, which you can see here.
Ultimately, all involved thought that the higher resolution file at the lower frame rate produced the best quality, so we went with 640×480@15 for our low data rate 4:3 files and 640×360@15 fps for our lowest bitrate 16:9 files. You can view the files here and draw your own conclusions.
