ffdshow tryouts project: Discussion & Development

[madshi]

Originally Posted by yesgrey

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.

Originally Posted by 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.

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]

Originally Posted by STaRGaZeR

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?

Originally Posted by STaRGaZeR

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]

Originally Posted by fastplayer

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?

Originally Posted by madshi

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.

Originally Posted by yesgrey

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.

Originally Posted by Gleb Egorych

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]

Originally Posted by STaRGaZeR

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]

Originally Posted by STaRGaZeR

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.

Originally Posted by STaRGaZeR

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]

Originally Posted by STaRGaZeR

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]

Originally Posted by yesgrey

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.

Originally Posted by madshi

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

Originally Posted by Midzuki

Please — no need to overrate the troll ^_^

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

[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]

Originally Posted by STaRGaZeR

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.

Originally Posted by STaRGaZeR

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.

Originally Posted by STaRGaZeR

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.

Originally Posted by STaRGaZeR

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.

Originally Posted by STaRGaZeR

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.

Originally Posted by JEEB

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]

Originally Posted by Qaq

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]

Originally Posted by Reimar

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]

Originally Posted by STaRGaZeR

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.

Originally Posted by madshi

Well, maybe I should try again now...

Please do. Maybe you have better luck now.

[JEEB]

Originally Posted by 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...

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.