Live data from Hacker News

Daala progress update

people.xiph.org

21–30 of 40 posts

Re: Daala progress update

#21

Interesting to see they're also applying Daala to still images. It's a very different set of constraints and optimizations than video. My first instinct was to wonder how it compared to Bellard's recently featured BPG image format [1], which achieves impressive quality at low sizes. Turns out you can check this by selecting "HEVC" in Xiph's image comparison, since that's the core method employed by BPG. [1] http://be…

Back when BPG was announced, I mentioned here that the real headline was the idea of distributing a new image codec without requiring a browser change, and without requiring the format to be solidified.

So, it should be possible to emscripten (that's basically how BPG works - it's an H.265 still-frame codec compiled to Javascript) with Daala, and distribute Daala still-images even though it's work-in-progress. The best bit is when Daala improves, you just re-generate your images and distribute a new Javascript decoder.

Anyone up for this? Even if it's not as good as BPG (it's very slightly worse it seems), at least it's royalty-free.

Re: Daala progress update

#22
post #20

Earlier quoted context omitted.

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!

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…

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.

Re: Daala progress update

#23
Just to add as feedback to that: I much prefer the Jpeg render of 2 things in particular in that sample image. First, the brownish stone on the lower-right corner. As we as the car tracks. Regarding the car-tracks, the rough look in the Jpeg render looks more natural to me. The stone is though only slightly better in the jpeg. For the rest of it, Daala wins! I specially like the thin, tall leave-less tree on the left.

Re: Daala progress update

#24
post #3

Interesting to see they're also applying Daala to still images. It's a very different set of constraints and optimizations than video. My first instinct was to wonder how it compared to Bellard's recently featured BPG image format [1], which achieves impressive quality at low sizes. Turns out you can check this by selecting "HEVC" in Xiph's image comparison, since that's the core method employed by BPG. [1] http://be…

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 f…

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.

Re: Daala progress update

#25
post #5

Earlier quoted context omitted.

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.

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.

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.

Re: Daala progress update

#26
post #21

Interesting to see they're also applying Daala to still images. It's a very different set of constraints and optimizations than video. My first instinct was to wonder how it compared to Bellard's recently featured BPG image format [1], which achieves impressive quality at low sizes. Turns out you can check this by selecting "HEVC" in Xiph's image comparison, since that's the core method employed by BPG. [1] http://be…

Back when BPG was announced, I mentioned here that the real headline was the idea of distributing a new image codec without requiring a browser change , and without requiring the format to be solidified . So, it should be possible to emscripten (that's basically how BPG works - it's an H.265 still-frame codec compiled to Javascript) with Daala, and distribute Daala still-images even though it's work-in-progress. The…

The demos there run Daala in JS already, but there is browser work to be done to make JS codecs more first class.

Re: Daala progress update

#27

Just to add as feedback to that: I much prefer the Jpeg render of 2 things in particular in that sample image. First, the brownish stone on the lower-right corner. As we as the car tracks. Regarding the car-tracks, the rough look in the Jpeg render looks more natural to me. The stone is though only slightly better in the jpeg. For the rest of it, Daala wins! I specially like the thin, tall leave-less tree on the left…

FWIW, I know that there is some research showing that students (over time) express a preference for MP3 compression artifacts. Something similar could be at play here.

Re: Daala progress update

#28
post #24
post #3

Earlier quoted context omitted.

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 f…

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 measu…

Where exactly did the community guarantee that Daala was clean of patents?

Re: Daala progress update

#29
post #21

Earlier quoted context omitted.

Back when BPG was announced, I mentioned here that the real headline was the idea of distributing a new image codec without requiring a browser change , and without requiring the format to be solidified . So, it should be possible to emscripten (that's basically how BPG works - it's an H.265 still-frame codec compiled to Javascript) with Daala, and distribute Daala still-images even though it's work-in-progress. The…

The demos there run Daala in JS already, but there is browser work to be done to make JS codecs more first class.

It's the packaging aspect of it -- BPG has an encoder ready to encode images, and Javascript ready to copy-paste into your web pages.

It might be a good way to get traction, even if it's not the end product.

Post reply on HN