ffdshow tryouts project: Discussion & Development

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

Originally Posted by fastplayer

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

Originally Posted by fastplayer

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]

Originally Posted by Wilbert

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

[LigH]

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

[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 (i forgot about that one). I will ask over there.

[clsid]

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

Originally Posted by madshi

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

Originally Posted by clsid

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]

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

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

[avih]

Originally Posted by STaRGaZeR

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

Calm down, and keep it that way please.

[clsid]

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

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]

Originally Posted by clsid

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