> On Mon, 11 January 2016, at 6:48 p.m., waltd...@waltdnes.org wrote: > > The other problem is that HTML5 sucks up more CPU for video. My data > point with an ancient underpowered Atom netbook watching a Youtube music > video https://www.youtube.com/watch?v=cwqhdRs4jyA > > Flash > ===== > 1) Regular (i.e. smallest) display plays OK > 2) Wide format display plays OK > 3) Fullscreen audio OK, but video stutters badly > > HTML5 > ===== > 1) Regular (i.e. smallest) display plays OK > 2) Wide format audio OK, but video stutters badly > 3) Fullscreen; you don't really want to know
That must be the codec or the resolution or something, surely? Or possibly the way your browser implements things. My understanding is that Flash™ is a compiled bytecode. So any video player written in Flash has to go through an extra step of translation, at runtime, for its instructions to be translated into native code. I believe different plugins may be written with different security frameworks - giving a plugin permission to talk directly to the GPU has more serious implications than the browser taking a 480x360 video stream and drawing it in the window itself. And one of those (the latter, I think?) will have more processing overhead, too. But I find it hard to believe that Flash it's generally more efficient to run Flash programs than native ones. Note that the video you refer to is available in two different formats at its best resolution - vp8 and avc1: $ youtube-dl https://www.youtube.com/watch?v=cwqhdRs4jyA -F … 43 webm 640x360 medium , vorbis, vp8.0 18 mp4 640x360 medium , mp4a.40.2, avc1.42001E (best) $ Undoubtedly one of these codecs is a bit more efficient than the other. Stroller.
