5 ms·

Didn't we already go through this with VP8/VP9/WebM?

JustSomeNobody 11y ago
I was thinking the same thing.
TD-Linux 11y ago
VP9 is a good choice if you want a royalty free video codec right now. NETVC is shooting for the next generation. In addition, the goal is to get the video codec standardized at the IETF. NETVC participation is open to anyone though, so it is possible more players will show up.
- jerf 11y ago
  "NETVC is shooting for the next generation." What makes a codec "next generation"? I assume, broadly, it involves trading off more yet more computation for a tighter encode? (As nearly an embarassingly-parallel problem, video coding continues to get faster with more silicon even if serial performance is stagnant.) What kind of gains can we expect from the "next generation"? All honest questions, BTW. Links welcome, though something focused on this question and not just a laundry list of features with no reference to the past would be preferred.
  - bqe 11y ago
    Next generation is indeed a vague term, but I would use HEVC as a good example of a next generation codec. For another codec to be next gen, it should have the same or better compression than HEVC: about half as many bits to encode the same video than H.264 required.
  - astrange 11y ago
    Video encoding is not embarrassingly parallel; no kind of compression ever can be, because if any bit doesn't depend on the previous bit you've wasted it. It is pretty suited to ASICs. Codecs are only efficient up to a certain image size, and then stop working because all the details are too large-scale for them. HEVC works much better than H.264 on 4K. Besides that, there's higher bit depth pixels, 3D, that kind of stuff. Also there's usually so many mistakes and compromises in any standard that you can always find something to fix in the next one.
    - jerf 11y ago
      "Video encoding is not embarrassingly parallel; no kind of compression ever can be, because if any bit doesn't depend on the previous bit you've wasted it." That objection makes no sense. That just implies that at worse parallelization may cost some encoding efficiency. In general, we are quite often willing to pay for that encoding efficiency with gusto given the speedup we can obtain. For instance, http://compression.ca/pbzip2/ http://compression.ca/pbzip2/.
      - astrange 11y ago
        * no compression aiming for efficiency can be If you have that much need for a speedup, you probably have multiple video streams going (like you're Youtube or a livestream broadcaster). In that case, it's better to do one video per CPU, and now you really are parallel. Also, you can get up to 4x parallel through slice-threads safely on one video, or 16x through x264's frame-threads if you don't care about your target bitrate. I wouldn't consider that embarrassingly parallel until it's up to 1024x or so, but maybe you do.
        nitrogen 11y ago
        Are there not stages of compression that are highly parallelizable, though? Like basic transformations that operate locally on the image (maybe DCT, per-block motion vector calculation)?
        astrange 11y ago
        Sure, if they worked on the original image. But that doesn't happen - when you're encoding, the DCT isn't actually run on the image but on the output of previous compression steps (prediction) which are based on the last encoded block. So there's a dependency on every pixel of the image to the upper left of you. And when you're decoding, it just never ends up worth it to read the whole bitstream so you have a whole frame of motion vectors to do it at once. The whole data locality thing.
      - ohazi 11y ago
  - lawl 11y ago
    From https://xiph.org/~xiphmont/demo/daala/demo1.shtml https://xiph.org/~xiphmont/demo/daala/demo1.shtml > Our performance target is roughly a generation beyond current 'next-generation' codecs like VP9 and HEVC, making Daala a next-next-generation effort. and > The next-generation VP9 and HEVC codecs are the latest incremental refinements of a basic codec design that dates back 25 years to h.261. This conservative, linear development strategy evolving a proven design has yielded reliable improvement with relatively low risk, but the law of diminishing returns is setting in. Recent performance increases are coming at exponentially increasing computational cost. > Daala tries for a larger leap forward— by first leaping sideways— to a new codec design and numerous novel coding techniques. In addition to the technical freedom of starting fresh, this new design consciously avoids most of the patent thicket surrounding mainstream block-DCT-based codecs. At its very core, for example, Daala is based on lapped transforms, not the traditional DCT.
- donpdonp 11y ago
  Okay they maybe the link text should say "Thor – A Project to Hammer Out the Next Royalty Free Video Codec". I'd be happy to see VP9 actually get deployed on any significant scale before putting another new codec into the mix.

I was thinking the same thing.

VP9 is a good choice if you want a royalty free video codec right now. NETVC is shooting for the next generation. In addition, the goal is to get the video codec standardized at the IETF. NETVC participation is open to anyone though, so it is possible more players will show up.

jerf 11y ago
"NETVC is shooting for the next generation." What makes a codec "next generation"? I assume, broadly, it involves trading off more yet more computation for a tighter encode? (As nearly an embarassingly-parallel problem, video coding continues to get faster with more silicon even if serial performance is stagnant.) What kind of gains can we expect from the "next generation"? All honest questions, BTW. Links welcome, though something focused on this question and not just a laundry list of features with no reference to the past would be preferred.
- bqe 11y ago
  Next generation is indeed a vague term, but I would use HEVC as a good example of a next generation codec. For another codec to be next gen, it should have the same or better compression than HEVC: about half as many bits to encode the same video than H.264 required.
- astrange 11y ago
  Video encoding is not embarrassingly parallel; no kind of compression ever can be, because if any bit doesn't depend on the previous bit you've wasted it. It is pretty suited to ASICs. Codecs are only efficient up to a certain image size, and then stop working because all the details are too large-scale for them. HEVC works much better than H.264 on 4K. Besides that, there's higher bit depth pixels, 3D, that kind of stuff. Also there's usually so many mistakes and compromises in any standard that you can always find something to fix in the next one.
  - jerf 11y ago
    "Video encoding is not embarrassingly parallel; no kind of compression ever can be, because if any bit doesn't depend on the previous bit you've wasted it." That objection makes no sense. That just implies that at worse parallelization may cost some encoding efficiency. In general, we are quite often willing to pay for that encoding efficiency with gusto given the speedup we can obtain. For instance, http://compression.ca/pbzip2/ http://compression.ca/pbzip2/.
    - astrange 11y ago
      * no compression aiming for efficiency can be If you have that much need for a speedup, you probably have multiple video streams going (like you're Youtube or a livestream broadcaster). In that case, it's better to do one video per CPU, and now you really are parallel. Also, you can get up to 4x parallel through slice-threads safely on one video, or 16x through x264's frame-threads if you don't care about your target bitrate. I wouldn't consider that embarrassingly parallel until it's up to 1024x or so, but maybe you do.
      - nitrogen 11y ago
        Are there not stages of compression that are highly parallelizable, though? Like basic transformations that operate locally on the image (maybe DCT, per-block motion vector calculation)?
        astrange 11y ago
        Sure, if they worked on the original image. But that doesn't happen - when you're encoding, the DCT isn't actually run on the image but on the output of previous compression steps (prediction) which are based on the last encoded block. So there's a dependency on every pixel of the image to the upper left of you. And when you're decoding, it just never ends up worth it to read the whole bitstream so you have a whole frame of motion vectors to do it at once. The whole data locality thing.
    - ohazi 11y ago
- lawl 11y ago
  From https://xiph.org/~xiphmont/demo/daala/demo1.shtml https://xiph.org/~xiphmont/demo/daala/demo1.shtml > Our performance target is roughly a generation beyond current 'next-generation' codecs like VP9 and HEVC, making Daala a next-next-generation effort. and > The next-generation VP9 and HEVC codecs are the latest incremental refinements of a basic codec design that dates back 25 years to h.261. This conservative, linear development strategy evolving a proven design has yielded reliable improvement with relatively low risk, but the law of diminishing returns is setting in. Recent performance increases are coming at exponentially increasing computational cost. > Daala tries for a larger leap forward— by first leaping sideways— to a new codec design and numerous novel coding techniques. In addition to the technical freedom of starting fresh, this new design consciously avoids most of the patent thicket surrounding mainstream block-DCT-based codecs. At its very core, for example, Daala is based on lapped transforms, not the traditional DCT.
donpdonp 11y ago
Okay they maybe the link text should say "Thor – A Project to Hammer Out the Next Royalty Free Video Codec". I'd be happy to see VP9 actually get deployed on any significant scale before putting another new codec into the mix.