4 ms·
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 reaso
by DarkShikari 17y ago
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.
- SystemOut 17y agoFlash 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.
- DarkShikari 17y agoThat'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.