ffdshow tryouts project: Discussion & Development

[Gleb Egorych]

Originally Posted by ikarad

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]

Originally Posted by ikarad

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]

Originally Posted by HeadlessCow

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]

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

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]

Originally Posted by clsid

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

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

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.

Originally Posted by fastplayer

@STaRGaZeR:
Since you've had some fun with the RGB32HQ code, does this explanation on our wiki 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

[fastplayer]

Originally Posted by STaRGaZeR

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!

Originally Posted by STaRGaZeR

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

Understood. I'll update that entry accordingly. Thanks!

[STaRGaZeR]

Originally Posted by fastplayer

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]

Originally Posted by STaRGaZeR

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]

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 STaRGaZeR

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

See? I knew it

[yesgrey]

Originally Posted by STaRGaZeR

See? I knew it

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?