ffdshow tryouts project: Discussion & Development

[Gleb Egorych]

Can uo utell me the 2 differents players that you tested to that I test.

Zoom Player and DVBViewer.

[nevcairiel]

You can turn off any audio processing by MPC-HC by simply turning off the "Use built-in Audio Switcher" Checkbox in the Audio options. If its still going out the wrong channels then, its ffdshows fault, no question.

Personally, i use the audio switcher to adjust for A/V delay, but without anything selected in the channel mapping table there. Never had any issues with any audio codec.

[HeadlessCow]

Thanks.
The problem is that the sub renderer of mpc-hc is still very buggued (and like for ffdshow, nobody works on the sub renderer) for example and even more buggued (ssa/ass renderer is buggued and pgs renderer is buggued) than sub renderer in ffdshow.
It's very difficult (I don't know the software) to find a software whose sub renderer is perfect and works all the time.

The "perfect" solution is to install vsFilter since that's the software that everyone making the subtitles uses. It's buggy too, but as long as you're using the same version as the maker of the subs, it's what they're using to create it anyways. MPC-HC should be nearly exactly the same since it's just an internal version of the same code.

[ikarad]

The "perfect" solution is to install vsFilter since that's the software that everyone making the subtitles uses. It's buggy too, but as long as you're using the same version as the maker of the subs, it's what they're using to create it anyways. MPC-HC should be nearly exactly the same since it's just an internal version of the same code.

The problem is that with mpc-hc there are many bugs with sub renderer and it's not the perfect solution. FFdshow sub renderer is better even if not perfect.

[ikarad]

You can turn off any audio processing by MPC-HC by simply turning off the "Use built-in Audio Switcher" Checkbox in the Audio options. If its still going out the wrong channels then, its ffdshows fault, no question.

Personally, i use the audio switcher to adjust for A/V delay, but without anything selected in the channel mapping table there. Never had any issues with any audio codec.

I have tried by simply turning off the "Use built-in Audio Switcher" Checkbox in the Audio options and there is the same problem.

[pirlouy]

I'm using ffdshow_rev3765_20110225_xhmikosr_icl12 build, but with an older build, I also have this problem:

I can't manage to read old MPEG1 videos with ffdshow. Player crashes quite quickly, with libmpeg2 or libavcodec. I did not have this problem some weeks ago... I don't have problem when using MPC-HC decoder though (huh ?).

I know it's not a splitter problem or a an audio decoder. It's really something to do with ffdshow video part.

[p0w3rh0u5e]

I have some problems with the mixer, but only with the x86-build.

If i set it up to 5.1 (3/0/2) it simply doesn't work, no sound at all and the filter only connects if i choose ReClock as renderer. MPC falls back to another decoder, if i don't use ReClock. Same thing happens when i disable the mixer, no sound...

I can set up the mixer to some other presets, with some working and some not (but nothing really fits, because i have a 5.1 setup). For example, 3/2/1 works without LFE, but not with LFE enabled... 3/0/1 works with both LFE enabled and disabled. 3/0/2 doesn't work at all. Changing the splitter doesn't help too (tried haali, lavf and mpc's internal)

Everything is working with the x64-build of the same version and identical configuration.

Any ideas?

[STaRGaZeR]

I've fixed the last issue I had with libavcodec and DTS streams. So here's a test build, so you guys can torture it. What to do:

- Test everything, DTS, all variants of DTS-HD (only the DTS core will be decoded obviously), switching, retarded splitters, etc.
- Test only software decoding. No bitstreaming.
- If you're going to report anything, try libdts and confirm you don't have the issue with it before reporting.
- Since someone is going to say it, 16-bit output is not an issue. Decoding failures are.

And if possible, do the same with AC3, AAC, MP1/2/3.

http://www.mediafire.com/?ac6bc5s3wb1st9u

[fastplayer]

What exactly was wrong with DTS in the first place? If it's libavcodec's fault, shouldn't it be fixed upstream instead?
Off to testing...

[hoborg]

@hoborg
We need a volunteer to fix the twos/sowt decoding code and also port some QT PCM additions from MPC-HC.
Preferably also separate these formats from "uncompressed" into new format options.

Thanks for info.
How much work it will need to separate them from RAW audio?
Right now i didn't found a way how to prevent FFDshow load to decode twos/sowt so MPA MPA decoder can be used instead. If i disable RAW audio, it will broke playback of videos with mixed PCM and compresed audio, so this is not good way.

Of course best will be if somebody fix twos/sowt playback, but i understand there is tasks with highter priorities :)

[fastplayer]

@STaRGaZeR:
Since you've had some fun with the RGB32HQ code, does this explanation on our wiki (http://ffdshow-tryout.sourceforge.net/wiki/video:rgb_conversion#high_quality_yv12_to_rgb_conversion) make any sense?
High quality YV12 to RGB conversion

This checkbox will instruct ffdshow to use a high quality conversion method. If you have a dual core CPU, you can do so without performance penalty. If you have quad core CPU, check this, it's faster with higher quality.
This sounds like a quad-core will produce a better image than a dual-core. Is there something in the code that suggests this or is this just bad wording?

[STaRGaZeR]

What exactly was wrong with DTS in the first place? If it's libavcodec's fault, shouldn't it be fixed upstream instead?
Off to testing...

DTS-HD (MA at least, dunno about HR) failed with libavcodec. This was caused by ffdshow's internal parser, doing something wrong stripping the HD blocks. So I just disabled it, letting ffmpeg's parser do its magic, and here it works just fine. In this test build DTS decoding is 100% ffmpeg unless there's something hidden in ffdshow I'm not aware of.

If nobody finds any bugs I'll make ffdshow audio default to libavcodec for everything, and eventually remove libmad, libfaad, liba52 and libdts.

@STaRGaZeR:
Since you've had some fun with the RGB32HQ code, does this explanation on our wiki (http://ffdshow-tryout.sourceforge.net/wiki/video:rgb_conversion#high_quality_yv12_to_rgb_conversion) make any sense?

This sounds like a quad-core will produce a better image than a dual-core. Is there something in the code that suggests this or is this just bad wording?

Not at all, more or less cores will only be faster or slower. Remember the previous dual core requirement for the checkbox to be enabled? That's probably why it says "if you have a dual core CPU". You wouldn't have been able to enable it otherwise :p

[fastplayer]

If nobody finds any bugs I'll make ffdshow audio default to libavcodec for everything, and eventually remove libmad, libfaad, liba52 and libdts.
Haven't noticed any issues so far with your build throughout the entire day and I've thrown AC3, DTS, AAC, and MP3 at it. :)
I've been using libavcodec as an audio decoder for months by now and I haven't encountered any anomalies. Keep in mind that I'm not doing any bitstreaming, post-processing or other fancy stuff. Just good ol' analog stereo output! :)
Not at all, more or less cores will only be faster or slower. Remember the previous dual core requirement for the checkbox to be enabled? That's probably why it says "if you have a dual core CPU". You wouldn't have been able to enable it otherwise :p
Understood. I'll update that entry accordingly. Thanks!

[STaRGaZeR]

Haven't noticed any issues so far with your build throughout the entire day and I've thrown AC3, DTS, AAC, and MP3 at it. :)
I've been using libavcodec as an audio decoder for months by now and I haven't encountered any anomalies. Keep in mind that I'm not doing any bitstreaming, post-processing or other fancy stuff. Just good ol' analog stereo output! :)

Post-processing, bitstreaming and stuff have nothing to do with the software decoding itself, so we're good :)

[yesgrey]

If nobody finds any bugs I'll make ffdshow audio default to libavcodec for everything, and eventually remove libmad, libfaad, liba52 and libdts.
The only problem I can see is that libavcodec outputs 16 bit integer for some formats. If you plan to patch ffdshow to allow 32 FP for those formats (like madshi did to use with eac3to) I agree with removing the others, otherwise don't.

[STaRGaZeR]

The only problem I can see is that libavcodec outputs 16 bit integer for some formats. If you plan to patch ffdshow to allow 32 FP for those formats (like madshi did to use with eac3to) I agree with removing the others, otherwise don't.

Since someone is going to say it, 16-bit output is not an issue. Decoding failures are.

See? I knew it :D

[yesgrey]

See? I knew it :D
Sorry, I've missed it, but even though it might not be an issue, it would make ffdshow worse, and I think that should be avoided.;)

[STaRGaZeR]

Let's end this flame before it even starts, shall we? I don't want to argue with the same guys that always bring these kind of debates, and that think they can hear stuff with equipment that produces more noise and distortion than the conversion does by itself. My arguments:

Yes, the 16-bit conversion is not optimal from a signal processing point of view.
Yes, ffmpeg is like that.
Yes, for me to modify ffmpeg there should be a showstopper situation. This one isn't.
Yes, if ffmpeg devs decide to remove the conversion and output 32-bit float, ffdshow will do it too.
Yes, basing your perception of quality in a number is just wrong. Proof: you don't know how they work internally, but you assume 32-bit float from libdts is better (not that it sounds better, hah!) than rounded 16-bit integer from libavcodec for example, without even listening to them. And what's worse, you and others will spread this nonsense like you always do. Then users without a clue come, with the same BS, and we have to endure it.
No, you can't hear the difference. Face it.
No, I don't want to (and won't) patch every ffdshow decoder, since that's what would be needed if you want to do it the right way.

I hope this will be my last post on the subject. No need to start a tl;dr useless post war. These are my arguments, I already know yours.

That said, I won't oppose at all if someone does it, even if I think it's a waste of time ;)

Now back to business, any bugs with the libavcodec decoders?

[Qaq]

If there is no chance to get libavcodec as perfect decoder I prefer to stay with 32fp decoders. At least I don't see they do that nonsense 32fp > 16int rounding. And thanks for 32fp for mp3 btw.

[fastplayer]

What has happened to visual styles in recent builds? In Win7 no themes are applied to controls at all. Manifest missing/broken?

[madshi]

The only problem I can see is that libavcodec outputs 16 bit integer for some formats. If you plan to patch ffdshow to allow 32 FP for those formats (like madshi did to use with eac3to) I agree with removing the others, otherwise don't.
If there is no chance to get libavcodec as perfect decoder I prefer to stay with 32fp decoders. At least I don't see they do that nonsense 32fp > 16int rounding. And thanks for 32fp for mp3 btw.
I fully agree with yesgrey and Qaq.

Rounding 32fp -> 16int is not just "not optimal", it's a straight forward violation of digital processing laws. Yes, ffmpeg is like that. And that is reason enough to not remove possibly better alternatives from ffdshow.

My opinion: Make libav default, if you want, but don't remove libdts/liba52, until the libav devs get their act together. Just to balance my (negatively sounding) comment, let me say here that IMHO libav is a *wonderful* open source project.

[yesgrey]

Let's end this flame before it even starts, shall we?
Agreed, but remember that was you who started it... ;)
Just keep the other decoders, it's as simple as that. Or is there any problem of having them inside ffdshow?

No, I don't want to (and won't) patch every ffdshow decoder, since that's what would be needed if you want to do it the right way.
Agreed. I also think that the problem should be handled by libavcodec authors, and not patched in ffdshow.

[Gleb Egorych]

I think that only libmad may be removed. liba52/libdts/libfaad2/libsamplerate in quality aspect are better than libav's ones.

About libav bugs: AAC decoder shows wrong bitrate, libfaad2 shows proper bitrate.

[STaRGaZeR]

What has happened to visual styles in recent builds? In Win7 no themes are applied to controls at all. Manifest missing/broken?

Can you narrow it to a specific rev?

And that is reason enough to not remove possibly better alternatives from ffdshow.

My opinion: Make libav default, if you want, but don't remove libdts/liba52, until the libav devs get their act together.

I don't base my decisions on possibility. You know that argument holds no water.

Just keep the other decoders, it's as simple as that. Or is there any problem of having them inside ffdshow?

Agreed. I also think that the problem should be handled by libavcodec authors, and not patched in ffdshow.

I don't see them as problems, I see them as redundant, since we have fully functional libavcodec decoders. And since they are redundant, there's no need to keep them. That's why I started this: to confirm the robustness of libavcodec in ffdshow, and act in consequence. Or do we remove the libavcodec decoders, since we have liba52, libdts, etc.? I don't think so ;)

And that's exactly the point. "Fix" it in ffmpeg, and all projects using ffmpeg will benefit for it.

About libav bugs: AAC decoder shows wrong bitrate, libfaad2 shows proper bitrate.

Unfixable, for the nth time. ffmpeg's AAC parser is needed for that, and it doesn't work even in LAV Audio. Also it doesn't affect decoding at all.

EDIT: I'll make it output "N/A" instead of 0 though.

[fastplayer]

Can you narrow it to a specific rev?
Oops, I'll take that back. It's just your build that's missing the MANIFEST file. IIRC, your previous test builds missed it, too.

[TheShadowRunner]

Regarding the "FLV4 decoding bug", reimar says it's a ffplay bug, not ffmpeg.. and now I wonder: ffplay = ffdshow?
http://roundup.ffmpeg.org/issue2620

[yesgrey]

I don't see them as problems, I see them as redundant, since we have fully functional libavcodec decoders.
You see them as redundant, but they aren't.

And that's exactly the point. "Fix" it in ffmpeg, and all projects using ffmpeg will benefit for it.
Unfortunately, if I remember correctly, its authors see it like you do, that there is no need to output as 32FP, even though all internal processing is performed using it. They simply round to 16 int.

I will not continue this discussion too. Besides, I'm not one of the devs, so my opinion doesn't really counts. Do what you want, and then I will decide what to use.

[madshi]

I don't base my decisions on possibility. You know that argument holds no water.
Well, I don't know for sure whether liba52 and libdts are true floating point decoders, but I think it's likely, since libav ac3/dts decoders are internally floating point, too. Anyway, you don't seem to have informed yourself properly whether liba52/libdts are better quality or not. So you are not in a good position to decide whether they can be removed.

From what I can see, up until now 4 people have voted against your suggestion to remove liba52/libdts, at least 2 of them being devs, and only 1 person (non-dev) so far seems to support your suggestion. So you should accept that you've been outvoted, at least so far.

That said, I very much appreciate you working on ffdshow. Thank you.

[STaRGaZeR]

Unfortunately, if I remember correctly, its authors see it like you do, that there is no need to output as 32FP, even though all internal processing is performed using it. They simply round to 16 int.

I never said there's no need for 32-bit output. In fact I said that when libavcodec outputs that, ffdshow will too, just like the MP1/2/3 decoder. Just in case you don't remember, it was me who changed it. You're just making things up. And I wonder why.

Well, I don't know for sure whether liba52 and libdts are true floating point decoders, but I think it's likely, since libav ac3/dts decoders are internally floating point, too. Anyway, you don't seem to have informed yourself properly whether liba52/libdts are better quality or not. So you are not in a good position to decide whether they can be removed.

From what I can see, up until now 4 people have voted against your suggestion to remove liba52/libdts, at least 2 of them being devs, and only 1 person (non-dev) so far seems to support your suggestion. So you should accept that you've been outvoted, at least so far.

That said, I very much appreciate you working on ffdshow. Thank you.

So let me get this straight. You, who uses liba52&co. only because it outputs 32-bit float, come here to tell me that I'm not in a good position to decide? You're just confirming what I said. No one here (including you and me) knows how they work internally. Also working in float or integer means nothing by itself to the final audio quality, and that's what matters. You shouldn't give a f*** about what it outputs, just how it sounds. And since the whole debate was started months ago by you and others I still haven't seen a single argument/opinion based on audio quality and not in output resolution, which is lame at best. Here's a hint: talk about audio quality instead of numbers, and then your suggestions will be taken into account. Your (and the others) whole argument comes down to "32 is better than 16", and that won't get you anywhere. EDIT: I just remembered something. Our beloved audio/video freak leeperry talked about it here (http://forum.doom9.org/showthread.php?p=1446603#post1446603). libdts sounds "metallic" compared to libavcodec according to him. Out of curiosity, what are your thoughts on this?

I'm having trouble with that sentence. 4 people: Qak, yesgrey, madshi, Gleb Egorych. You say 2 are devs. I see no devs in there. I see 2 placebo guys I know very well, and 2 guys that don't give any reason for anything, just like with the recent encoder removal. This is not a public poll, just in case you missed it. Also it doesn't matter where an opinion comes from, a dev or an idiot, the content is what matters.

And after I said I didn't want tl;dr posts, I'm finishing one of them for the exact same reason as always. Sigh. I see no reason to continue this conversation unless you provide something to backup your desire of not removing liba52/dts/faad/mad. Output resolution isn't one of them. Put up or shut up, as they say.

[STaRGaZeR]

Please — no need to overrate the troll ^_^

http://img687.imageshack.us/img687/2017/lookslikeanothercoolsto.jpg

Sorry for the OT guys, this is the continuation of a Doom10 thread :D

[JEEB]

Overall agreeing with STaRGaZeR here.

People should care if a decoder follows spec or not decoding-wise, instead of looking at some random int/float output setting. In case of at least AC3 and AAC my opinion is that the libav decoders would be at the very least on the level of the current outside decoder libraries if not better, as both have been worked on during the last year+ (The AAC one at the very least should be better, looking at its added and fixed features, which lead to the removal of libfaad from the ffmpeg supported outside libraries).

The DTS decoder has also been under at least some kind of development, although I haven't taken as deep look at it as with f.ex. AAC.

And if there are bugs, ffmpeg is actually an active project, and looking at how Jumpyshoes as well as elenril got their patches in I'd say it's no longer as impossible as it used to be to get your patches in if they make sense.

Of course, just taking a look at the spec, making sure that the decoder actually fails at it, and taking contact with the current maintainer of the given part of libavcodec is never a bad idea and isn't exactly impossible either, given the fact that even I have posted something on the ffmpeg mailing lists -- and gotten a response.

[madshi]

So let me get this straight. You, who uses liba52&co
Actually no. I do not use liba52. I use libavcodec, patched to floating point output.

come here to tell me that I'm not in a good position to decide?
Exactly. You plan to remove a codec without knowing anything about how it compares quality wise. That's blind behaviour.

No one here (including you and me) knows how they work internally.
Actually I just checked out the liba52 source code and it *DOES* decode to full floating point. So it is definitely better quality than (unpatched) ffmpeg/libavcodec. QED.

Output resolution isn't one of them.
Output resolution was never the problem. The problem is raping the audio data by skipping the required dithering and thus introducing measurable and (with good equipment) audible quantization noise. Which is exactly what (unpatched) libavcodec is doing.

Put up or shut up, as they say.
I just did. Which would have been your job, btw, before making decisions on which decoders you remove.

People should care if a decoder follows spec or not decoding-wise
libavcodec violates fundamental audio processing laws, liba52 does not.

[Qaq]

Personally, I don't really care, I already have what I want. I use bitstream under Win7 and under XP I build a chain like this: ffdshow decoder (32fp) > ffdshow output (32fp) > ReClock processing: resampling (32fp AFAIR), volume attenuation (53fp), final stage rounding (24 padded to 32int) > Kernel Streaming. Do I see any sense in 32fp > 16int > 32fp? No. It's stupid and should be fixed by someone who is in right mind. Too bad we lost albain. He is never used to play a *boss* or something.

[Reimar]

Do I see any sense in 32fp > 16int > 32fp? No. It's stupid and should be fixed by someone who is in right mind.

Yes it is. Which is why there is unlikely to be resistance to it on principle in FFmpeg. However if someone just rips out the conversion it's likely to be not very welcome. The 32fp -> 16int conversion is very often needed (most sound cards do not support anything else) and on older or at least some ARM systems it can be _very_ slow, doing it in the decoder allows some tricks to make it faster.
As long as any advanced processing is still in 32fp, this conversion costs rather little in quality, and in performance only on systems that can easily afford it. If it's an either-or decision the performance advantage on systems that need it is what makes the current solution win.
That said, I do not think it would be that had to make libavcodec support both, it just needs someone who considers it worth the effort to do it.

[madshi]

A couple of years ago I tried getting patches in to allow floating point output via #define. But my patches were declined with the argument that the audio pipeline would "soon" be rewritten, anyway. Well, maybe I should try again now... :)

What did happen to albain, btw?

[Qaq]

The 32fp -> 16int conversion is very often needed (most sound cards do not support anything else)
Yes, but at final stage, right? That's the point.
.. and on older or at least some ARM systems it can be _very_ slow, doing it in the decoder allows some tricks to make it faster.
Yes, but user can use some old software for older systems, right? User should has a choice - that's the point. And now situation comes to that users with older systems will be using new (16int) software and users with newer systems will be using old (32fp) software. Good choice, yeah. I can't call it progress.
As long as any advanced processing is still in 32fp, this conversion costs rather little in quality, and in performance only on systems that can easily afford it.
Imagine how many parts of whole audio chain have their *little compromises*. Isn't it the reason of that crap at final stage?

[clsid]

liba52/libdts/libfaad will only be removed once libavcodec becomes superior. That includes having 32fp support.

@madshi,
Can you send me your ffmpeg patches for 32fp ac3/dts (and possibly other formats)?

[madshi]

Thanks, clsid.

You can find the patches I'm using in the "eac3to\legal stuff\ffmpeg\compiling" folder. You should probably ignore the mlp patches. Important are mainly the dca and ac3dec patches.

[yesgrey]

I never said there's no need for 32-bit output. In fact I said that when libavcodec outputs that, ffdshow will too, just like the MP1/2/3 decoder. Just in case you don't remember, it was me who changed it. You're just making things up. And I wonder why.
If you also agree that it might be useful outputting with the same bit depth used on internal processing, why insisting in removing the other decoders? It was you, not me, who said they were redundant, and I only consider something to be redundant when there is another one which does exactly the same, and that's not what's happening.
Sorry if put words on you that weren't exact. I have no hidden agenda, just gave my opinion.

Well, maybe I should try again now...
Please do. Maybe you have better luck now. ;)

[JEEB]

A couple of years ago I tried getting patches in to allow floating point output via #define. But my patches were declined with the argument that the audio pipeline would "soon" be rewritten, anyway. Well, maybe I should try again now... :)
Please do, the ffmpeg process was streamlined and I'd bet they'd be more realistic about their current progress on many accounts.

Also, personally I would feel that run-time code path selection would be the better alternative than #defining stuff in the source files before building... Although I guess that would add some "unneeded" fluff into the whole thing.

Also, ever since I saw this audiophile herp derp on these threads I've been thinking, don't the specifications for audio decoders specify what is right and what is wrong to do with an encoded audio stream? Or am I one of those happy fellows who has gotten used to standards like H.264 that standardize the decoder to be bit-exact? All this "You should have X instead of Y to have better output" stuff just doesn't make muchos sense, coming from such a background.

And if it's something like dithering post-decoding, I don't really get why it can't be decoded with int to get the exact output that was meant to be gotten (given if the specification specifies this -- and I would guess it actually might specify it given the fact that float math's results depend highly on the system/architecture etc.), and then converted to float with dithering for output/filtering/whatever your cat wants to do to it.

But maybe lossy audio codecs just make less sense than I thought.

[SamuriHL]

What did happen to albain, btw?

That's a damn good question. :(

[madshi]

Please do, the ffmpeg process was streamlined and I'd bet they'd be more realistic about their current progress on many accounts.
Ok, will put that on my to do list.

Also, ever since I saw this audiophile herp derp on these threads I've been thinking, don't the specifications for audio decoders specify what is right and what is wrong to do with an encoded audio stream? Or am I one of those happy fellows who has gotten used to standards like H.264 that standardize the decoder to be bit-exact? All this "You should have X instead of Y to have better output" stuff just doesn't make muchos sense, coming from such a background.
Video codecs work *very* differently compared to lossy audio codecs. Video codecs use motion estimation to try to minimize the difference between video frames and then store the motion vectors together with changed pixels (well, very much simplified). Lossy audio compression is worlds away from that in technical implementation. There's no such thing as "motion estimation" for audio compression.

Audio decoders are standardized in a way, too. However, what you need to be aware of is that standards only tell us how to decode video and audio. They don't tell us how to do post processing. E.g. does the h264 standard tell you how to upsample chroma from 4:2:0 to 4:4:4? No, it doesn't, that's outside of the decoder, it's a post process. Does the h264 standard tell you how to downconvert 8bit per component video to 7bit per component video? Nope, it doesn't, because that's got nothing to do with encoding/decoding. The same thing applies to audio: How you post process the audio got nothing to do with decoding. So it's not specified in the codec specs. You can downconvert 24bit audio to 4bit, if you like. You shouldn't do that, but you can. So do you expect the decoder specs to contain information on how to downconvert 24bit audio to 4bit?

And if it's something like dithering post-decoding, I don't really get why it can't be decoded with int to get the exact output that was meant to be gotten (given if the specification specifies this -- and I would guess it actually might specify it given the fact that float math's results depend highly on the system/architecture etc.), and then converted to float with dithering for output/filtering/whatever your cat wants to do to it.

But maybe lossy audio codecs just make less sense than I thought.
AC3 and DTS do not compress in time domain. They do not compress PCM audio. They convert PCM to frequency domain, IIRC, and then compress the data in the frequency domain. When decompressing, the frequency data needs to be converted back to PCM, which usually results in floating point data. If you look at the AC3 and DTS decoder source code, you'll notice that it natively decodes to floating point data.

So the final question is: *After* the decoders have completed their task, what further processing is done to the decoded audio data? libavcodec and liba52/libdts do not differ so much in how they decode. They differ on how they post process. libavcodec violates processing laws by forcedly rounding down to 16bit integer. liba52 doesn't do that, it outputs the decoding result untouched. So the problem with libavcodec is not the decoding itself, it's the post processing, which can't be turned off. Not even via compiler switches or #defines.

[JEEB]

...So the problem with libavcodec is not the decoding itself, it's the post processing, which can't be turned off. Not even via compiler switches or #defines.
Finally, the first person to actually make sense for me in this. So the problem really isn't in the decoding itself, but, as I was already kind of thinking, the output a post processor gives. Thank you for making this clear for me, as the multiple levels of audio hipsters have made this problem look like an actual decoder problem, which of course makes me go wee on the "How much does this make sense" scale.

+1 reason for ffmpeg not to reject a patch that lets it handle more than one type of output. Or something that would just let the calling application get the decoded output and do whatever it wants to the output, so the next generation of audio hipsters can get their float64 or float128 instead without concerning the ffmpeg project itself (*grin*).

[Kovensky]

A couple of years ago I tried getting patches in to allow floating point output via #define.
From AVCodecContext's definition:

/**
* audio sample format
* - encoding: Set by user.
* - decoding: Set by libavcodec.
*/
enum AVSampleFormat sample_fmt; ///< sample format
A better approach for a patch would be to allow the user to set sample_fmt for decoding too. There are several audio functions in the API that deal with int16_t* btw, but that does *not* mean they only return int16_t.

The audio decoding API will soon be changed anyway to return AVFrames instead of the user having to manage buffers.

[madshi]

A better approach for a patch would be to allow the user to set sample_fmt for decoding too.
Yes, that would be nice.

The audio decoding API will soon be changed anyway
Deja vu. I've been told that 3 years ago... :p

[Kovensky]

Deja vu. I've been told that 3 years ago... :p
This time there are actual patches :)

EDIT: and this wouldn't affect or block any possible patches you make for sample format; it's just an user interface change not internal ffmpeg stuff

[madshi]

Well, that sounds good... :)

[ranpha]

libdts at least should not be removed, until libavcodec can decode DTS core in DTS-HD MA track properly. My test MKVs files with DTS-HD MA tracks will not start playing, if I were to use libavcodec to play the core audio track, but with libdts playback works perfectly.

[STaRGaZeR]

If you also agree that it might be useful outputting with the same bit depth used on internal processing, why insisting in removing the other decoders? It was you, not me, who said they were redundant, and I only consider something to be redundant when there is another one which does exactly the same, and that's not what's happening.
Sorry if put words on you that weren't exact. I have no hidden agenda, just gave my opinion.

Because a decoder is a lot more than what it outputs. Accepting this, the decoders are redundant. But it seems that this fact is not acknowledged here. As you can see there's still not a single argument against the removal based on audio quality or features supported, the ultimate goals of an audio decoder.

Since clsid is with the placebo guys, I'm outta this debate. At least I hope that the guy in charge of the patching does it right: by patching AAC, AC3, DTS, Vorbis, WMA and Nellymoser. That's another thing I've noticed, the guys complaining only complain because it affects themselves directly. ffdshow is a lot more than an AC3/DTS decoder for playing your DVDs. I don't remember anyone complaining when tremor (32-bit int output) was removed, leaving only libavcodec (16-bit int). A word exist for this: hipocrisy.

Actually I just checked out the liba52 source code and it *DOES* decode to full floating point. So it is definitely better quality than (unpatched) ffmpeg/libavcodec. QED.

As I said, working in float or integer, by itself, means *NOTHING* to the final audio quality. QED.

And as always, you don't answer the key questions, only what's best for your interests. I will do the same with you from now on.

AC3 and DTS do not compress in time domain. They do not compress PCM audio. They convert PCM to frequency domain, IIRC, and then compress the data in the frequency domain. When decompressing, the frequency data needs to be converted back to PCM, which usually results in floating point data. If you look at the AC3 and DTS decoder source code, you'll notice that it natively decodes to floating point data.

You're wrong. DTS doesn't work in frequency domain. DTS compress in time domain, filtered PCM audio as ADPCM or APCM. For details, see here: http://www.mp3-tech.org/programmer/docs/dts_whitepaper.pdf, pages 5 and 7. You don't seem to have informed yourself properly, and at the same time you like to judge others. I won't comment on that, it's pretty self explanatory.

libdts at least should not be removed, until libavcodec can decode DTS core in DTS-HD MA track properly. My test MKVs files with DTS-HD MA tracks will not start playing, if I were to use libavcodec to play the core audio track, but with libdts playback works perfectly.

I've fixed that in my last build. Search a few pages back for it. And report if it works for you too!

[yesgrey]

At least I hope that the guy in charge of the patching does it right: by patching AAC, AC3, DTS, Vorbis, WMA and Nellymoser.
Agreed.

I don't remember anyone complaining when tremor (32-bit int output) was removed, leaving only libavcodec (16-bit int). A word exist for this: hipocrisy.
There is another word for that (3 words to be exact): "lack of knowledge"

I don't know every single feature of ffdshow. It contains a lot more decoders than I will ever need, so it's natural for me to complain only about the parts that I know.