ffdshow tryouts project: Discussion & Development

[madshi]

As you can see there's still not a single argument against the removal based on audio quality
Oh yes, there is, you're just choosing to ignore it.

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.
Huh? I can only comment on things I know anything about. I've no clue what "tremor" is, never heard of it.

As I said, working in float or integer, by itself, means *NOTHING* to the final audio quality. QED.
Violating audio processing laws, resulting in measurable addition of quantization noise, does very much mean something to the final audio quality.

You're wrong. DTS doesn't work in frequency domain. DTS compress in time domain, filtered PCM audio as ADPCM or APCM.
Ok, didn't know that. But it doesn't change the fact that the libavcodec DTS decoder natively produces floating point samples. Rounding them to 16bit integer samples introduces quantization noise.

[STaRGaZeR]

Oh yes, there is, you're just choosing to ignore it.

Maybe I'm missing something, but I don't remember you saying anywhere that liba52, libdts, libfaad or libmad sound better than unpatched libavcodec? Can you point me to it? All I read is "32 to 16 sucks, adds shit to the decoded PCM". While this is 100% true, you're comparing patched libavcodec with unpatched libavcodec. And the debate is not there.

Huh? I can only comment on things I know anything about. I've no clue what "tremor" is, never heard of it.

That's the problem, there's a lot of things you don't know about ffdshow and stuff in general, yet you're here pretending to be some kind of I-know-it-all guy. Just to put you in perspective: it was the same situation, nobody objected. tremor sounded like crap compared to libavcodec, despite outputting 32-bit int samples.

Violating audio processing laws, resulting in measurable addition of quantization noise, does very much mean something to the final audio quality.

Aha. Since I'm sure you're not talking out of your a** when you say it does very much mean something to the final audio quality, where's that audio quality comparison between liba52/dts/faad/mad and unpatched libavcodec? Where are the blind tests?

Ok, didn't know that. But it doesn't change the fact that the libavcodec DTS decoder natively produces floating point samples. Rounding them to 16bit integer samples introduces quantization noise.

Read the first quote: the debate is not here.

[madshi]

All I read is "32 to 16 sucks, adds shit to the decoded PCM".
Not really. If libavcodec *dithered* down to 16bit, I would agree with removing liba52 and libdts. The problem is not doing a conversion from 32bit float to 16bit integer. That's fine with me. The problem is that libav is doing the conversion in a bad way.

That's the problem, there's a lot of things you don't know about ffdshow and stuff in general, yet you're here pretending to be some kind of I-know-it-all guy.
I don't "know it all". But I do know some things, one of them is how audio and video data processing should be done. And I know that libav's conversion from 32fp to 16int is done in a bad way, which adds quantization noise.

Aha. Since I'm sure you're not talking out of your a** when you say it does very much mean something to the final audio quality, where's that audio quality comparison between liba52/dts/faad/mad and unpatched libavcodec? Where are the blind tests?
I don't trust in blind tests I haven't faked myself.

I think you're misunderstanding me a bit: I do not explicitly claim that liba52 sounds noticeably better than libavcodec. I don't know that for a fact. *However*, there's a known problem with libavcodec decoding quality, while there is no known problem with liba52 decoding quality. This alone is IMHO a key argument to not remove liba52 until the libavcodec problem is fixed. I don't see any sense in removing a decoder which has no known audio quality problems in favor of another decoder which does have known audio quality problems. And that's basically what I was trying to say from the start.

[fastplayer]

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
Just a bump in case people missed it. Please test! :)

[clsid]

Here is a test build with fp32 output for libavcodec AC3 and DTS:
http://www.sendspace.com/file/lrjn02

[STaRGaZeR]

Not really. If libavcodec *dithered* down to 16bit, I would agree with removing liba52 and libdts. The problem is not doing a conversion from 32bit float to 16bit integer. That's fine with me. The problem is that libav is doing the conversion in a bad way.

I know that. But we're not talking about ifs. I'll paste you here the question you didn't selectively answer, since you accused me of something I didn't do, and it's also very relevant to this debate:

Maybe I'm missing something, but I don't remember you saying anywhere that liba52, libdts, libfaad or libmad sound better than unpatched libavcodec? Can you point me to it?

Thanks.

I don't "know it all". But I do know some things, one of them is how audio and video data processing should be done. And I know that libav's conversion from 32fp to 16int is done in a bad way, which adds quantization noise.

I know that too. There's no need to repeat it in every post. However, thanks.

I don't trust in blind tests I haven't faked myself.

I think you're misunderstanding me a bit: I do not explicitly claim that liba52 sounds noticeably better than libavcodec. I don't know that for a fact. *However*, there's a known problem with libavcodec decoding quality, while there is no known problem with liba52 decoding quality. This alone is IMHO a key argument to not remove liba52 until the libavcodec problem is fixed. I don't see any sense in removing a decoder which has no known audio quality problems in favor of another decoder which does have known audio quality problems. And that's basically what I was trying to say from the start.

Just in case it wasn't clear enough already, I'll tell you again what I think it's THE flaw in your argument: the bolded part. Nobody here should be thinking about what happens internally in ffdshow, you should only care about the final result. You base your claim in problems you can't hear, in numbers you can't hear. Well, let's rephrase that a bit: in stuff I can't hear. I'm human, I have limitations. A lot of them. I'm asking you to prove me wrong since the very beginning. You're constantly ignoring that simple request, for example when I ask you for blind tests, you talk about faking and all that. Do we trust the numbers, or do we trust our ears? This is not an academic signal processing exercise. Prove me wrong on the field. I know what should be done from the academic point of view, and I'll apply it once it's done in the proper place to do it: the ffmpeg repository. Until then, I'll trust my ears unless someone comes with an audio quality objection (based on his or someone's ears, of course).

And just for the record: the libs removal was in no way inmediate. Time is needed to fix any possible bugs in ffdshow's implementation of libavcodec. You, in the meantime, should try to get the ffmpeg stuff done. That's where you excell, and with the new ffmpeg's direction I see it doable. Go for it.

[STaRGaZeR]

Here is a test build with fp32 output for libavcodec AC3 and DTS:
http://www.sendspace.com/file/lrjn02

Works just fine here.

[pirlouy]

You base your claim in problems you can't hear, in numbers you can't hear. Well, let's rephrase that a bit: in stuff I can't hear. I'm human, I have limitations.

I'm a noob, so you can ignore this, but on Hydrogenaudio forum (that I dislike because too much harsh), they ban you if you base things on what you hear, and not on numbers, graph,etc.

In my case, I don't hear any difference between sources in 16 bits, 24 bits, 44100Hz, 96000Hz etc.

But even if it's boring for you, it's a good thing that there is a discussion. Better now than later.

[Astrophizz]

I'm a noob, so you can ignore this, but on Hydrogenaudio forum (that I dislike because too much harsh), they ban you if you base things on what you hear, and not on numbers, graph,etc.

AFAIK on Hydrogenaudio they actually prefer if you can provide ABX results for your comparisons. That's based on what you hear and not on numbers. But that's for more minute differences than 32 bit downconverted with and without dithering, for which they have an agreed upon stance (the same as madshi's) based on past ABX tests. That's also why they don't like certain people who post here on Doom9 that use company press releases as evidence for superior audio quality and don't provide ABX comparisons for their claims that (eg.) upsampling 44.1 kHz to 96 kHz makes audio sound better.

[Gleb Egorych]

AAC, AC3, DTS, Vorbis, WMA and Nellymoser
E-AC3 as well.
hipocrisy
I guess very few people need Vorbis in ffdshow. In fact only AAC, (E-)AC3 and DTS decoders need to be patched. Everything else either work as it should or simply not used. BTW I don't know who needs 12 (twelve) software deinterlacers (and +1 HW) in ffdshow.

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.
I've read that paper. DTS encoder clearly works in frequency domain. To be exact, it operates in joint time-frequency domain, for every given time-window it decomposes input signal into frequency sub-bands and then works with that decomposition.

Here is a test build with fp32 output for libavcodec AC3 and DTS
Thanks, clsid

[madshi]

Here is a test build with fp32 output for libavcodec AC3 and DTS:
http://www.sendspace.com/file/lrjn02
Wonderful, thanks a bunch!!

I'm asking you to prove me wrong since the very beginning. You're constantly ignoring that simple request, for example when I ask you for blind tests, you talk about faking and all that. Do we trust the numbers, or do we trust our ears? This is not an academic signal processing exercise. Prove me wrong on the field.
I've tried to prove you wrong, you just don't like my way of doing that. You don't seem to like technical/scientific eplxanations. You don't seem to like quotes of well known processing laws and mentioning of measurements. I'm not sure how you expect me to prove you wrong instead. If I did a blind test myself and reported the results here, would you believe my subjective test results? Probably not, why would you. I wouldn't trust your subjective blind test results, either. There is no "prove" by using our ears, unless we do a large scale study by letting hundreds of people vote in a blind test. Do you want to organize such an event? I don't, I have so many more important things to do. Furthermore, even if we did organize such an event, there might still be discussions like "oh, with different audio clips the results might have been different", or "most users probably have too low quality hardware to hear a difference", or "most users don't really know what to listen for" etc etc...

Anyway, this is all moot, if clsid's patch makes it into SVN. Then we can truely get rid of liba52 and libdts!

[yesgrey]

Here is a test build with fp32 output for libavcodec AC3 and DTS
Both AC3 and DTS are working perfectly.

Thanks for adding the patches, and specially for bringing some reasonability and help ending this sterile discussion. :)

[clsid]

I found a DTS bug (unrelated to float output). Switching from a 1536kbps track to a 768kbps track causes the video to play at double speed. I suspect it is a bug in the parser.
sample file (http://www.cccp-project.net/beta/test_files/%5BCCCP%5D_Mega_Audio_Test.mkv)
Using Haali as splitter.

[ranpha]

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

Just tested it, the core DTS in DTS-HD MA tracks now works fine.

[fastplayer]

I found a DTS bug (unrelated to float output). Switching from a 1536kbps track to a 768kbps track causes the video to play at double speed. I suspect it is a bug in the parser.
sample file (http://www.cccp-project.net/beta/test_files/%5BCCCP%5D_Mega_Audio_Test.mkv)
Using Haali as splitter.
Confirmed. LAVSplitter handles it fine, though.

[Reimar]

+1 reason for ffmpeg not to reject a patch that lets it handle more than one type of output.

They won't. But they will most likely reject a patch that just removes the current method, because only outputting float is worse in some ways than only outputting float (unless you do some additional changes to make sure it is not).
They most likely will reject a lazy-way patch that uses a compile-time define, it will cause compatibility issues (e.g. for Linux systems where all programs use the same binary).
I do not really mean to discuss pro or contra (this has been done beyond the point where it is useful), I just want to make sure that everyone understands very clearly that just because some of you think this is incredibly important the FFmpeg developers will not accept a horribly crappy patch. And there and only there is where the problem lies.
And concerning audio API changes: It actually has changed 2 times already, and only since the second change is float output even supported.
I think a third change is pending that probably should make things work a bit better still, but I didn't really follow it.

[Gleb Egorych]

Changes (3769-3771):
* Updated FFmpeg. Libavcodec AC3/E-AC3/DTS decoders now output floating point data.;
* Float output for libavcodec AAC decoder;
* Float output for libavcodec Vorbis decoder.
Thanks, clsid!

I found a DTS bug (unrelated to float output). Switching from a 1536kbps track to a 768kbps track causes the video to play at double speed. I suspect it is a bug in the parser.
sample file (http://www.cccp-project.net/beta/test_files/%5BCCCP%5D_Mega_Audio_Test.mkv)
Using Haali as splitter.
Have this too. Haali 1.11.96.14. libdts is OK.

[fastplayer]

@Devs:
Can you take a look at this and commit if it's OK?
Updated Japanese translation and iss (http://sourceforge.net/tracker/index.php?func=detail&aid=3199504&group_id=173941&atid=867362)

[Andy o]

Hi, I'm having this problem with PGS subs in mkvs. These are straight blu-ray rips. It usually shows with anime, because the characters on-screen are subbed, at the same time that the characters' voices are being subbed too.

http://photos.smugmug.com/photos/1208599178_inGYm-O.jpg

As you can see the subs are cut off. If I switch to MPC-HC's sub renderer, I can only see one or the other.

This is using 32-bit versions of MPC-HC 1.5.1.2959 with EVR-Sync (also happens with madVR), and ffdshow 3768. I have an ATI 5770 on Win 7 64-bit if that matters.

[Sarasa]

I found a DTS bug (unrelated to float output). Switching from a 1536kbps track to a 768kbps track causes the video to play at double speed. I suspect it is a bug in the parser.
sample file (http://www.cccp-project.net/beta/test_files/%5BCCCP%5D_Mega_Audio_Test.mkv)
Using Haali as splitter.
Same bug here, no prob with libdts

[STaRGaZeR]

I'm a noob, so you can ignore this, but on Hydrogenaudio forum (that I dislike because too much harsh), they ban you if you base things on what you hear, and not on numbers, graph,etc.

In my case, I don't hear any difference between sources in 16 bits, 24 bits, 44100Hz, 96000Hz etc.

But even if it's boring for you, it's a good thing that there is a discussion. Better now than later.

Since you know how Hydrogenaudio is, you can clearly see that this forum has been progressively becoming like HA for a good number of months already: full of pedantic individuals that only care about themselves. Don't worry, nobody here can hear the difference. It's just placebo and stupidity. Plus, the debate wasn't there to begin with.

E-AC3 as well.

I guess very few people need Vorbis in ffdshow. In fact only AAC, (E-)AC3 and DTS decoders need to be patched. Everything else either work as it should or simply not used. BTW I don't know who needs 12 (twelve) software deinterlacers (and +1 HW) in ffdshow.


I've read that paper. DTS encoder clearly works in frequency domain. To be exact, it operates in joint time-frequency domain, for every given time-window it decomposes input signal into frequency sub-bands and then works with that decomposition.

AC3 and E-AC3 are the same decoder.

You guess wrong. And I already proposed a long time ago to remove some of those deinterlacers, since a lot of them have the same quality/speed ratio. The devs didn't want to do that, and I fully respect that decision.

If you came to that conclusion, you should read the paper again. There's not a single transform to frequency domain in the process. You divide your initial PCM stream in 32 sub-bands by filtering it, and each band is still PCM audio (time domain). Then you compress them differently based on psychoacoustic analyses.

Anyway, this is all moot, if clsid's patch makes it into SVN. Then we can truely get rid of liba52 and libdts!

Yes, it's all moot now that you've achieved what you wanted, kissing some asses here and there and ignoring key questions, as always. Good job doing a half-ass job in ffdshow. Now we have a half-patched ffdshow and nobody willing to do it the right way. It's a pity others can't see the damage you and your kind are doing. Enjoy your 32-bit float output, I guess.

Oh yes, go ahead and remove the libs right now! The bugs are not important, since we have 32-bit output! Banana republic.

[avih]

...
Yes, it's all moot now that you've achieved what you wanted, kissing some asses here and there and ignoring key questions, as always. Good job doing a half-ass job in ffdshow. Now we have a half-patched ffdshow and nobody willing to do it the right way. It's a pity others can't see the damage you and your kind are doing. Enjoy your 32-bit float output, I guess.

Oh yes, go ahead and remove the libs right now! The bugs are not important, since we have 32-bit output! Banana republic.
No need for sarcasm. Make your point, and stop there please.
Consider it a warning.
Thanks.

[TheShadowRunner]

They won't. But they will most likely reject a patch that just removes the current method, because only outputting float is worse in some ways than only outputting float (unless you do some additional changes to make sure it is not).
<snip>
I think a third change is pending that probably should make things work a bit better still, but I didn't really follow it.

Oh Reimar, unrelated but could you elaborate on this?
Regarding the "FLV4 decoding bug", you say it's a ffplay bug, not ffmpeg.. and now I wonder: ffplay = ffdshow?
http://roundup.ffmpeg.org/issue2620
Thanks,

TSR

[arestarh]

Updated Russian translation for ffdshow:
http://www.mediafire.com/?cjrr610n2z2a2r0

[clsid]

And I already proposed a long time ago to remove some of those deinterlacers, since a lot of them have the same quality/speed ratio. The devs didn't want to do that, and I fully respect that decision.I support any effort from anyone that wants to help make ffdshow better and/or cleaner. If there are deinterlacers that can be considered inferior or redundant, then they could be removed. I suggest starting a new topic to discuss the deinterlacers of ffdshow. Then users who play a lot of interlaced material can explain which algorithms they prefer and why. Given enough feedback we can decide if there are any candidates for removal.

Oh yes, go ahead and remove the libs right now! The bugs are not important, since we have 32-bit output! Banana republic.Calm down ;) Nothing will be removed anytime soon, certainly not if there are good reasons (bugs, performance, quality) to prefer any of the external libs over libavcodec.
Instead of getting lost in technical discussions, let just focus on bugs and the actual experiences when using the various decoders. In the end that is what matters to the users.

[BelowSky]

I hope I'm not interrupting something here. But FFDShow can't play (some) Real Cook Audio with a sample rate at 22KHz.
I can play them with FFplay and Real Player Alternative without any problem.

http://samples.mplayerhq.hu/real/AC-cook/Vetenskap_extramaterial_2005-10-31_142936.rm
http://samples.mplayerhq.hu/real/AC-cook/Vetenskap_mosbricka_2005-03-02_105820.rm

[STaRGaZeR]

I support any effort from anyone that wants to help make ffdshow better and/or cleaner.

These patches don't make ffdshow better nor cleaner. They contribute to the mess it already is.

Nothing will be removed anytime soon, certainly not if there are good reasons (bugs, performance, quality) to prefer any of the external libs over libavcodec.
Instead of getting lost in technical discussions, let just focus on bugs and the actual experiences when using the various decoders. In the end that is what matters to the users.

I was focusing on bugs and the actual experiences of users instead of papers and numbers without any kind of meaning since the very beginning. See my initial post. The usual whiners convinced you of something that doesn't benefit ffdshow in any way. If you, the leader of ffdshow, who has the final word on everything, didn't see this simple fact as your words and actions suggest, we're screwed.

[clsid]

The fact that most people won't hear any difference (including myself), doesn't mean the patch is wrong or useless. The FFmpeg developers even want to eventually make their decoders output in the native data format. But they first need to extend the rest of their audio pipeline with more functionality. API changes like that are very slow in FFmpeg. That extra functionality is not needed by ffdshow, so there is no need to wait for that. The used patch is sufficient.

[STaRGaZeR]

After all this BS it seems you got it wrong too, like everyone else. What the patch does is the right thing to do, we all agree on that. The way it does it isn't. Good luck waiting for anything related to ffmpeg now, you're going to need it.

[roytam1]

E-AC3 as well.

I guess very few people need Vorbis in ffdshow. In fact only AAC, (E-)AC3 and DTS decoders need to be patched. Everything else either work as it should or simply not used. BTW I don't know who needs 12 (twelve) software deinterlacers (and +1 HW) in ffdshow.


I've read that paper. DTS encoder clearly works in frequency domain. To be exact, it operates in joint time-frequency domain, for every given time-window it decomposes input signal into frequency sub-bands and then works with that decomposition.


Thanks, clsid

the audio part in Google WebM format uses Vorbis.

[madshi]

FWIW, I've tried yesterday to get a patch committed to ffmpeg to enable optional float output to the AC3 and E-AC3 decoders. So far I've not succeeded. However, as a reaction Michael Niedermayer actually suggested to change all native float decoders to always output float instead of int16 *right now*. Unfortunately he's not the leader, anymore, and some other guys seem to prefer to wait (for a sample conversion framework to be implemented/completed) before implementing such a change. Not sure yet how it will play out. But it looks like everyone agrees that ultimately ffmpeg native float decoders (ac3, e-ac3, dts, aac, vorbis, wma, ...) should output float. It's only a matter of time when this gets implemented. If we have good luck, it can happen today. If we have bad luck, the change can be delayed another few months (or years). Anyway, I've tried.

@STaRGaZeR, I don't really understand what problem you have now. The patch clsid implemented seems to work well, it has no theoretical or practical disavantages. It does improve audio quality. Maybe the improvement is not audible to your ears on your hardware but that doesn't mean nobody can hear a difference. Your ear/hardware alone can not be the judge for the rest of the world. Furthermore the patch does what ffmpeg will do in the (hopefully near) future, anyway. And implementing the patch in ffdshow has *ZERO* effect on ffmpeg/libav. Just because ffdshow implemented such a patch does not mean that the "real" fix in ffmpeg/libav will be delayed even one second. So there is no damage done by implementing the patch in ffdshow now.

(Thanks to Reimar for his constructive way of posting in the ffmpeg-devel mailing list.)

[STaRGaZeR]

If ffmpeg outputting float is so inmediate, there should have been no commits to ffdshow. If this is in no way inmediate as almost everything in ffmpeg, putting even more custom stuff/patches/workarounds (call it what you want) in ffdshow that it already has is the number one thing you should not do.

The quality argument wasn't to justify float vs integer, get it already ffs.

[fastplayer]

Instead of reducing the number of /* ffdshow custom code */ comments in the code, we have now added half a dozen of these "things"... IMO the goal should be to stay as close as possible to ffmpeg. If they think that 16-bit int is a reasonable trade-off (http://forum.doom9.org/showthread.php?p=1482627#post1482627) between quality and performance, then I don't see why we should deviate from that position. Most certainly not to please a vocal minority...

[madshi]

IMO the goal should be to stay as close as possible to ffmpeg. If they think that 16-bit int is a reasonable trade-off (http://forum.doom9.org/showthread.php?p=1482627#post1482627) between quality and performance, then I don't see why we should deviate from that position.
They do plan to change to float output as soon as possible. The only reason why they haven't done that yet is that they want to do some other things first, as usual. So the patch clsid added does not deviate from ffmpeg's position, it actually realizes ffmpeg's ultimate goal for how the decoders should behave.

Most certainly not to please a vocal minority...
If you browse through the last few pages you'll find that STaRGaZeR and you seem to be the vocal minority.

Ok, I'm out of this discussion now.

[Wilbert]

@STaRGaZeR, I don't really understand what problem you have now. The patch clsid implemented seems to work well, it has no theoretical or practical disavantages. It does improve audio quality. Maybe the improvement is not audible to your ears on your hardware but that doesn't mean nobody can hear a difference. Your ear/hardware alone can not be the judge for the rest of the world. Furthermore the patch does what ffmpeg will do in the (hopefully near) future, anyway. And implementing the patch in ffdshow has *ZERO* effect on ffmpeg/libav. Just because ffdshow implemented such a patch does not mean that the "real" fix in ffmpeg/libav will be delayed even one second. So there is no damage done by implementing the patch in ffdshow now.
I have been trying to follow the last few pages in this thread. Does that mean we can open our audio as float in AviSynth using ffdshow and process it from there? That would be great.

[yesgrey]

Does that mean we can open our audio as float in AviSynth using ffdshow and process it from there? That would be great.
Yes. Welcome to the "vocal minority". :D

[LigH]

:D

Do you remember why BeSweet was developed?

Besides joining decoder and encoder DLLs, processing the audio in floating-point format for optimal quality was one of those reasons.

This is all just a little bit of history repeating... (http://www.youtube.com/watch?v=a-a5HTLDMWc)

[Wilbert]

@Wilbert, I'm no AviSynth expert, but if you can generally use ffdshow output as AviSnyth input then yet, that should work just fine, and you should get full floating point quality directly from the libav decoders, passed through ffdshow. But I'm wondering: Is there no direct AviSynth audio decoder available based on libav?

Yes, ffmpegsource (http://forum.doom9.org/showthread.php?t=127037) (i forgot about that one). I will ask over there.

[clsid]

Instead of reducing the number of /* ffdshow custom code */ comments in the code, we have now added half a dozen of these "things"... IMO the goal should be to stay as close as possible to ffmpeg. If they think that 16-bit int is a reasonable trade-off (http://forum.doom9.org/showthread.php?p=1482627#post1482627) between quality and performance, then I don't see why we should deviate from that position. Most certainly not to please a vocal minority...I agree that it is the overall goal to reduce the amount of custom code. But in this case it is just a small amount, and mostly just a few extra lines, so its easy to maintain (by me).

[STaRGaZeR]

They do plan to change to float output as soon as possible. The only reason why they haven't done that yet is that they want to do some other things first, as usual. So the patch clsid added does not deviate from ffmpeg's position, it actually realizes ffmpeg's ultimate goal for how the decoders should behave.

Yes, that's why you have been waiting 3 years, and complained loads of times because of that. Like here (http://forum.doom9.org/showthread.php?p=1482634#post1482634) and here (http://forum.doom9.org/showthread.php?p=1482670#post1482670). :stupid:

I agree that it is the overall goal to reduce the amount of custom code. But in this case it is just a small amount, and mostly just a few extra lines, so its easy to maintain (by me).

Have fun managing that custom code. I'm outta this ffdshow comedy.

[mark0077]

Hi guys, when using ffdshow video decoder with mpc-hc, when I right click on the player and choose "Filters" -> "ffdshow Video Decoder" -> I see audio information rather than video information. ie i'm watching a h264 mkv file atm and ffdshow video decoder submenu is showing me ac3 audio information... Is it something thats known about or easy to fix?

[nevcairiel]

Hi guys, when using ffdshow video decoder with mpc-hc, when I right click on the player and choose "Filters" -> "ffdshow Video Decoder" -> I see audio information rather than video information. ie i'm watching a h264 mkv file atm and ffdshow video decoder submenu is showing me ac3 audio information... Is it something thats known about or easy to fix?

I think its intended. I forgot why, but i remember asking ended in me being flamed for some reason.

[avih]

...
The quality argument wasn't to justify float vs integer, get it already ffs.
Calm down, and keep it that way please.

[clsid]

Hi guys, when using ffdshow video decoder with mpc-hc, when I right click on the player and choose "Filters" -> "ffdshow Video Decoder" -> I see audio information rather than video information. ie i'm watching a h264 mkv file atm and ffdshow video decoder submenu is showing me ac3 audio information... Is it something thats known about or easy to fix?That is the stream selection (for the splitter).

It could be a bug in the code that determines what should be shown in that context menu. Its shared code between audio/video decoder.

If it was intentional, I don't remember what the exact rationale was for it. Maybe albain can explain if he is still around.

[fastplayer]

If it was intentional, I don't remember what the exact rationale was for it. Maybe albain can explain if he is still around.
According (http://forum.doom9.org/showthread.php?p=1404103#post1404103) to albain, the missing video track info is a limitation of ffdshow.

[clsid]

That is true. But I wasn't talking about showing video info there, but hiding the audio info (and show it only in the audio decoder).

[TheShadowRunner]

Thanks for build 3771, but I can confirm the FLV4 bug (http://roundup.ffmpeg.org/issue2620) is still there.

[clsid]

The FLV4 issue is not a decoding bug. The video was padded to make it mod16 and needs to be cropped. ffdshow will automatically crop based on info signaled by the splitter, but only if the video render is not Overlay Mixer, which does not support it properly.

[TheShadowRunner]

Thanks for checking it. I tested with VMR9 and EVR, the issue is there with both renderers, meaning ffdshow doesn't crop properly then?
Or is it a splitter bug?
The On2 flv4 directshow decoder is free of this bug but I'd really rather use ffdshow for everything. ^^;

[clsid]

It indeed doesn't work. If I remember correctly it used to work, so you could try some old builds to see where things got broken.