It isn't video decoding per se: the .flv videos are merely containers for real video encoding formats, and playback alone shouldn't eat considerably more cpu th

It isn't video decoding per se: the .flv videos are merely containers for real video encoding formats, and playback alone shouldn't eat considerably more cpu than with other players. Of course, if you have video decoding hardware you can even offload the heavy number crunching to that unit which kind of gives you "free" video except for any memory I/O overhead for video stream and buffering decoded frames. Flash runtime seems to be pretty slow, as for animating and as for executing ActionScript itself. I don't know how much AS3 helps in that, though. Compositing in Flash can be pretty heavy: SWF videoplayers often have a mix of layers for controls, progress bars, advertisements etc. that all have to be composited on top of each other. Even worse, the SWF videoplayer might be set to run at 40 FPS or 60 FPS eventhough the video itself runs only at 25 fps, for example. This means that Flash tries to render much more and more often than is needed for the video alone. This all happily cumulates: even if we can decode video frames fast enough, the frames still have to be synchronized through the choking Flash core and compositing which may be running late, causing delayed or dropped frames, jittering, unresponsiveness etc. If we played H.264 videos via HTML5 and JavaScript/CSS, I suspect that websites could (and would!) still program their videplayers to do too much and eventually choke on scripting and rendering. Similarly, I guess it's possible to create a lean&mean Flash videoplayer that just basically shows the video layer at the video FPS and nothing else. Disclaimer: I work on next-gen smartphones in a closely related field. YouTube chokes my EeePC 901 on Ubuntu; it runs much better on these little next-gen devices where practically anything graphics related is being accelerated.