This makes sense seeing the increased interest in browser video support and mozilla supporting improvements in the Theora video codec. Guess what are the most comon use cases for 5.1 and 7.1 channel audio. Movies.

Ohh nice it's 100x times easier to understand now (well almost) . I noticed Monty added in a few new stereo modes for 5.1 channel. You guys are right about your assertions though with more people watching movies in 5.1 and 7.1 it's worth having a few new extra surround modes.

QUOTE

Who wants us to watch movies in a web browser? Please stop

That's how I actually feel about the situation as well (with the advent of Hulu though it seems to have become a new fad) that and someday we will rid the world of Flash sooner then never.

I'm not hot for watching movies in a browser, but my heart is always warmed when Vorbis makes a step forward. I hope that for the next round of standards implementation (whether html or the next successor in video-land), Theora is improved to the point that it's a viable competitor in the video codec world. Some people would block it, but as it gets better, and currently with Mozilla and Google behind implementing open-source browser standards, there's hope here.

Theora is improved to the point that it's a viable competitor in the video codec world. Some people would block it, but as it gets better, and currently with Mozilla and Google behind implementing open-source browser standards, there's hope here

It doesn't look to bad actually. I think the complaints are mostly with how it handles the "motion vectors", which on different image structures sometimes cause macro-blocking artifacts. It's somewhat noticeable at higher resolutions, but it's not like it can be fixed at the cost rebuilding the code from scratch and implementing some other stuff from what I have heard. The only other problem that plagues Theora is there is no real hardware decoding right now. It's going to take some time to mature and that's the key to achieving widespread usage of it. Thusnelda is first the step though.

I think the complaints are mostly with how it handles the "motion vectors", which on different image structures sometimes cause macro-blocking artifacts. It's somewhat noticeable at higher resolutions, but it's not like it can be fixed at the cost rebuilding the code from scratch and implementing some other stuff from what I have heard.

[italics added]

I'm not sure exactly how to read you here. Do you mean that (from what you've heard) Theora will have trouble with motion vector blocking artifacts and there's no hope for improvement on this issue without a complete rebuild of the code? Or do you mean that there IS hope to improve this, without having to completely rebuild the code?

I'm not sure exactly how to read you here. Do you mean that (from what you've heard) Theora will have trouble with motion vector blocking artifacts and there's no hope for improvement on this issue without a complete rebuild of the code? Or do you mean that there IS hope to improve this, without having to completely rebuild the code?

Both I would say . It can only be tweaked for near optimum performance, but if you really wanted it to look at it would be best if it was rebuilt entirely from the ground up . A lot of people don't realize how good of a job Monty has done with the original code rebuilding the motion vector code over these last few years compared to where it was several years ago. Most people expectations though exceed that of H.264, but the reality is the average user will end up transcoding all of their stuff away and these people have the audacity to complain about it's performance and it being in the HTML 5 standard? It's ridiculous.

Xiph have added a web page with ideas for where people with various skill sets could contribute. The Vorbis section currently includes:

* Identifying test samples where Vorbis encodings at very high quality are not completely transparent under careful listening tests. * Identifying test cases that exemplify the improvements in the current AoTuV development. (Helps with AoTuV merging) * Identifying test samples where Vorbis performs worse than other formats.

That isn't what it says at all. The figure in "contribution of the entropy backend" shows only a fairly modest contribution from the entropy coding: The distance from the minimum of the two upper lines to the lower line. It's a contribution, but not a big one.

Just because a particular linear transform doesn't compact all the energy doesn't make it useless. Even if there were no predictive gain from the transformation, it would still be useful in that it changes the noise distribution,

Yes and no. It's not useful all by itself as a lossless coupling. It would need to be switched on to gain in those cases where the spectral content of the coupled channels is similar and off when it isn't. Vorbis can do this, but doesn't currently (it's one of those things where the patent picture is murky). Like mid/side, square polar is a liability in a lossless encoding because it increases the random energy content of the result.

You're right. I was kind of reading between the lines and adding my bits from what I've learned writing an Ogg/Vorbis decoder from scratch a couple of years ago. It was sort of the first thing that came to my mind while reading the text.

QUOTE (NullC @ Mar 27 2010, 00:16)

Just because a particular linear transform doesn't compact all the energy doesn't make it useless.

It isn't linear and that's actually a big issue. I still think it serves no purpose. I base this on the things you can find in the specification -- not on the figures you referred to (figures showing results from a specific implementation of the specification).

QUOTE (xiphmont @ Mar 28 2010, 07:01)

QUOTE (SebastianG @ Mar 16 2010, 08:57)

[...] "square polar mapping" is essentially useless. [...]

Yes and no. It's not useful all by itself as a lossless coupling. It would need to be switched on to gain in those cases where the spectral content of the coupled channels is similar

What gain? When you switch it on between two channels, it's on for the whole spectrum. If it's on for the whole spectrum and don't want to mess with the phase for lower frequencies you have to losslessly code "magnitude" and "angle" in those regions. But this nonlinear mapping introduces the dependency -2|mag| <= ang <= 2|mag|, so you have to use channel-interleaved vector quantization ("residue 2" + VQ, I'll just use "CIVQ" for short) in order to avoid wasting bits. However, I get the same effect by removing SPM and replacing the vector codebooks. Even for things like "point stereo" one could use "sparse" vector code books. No need for SPM. I'm not claiming to have it figured out 100% -- after all, I didn't write an encoder from scratch. So, maybe it's really much more convenient to use SPM for things like point stereo (in the sense that it allows the codec setup packets with the code books to be smaller). If that's not the case then either of us misses something. The use of SPM requires CIVQ. But CIVQ kind of makes SPM obsolete, doesn't it?. If i remember correctly we've had this conversation already. If my memory serves me well, your reply to that was something along the lines of "SPM still helps during multipass encoding" but I could neither figure out how nor do I remember you telling me why you think so.

QUOTE (xiphmont @ Mar 28 2010, 07:01)

Like mid/side, square polar is a liability in a lossless encoding because it increases the random energy content of the result.

As long as you're here, could I ask about getting my Tremor patch reviewed? I have some ideas about how to speed up vorbis decoding, and would like to get the first of them in so I can move on to the next

The astute reader, at this point, will notice that in the theoretical case in which we can use monolithic codebooks of arbitrarily large size, we can directly interleave and encode left and right without polar mapping; in fact, the polar mapping does not appear to lend any benefit whatsoever to the efficiency of the entropy coding.

Bingo. It doesn't "appear" that way -- not to me. I would love to read explanations for this.

QUOTE

In fact, it is perfectly possible and reasonable to build a Vorbis encoder that dispenses with polar mapping entirely and merely interleaves the channel.

Yeah, that's what I said.

QUOTE

However, when we leave the ideal/theoretical domain, we notice that polar mapping does give additional practical benefits, as discussed in the above section on polar mapping and summarized again here:

Polar mapping aids in controlling entropy 'leakage' between stages of a cascaded codebook.

Polar mapping separates the stereo image into point and diffuse components which may be analyzed and handled differently.

Someone please explain this to me. I don't get it. What's "entropy leakage"? Where exactly is the benefit of SPM for "casdaded codebooks"? Encoders can analyze as much as they want. This doesn't require the use of SPM in the coded bitstream. What does "handled differently" exactly mean in this context? We cannot handle them separately during coding without wasting precious bits which makes us use CIVQ to compensate for it. With CIVQ in use, SPM becomes "pretty much" obsolete. The only thing I can imagine where SPM might be useful (in not-yet-existing encoders) and this might be what Monty referred to by "handled differently" is that if you treat VQ and SPM as a single "vector coding black box" you can represent code books with code vectors distributed like this:

CODE

+ + + + + + + + [+] + + + + + + + +

(effectivly, higher resolution "magnitude" and lower resolution "angle") more efficiently because you don't need the "tesselated VQ mode" for emulating this without SPM. But this only reduces the size of the codec setup packet (which is good, no question) -- not the actual audio packets, unfortunately. But as far as I know this hasn't been done in any encoders, and yet, Monty suggests the existence of actual benefits in todays encoders.