The Flash player has a horrifically inefficient H264 decoder. One is almost led to wonder, at times, if it's interpreted. (This would explain a lot.)
HTTP pseudostreaming is, indeed, just a plain HTTP GET with a URL parameter (or an extra header) to indicate what byte position to start at, based on a seek index at the front of the file. It's incredibly "dumb", but trivial to implement even on a shared web host. (You can write the server-side component in a few dozen lines of PHP, for instance.)
The Flash player has a horrifically inefficient H264 decoder. One is almost led to wonder, at times, if it's interpreted. (This would explain a lot.)
The reason it's slow is that the compositing engine requires that the YV12 -> RGB conversion be done in software rather than in a hardware overlay. This is probably exacerbated by the fact that many sites still seem to turn off the hardware accelerated display out. Note that as far as I know, all current implementations of HTML 5 video have a similar problem (compositing engine requires RGB input).
It's based on Mainconcept's decoder, which while not incredibly fast, isn't particularly slow either. Though I wouldn't be surprised if Adobe stripped out some of the assembly to try to make it smaller (or compiled it with -Os).
My advice for performance would be to disable CABAC; that can probably save 15-25% decoding time right off the bat at the cost of 10-25% compression.
Flash only supports hardware accelerated display when you're running full-screen in "kiosk" mode. That is not too useful.
What we've done is sacrifice some quality and encode using one of the mobile h264 profiles (I forget which profile off the top of my head). It essentially outputs h264 in a form that is easier to decode on the client side. It helped us eke out a few extra fps that helped quell an initial user revolt.
Most of the higher profile features of H.264 actually decrease CPU requirements at the same quality level, because they reduce bitrate required for a given quality (in particular, B-frames and 8x8dct).
The only things that significantly affect CPU usage are CABAC, deblocking, bitrate, and resolution. Sticking to a "mobile" profile (i.e. Baseline Profile) is needlessly slashing quality.
Pseudo streaming h264 is a bit trickier than a dozen lines of PHP, although that works for FLV files (I'm assuming you've got your h264 in a .MOV-like container here, since that's what's recommended). You'll need to create an updated file header with new offsets to samples, which is a bit more work than "add a FLV header and cat the rest of the file".
The good thing is that it's Been Done for most servers (mod_h264_streaming modules exist for practically everything under the sun), so one rarely has to reinvent the wheel.
Comments
The Flash player has a horrifically inefficient H264 decoder. One is almost led to wonder, at times, if it's interpreted. (This would explain a lot.)
HTTP pseudostreaming is, indeed, just a plain HTTP GET with a URL parameter (or an extra header) to indicate what byte position to start at, based on a seek index at the front of the file. It's incredibly "dumb", but trivial to implement even on a shared web host. (You can write the server-side component in a few dozen lines of PHP, for instance.)
The Flash player has a horrifically inefficient H264 decoder. One is almost led to wonder, at times, if it's interpreted. (This would explain a lot.)
The reason it's slow is that the compositing engine requires that the YV12 -> RGB conversion be done in software rather than in a hardware overlay. This is probably exacerbated by the fact that many sites still seem to turn off the hardware accelerated display out. Note that as far as I know, all current implementations of HTML 5 video have a similar problem (compositing engine requires RGB input).
It's based on Mainconcept's decoder, which while not incredibly fast, isn't particularly slow either. Though I wouldn't be surprised if Adobe stripped out some of the assembly to try to make it smaller (or compiled it with -Os).
My advice for performance would be to disable CABAC; that can probably save 15-25% decoding time right off the bat at the cost of 10-25% compression.
Flash only supports hardware accelerated display when you're running full-screen in "kiosk" mode. That is not too useful.
What we've done is sacrifice some quality and encode using one of the mobile h264 profiles (I forget which profile off the top of my head). It essentially outputs h264 in a form that is easier to decode on the client side. It helped us eke out a few extra fps that helped quell an initial user revolt.
That's not necessarily a good idea.
Most of the higher profile features of H.264 actually decrease CPU requirements at the same quality level, because they reduce bitrate required for a given quality (in particular, B-frames and 8x8dct).
The only things that significantly affect CPU usage are CABAC, deblocking, bitrate, and resolution. Sticking to a "mobile" profile (i.e. Baseline Profile) is needlessly slashing quality.
Pseudo streaming h264 is a bit trickier than a dozen lines of PHP, although that works for FLV files (I'm assuming you've got your h264 in a .MOV-like container here, since that's what's recommended). You'll need to create an updated file header with new offsets to samples, which is a bit more work than "add a FLV header and cat the rest of the file".
See e.g. http://h264.code-shop.com/trac/wiki/WikiStart
The good thing is that it's Been Done for most servers (mod_h264_streaming modules exist for practically everything under the sun), so one rarely has to reinvent the wheel.