6 ms·

Probably pulls the h264 version instead of VP8/9.

noobie 11y ago
I was gonna say there's a Chrome extension (H264ify) that allows that, but then again I doubt the machine would even be capable of running chrome.
ploxiln 11y ago
That's probably not why. h264 would indeed use less cpu time than vp8 if there was hardware acceleration from the graphics driver available and being used for h264 but not vp8 (which is plausible). But software decoding can be pretty efficient in dedicated video players, and browsers and flash can be pretty damn slow at just getting decoded frames to display. Back in 2010 I was using a computer I built in 2004, which had a single-core athlon64 3200. Watching standard definition video in Hulu was a blocky slideshow, totally unusable. But I could watch 720p h264 video at a decent bitrate, with mplayer, with no hardware acceleration. One of the bigger differences is that browsers/flash have to put the video output as a surface that they composite with the controls on top and the rest of the page behind. Old-style video players actually render to a different hardware "overlay" plane and don't mix anything with it in software, and it makes a huge difference. (My mplayer example is from linux, but I've also used MPC on windows a lot. You can change the renderer in the settings, and "overlay" doesn't support showing subtitles, but has noticeably faster/smoother performance. Well, back on windows XP.)
- jsprogrammer 11y ago
  You think VLC pulls the VP8/9 version instead of the h264 version? I seriously doubt it. Why would it? It would make no sense. Most devices have h264 hardware decoders. Most don't have VP8/9 decoders (though they exist). I also have no doubts that an Athlon64 could decode 720p h264 completely in software. You'd be pegging that single core pretty high, but it could do it.
  - ploxiln 11y ago
    My point was that the hardware acceleration, and vp8 vs h264, doesn't really matter. The computation power of processors sold in 2010, even those in not-very-thick laptops, was probably double my Athlon64. The difference is everything else, the UI stuff (and maybe also flash and browsers being less efficient at decoding than ffmpeg).
    - jsprogrammer 11y ago
      Well, on a single core you are going to hit issues with multiple processes running. If you have the browser, flash, network, and decoding all happening on a single core, it wouldn't be surprising to see stuttering. Obviously, offloading the decode to a different processor would help out, but so would running just a single process.
  - TD-Linux 11y ago
    Well, you'd use 30% less bandwidth (and therefore start / seek faster). In addition, decoding VP9 in software is actually faster than H.264 with ffmpeg, the decoding library that VLC uses.
- StavrosK 11y ago
  Are you sure overlay doesn't support subtitles? IIRC, they had a special color value that the graphics card replaced with the decoded video, and they just didn't use that color wherever they wanted to display subtitles. This is just from memory and from what I deduced, so take it with a grain of salt.

I was gonna say there's a Chrome extension (H264ify) that allows that, but then again I doubt the machine would even be capable of running chrome.

ploxiln 11y ago

That's probably not why. h264 would indeed use less cpu time than vp8 if there was hardware acceleration from the graphics driver available and being used for h264 but not vp8 (which is plausible). But software decoding can be pretty efficient in dedicated video players, and browsers and flash can be pretty damn slow at just getting decoded frames to display. Back in 2010 I was using a computer I built in 2004, which had a single-core athlon64 3200. Watching standard definition video in Hulu was a blocky slideshow, totally unusable. But I could watch 720p h264 video at a decent bitrate, with mplayer, with no hardware acceleration. One of the bigger differences is that browsers/flash have to put the video output as a surface that they composite with the controls on top and the rest of the page behind. Old-style video players actually render to a different hardware "overlay" plane and don't mix anything with it in software, and it makes a huge difference. (My mplayer example is from linux, but I've also used MPC on windows a lot. You can change the renderer in the settings, and "overlay" doesn't support showing subtitles, but has noticeably faster/smoother performance. Well, back on windows XP.)

jsprogrammer 11y ago
You think VLC pulls the VP8/9 version instead of the h264 version? I seriously doubt it. Why would it? It would make no sense. Most devices have h264 hardware decoders. Most don't have VP8/9 decoders (though they exist). I also have no doubts that an Athlon64 could decode 720p h264 completely in software. You'd be pegging that single core pretty high, but it could do it.
- ploxiln 11y ago
  My point was that the hardware acceleration, and vp8 vs h264, doesn't really matter. The computation power of processors sold in 2010, even those in not-very-thick laptops, was probably double my Athlon64. The difference is everything else, the UI stuff (and maybe also flash and browsers being less efficient at decoding than ffmpeg).
  - jsprogrammer 11y ago
    Well, on a single core you are going to hit issues with multiple processes running. If you have the browser, flash, network, and decoding all happening on a single core, it wouldn't be surprising to see stuttering. Obviously, offloading the decode to a different processor would help out, but so would running just a single process.
- TD-Linux 11y ago
  Well, you'd use 30% less bandwidth (and therefore start / seek faster). In addition, decoding VP9 in software is actually faster than H.264 with ffmpeg, the decoding library that VLC uses.
StavrosK 11y ago
Are you sure overlay doesn't support subtitles? IIRC, they had a special color value that the graphics card replaced with the decoded video, and they just didn't use that color wherever they wanted to display subtitles. This is just from memory and from what I deduced, so take it with a grain of salt.