5 ms·

I am kinda annoyed by VP8. It is so widespread and so awful due no support in hardware. I think even latest macos doesn't support hardware encoding. Once video

by ex3ndr 6y ago

I am kinda annoyed by VP8. It is so widespread and so awful due no support in hardware. I think even latest macos doesn't support hardware encoding. Once video is on VP8 iPhone will became hot, 5 year old MBP turns on all fans. Just switch to H264 and everything works just fine. Quality is not that different. Why everyone is obsessed with it?

j1elo 6y ago
> latest macos doesn't support hardware encoding. Once video is on VP8 iPhone will became hot, 5 year old MBP turns on all fans I don't understand. Why isn't your question "Why is Apple so extremely late to the party?" ? An iPhone becoming hot with VP8 is caused by Apple not improving VP8 support, not by any inherent quality of H.264. They have been denying for quite a lot of time that the industry did standardize and make mandatory the support for both H.264 and VP8 if you want to implement WebRTC. Apple ignored that and until very recently, they decided to ignore half of those codecs. If I had to guess, maybe "everyone" is "obsessed" with VP8 because H.264 is encumbered by royalties and stuff. VP8 is royalty-free, and its successor VP9 is too.
- ex3ndr 6y ago
  What? If your CPU have H264 then you shouldn't pay any licenses. You will have it in any CPU everywhere. It is not apple late to the party, it is just doesn't make sense to implement VP8 in silicone. Also burning macbooks is Intel issue, not mac. Or may be chrome team are not using hardware acceleration. VP8 is supported for sure, but this codec is subpar comparing to H264. I can easily encode H264 even on Raspberry Pi Zero and i can't do the same for VP8 at all. Also average engineer doesn't care about royalties, but still everyone is using VP8 as default.
  - bastawhiz 6y ago
    > If your CPU have H264 then you shouldn't pay any licenses. You will have it in any CPU everywhere. Except for software that runs on multiple platforms, which might not have H.264 hardware support (or might not be compatible with WebRTC even if they do exist). If you're anyone other than Safari, you have exactly zero reason to believe you'll be able to run WebRTC without a software implementation of H.264. Software encoding means royalty payments if you're a legitimate business.
    - ex3ndr 6y ago
      I yet to see CPU without H264 built in. Even cheapest mobile CPU (more like MCU) have it. Again, no one wants software encoding. This is a thing to avoid.
  - Orphis 6y ago
    Disclaimer: I work on WebRTC somewhere in the codec stack. Certainly not the most knowledgeable in that field but here are a few reasons. Software encoders will always have more features than hardware encoders, which are prone to bugs. A bug in a HW encoder needs either a new driver or new silicone. You can't work with those and sometimes you can't even detect which version it is. So if you want to ship a reliable application, you can either use a software codec (which you control) or hope the HW encoder which is totally random works as intended. HW encoder bugs show in many forms. Sometimes the stream is just broken and can't be decoded, sometimes it won't listen to encoding parameter updates you send it (eg max bitrate or quality settings), sometimes it just generates a valid but bad stream (too many I frames, breaking the max bitrate setting), sometimes they have a TERRIBLE latency. Sometimes, they just plainly lack features, for example can't encode temporal layers, don't have any denoising (useful for VP8), have a limited amount of instances limiting simulcast opportunities, have extreme frame size limitations (can't do screensharing with it)... And that's just what I could come up with in a few minutes of thinking, I'm sure people who have worked on it for a much longer time would be able to say much more.
    - j1elo 6y ago
      We could argue that those issues would apply exactly the same for both H.264 and VP8 hardware-based encoders, so these aren't reasons for lacking VP8 encoders in phones and other devices... otherwise we wouldn't have H.264 hardware either. I agree in spirit with the parent comment (although judging from my post it would seem the contrary). Ideally, both codecs would have hardware encoders. The difference in performance and battery savings are huge. I just understand that the industry players felt that it was necessary to provide a royalty-free option among the proposed codecs... either that or it was just Google pushing their own thing, which also sounds very likely.
      - Orphis 6y ago
        They do apply to all codecs, absolutely. Some just have historically more usage, so the encoders might behave better. There are still bugs though, I do remember hearing about some device producing an H264 stream that another device couldn't decode in HW. It's still not perfect. Also, as many people have pointed out, VP8 is a more complex codec than H264, so harder to test coverage of all features, especially as most applications (especially on desktop) are not really doing RTC, which is quite a specific use case. And phones DO have VP8 encoders. It's just that iPhones for historical reason don't have one. Pure speculation from my part, but I'm guessing they'll do AV1 someday as Apple is working on the spec. But in general, even though HW encoders would be awesome for all codecs if they were working well in all situations, the reality is they don't always work, you usually need to build lists of HW that is supposedly behaving well with your use case. All advanced features (eg spatial layering) are tricky to implement in HW and are usually not configurable, so SW codecs will still have quite a lot of usage for the sake of quality.
kabes 6y ago
Im regards to webRTC: vp8 supports temporal layers, h264 does not. Meaning you can encode and upload 1 stream while participants with different network conditions can be served the best possible framerate. Vp9 and av1 also support spatial layers, which is the same for the resolution. For this you currently need simulcast in vp8 or h264.
- ex3ndr 6y ago
  Yeah, it is like people care about this when they literally can't hear a person on the other side because of fans. Without hardware support all this codecs are useless on mobile. If you will take a look at Zoom, they are essentially doing simulcast over websockets/webrtc data channel and it works well for large amount of participants. Unlike VP8 that can't handle even two.
  - ajconway 6y ago
    Apparently, Zoom encodes and decodes video in software using Webassembly.
    - ex3ndr 6y ago
      WebAssembly is in browsers only, i bet they use proper codecs on desktop apps where most users are.
Orphis 6y ago
There are HW VP8 encoders around. Can't find a definitive list, but I suspect most of the ones that can do VP9 will do VP8 as well: https://en.wikipedia.org/wiki/VP9#Hardware_implementations https://en.wikipedia.org/wiki/VP9#Hardware_implementations

by ex3ndr 6y ago

j1elo 6y ago

> latest macos doesn't support hardware encoding. Once video is on VP8 iPhone will became hot, 5 year old MBP turns on all fans I don't understand. Why isn't your question "Why is Apple so extremely late to the party?" ? An iPhone becoming hot with VP8 is caused by Apple not improving VP8 support, not by any inherent quality of H.264. They have been denying for quite a lot of time that the industry did standardize and make mandatory the support for both H.264 and VP8 if you want to implement WebRTC. Apple ignored that and until very recently, they decided to ignore half of those codecs. If I had to guess, maybe "everyone" is "obsessed" with VP8 because H.264 is encumbered by royalties and stuff. VP8 is royalty-free, and its successor VP9 is too.

ex3ndr 6y ago
What? If your CPU have H264 then you shouldn't pay any licenses. You will have it in any CPU everywhere. It is not apple late to the party, it is just doesn't make sense to implement VP8 in silicone. Also burning macbooks is Intel issue, not mac. Or may be chrome team are not using hardware acceleration. VP8 is supported for sure, but this codec is subpar comparing to H264. I can easily encode H264 even on Raspberry Pi Zero and i can't do the same for VP8 at all. Also average engineer doesn't care about royalties, but still everyone is using VP8 as default.
- bastawhiz 6y ago
  > If your CPU have H264 then you shouldn't pay any licenses. You will have it in any CPU everywhere. Except for software that runs on multiple platforms, which might not have H.264 hardware support (or might not be compatible with WebRTC even if they do exist). If you're anyone other than Safari, you have exactly zero reason to believe you'll be able to run WebRTC without a software implementation of H.264. Software encoding means royalty payments if you're a legitimate business.
  - ex3ndr 6y ago
    I yet to see CPU without H264 built in. Even cheapest mobile CPU (more like MCU) have it. Again, no one wants software encoding. This is a thing to avoid.
- Orphis 6y ago
  Disclaimer: I work on WebRTC somewhere in the codec stack. Certainly not the most knowledgeable in that field but here are a few reasons. Software encoders will always have more features than hardware encoders, which are prone to bugs. A bug in a HW encoder needs either a new driver or new silicone. You can't work with those and sometimes you can't even detect which version it is. So if you want to ship a reliable application, you can either use a software codec (which you control) or hope the HW encoder which is totally random works as intended. HW encoder bugs show in many forms. Sometimes the stream is just broken and can't be decoded, sometimes it won't listen to encoding parameter updates you send it (eg max bitrate or quality settings), sometimes it just generates a valid but bad stream (too many I frames, breaking the max bitrate setting), sometimes they have a TERRIBLE latency. Sometimes, they just plainly lack features, for example can't encode temporal layers, don't have any denoising (useful for VP8), have a limited amount of instances limiting simulcast opportunities, have extreme frame size limitations (can't do screensharing with it)... And that's just what I could come up with in a few minutes of thinking, I'm sure people who have worked on it for a much longer time would be able to say much more.
  - j1elo 6y ago
    We could argue that those issues would apply exactly the same for both H.264 and VP8 hardware-based encoders, so these aren't reasons for lacking VP8 encoders in phones and other devices... otherwise we wouldn't have H.264 hardware either. I agree in spirit with the parent comment (although judging from my post it would seem the contrary). Ideally, both codecs would have hardware encoders. The difference in performance and battery savings are huge. I just understand that the industry players felt that it was necessary to provide a royalty-free option among the proposed codecs... either that or it was just Google pushing their own thing, which also sounds very likely.
    - Orphis 6y ago
      They do apply to all codecs, absolutely. Some just have historically more usage, so the encoders might behave better. There are still bugs though, I do remember hearing about some device producing an H264 stream that another device couldn't decode in HW. It's still not perfect. Also, as many people have pointed out, VP8 is a more complex codec than H264, so harder to test coverage of all features, especially as most applications (especially on desktop) are not really doing RTC, which is quite a specific use case. And phones DO have VP8 encoders. It's just that iPhones for historical reason don't have one. Pure speculation from my part, but I'm guessing they'll do AV1 someday as Apple is working on the spec. But in general, even though HW encoders would be awesome for all codecs if they were working well in all situations, the reality is they don't always work, you usually need to build lists of HW that is supposedly behaving well with your use case. All advanced features (eg spatial layering) are tricky to implement in HW and are usually not configurable, so SW codecs will still have quite a lot of usage for the sake of quality.

kabes 6y ago

Im regards to webRTC: vp8 supports temporal layers, h264 does not. Meaning you can encode and upload 1 stream while participants with different network conditions can be served the best possible framerate. Vp9 and av1 also support spatial layers, which is the same for the resolution. For this you currently need simulcast in vp8 or h264.

ex3ndr 6y ago
Yeah, it is like people care about this when they literally can't hear a person on the other side because of fans. Without hardware support all this codecs are useless on mobile. If you will take a look at Zoom, they are essentially doing simulcast over websockets/webrtc data channel and it works well for large amount of participants. Unlike VP8 that can't handle even two.
- ajconway 6y ago
  Apparently, Zoom encodes and decodes video in software using Webassembly.
  - ex3ndr 6y ago
    WebAssembly is in browsers only, i bet they use proper codecs on desktop apps where most users are.

Orphis 6y ago

There are HW VP8 encoders around. Can't find a definitive list, but I suspect most of the ones that can do VP9 will do VP8 as well: https://en.wikipedia.org/wiki/VP9#Hardware_implementations https://en.wikipedia.org/wiki/VP9#Hardware_implementations