1 |
> On Mon, 11 January 2016, at 6:48 p.m., waltdnes@××××××××.org wrote: |
2 |
> |
3 |
> The other problem is that HTML5 sucks up more CPU for video. My data |
4 |
> point with an ancient underpowered Atom netbook watching a Youtube music |
5 |
> video https://www.youtube.com/watch?v=cwqhdRs4jyA |
6 |
> |
7 |
> Flash |
8 |
> ===== |
9 |
> 1) Regular (i.e. smallest) display plays OK |
10 |
> 2) Wide format display plays OK |
11 |
> 3) Fullscreen audio OK, but video stutters badly |
12 |
> |
13 |
> HTML5 |
14 |
> ===== |
15 |
> 1) Regular (i.e. smallest) display plays OK |
16 |
> 2) Wide format audio OK, but video stutters badly |
17 |
> 3) Fullscreen; you don't really want to know |
18 |
|
19 |
That must be the codec or the resolution or something, surely? |
20 |
|
21 |
Or possibly the way your browser implements things. |
22 |
|
23 |
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. |
24 |
|
25 |
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. |
26 |
|
27 |
But I find it hard to believe that Flash it's generally more efficient to run Flash programs than native ones. |
28 |
|
29 |
Note that the video you refer to is available in two different formats at its best resolution - vp8 and avc1: |
30 |
|
31 |
$ youtube-dl https://www.youtube.com/watch?v=cwqhdRs4jyA -F |
32 |
… |
33 |
43 webm 640x360 medium , vorbis, vp8.0 |
34 |
18 mp4 640x360 medium , mp4a.40.2, avc1.42001E (best) |
35 |
$ |
36 |
|
37 |
Undoubtedly one of these codecs is a bit more efficient than the other. |
38 |
|
39 |
Stroller. |