ffdshow tryouts project: Discussion & Development

[madshi]

Originally Posted by clsid

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

Wonderful, thanks a bunch!!

Originally Posted by STaRGaZeR

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]

Originally Posted by clsid

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
Using Haali as splitter.

[ranpha]

Originally Posted by STaRGaZeR

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

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

[fastplayer]

Originally Posted by 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
Using Haali as splitter.

Confirmed. LAVSplitter handles it fine, though.

[Reimar]

Originally Posted by JEEB

+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!

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

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



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]

Originally Posted by 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
Using Haali as splitter.

Same bug here, no prob with libdts

[STaRGaZeR]

Originally Posted by pirlouy

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.

Originally Posted by Gleb Egorych

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.

Originally Posted by madshi

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]

Originally Posted by STaRGaZeR

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

Originally Posted by Reimar

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]

Originally Posted by STaRGaZeR

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-...0-31_142936.rm
http://samples.mplayerhq.hu/real/AC-...3-02_105820.rm

[STaRGaZeR]

Originally Posted by clsid

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.

Originally Posted by clsid

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]

Originally Posted by Gleb Egorych

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.