ffdshow tryouts project: Discussion & Development

[Gleb Egorych]

The colorspaces EVR supports depends of the graphics card drivers. Since you have one that supports YV12, YV12 is used over NV12.
I use Geforce 8800GT with drivers 266.58. Maybe NV12 should be made a higher-priority output colorspace than YV12. At the moment behaviour is almost the same as it was before your changes.

*EDIT* Tab-order of this settings page and other pages is curious.

[Ger]

:thanks:


Ideally we'd have HW deint enabled by default, like Microsoft decoders do so users don't have to mess up with deinterlacing. This could cause problems with ffdshow's internal deinterlacer filter thou, like double deinterlacing (120fps output :p). I want to hear opinions about this.


I like the idea of having it working "out of the box" like MS decoders. Maybe add a big/fat/red warning in the software deinterlacing tab if both are enabled at the same time? Or would any user messing with that tab already know that? I don't know.

Regarding the DV option it doesn't have a tooltip explaining what it does, and it seems to disable just about "everything", but at least you can see many options getting grayed out as soon as you check it.

I use Geforce 8800GT with drivers 266.58. Maybe NV12 should be made a higher-priority output colorspace than YV12. At the moment behaviour is almost the same as it was before your changes.

I tend to agree with Gleb Egorych and khagaroth, moving NV12 to the top, above YV12 in priority.

That would solve the issues that apparently occur with Nvidia and EVR, not needing to uncheck YV12, and would also give XP/VMR9 user hw deint by default.

Given the lossless nature of YV12 -> NV12 conversion, the only downside would be a slightly higher CPU usage, right? My CPU is from 2006 and while it may be a few percent higher with YV12 uncheked, it really seems negligible with todays hardware.

If JanWillem32's changes are accepted in MPC-HC their decoders will use NV12 a lot more, and Microsoft already does use NV12, even with non-DXVA. Just tried "Mpeg4s Decoder DMO" for software XviD decoding connected to VMR9 and it used NV12. With madVR it falls back to YV12.

*EDIT* Tab-order of this settings page and other pages is curious.

I had to read that a few times before I understood you meant the Tab key and not a GUI tab, but yes you're right.

EDIT: One more thing. I know it was agreed to keep UYVY because of capture cards and disable it by default, but if it's bottom of the priority list anyway, why not just enable it by default, just in case something needs it.

[clsid]

If the internal deinterlacing is enabled, then the input interlacing flag should obviously not be propagated to the next filter in the chain.
So set output interlacing flag only if input had the flag enabled and internal deinterlacing is not enabled.

[mark0077]

Guys, discussion going on over at the avsforums regarding problems with ffdshow causing crashes when using avisynth. A couple of the chaps over there narrowed it down to right after build 3356

http://www.avsforum.com/avs-vb/showthread.php?t=1025800&page=33

I can only assume this change brought in the problems.

Revision 3358 - Directory Listing
Modified Thu Apr 15 08:27:07 2010 UTC (10 months, 1 week ago) by tal_aloni
AviSynth Frame accurate seeking. (patch by SEt and Jeremy Duncan)

Anyone know why these changes might be causing ffdshow to cause crashes from time to time, mostly when opening a second / third file without closing down the software player.

[fastplayer]

Forum status update

I've updated it to the latest phpBB version, cleaned out countless spam accounts, added hundreds of e-mail addresses, domains, and usernames to the ban list and they still keep coming. Unfortunately, we can't ban by IP because SourceForge is doing something funky with them (probably routing through their own proxies).
Unless someone knows how to effectively block spam and is willing to implement it, I see no other choice than killing off the forum... Any takers or should I pull the plug?

Edit:
I've pulled the plug today. Redirects point to ffdshow's SF.net forum.

[madshi]

I tend to agree with Gleb Egorych and khagaroth, moving NV12 to the top, above YV12 in priority.
I also agree. The MS documentation says this about NV12:

> NV12 is the preferred 4:2:0 pixel format for DirectX VA.
> It is expected to be an intermediate-term requirement
> for DirectX VA accelerators supporting 4:2:0 video.

BTW, the next madVR build will support NV12 and YV12.

[Px]

Unless someone knows how to effectively block spam
Replace default captcha with this - http://www.captcha.ru/en/

[Ger]

Just did a test with yadif with double framerate + output flags checked. Double double framerate (well, only an increase from 50 to 60, monitor refresh rate, in my case) only happens if Force bob is selected (output/method). With The default "Auto" mode it seems no hw deint is applied if already deinterlaced internally. This according to the CTRL-J stats in EVR Custom.

[nevcairiel]

BTW, the next madVR build will support NV12 and YV12.

Awesome, then my CUVID decoder doesn't have to implement conversion to YV12 :D

[SamuriHL]

I also agree. The MS documentation says this about NV12:

> NV12 is the preferred 4:2:0 pixel format for DirectX VA.
> It is expected to be an intermediate-term requirement
> for DirectX VA accelerators supporting 4:2:0 video.

BTW, the next madVR build will support NV12 and YV12.

Oh THIS will be fun! :D

[madshi]

Just so that there are no misunderstandings: madVR supporting NV12 does *not* mean that DXVA decoding or deinterlacing works... ;)

Hmmmm... Does anybody know a decoder or source filter which outputs P010 or P016 video data? That's 10bit or 16bit 4:2:0 (NV12 and YV12 are 8bit). I've just added support for P010 and P016 to madVR, but I have no way to test it.

[nevcairiel]

Just so that there are no misunderstandings: madVR supporting NV12 does *not* mean that DXVA decoding or deinterlacing works... ;)


I know that, but it still saves me time coding a conversion!

[madshi]

@nevcairiel, I knew that you knew. :) But not everyone knows as much as you do. Just wanted to make sure that nobody gets up his hopes.

[SamuriHL]

@nevcairiel, I knew that you knew. :) But not everyone knows as much as you do. Just wanted to make sure that nobody gets up his hopes.

I wasn't entirely sure if dxva was being utilized or not, so, good clarification. Still, this is a good thing IMO!

[madshi]

Ok, new version out now with support for YV12, NV12, P010, P016:

http://madshi.net/madVR.zip (v0.38)

Follow up please in the madVR thread, thanks.

[STaRGaZeR]

I tested inside a WinXP VM and HQ was definitely disabled, while Dithering was greyed-out. Or does it get automagically enabled when YV12/NV12 fail?

Hah, good find. What's your CPU? It's only enabled by default if you have at least 2 cores AND SSSE3 support (Core2Duo and newer, dunno about AMD). I don't know why haruhiko used SSSE3 as requirement, since the HQ converter only needs SSE2, so let's do it this way. Internally the converter already has a SSE2 check, only the GUI has to be fixed. So disable both checkboxes if the CPU doesn't support SSE2. Try the build below to see if they're properly disabled for CPUs not supporting SSE2.

I use Geforce 8800GT with drivers 266.58. Maybe NV12 should be made a higher-priority output colorspace than YV12. At the moment behaviour is almost the same as it was before your changes.

*EDIT* Tab-order of this settings page and other pages is curious.

Interesting. So with nvidia cards EVR accepts YV12?

And what has changed? Better or worse now? Be specific! Remember that what I'm changing here is the order of the output colorspaces, but only if the original fails. That is, if you have YV12 video, the list is only consulted if you have YV12 disabled or if the renderer doesn't accept it. Doing YV12->NV12 by default will require changing code I'm not familiar with. So for now YV12 > NV12.

Indeed. At least the output tab should be better now.

:thanks:

I like the idea of having it working "out of the box" like MS decoders. Maybe add a big/fat/red warning in the software deinterlacing tab if both are enabled at the same time? Or would any user messing with that tab already know that? I don't know.

Regarding the DV option it doesn't have a tooltip explaining what it does, and it seems to disable just about "everything", but at least you can see many options getting grayed out as soon as you check it.

I tend to agree with Gleb Egorych and khagaroth, moving NV12 to the top, above YV12 in priority.

That would solve the issues that apparently occur with Nvidia and EVR, not needing to uncheck YV12, and would also give XP/VMR9 user hw deint by default.

Given the lossless nature of YV12 -> NV12 conversion, the only downside would be a slightly higher CPU usage, right? My CPU is from 2006 and while it may be a few percent higher with YV12 uncheked, it really seems negligible with todays hardware.

If JanWillem32's changes are accepted in MPC-HC their decoders will use NV12 a lot more, and Microsoft already does use NV12, even with non-DXVA. Just tried "Mpeg4s Decoder DMO" for software XviD decoding connected to VMR9 and it used NV12. With madVR it falls back to YV12.

I had to read that a few times before I understood you meant the Tab key and not a GUI tab, but yes you're right.

EDIT: One more thing. I know it was agreed to keep UYVY because of capture cards and disable it by default, but if it's bottom of the priority list anyway, why not just enable it by default, just in case something needs it.

See below for the double deinterlacing solution.

I'm not 100% sure, but here it goes: the DV option encodes (yes, encoding, it requires libavcodec) your video to DV and outputs it like that. That's why the option disables everything else.

See above. When I'm more familiar with the code I may change that. But not now. The truth is that if the price is HW deinterlacing by default everywhere without any downsides except very little CPU usage increase, NV12 may be a better option. However, at least with my HD5850, NV12+flags only works with EVR and Overlay mixer. With VMR7/9 they're simply ignored, so we'd be in the same situation as with YV12.

Good observation. Enabled by default now.

If the internal deinterlacing is enabled, then the input interlacing flag should obviously not be propagated to the next filter in the chain.
So set output interlacing flag only if input had the flag enabled and internal deinterlacing is not enabled.

Yep. In this build, if the deinterlacing filter is enabled the flags are set to weave, which is the same as "do nothing".

Just for the record, if somebody wants to see the difference between any of ffdshow's deinterlacers and HW deinterlacing in real time: output NV12+flags so HW deint is enabled, then check the deinterlacing filter configured as you want. This will result in HW deint stopping working and for example yadif being enabled almost instantly, so differences can clearly be seen between the two.

Test build: http://www.mediafire.com/?vny5xjraq0fjn9m

[ranpha]

Interesting. So with nvidia cards EVR accepts YV12?

And what has changed? Better or worse now? Be specific! Remember that what I'm changing here is the order of the output colorspaces, but only if the original fails. That is, if you have YV12 video, the list is only consulted if you have YV12 disabled or if the renderer doesn't accept it. Doing YV12->NV12 by default will require changing code I'm not familiar with. So for now YV12 > NV12.


It seems so in my case.

http://i.min.us/ijif0u.jpg

Oh BTW, the requirement that you must pass NV12 to EVR (vanilla/custom presenter) in order to have hardware deinterlacing only applies to ATI GPUs. This doesn't apply to nVidia GPUs, because hardware deinterlacing with EVR (vanilla/custom presenter) can be achieved even when you pass NV12 or YV12 or whatever colorspace the GPU supported (see picture below).

http://i.min.us/il3mZg.jpg

[Ger]

Remember that what I'm changing here is the order of the output colorspaces, but only if the original fails. That is, if you have YV12 video, the list is only consulted if you have YV12 disabled or if the renderer doesn't accept it. Doing YV12->NV12 by default will require changing code I'm not familiar with. So for now YV12 > NV12.

When I'm more familiar with the code I may change that. But not now.
OK. I think most of us wrongly assumed that it was as easy to change the YV12 order as the other ones, but clearly not. Hopefully you or someone else will be able to change it another time then.

In the meantime Nvidia users can disable YV12 and leave everything else enabled if they want hw deint in EVR. Now that madVR supports NV12 it shouldn't cause too many problems. I remember Stax had an issue with DirectShowSource, but (unless YV12 was forced with parameters) I'm pretty sure that was because only NV12 was enabled, and that won't be a problem after your changes.


The truth is that if the price is HW deinterlacing by default everywhere without any downsides except very little CPU usage increase, NV12 may be a better option. However, at least with my HD5850, NV12+flags only works with EVR and Overlay mixer. With VMR7/9 they're simply ignored, so we'd be in the same situation as with YV12.

Weird, I assumed it worked in VMR9 because I didn't see combing. Checking "Set interlaced flags in output media type" definitely triggers some kind of deinterlacing with NV12 + VMR9 renderless here (Win7 x64, ATI 5770, 11.2 drivers), but it looks way worse than with EVR. I see blocking in the channel logo that aren't there in EVR. On an Nvidia laptop I can't see that quality difference between EVR and VMR9, but the panel is horrible on that one so I don't trust my eyes 100%.

With EVR I can see the effect live/immediately if I change Method (Auto/Force bob/Weave) or Field order, but with VMR9 there is no difference even after a reconnect. Only the checkbox matters. I guess VMR9 (in Win7 at least) checks VIH2 and if "dwInterlaceFlags: 0x00000081", makes its own decisions regardless of bob/weave/field order flags in the stream. If dwInterlaceFlags: 0x00000000, no deinterlacing.

Oh, well. I really don't care what happens in VMR9 in Win7 anyway. I don't know why I bothered writing all that. I don't even care what happens in XP since I haven't used it since 2006. :p


Yep. In this build, if the deinterlacing filter is enabled the flags are set to weave, which is the same as "do nothing".

Test build: http://www.mediafire.com/?vny5xjraq0fjn9m


And with the same frame rate test I used with the last build, I now get around 50 fps as it should be, so no double deinterlacing occurs even when Force bob is selected. So that seems to work just fine. :cool:

Oh BTW, the requirement that you must pass NV12 to EVR (vanilla/custom presenter) in order to have hardware deinterlacing only applies to ATI GPUs. This doesn't apply to nVidia GPUs, because hardware deinterlacing with EVR (vanilla/custom presenter) can be achieved even when you pass NV12 or YV12 or whatever colorspace the GPU supported (see picture below).

I don't think so. I can't double check at the moment, but I'm pretty sure I tested with YV12 + EVR Custom with Nvidia drivers reporting like that and I saw combing, and no visible deinterlacing at all until i switched to NV12 or YUY2. I just think DXVAChecker gets incorrect info from the drivers. I pretty sure the old drivers (below 200.xx somewhere) didn't report it that way last time I checked, a year or so ago. Have you seen hw deint really happening with YV12?

The ATI drivers only show NV12, YUY2 and UYVY in that list, with only NV12 supporting VectorAdaptiveDevice and MotionAdaptiveDevice.

EDIT: Oh, that's right. No flags activated with ffdshow + YV12 anyway, so I guess I haven't tested at all then. Sorry. I guess you have to use another decoder to test then. Maybe DXVAChecker is right after all.

[fastplayer]

Hah, good find. What's your CPU? It's only enabled by default if you have at least 2 cores AND SSSE3 support (Core2Duo and newer, dunno about AMD).
It's an Athlon64 X2 and inside the VM it's just a single-core and SSE3 is as far as it goes SIMD-wise (SSSE3 is not supported).
I don't know why haruhiko used SSSE3 as requirement, since the HQ converter only needs SSE2, so let's do it this way. Internally the converter already has a SSE2 check, only the GUI has to be fixed. So disable both checkboxes if the CPU doesn't support SSE2. Try the build below to see if they're properly disabled for CPUs not supporting SSE2.
You mean NV12/YV12, right? If I disable both, RGB32 takes over and plays fine. RGB32HQ is now enabled by default on this setup.
If I disable SSE2 (and SSE3), then RGB32HQ+Dithering is grayed-out. The SSE2-check seems to work. :)
I'm not sure about the RGB32HQ multi-core requirement, though. It seems to work fine with one core in the VM...

[madshi]

Hmmmm... Does anybody know what NV24 is? NVidia DXVA seems to support it. Is it 16bit 4:2:0? Then it would be identical to P016?

[nevcairiel]

Hmmmm... Does anybody know what NV24 is? NVidia DXVA seems to support it. Is it 16bit 4:2:0? Then it would be identical to P016?

I found this reference on the MSDN

The FOURCC format of the surface defines whether the interlaced fields are interleaved or not. For example, NV12 is an interlaced format with interleaved fields whereas NV24 is an interlaced format with non-interleaved fields.

http://msdn.microsoft.com/en-us/library/ff563056%28v=vs.85%29.aspx

From what i can tell, commercial players seem to be using NV24 alot, especially PowerDVD. Other then that, not much references popped up.

[ranpha]

I don't think so. I can't double check at the moment, but I'm pretty sure I tested with YV12 + EVR Custom with Nvidia drivers reporting like that and I saw combing, and no visible deinterlacing at all until i switched to NV12 or YUY2. I just think DXVAChecker gets incorrect info from the drivers. I pretty sure the old drivers (below 200.xx somewhere) didn't report it that way last time I checked, a year or so ago. Have you seen hw deint really happening with YV12?

The ATI drivers only show NV12, YUY2 and UYVY in that list, with only NV12 supporting VectorAdaptiveDevice and MotionAdaptiveDevice.

EDIT: Oh, that's right. No flags activated with ffdshow + YV12 anyway, so I guess I haven't tested at all then. Sorry. I guess you have to use another decoder to test then. Maybe DXVAChecker is right after all.

I cannot test with YV12, because if the 'Set interlace flag in output media type' is checked, YV12 will be greyed out. Hardware deinterlacing works fine with YUY2 though.

[nevcairiel]

Hardware deinterlacing works fine with YUY2 though.

YUY2 is a 4:2:2 format though, and your chroma will be (badly) upsampled to get there.

[Gleb Egorych]

And what has changed? Better or worse now? Be specific!
I wrote *almost* because in fact you removed several checkboxes which *theoretically* could be checked or unchecked. *Practically* in my usage scenarios I didn't notice any changes in behaviour because enabling YV12 gave me no HW deinterlacing and I needed to disable YV12 to get HW deinterlacing with NV12.

[ranpha]

YUY2 is a 4:2:2 format though, and your chroma will be (badly) upsampled to get there.

Yes, the quality is a disaster (deinterlacing works, but other image quality problems surfaced). But the best way to test hardware deinterlacing with YV12 is to use CoreAVC (no need to turn on CUDA decoding), make it output YV12 only, set the deinterlacing method to 'Hardware' and connect it directly to EVR renderer. Works very well with YV12, NV12 et. al. but not if CoreAVC is forced to only output any of RGB* colorspaces (which the DXVA Checker says isn't supported).

[madshi]

I found this reference on the MSDN

http://msdn.microsoft.com/en-us/library/ff563056%28v=vs.85%29.aspx

From what i can tell, commercial players seem to be using NV24 alot, especially PowerDVD. Other then that, not much references popped up.
Ah thanks! Makes sense. Too bad, though, I was excited for a moment, hoping NV24 would be 16bit 4:2:0.

[Ger]

I cannot test with YV12, because if the 'Set interlace flag in output media type' is checked, YV12 will be greyed out. Hardware deinterlacing works fine with YUY2 though.

Yeah, I know. That's what I meant with the edit. In STaRGaZeR's latest test builds it won't be grayed out, but the flags will be automatically disabled when YV12 is used, so it still can't be used for testing that particular issue.

YUY2 works on ATI as well (but not with the two best algos), so that's less interesting than YV12.

Given the currently available ffdshow implementations another decoder that allows forced YV12 + hw deint flags would be the only way to test for sure.

EDIT:
Didn't see your last post regarding CoreAVC. I guess we know it works then. You learn something new every day.

[STaRGaZeR]

It seems so in my case.

Oh BTW, the requirement that you must pass NV12 to EVR (vanilla/custom presenter) in order to have hardware deinterlacing only applies to ATI GPUs. This doesn't apply to nVidia GPUs, because hardware deinterlacing with EVR (vanilla/custom presenter) can be achieved even when you pass NV12 or YV12 or whatever colorspace the GPU supported (see picture below).

I will enable the flags for YV12 then, so you guys can run some tests.

Oh, well. I really don't care what happens in VMR9 in Win7 anyway. I don't know why I bothered writing all that. I don't even care what happens in XP since I haven't used it since 2006. :p

You can't alienate XP users, even if you don't use XP :p

It's an Athlon64 X2 and inside the VM it's just a single-core and SSE3 is as far as it goes SIMD-wise (SSSE3 is not supported).

You mean NV12/YV12, right? If I disable both, RGB32 takes over and plays fine. RGB32HQ is now enabled by default on this setup.
If I disable SSE2 (and SSE3), then RGB32HQ+Dithering is grayed-out. The SSE2-check seems to work. :)
I'm not sure about the RGB32HQ multi-core requirement, though. It seems to work fine with one core in the VM...

ffdshow has several converters for different colorspaces (a mess, I must say). If you convert to RGB32 from YV12, one is used. If you convert to RGB32HQ from YV12, another is used. This is obviously controlled by the "High quality..." option. This HQ converter is only for YV12/NV12/YUY2 -> RGB32 conversion. The HQ converter requires SSE2 and nothing else. It's multithreaded. The dual core and SSSE3 check is only for determining the default value, you can still use it as long as your CPU supports SSE2. haruhiko probably used this particular combination just to make sure only fast modern CPUs have it enabled by default.

I wrote *almost* because in fact you removed several checkboxes which *theoretically* could be checked or unchecked. *Practically* in my usage scenarios I didn't notice any changes in behaviour because enabling YV12 gave me no HW deinterlacing and I needed to disable YV12 to get HW deinterlacing with NV12.

OK, then everything is right.


In this build, the flags are enabled for all colorspaces. The only real change compared to the previous one is that YV12 is flagged too. Report your findings in both ATI and NV, XP and Vista/7.

http://www.mediafire.com/?5g9jtd6yzjd2c0t

As expected, in my system (ATI + Vista) it makes no difference: YV12 is still not deinterlaced, the renderer doesn't matter. No downsides observed.

[fastplayer]

The dual core and SSSE3 check is only for determining the default value, you can still use it as long as your CPU supports SSE2. haruhiko probably used this particular combination just to make sure only fast modern CPUs have it enabled by default.
Thanks for summing it up! :)
Looks like Haruhiko played the "better safe than sorry"-card with this check.

[madshi]

Can anybody reproduce the following problem I'm seeing here?

- all output colorspaces active in the ffdshow output section
- external decoder delivers NV12 to ffdshow raw video processor
- ffdshow raw video processor connects to renderer with NV12

In this situation MPC-HC with EVR Custom crashes for me. And with madVR half the screen is black while the other half is empty. It seems to me that the ffdshow raw video processor doesn't handle NV12 input + NV12 output correctly. Any other combination seems to work fine, though. E.g. YV12 input + NV12 output works fine.

[ranpha]

Test video (http://www.filesonic.com/file/20150847/history_chan_hd_sample_interlaced.mkv)

No deinterlacing (ffdshow raw video filter outputing YV12 to EVR custom presenter without the interlace flag been set):-
http://i.min.us/ijqKyO.jpg

ffdshow raw video filter set to output YV12 with interlace flags being set:-
http://i.min.us/ijvjlu.jpg

ffdshow raw video filter set to output UYVY with interlace flags being set:-
http://i.min.us/ijvhdm.jpg

Haven't tested with NV12 or YUY2, I assume that they will just work in my nVidia GPU. In other words, this build works really well. Now hardware deinterlacing with YV12 in ffdshow is actually doable.


Can anybody reproduce the following problem I'm seeing here?

- all output colorspaces active in the ffdshow output section
- external decoder delivers NV12 to ffdshow raw video processor
- ffdshow raw video processor connects to renderer with NV12

In this situation MPC-HC with EVR Custom crashes for me. And with madVR half the screen is black while the other half is empty. It seems to me that the ffdshow raw video processor doesn't handle NV12 input + NV12 output correctly. Any other combination seems to work fine, though. E.g. YV12 input + NV12 output works fine.

With Stargazer build, there is no crash reported (CoreAVC output NV12, pass it to ffdshow raw video filter that will then output NV12 to EVR custom presenter). Haven't tried with the latest madVR though, I haven't got around installing it yet (still using 0.36) .

[Gleb Egorych]

In other words, this build works really well. Now hardware deinterlacing with YV12 in ffdshow is actually doable.
Same here. Tested on my samples, HW deinterlacing works with YV12 now.

[Ger]

I will enable the flags for YV12 then, so you guys can run some tests.

In this build, the flags are enabled for all colorspaces. The only real change compared to the previous one is that YV12 is flagged too. Report your findings in both ATI and NV, XP and Vista/7.

http://www.mediafire.com/?5g9jtd6yzjd2c0t

As expected, in my system (ATI + Vista) it makes no difference: YV12 is still not deinterlaced, the renderer doesn't matter. No downsides observed.

In other words, this build works really well. Now hardware deinterlacing with YV12 in ffdshow is actually doable.

Cool. I can also confirm that on a borrowed Nvidia laptop it also works with YV12 in both EVR and VMR9r (Win7). There is no ugly half-way solution in VMR9 like on ATI+NV12, and flag changes are also immediately visible in VMR9r with Nvidia. In short Nvidia drivers/deinterlacers seem far more flexible with regards to both colorspace and renderer.

The defaults in the last build should make everyone happy. Hw deint works out of the box (with properly flagged streams at least) for both Nvidia and ATI on Vista/7 + EVR. :thanks:

XP and Intel behavior is still untested, but I doubt these changes will make anything worse than before for them. It will most likely be better there as well. Would be nice if anyone could confirm this though.

I do have a long-standing issue with a particular spot in one of the auto flagging algos, but I'm not going to even bring that up until these changes are safely committed.

[STaRGaZeR]

Nice.

Devs, tell me when you want this commited (IF you want to :p).

[fastplayer]

How about... right now? I need my daily ffdshow fix! :D
I haven't noticed any anomalies today while "testing" the latest build you posted. It just works™! :)

[STaRGaZeR]

It's on now :D

[mark0077]

Anyone know how I can contact SEt, I doubt he has seen my PM regarding avisynth / ffdshow crashes problem since a commit he made a few months back...

[madrazel]

I found a problem with old Real Video file. Since FFdshow has appropriate codecs for RealVideo 1 to 4, I think this might be interesting to you. This issue is with RealVideo 3.
The video is a lecture from Berkeley on their webcast, for the file go to: http://webcast.berkeley.edu/course_details.php?seriesid=1906978254.
and the link to the file is: http://webcast.berkeley.edu/stream.php?type=real&webcastid=13952 -> rtsp://169.229.131.16:554//bibs/f2004/group6/psych1/20040830.rm , 87 MB - to download it I used Portable Offline Browser, 30 day full working trial here: http://www.metaproducts.com/mp/Portable_Offline_Browser.htm
I was trying to play it in latest GOM Player, but I think the player is irrelevant here, because other Real Media videos from that site go through ffdshow without issues.
Also this file is playing fine with VLC 1.1.7, and with Media Player Classics when Real Alternative 1.9.0 is installed , that is bypassing ffdshow. There is an error at the beginning of the file visible in players that can handle this file, but I don't know it is a recorded analog error from the camera or digital error in the file. However if it is a digital error I think there should be a way to seal the algorithm to not go stupid while encountering it.

Error is that the picture is gray about 1 second at the beginning of the file and then player hangs up and quits.

[ikarad]

I found a problem with ffdshow 3760 and the last versions.
The back right channel (speaker) and the LFE crossover channel are swapped. I found a workaround for this problem by using the swap channel options to swap the LFE and Back right channels.

I use ffdshow with mpc-HC

Edit: I try with ffdshow since 3361 and thre is the same problem. I have tried with different version of mpc-hc (1.2.2972 until the last 1.5.1.2931) and There is the same problem (I haven't tried with older version of ffdshow and mpc-hc)

edit2: I try under xp sp3 or vista and there is the same problem

https://sourceforge.net/tracker/?func=detail&aid=3193503&group_id=173941&atid=867360

[ikarad]

I find a problem with ffdshow sub renderer

file here
http://www.megaupload.com/?d=SB6Y47LD

With mpc-hc subs work very well and there is animation
http://img526.imageshack.us/img526/3982/mpchcsub.th.jpg (http://img526.imageshack.us/i/mpchcsub.jpg/)



With ffdshow subs work well (but japan subs are not displayed vertically) but there isn't any animation
http://img822.imageshack.us/img822/9428/ffdshowsub.th.jpg (http://img822.imageshack.us/i/ffdshowsub.jpg/)



bugtracker
https://sourceforge.net/tracker/?func=detail&aid=3186705&group_id=173941&atid=867360
Up for this problem present in ffdshow 3765

[Gleb Egorych]

I found a problem with ffdshow 3760 and the last versions.
The back right channel (speaker) and the LFE crossover channel are swapped.
At sf.net you wrote "I use ffdshow with mpc-HC but this bug doesn't appeared with mpc-hc only". Sounds like it's rather mpc-hc's bug.

[STaRGaZeR]

Up for this problem present in ffdshow 3765

Upping your problems won't solve them.

[ikarad]

At sf.net you wrote "I use ffdshow with mpc-HC but this bug doesn't appeared with mpc-hc only". Sounds like it's rather mpc-hc's bug.

No it's a bug of ffdshow because without ffdshow it works. If it was a bug of mpc-hc, it wouldn't work with mpc-hc only.

[ikarad]

Upping your problems won't solve them.

Yes I know but It's for that developpers see this bug.
I don't know if bugtracker is still used by developpers.

[Gleb Egorych]

No it's a bug of ffdshow because without ffdshow it works. If it was a bug of mpc-hc, it wouldn't work with mpc-hc only.
Your logic is wrong. Imagine that MPC-HC has 2 bugs: wrong mapping in internal decoder and wrong mapping in internal mixer and these 2 bugs "neutralize" each other, ie the output is correct.
But when external decoder (ffdshow in your case) is connected to internal mixer then the output is wrong. Your description of the problem does not rule out this speculative situation.

BTW I tested ffdshow in 2 different players (not MPC-HC) and didn't noticed the problem.

[nevcairiel]

Its much more likely that there is one bug, and not two bugs correcting each other.
Besides, i have no issues with channel assignment using MPC-HC, and i know for a fact that the MPC-HC audio switcher does not do any channel mappings, unless you setup some mappings manually.

[ikarad]

Your logic is wrong. Imagine that MPC-HC has 2 bugs: wrong mapping in internal decoder and wrong mapping in internal mixer and these 2 bugs "neutralize" each other, ie the output is correct.
But when external decoder (ffdshow in your case) is connected to internal mixer then the output is wrong. Your description of the problem does not rule out this speculative situation.

BTW I tested ffdshow in 2 different players (not MPC-HC) and didn't noticed the problem.
Can uo utell me the 2 differents players that you tested to that I test.

Moreover, it's maybe a bug with comportment of ffdshow when mpc-hc use ffdshow and not a bug of mpc-hc.

After it's maybe a bug of mpc-hc.

For that I refer also this problem on the bug tracker of mpc-hc.

[ikarad]

Its much more likely that there is one bug, and not two bugs correcting each other.
Besides, i have no issues with channel assignment using MPC-HC, and i know for a fact that the MPC-HC audio switcher does not do any channel mappings, unless you setup some mappings manually.

Finally, it's a bug with mpc-hc or ffdshow?

[HeadlessCow]

Yes I know but It's for that developpers see this bug.
I don't know if bugtracker is still used by developpers.

The ffdshow ssa/ass subtitle renderer is not very complete and (from what I understand) there is no real plan to fix that given the large amount of work it would require. At some point ffdshow might integrate libass (or vsFilter) to give it better support, but it's also a lot of work and low priority for the developers.

[ikarad]

The ffdshow ssa/ass subtitle renderer is not very complete and (from what I understand) there is no real plan to fix that given the large amount of work it would require. At some point ffdshow might integrate libass (or vsFilter) to give it better support, but it's also a lot of work and low priority for the developers.

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.