Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Def Vorbis Decoder in ffdshow To be Changed: Tremor->LAVC: Any comm (Read 18195 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Def Vorbis Decoder in ffdshow To be Changed: Tremor->LAVC: Any comm

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
Quote
I'd like to leave tremor as it is as fast but not so high-quality option for those with slower computers and make libavcodec the default decoder for vorbis.

Do you or others have vorbis samples which aren't decoded correctly with libavcodec vorbis decoder? I'd like to fix them if there are any before making libavcodec vorbis decoder the default.


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_.

Def Vorbis Decoder in ffdshow To be Changed: Tremor->LAVC: Any comm

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

Def Vorbis Decoder in ffdshow To be Changed: Tremor->LAVC: Any comm

Reply #2
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.

 
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
Wavpack Hybrid -c4hx6

Def Vorbis Decoder in ffdshow To be Changed: Tremor->LAVC: Any comm

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

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

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.
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.

Def Vorbis Decoder in ffdshow To be Changed: Tremor->LAVC: Any comm

Reply #4
Yes, ffdshow (I didn't use MPC as audio player) for video files. Sorry for the confusion.
Wavpack Hybrid -c4hx6

Def Vorbis Decoder in ffdshow To be Changed: Tremor->LAVC: Any comm

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

Def Vorbis Decoder in ffdshow To be Changed: Tremor->LAVC: Any comm

Reply #6
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.

Def Vorbis Decoder in ffdshow To be Changed: Tremor->LAVC: Any comm

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

Def Vorbis Decoder in ffdshow To be Changed: Tremor->LAVC: Any comm

Reply #8
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...?
Not really a Signature.

Def Vorbis Decoder in ffdshow To be Changed: Tremor->LAVC: Any comm

Reply #9
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)

Def Vorbis Decoder in ffdshow To be Changed: Tremor->LAVC: Any comm

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


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?

- they wantd to make it GPL, not a BSD-style license.


Like... whoa 

Def Vorbis Decoder in ffdshow To be Changed: Tremor->LAVC: Any comm

Reply #11
Quote
- they wantd to make it GPL, not a BSD-style license.


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".

Def Vorbis Decoder in ffdshow To be Changed: Tremor->LAVC: Any comm

Reply #12
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.






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?


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

Quote

- they wantd to make it GPL, not a BSD-style license.


Like... whoa 

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.

Def Vorbis Decoder in ffdshow To be Changed: Tremor->LAVC: Any comm

Reply #13
Quote
- they wantd to make it GPL, not a BSD-style license.


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".


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

Code: [Select]
*     * Redistributions of source code must retain the above copyright
*       notice, this list of conditions and the following disclaimer.


That prevents slapping another license on it.

Def Vorbis Decoder in ffdshow To be Changed: Tremor->LAVC: Any comm

Reply #14
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.

Def Vorbis Decoder in ffdshow To be Changed: Tremor->LAVC: Any comm

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

Def Vorbis Decoder in ffdshow To be Changed: Tremor->LAVC: Any comm

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

Def Vorbis Decoder in ffdshow To be Changed: Tremor->LAVC: Any comm

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

 

Def Vorbis Decoder in ffdshow To be Changed: Tremor->LAVC: Any comm

Reply #18
@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?

Def Vorbis Decoder in ffdshow To be Changed: Tremor->LAVC: Any comm

Reply #19
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.

Def Vorbis Decoder in ffdshow To be Changed: Tremor->LAVC: Any comm

Reply #20

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)

- 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

Def Vorbis Decoder in ffdshow To be Changed: Tremor->LAVC: Any comm

Reply #21
@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?

Def Vorbis Decoder in ffdshow To be Changed: Tremor->LAVC: Any comm

Reply #22
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.

Def Vorbis Decoder in ffdshow To be Changed: Tremor->LAVC: Any comm

Reply #23
In other words chances are that milan is probably going to keep using LAVC for ffdshow


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 ?????????