I’ve been enjoying Jan Ozer’s new book, Video Compression for Flash, Apple Devices and HTML5. It’s the comprehensive how-to tutorial on video encoding you’d expect from Jan, as well as a lot of insight about best practices and all the things you should be paying attention to when you’re publishing video online.
Chock full of examples, test results, tables of useful data, and technical information you can put to use right away – this is a great resource for anyone: novice to expert.
Part of what I like is Jan’s no-nonsense approach as a practitioner. For example, after a detailed analysis of publishing using HTML5, he cuts to the chase:
HTML5’s value proposition today, and for the foreseeable future, is “encode in more formats that offer no advantage over H.264, and play on fewer computers, and distribute your on-demand content to vastly fewer viewers with lower quality of service, less features and a reduced ability to monetize than you can with Flash or Silverlight. Oh, and forget live.”
Don’t get me wrong – he still covers everything you need to know (in great detail!) about targeting HTML5 players. But he explains in practical terms what it really means to do so, and when and why you ought to.
The biggest obstacle I’ve had with live Flash Media encoding with Adobe Flash Live Media Encoder 3.1 is the inability to reliably save a version of the encoded file to disk. It’s actually a huge operational problem that we can’t count on archiving a recording at the encoder!
It seems a fairly common case that you’d want to archive a copy, and post it to an on-demand server as soon as the live event is done. But my attempts to do that with FMLE have not been successful.
FMLE saves a .f4v version of the encoding. It’s a chunked file format that needs to be converted to .mp4 to be useful for anything else. Using the free f4vpp tool from Adobe, we should be able to do this conversion and get on with our lives. In practice, the conversion seems to result in either .mp4 files with no audio, or .mp4 files with horrendously out-of-sync audio.
A quick Web search doesn’t turn up too many people complaining about the same thing, so I wonder if there’s something obvious I’m missing. Has anyone else had any success with converting FMLE’s .f4v files to something useful?
Dynamic Streaming article on streamingmedia.com
generated some follow-up over at Longtail
Video, home of the JW FLV Player
. In an email exchange, JW himself, Jeroen Wijering, explained how the JW was handling stream switching, and that in response to my test results, they'd made some changes for the next release (5.2). You will find excerpts of the ensuing email discussion in the comment section of the article page, appearing shortly. In that discussion, Jereon offers a terrific explanation of how it works, and confirms two of the rules of thumb I deduced in my testing:
- Encode with a fixed keyframe interval, ideally every 2 seconds or so
- Use a bufferlength about 2x the keyframe interval
To quote Jeroen:
Herein lies the tradeoff to be made for dynamic streaming. Higher bufferlengths decrease the likelihood of playback stuttering, but slow down any responses to screensize / bandwidth increases. Hence the rules of thumb for short keyframe intervals and "2x keyframe" bufferlengths.
I've updated the Dynamic Streaming example page
to load a build of the player that contains the fix. My testing shows that it performs beautifully - on par with the 1080p player at switching both up and down, with seamless playback during the switch. This will be part of the next release of JW Player, 5.2, now scheduled for around the end of May.
I haven't had any communication from anyone involved with Flowplayer
. Their dynamic streaming implementation as tested for this article (bandwidth-check plugin 3.1.3
) remains not really useful for during-playback streaming, although it was fine a selecting the correct stream at startup.
My latest article, How to do Dynamic Streaming with Flash Media Server, has been published at streamingmedia.com. There’s a page with code examples and demos of dynamic streaming on this site, as well.
I’d expected that writing this article was going to be an easy, quick process of explaining how to encode multiple files and set up a playlist in a couple of popular Flash video players (JW FLV Player 5.1 and Flowplayer 3.1.5). My problems started when I decided to actually test out the process as documented by Adobe and the player vendors by creating actual bandwidth fluctuations and watching the behavior of the player.
Imagine my surprise when things didn’t always work very well. I started to wonder if the dynamic streaming technology wasn’t really ready for prime-time. Some research led to finding and testing the 1080p player (from flashstreamworks.com), which had simply outstanding switching performance – on the same videos from the same server. So the technology definitely works. [whew!]
After much research, talking to the vendors, and more testing, I came up with some guidelines that make things work pretty well in all the players. Still, there remains some room for improvement in the implementations of dynamic streaming in the popular players I tested, particularly when it comes to detecting bandwidth changes and then smoothly switching streams during playback.
Is Flash video on a Mac a CPU hog? More than on Windows? If so, why?
Thankfully, someone’s finally done a test to put some data behind the anecdotes. (Doh! Why I didn’t think of doing that?!?) Jan Ozer over at the Streaming Learning Center hastested Flash video vs. HTML5 video, covering all the browsers on both Windows and (Intel) Mac, and Flash versions 10.0 and (the new, performance-optimized) 10.1.
It’s hard to summarize the findings without leaving out important detail, so I recommend looking at Jan’s data directly. The tables are revealing. But in a nutshell, Jan found that where the video decoder can access hardware acceleration, performance is excellent, and where it can’t…not so much. This means that on Windows, Flash is actually slightly more CPU-efficient than HTML5. On the Mac, where Apple has not made API hooks to its graphics hardware acceleration available to software developers, Flash and HTML5 are both hogs – unless you’re using HTML5 in Safari. It suggests that Apple is using graphics acceleration APIs that it’s keeping from others who are developing applications for the Mac. (Kinda smells like what Microsoft was accused of years ago – keeping various Windows APIs secret so that its non-OS products would always have an advantage over competitors. Microsoft has denied this. )
Is it fair – or smart – to withhold powerful APIs from the devleopers who create the applications that make your computer useful and relevant to users? At best. it’s disingenuous for Apple to criticize Adobe for Flash performance on the Mac while keeping access to hardware acceleration under wraps.
In any case, Jan’s tests show that Adobe is continuing to work on this (to the extent that it can). Video performance in Flash 10.1 is improved over 10.0 on both Mac and Windows. On Windows, the difference is dramatic.