ffdshow tryouts project: Discussion & Development

[Midzuki]

Originally Posted by vince100

Is there anyway to get closed captions displayed and also have the video decoded by a non-ffdshow mpeg2 decoder and post-processed by ffdshow's special filters?

No.

What configuration is required in ffdshow and which player can implement this setup?

Post a "proper" bug report on the "official channels"
(this thread is not an "official" channel)
and PRAY.

:-\

[jmartinr]

Concerning this bug, giving problems in new builds of MPC-HC: http://forum.doom9.org/showthread.ph...36#post1430936

It's enough to make a small adjustment to the contents of ffavisynth.avsi that's installed by ffdshow. A simple try... catch... will do.

try { Load_Stdcall_Plugin("ffavisynth.dll") }
catch(err_msg) { NOP() }

[djcla]

ANy idea why any AVI's i have with a DTS track in them stutter at the start of the video everytime when using FFDSHow? I do not get this issue bitstreaming with MS audio decoder or MPC-HC own decoders.. I have FFDSHow audio decoder setup as an external filter in MPC-HC.

I do not get this issue with DD 5.1 or HD audio i use a an ATI 5670 via HDMI out to SOny 2400ES reciever.

Next issue i have always had is when i configure FFDShow and mediaplayer or 7MC to decode H264 MKV's they always play with a green bars through them VC1 stuff is fine.

I tried using MPC-HC and FFDshow DXVA yesterday and seemed to have mroe success but need to investigate that further .

Any one else get these issues?

[Snowknight26]

You don't get the issue with Microsoft's audio decoder because it doesn't decode DTS.

[louisnet]

In recent version, the "Flip" option in context menu has been deleted,

I set the mirror in "Offset & flip" to Enable,
When I want to flip the screen horizontally, I just do to select the "Offset & flip" in Context Menu
if I want to flip the screen vertically, I just do to select the "Flip" in Context Menu.
Both function can be done thru the Context menu.

So the "Flip" option in Context Menu is very important.

Please....consider to make it appear again.
Thanks

[djcla]

Originally Posted by Snowknight26

You don't get the issue with Microsoft's audio decoder because it doesn't decode DTS.

i meant bitstreaming and the MS one works fine for that

[magic144]

Hooray, the ffdshow FFv tray icon right-click no longer makes ZP go boom! (build 3562) - thanks to all concerned for addressing this one!

[vince100]

Originally Posted by vince100

Is there anyway to get closed captions displayed and also have the video decoded by a non-ffdshow mpeg2 decoder and post-processed by ffdshow's special filters?
What configuration is required in ffdshow and which player can implement this setup?

Thanks.

Is it possible to achieve this by using Avisynth within ffdshow?

[tschi]

Originally Posted by jmartinr

Concerning this bug, giving problems in new builds of MPC-HC: http://forum.doom9.org/showthread.ph...36#post1430936

It's enough to make a small adjustment to the contents of ffavisynth.avsi that's installed by ffdshow. A simple try... catch... will do.

try { Load_Stdcall_Plugin("ffavisynth.dll") }
catch(err_msg) { NOP() }

What do you means exactly by "enough ??"
I tried but MPC-HC still crash when I use avisynth with ffdshow
The only working solution I found is to not use MPC-HC

[jmartinr]

@Tschi

You might have another avsi-file in your avisynth plugin directory that loads a dll. Delete it, move it or edit it.

[dansrfe]

Slight n00b question. I have made a script which resizes to 1080p depending on the source A/R in ffdshow and I am not quite sure if ffdshow's "Output" tab picks up the original video resolution from the initial video input before AviSynth or after AviSynth for the purpose of determining YCbCr Specification being ITU-R BT.601 or ITU-R BT.709. I hope it picks it up before AviSynth. Another probably more important question I have is that does YCbCr Specification matter if I am outputting only YV12 for madVR? In this case does madVR determine the colorspace by itself? If so then that is probably messing up due to my AviSynth resize script. Any explanation for this whole situation would be great. Thanks.

[STaRGaZeR]

Originally Posted by dansrfe

Slight n00b question. I have made a script which resizes to 1080p depending on the source A/R in ffdshow and I am not quite sure if ffdshow's "Output" tab picks up the original video resolution from the initial video input before AviSynth or after AviSynth for the purpose of determining YCbCr Specification being ITU-R BT.601 or ITU-R BT.709. I hope it picks it up before AviSynth.

It picks the initial video input dimensions, so it guarantees that the correct matrix is used. You can check it by changing between the two to see which one is actually used.

Originally Posted by dansrfe

Another probably more important question I have is that does YCbCr Specification matter if I am outputting only YV12 for madVR? In this case does madVR determine the colorspace by itself? If so then that is probably messing up due to my AviSynth resize script. Any explanation for this whole situation would be great. Thanks.

The whole "RGB conversion" tab affects things only when you're outputting RGB from ffdshow (obviously ). If you're outputting YV12 no conversion is done in ffdshow, the video renderer (madVR in this case) does all the stuff. You should ask madshi when madVR uses each one. However, if it uses one or another based on the video dimensions that it receives from the previous filter the whole thing will be incorrect if you resize before madVR, since the resized image may toggle 709 when the video is 601 and viceversa.

Any kind of postprocessing is yet another situation where RGB32 input would make perfect sense in madVR, but madshi didn't want to add it the last time I asked for it, not even with an option to disable it.

[Keiyakusha]

Originally Posted by STaRGaZeR

It picks the initial video input dimensions, so it guarantees that the correct matrix is used. You can check it by changing between the two to see which one is actually used.

If we talking about avisynth script, then output colors will be wrong. What you said is valid for internal resizer only. However I'm not sure, maybe this was fixed in some of the recent revisions.
EDIT: also SD -> 1080p using internal resizing AND keeping it YV12 -> wrong colors.

[STaRGaZeR]

Originally Posted by Keiyakusha

If we talking about avisynth script, then output colors will be wrong. What you said is valid for internal resizer only. However I'm not sure, maybe this was fixed in some of the recent revisions.
EDIT: also SD -> 1080p using internal resizing AND keeping it YV12 -> wrong colors.

If you're not outputting RGB ffdshow doesn't do anything. You have to convert whatever you have to RGB somewhere in the filter chain. These settings are only used when the YCbCr-->RGB conversion is done inside ffdshow. If you resize, with avisynth or the resize filter, and output YV12 or any other non-RGB colorspace, colors will be wrong if your video was mastered using 601 and the filter doing the conversion uses 709 because of the new resolution. This is not a bug in ffdshow, nor in the renderer. The selection 601 vs 709 is done assuming that certain resolutions are 601 and 709.

Example: you have SD video, ffdshow and renderer assume 601. If you resize to 1080p within ffdshow AND you output RGB, the RGB conversion will be done inside ffdshow with 601, as it should, because ffdshow knows that the source is SD. If you're NOT outputting RGB no conversion is done in ffdshow, but in the renderer. Now, the renderer sees 1080p YV12 video, it doesn't know what the original dimensions were, so it assumes 709 --> wrong colors. Again, this is not a bug, is a limitation.

[Midzuki]

Bug in ffdshow r3529 Audio Processor:

when a 4.0 FLAC is decoded by the latest madFlac and then sent to ffdshow audio processor, this produces a 3.1 output. No problem when madFlac connects to AC3Filter, OTOH.

[madshi]

Originally Posted by Midzuki

Bug in ffdshow r3529 Audio Processor:

when a 4.0 FLAC is decoded by the latest madFlac and then sent to ffdshow audio processor, this produces a 3.1 output. No problem when madFlac connects to AC3Filter, OTOH.

FWIW, the latest madFlac version outputs a correct dwChannelMask value in the media type information. So if Midzuki's bug report is true (haven't checked), then ffdshow probably doesn't properly handle a 4.0 dwChannelMask.

[Midzuki]

@ madshi: the audio processor works fine when connected to the audio decoder of ffdshow, so it seems there is a "language barrier" between the audio processor and madFlac's decoder filter.

[madshi]

Can you please post the dwChannelMask information for both cases? Don't need the whole media type, just the channel mask for comparison.

[Midzuki]

I'm afraid I spoke too early ... I will have to re-create the test .WAVs and .FLACs, not only because I've already deleted them , but principally because, now that I think it all over, it's quite possible that they were VERY "non-standard" ... Just out of curiosity, does madFlac (or/and eac3to) support ALL "weird" channel masks --- let's say, 0x003C (FC, LFE, BL, BR) ---

[madshi]

madFlac (at least in theory) supports all channel mask combinations that can be expressed with the MS flags.