The question is: Does anyone have vorbis samples which aren't decoded correctly with libavcodec vorbis decoder? If any, milan_cutka would like to fix the problem(s).

Let me explain the situation:

- In some movie formats, you can use Ogg Vorbis as its audio part. For instance, (Theora+Vorbis).ogg, (XviD+Vorbis).ogm, (x264+Vorbis).mkv, (SNOW+Vorbis).dsm.

- ffdshow is software that is widely used (*1) to decode such Vorbis Track on Windows. ffdshow actually has two Vorbis decoders, Tremor and libavcodec (lavc), the default being currently Tremor. However, the decoding result of Tremor can be bad, quality-wise, because it is compiled in the "fast/low-quality mode" i.e. with _LOW_ACCURACY_ defined. Many ppl say Tremor with _LOW_ACCURACY_ is problematic quality-wise, and using libavcodec would be safer. The quality difference can be easily proven by ABXing wav file decoded by ffdshow (*2) against the original: the one decoded by libavcodec is transparent if bitrate is enough high where as the one decoded by Tremor gets 15/15 at the same bitrate.

- It would be a possible option to compile Tremor without _LOW_ACCURACY_ in ffdshow (*3). celtic_druid actually did that, and the resulted decoder is working obviously better, quality-wise. However, when suggested to do so, milan_cutka, the author of ffdshow replied and asked:
http://sourceforge.net/tracker/index.php?f...761&atid=471492


Libavcodec is working ok afaik, but does anyone know anything bad about its Vorbis decoder? Or any comment?

Tyia.



*1 Not the only one, but widely used. The other DirectShow Vorbis decoders include: CoreVorbis, OggDS, illiminable's, RadLight.
*2 in this way on GraphEdit: Movie->Splitter->ffdshow (Vorbis decoder)->WavDest->File Writer (wav file)
*3 Media Player Classic (MPC)'s internal vorbis decoder is currently Tremor without _LOW_ACCURACY_.

Why doesn't Milan just use libvorbis and forget about it?

Now I understand why some of my Xvid+Vorbis movies didn't enjoyed me... I was used to evaluate the quality through foobar2000 (or any audio player) but sometimes I experienced a different (and poorer) sound quality with MediaPlayerClassics. I always thought I was dreaming or imagining things...
Thanks for the expanation.

N.B. I can't anwser to your original question

According to him, Tremor is very fast in x86, and so is usable for those who have very slow CPUs.

You mean, that's when you use ffdshow's default Vorbis decoder? I'd like to make it clear that it's not MPC's fault if so, because the decoder is ffdshow, and not MPC in that case.

Yes, ffdshow (I didn't use MPC as audio player) for video files. Sorry for the confusion.

Is the libavcodec decoder really original, or is it just libvorbis with another name slapped on?

Correct me if I am wrong.
libvorbis is by xiph.org.
The author of libavcodec vorbis.c is Denes Balatoni.
I think it's original.

EDIT.
Some tables (eg vwin64[], vwin128[]...) were apparently just copy-pasted, but that's normal.
Some parts were practically copied (eg vorbis_comment_query_count).
The other parts are, probably, totally rewritten, and so ffmeg/libavcodec/vorbis.c is not libvorbis.

I checked the source and you are right. It's an independent implementation.

OK, I understand Tremor was written as fast integer-only decoder, with hardware players in mind. But why writing another independent Vorbis decoder in libavcodec, possibly buggy, when there is already proper one delivered by Xiph...?

That's not something I can tell for sure, but possible reasons include:
- ffmpeg devs thought they could write better/faster/cleaner code.
- they wantd to make it GPL, not a BSD-style license.
- just wanted to redo anyway, because re-implementing is fun helping you to know deeply about vorbis.
- wanted to stick to ffmepg naming conventions, so that every file would be consistent (as you know ffmpeg is a much larger set of encoders/decoders, not just vorbis)

yes, I understood he will keep tremor anyway as a low-accuracy solution to people on slow computers.

But why not use libvorbis instead of libavcodec for high accuracy?



Like... whoa

You can do that just by adding the comment to the top of the source. BSD is GPL compatable.

Edit: I suppose that should really be "GPL is BSD compatable".

libavcodec seems to be actually buggy when decoding 6ch vorbis. i.e. Tremor is better for 6ch vorbis. Can any one confirm?
xvid+6ch_vorbis.ogm 2.5 MB

Just in case you wonder:
- To play .ogm use Media Player Classic (MPC). (*If you happen to have a newer SVN version of MPC, make sure to disable its internal Vorbis decoder and let ffdshow to decode.) Or, if you already have something that can load and split .ogm file, that will suffice.

- Here's ffdshow, milan's own builds.
http://ffdshow.sourceforge.net/tikiwiki/ti...Getting+ffdshow

- Go to Start->Programs->ffdshow->audio decoder configuration->Codecs. (1) First set Vorbis=tremor. and play the sample. (2) Then set Vorbis=libavcodec, and reopen the sample clip. I think the result is buggy. (3) You might also want to set Vorbis=disabled to test another DirectShow Vorbis decoder such as CoreVorbis.








I'll ask milan. Personally I can use CoreVorbis, but many people use ffdshow without a second thought, and probably end up feeling "This vorbis thing is not that good." Not a good situation, unfairly damaging the impression of Ogg Vorbis.
As another note, I'd also think that xiph could have just released their official DirectShow decoder for Windows, but that's something not related here.

As its name shows, ffdshow is a project inspired by and based on ffmpeg. So, it's only natural that ffdshow is using libavcodec (which is part of the ffmpeg), par se.
http://en.wikipedia.org/wiki/Libavcodec
http://en.wikipedia.org/wiki/FFmpeg


Um, that's one of my random guesses probably I'm not guessing right at all. I just said random possible reasons popping up in my head.

No, you can't. Quote from the BSD license:



That prevents slapping another license on it.

MPlayer can play that vorbis 6ch decently.
So, perhaps, the problem is not in libavcodec itself, but in the way ffdshow uses it.
If so, libavcodec is ok, and this is a pb milan should fix.

ffmpeg is LGPL...some parts are GPL but I think all the codecs are LGPL.

@Bonzi
True, vorbis.c is LGPLed. I should've checked it more carefully.

mplayer by default would be using tremor or libvorbis, not lavc.

@hangman
Oh I see. Then the problem may be in LAVC vorbis.c after all. Already reported to milan anyway.

Can you reproduce the LAVC/Vorbis 6ch pb in the above sample?

6ch vorbis + lavc in ffdshow = garbage here.

Same results when using ffmpeg to convert so it does appear to be lavc and not just ffdshow+lavc.

- the less external deps (you don't have control over... think faad licensing) the better
I guess it's a step towards totally self-contained system (upto own c lib and compiler :)
Oh btw, rumours are, they've got aac decoder in the making.

In fact 1st reason looks more like it, faster being the keyword

@hangman
Thanks for your confirmation. Now I'm sure this is a bug in lavc.

I was also told by others, that 5.1 vorbis, par se, is not a good idea anyway, because "it has no channel coupling logic, so even vorbis backers point people to aac for that right now. There's no quality bugs (with the reference decoder), just that it's a lot larger than it has to be for any given quality."

I can see the point too. The vorbis 6ch in the above sample is like 500kbps avg. (q=5)
It was converted from 384kbps AC3, so it's really meaningless, as in reality, you can just mux the original AC3 as it is losslessly into .ogm .mkv etc. Vorbis is not compressing in a usual sense, rather it makes it bloated and the conversion is lossy. So totally meaningless, unless you use a real small q (but then you could use aac). This was done only for testing the vorbis decoder. I can see why this bug was unknown for a long time--no one wanted to use vorbis 6ch anyway.
Still, a bug is a bug. (I mean, the pb in lavc decodder is a bug: the problem of 6ch vorbis itself is not a bug but...um... something like a "known limitation." Let me distinguish those 2 things clearly here.)

I also asked milan if it'd be possible to use libvorbis in ffdshow. No reply yet as of writing this.

Altho, since lavc is used in other apps too, not only ffdshow pb, I believe that trying to fix it is the right thing. But then again, as the situation is like above, maybe this doesn't get any high priority.

@ak
I checked CoreVorbis, and I think CoreVorbis decoder is not based on libvorbis either, but it's re-implementation too.
Which directshow Vorbis decoder (for Windows ofcos) is actually based on libvorbis? Does anyone know? Or libvorbis is rather for the reference, and not optimized as you suggested?

In case someone is still interested in the above pb.
That multichan vorbis bug seems 2 have been fixed in ffmpeg,
and celtic_druid just released this binary--patched ffdshow,
which plays vorbis 6ch with LAVC at least decently.
ffdshow-rev2546-SSE2.exe

In other words chances are that milan is probably going to keep using LAVC for ffdshow, not migrating to libvorbis.

I support ffdshow offering an option for libvorbis. In this way, I can use ffdshow in combination with the highly tuned libvorbis DLLs available at:

Ogg Vorbis 高速化プロジェクト

milan is not reading here.
you can post it here
http://sourceforge.net/tracker/?atid=47149...761&func=browse

Just for the clarification: like I said, personally I had already told milan a while ago, "A few persons suggested that ffdshow should use xiph's libvorbis, which would be the safest way to get the best decoding quality." and asked if that would be possible.
http://sourceforge.net/tracker/index.php?f...761&atid=471492

What I meant was, if more ppl post a feature req, that might convince milan in the end. ffdshow is a ffmpeg-related project, but there would be nothing wrong if it had 3 decoders--tremor, lavac, libvorbis, no?
Just my 2 yen.