4 ms·

And Daala is not fixed yet, so there's a good chance of further improvements a-coming. And it's likely to be relatively clean of patents and may enable a cross-

by quink 12y ago

And Daala is not fixed yet, so there's a good chance of further improvements a-coming. And it's likely to be relatively clean of patents and may enable a cross-everything royalty free implementation. But time will tell how MPEG LA will feel about that. Edit: I'm also wondering, just in case any experts are around... with Daala's design seeming at first glance inherently more suitable for that kind of thing, lifting filters, wavelets and all, does that mean that we're more likely to see some hierarchical modulation/scalable video coding/bitrate peeling sooner rather than later?

nitrogen 12y ago
Has bitrate peeling been used in production by anybody? I got the impression that the bitrate peeling in Vorbis is never used, and that streaming providers will just encode multiple rates for a video and switch between them. It does sound like a cool concept, though.
- TD-Linux 12y ago
  Vidyo uses an implementation of H.264 SVC, I believe. But in general it's not been widely adopted. SVC generally has worse compression than normal H.264, so for streaming it makes more sense just to store multiple encodes at different qualities.
  - pcl 12y ago
    Yes, SVC's sweet spot is more geared towards real-time than pre-cacheable streams. SVC stands for "scalable video coding", and generally behaves in at least one of two dimensions: temporal or spatial. Temporal SVC is pretty much what we have with H.264 AVC; it provides a means to support multiple receiver frame rates from a single sender frame rate. So, if Alice transmits at 60fps, a temporally-smart coding will allow a switch between Alice and Bob to drop some frames so Bob only gets 30fps, say, while Charlie gets the full 60fps. This is useful if Alice has a wonderful upstream connection and Charlie has a great downstream connection, but Bob is connecting via a crappy mobile connection. Spatial SVC is the same thing, but cast in terms of resolution. Imagine that Alice is transmitting 1080p, and Bob is still on that bad mobile network. An SVC coding would mean that Alice could transmit a single high-res stream, and a smart media switch could send Bob a "down-sampled" 380p stream without having to decode and re-encode, while still sending the full 1080p to Charlie. So. Clearly, this is awesome when dealing with real-time coding (e.g., video calling). But when streaming content from Netflix or Youtube or whatever, it's trivial to provide different streams at different resolutions to different users, based on prevailing network conditions for each user. The up-front cost of encoding and storing a dozen so different versions of the same content is minimal, and the work to identify the right stream for each user is about the same in either case.
    - derf_ 12y ago
      Even for real-time use cases, the range of bitrates where (spatial) SVC provides an advantage over simulcast is relatively small, and it's not a big advantage. Plus, it's a patent minefield. I've also seen people argue that it has a computational complexity advantage over coding multiple streams, but a properly written simulcast encoder can share a bunch of the work between encodes as well (libvpx has an implementation of this for VP8, for example, for use in WebRTC).
      - pcl 12y ago
        Agreed; the way the numbers work out today, the advantages are minimal. The story looks like it might be a bit different with 4k on the horizon, though.
derf_ 12y ago
Bitrate peeling is not a design goal, no.
TD-Linux 12y ago
Daala uses wavelets in a few areas, but is largely a lapped DCT based codec. It's not especially suited for producing scalable bitstreams, at least not much more than any other codec. There's little demand for it right now, so we don't plan to include it as a feature. However, if you have some interesting application of it, feel free to let us know!
- Taek 12y ago
  This isn't my direct area of expertise, so I apologize in advance if I am incorrect about anything. Video streaming suffers from unstable connections, and varied throughputs. Some home connections can support high fidelity 1080p and others can just manage visibly degraded 480p. Right now, either you have to store each resolution separately (which can be costly, esp. at 3x redundancy and esp. if your average video is only going to be watched a few hundred times e.g. YouTube), or you have to transcode on-the-fly, which is expensive for any sort of good compression rate. As we move forward, p2p streaming is likely to be a lot more dominant. There are a few services already out there and a few more in development that have a lot of promise. P2p settings are even more sensitive to transcoding costs, as you'd rather have peers uploading in high parallelism, meaning each one would need to be transcoding. I do believe that scalable bitstreams will be important, as they solve a lot of the problems.
  - Dylan16807 12y ago
    Storing multiple copies is a cost but 720 is less than half of 1080, and every smaller resolution combined is also less than half of 1080. The real pain is when you have to have redundant formats each at high quality.
  - deleted 12y ago
    [deleted]
pcl 12y ago
it's likely to be relatively clean of patents and may enable a cross-everything royalty free implementation. But time will tell how MPEG LA will feel about that. So that's the thing. I'm all for royalty-free encoders, but the only way to know if an algorithm is really royalty-free is for it to be older than the current maximum patent age. I believe that Daala is being designed to be royalty-free, but that's not measurable in advance. There are other good reasons to support Daala, and explicitly building something to avoid royalty issues is certainly laudable (esp. compared to explicitly doing the opposite), but you can't just go and guarantee that something new is royalty-free, and it's frustrating to see the community make exactly those sorts of statements.
- phaemon 12y ago
  Where exactly did the community guarantee that Daala was clean of patents?
  - keeperofdakeys 12y ago
    I don't know if there has been any concerted effort to find possible patents, however daala is touted as patent free because its implementation uses different technologies from H264/HEVC, hence most/all of the MPEG-LA patents shouldn't apply.
- derf_ 12y ago
  The U.S. patent system makes it impossible to guarantee anything with respect to patent infringement. But how many royalty-free codecs does Xiph need to develop and deploy at scale [0-4], without anyone filing lawsuits, before people believe that success here is possible? P.S., in case it's not clear, I've volunteered for the Xiph.Org Foundation for over a decade. [0] https://en.wikipedia.org/wiki/Vorbis#Support https://en.wikipedia.org/wiki/Vorbis#Support [1] https://en.wikipedia.org/wiki/List_of_hardware_and_software_that_supports_FLAC https://en.wikipedia.org/wiki/List_of_hardware_and_software_... [2] https://en.wikipedia.org/wiki/Speex#Applications https://en.wikipedia.org/wiki/Speex#Applications [3] https://en.wikipedia.org/wiki/Theora#Playback https://en.wikipedia.org/wiki/Theora#Playback [4] https://en.wikipedia.org/wiki/Opus_%28audio_codec%29#Support https://en.wikipedia.org/wiki/Opus_%28audio_codec%29#Support

by quink 12y ago

nitrogen 12y ago

Has bitrate peeling been used in production by anybody? I got the impression that the bitrate peeling in Vorbis is never used, and that streaming providers will just encode multiple rates for a video and switch between them. It does sound like a cool concept, though.

TD-Linux 12y ago
Vidyo uses an implementation of H.264 SVC, I believe. But in general it's not been widely adopted. SVC generally has worse compression than normal H.264, so for streaming it makes more sense just to store multiple encodes at different qualities.
- pcl 12y ago
  Yes, SVC's sweet spot is more geared towards real-time than pre-cacheable streams. SVC stands for "scalable video coding", and generally behaves in at least one of two dimensions: temporal or spatial. Temporal SVC is pretty much what we have with H.264 AVC; it provides a means to support multiple receiver frame rates from a single sender frame rate. So, if Alice transmits at 60fps, a temporally-smart coding will allow a switch between Alice and Bob to drop some frames so Bob only gets 30fps, say, while Charlie gets the full 60fps. This is useful if Alice has a wonderful upstream connection and Charlie has a great downstream connection, but Bob is connecting via a crappy mobile connection. Spatial SVC is the same thing, but cast in terms of resolution. Imagine that Alice is transmitting 1080p, and Bob is still on that bad mobile network. An SVC coding would mean that Alice could transmit a single high-res stream, and a smart media switch could send Bob a "down-sampled" 380p stream without having to decode and re-encode, while still sending the full 1080p to Charlie. So. Clearly, this is awesome when dealing with real-time coding (e.g., video calling). But when streaming content from Netflix or Youtube or whatever, it's trivial to provide different streams at different resolutions to different users, based on prevailing network conditions for each user. The up-front cost of encoding and storing a dozen so different versions of the same content is minimal, and the work to identify the right stream for each user is about the same in either case.
  - derf_ 12y ago
    Even for real-time use cases, the range of bitrates where (spatial) SVC provides an advantage over simulcast is relatively small, and it's not a big advantage. Plus, it's a patent minefield. I've also seen people argue that it has a computational complexity advantage over coding multiple streams, but a properly written simulcast encoder can share a bunch of the work between encodes as well (libvpx has an implementation of this for VP8, for example, for use in WebRTC).
    - pcl 12y ago
      Agreed; the way the numbers work out today, the advantages are minimal. The story looks like it might be a bit different with 4k on the horizon, though.

derf_ 12y ago

Bitrate peeling is not a design goal, no.

TD-Linux 12y ago

Daala uses wavelets in a few areas, but is largely a lapped DCT based codec. It's not especially suited for producing scalable bitstreams, at least not much more than any other codec. There's little demand for it right now, so we don't plan to include it as a feature. However, if you have some interesting application of it, feel free to let us know!

Taek 12y ago
This isn't my direct area of expertise, so I apologize in advance if I am incorrect about anything. Video streaming suffers from unstable connections, and varied throughputs. Some home connections can support high fidelity 1080p and others can just manage visibly degraded 480p. Right now, either you have to store each resolution separately (which can be costly, esp. at 3x redundancy and esp. if your average video is only going to be watched a few hundred times e.g. YouTube), or you have to transcode on-the-fly, which is expensive for any sort of good compression rate. As we move forward, p2p streaming is likely to be a lot more dominant. There are a few services already out there and a few more in development that have a lot of promise. P2p settings are even more sensitive to transcoding costs, as you'd rather have peers uploading in high parallelism, meaning each one would need to be transcoding. I do believe that scalable bitstreams will be important, as they solve a lot of the problems.
- Dylan16807 12y ago
  Storing multiple copies is a cost but 720 is less than half of 1080, and every smaller resolution combined is also less than half of 1080. The real pain is when you have to have redundant formats each at high quality.
- deleted 12y ago
  [deleted]

pcl 12y ago

it's likely to be relatively clean of patents and may enable a cross-everything royalty free implementation. But time will tell how MPEG LA will feel about that. So that's the thing. I'm all for royalty-free encoders, but the only way to know if an algorithm is really royalty-free is for it to be older than the current maximum patent age. I believe that Daala is being designed to be royalty-free, but that's not measurable in advance. There are other good reasons to support Daala, and explicitly building something to avoid royalty issues is certainly laudable (esp. compared to explicitly doing the opposite), but you can't just go and guarantee that something new is royalty-free, and it's frustrating to see the community make exactly those sorts of statements.

phaemon 12y ago
Where exactly did the community guarantee that Daala was clean of patents?
- keeperofdakeys 12y ago
  I don't know if there has been any concerted effort to find possible patents, however daala is touted as patent free because its implementation uses different technologies from H264/HEVC, hence most/all of the MPEG-LA patents shouldn't apply.
derf_ 12y ago
The U.S. patent system makes it impossible to guarantee anything with respect to patent infringement. But how many royalty-free codecs does Xiph need to develop and deploy at scale [0-4], without anyone filing lawsuits, before people believe that success here is possible? P.S., in case it's not clear, I've volunteered for the Xiph.Org Foundation for over a decade. [0] https://en.wikipedia.org/wiki/Vorbis#Support https://en.wikipedia.org/wiki/Vorbis#Support [1] https://en.wikipedia.org/wiki/List_of_hardware_and_software_that_supports_FLAC https://en.wikipedia.org/wiki/List_of_hardware_and_software_... [2] https://en.wikipedia.org/wiki/Speex#Applications https://en.wikipedia.org/wiki/Speex#Applications [3] https://en.wikipedia.org/wiki/Theora#Playback https://en.wikipedia.org/wiki/Theora#Playback [4] https://en.wikipedia.org/wiki/Opus_%28audio_codec%29#Support https://en.wikipedia.org/wiki/Opus_%28audio_codec%29#Support