Media Player Classic Home Cinema (MPC-HC) - DXVA!

[Rain1]

I set Auto-zoom: 100% in Playback and it works well for vids with resolution < my monitor's res. 1920x1200 (They were played 100% at their resolution). However, with full HD vids, MPC-HC plays in maximize window mode & still show the border. Doesn't it suppose to play at full screen (without border, at all) ?

I know there's a full screen option, but that setting overwrite the auto-zoom setting at 100% & always play vids in fullscreen, regardless of their res.

Is there anyway to make the player to auto switch to full screen for fullHD clips, when Auto-zoom is set to 100% ?

Thanks /

[JanWillem32]

@Rain1: Only the "D3D Fullscreen Mode" option will make videos render in full screen on startup, as far as I know.

@Ger: Thank you for testing. I already thought my changes to the bicubic resizer wouldn't make much of a difference (the output assembly didn't change much). Bicubic resizing in a single pass with the current matrix method is sub-optimal anyway. I hope you have more luck when other two-pass resizing modes are added. Luckily, (although blurry) native GPU bilinear filtering is default.

I do have some remarks, of course. (I'm in a technical mood/mode today.)

Chroma up-sampling is something best left to a custom mixer. The native surface blitting from Y'CbCr to RGB on GPUs have incoherent results. Newer nVidia models force a bilinear filter on doubling the dimensions of the chroma data, which can't be disabled. Older nVidia models, ATi and Intel models don't filter, so the chroma is resized with the nearest neighbor method. Of course, neither forcing bilinear filtering nor skipping filtering is a good solution. However, I can understand that adding a GUI option in the video section of the drivers with a range of chroma resizing filters that range from unfiltered to something like Lanczos256 would be rather much to ask from GPU driver developers.
The only thing I can do at the moment is integrating the shaders I've written in a similar way as the color management and dithering function, making in effect half a mixer. That would work okay as a user-selectable option, but not as an automatic one.
The other (preferred) option would be to discard the EVR and VMR-9 mixer and give the shared renderer part of VMR-9 (renderless) and EVR CP a custom mixer. The hard parts are that I've haven't seen any mixers with a GPL license around, I can't just write one on my own, without months worth of lessons in media handling like this in my spare time and lastly, I wouldn't know a good name for the renderer, as (renderless) and CP are what would remain of the original names.

I'm the one that pushed conversion to RGB32 or RGB24 to the very bottom of the mixer input priority list. All the current decoders are natively NV12, YV12, I420 and YUY2 anyway. With the conversion to RGB32 or RGB24, after having conversion from Y'CbCr to RGB, the resulting floating points are rounded to 8-bit integer. With some luck, there's some dithering involved (that can't be compared to the internal 32²||128² dither maps and randomized dithering methods). Anyway, this kind of conversion is pretty lossy. It's completely unacceptable for any renderer chain to be designed like that.
Conversion to RGB32 or RGB24 before the mixer is just a compatibility option for old GPUs that can't provide any suitable Y'CbCr surfaces for the VMR-9 or EVR mixer that for some reason demand such support.

Absolutely all current internal shaders can be replaced by a set I've written (and a selection of a few more). I highly doubt there will be anyone that will deny that the versions I've written are superior. I'll happily defend that statement if someone wants to challenge me. The "YV12" shader was one of the first I've re-written for MPC-HC (last September). See the OP and the first few posts from the shaders thread for reference.

Advanced deinterlacing methods are not exclusive to ATi hardware. The nVidia and (recent) Intel solutions include those, too. Software deinterlacing has included several advanced methods for more than a decade.
The current GPUs just prefer to do deinterlacing with NV12 input it seems. The deinterlacing capabilities of a GPU can be checked with the DXVAchecker program.

[oddball]

I'm quite happy with things the way they are now. I can now use D3D tickbox and get MadVR with exclusive mode on secondary display. All menu's and controls appear to function correctly. The only snag I had was my GPU is not fast enough to handle 720p with subtitle heavy video at 720p (desktop res and power of 2). I wanted to use softcubic 100 on chroma and spline 4 tap on luma up and down. But it was dropping frames too much. I've ended up overclocking my G210 and things are a LOT better (see link below on the overclock)! :)

http://www.techpowerup.com/gpuz/79mv/

I'll probably upgrade my card at some point though as it does get quite hot since it's passively cooled. Max temp after a 25 minute episode was 82 degrees C. But the max operating temp is 105c so not too worried.

[madshi]

The native surface blitting from Y'CbCr to RGB on GPUs have incoherent results. Newer nVidia models force a bilinear filter on doubling the dimensions of the chroma data, which can't be disabled. Older nVidia models, ATi and Intel models don't filter, so the chroma is resized with the nearest neighbor method.
I've recently asked madVR users to run tests for me on their GPUs. The result is that all DX9 NVidia GPUs that have been tested have forced some kind of chroma upsampling with no way to turn it off. On the other hand, with ATI all GPUs have used nearest neighbor when using StretchRect with D3DTEXF_NONE. You can however make ATI GPUs use bilinear chroma upsampling by using D3DTEXF_LINEAR in the NV12 -> RGB StretchRect call.

I'm quite happy with things the way they are now. I can now use D3D tickbox and get MadVR with exclusive mode on secondary display. All menu's and controls appear to function correctly.
Good to hear, thanks for feedback.

[Ger]

@Ger: Thank you for testing. I already thought my changes to the bicubic resizer wouldn't make much of a difference (the output assembly didn't change much). Bicubic resizing in a single pass with the current matrix method is sub-optimal anyway. I hope you have more luck when other two-pass resizing modes are added.

I'm happy as long as A=-1.00 works. I don't remember seeing much of a difference between that and the other two when I was using Nvidia. I don't remember anyone else reporting this issue either, so I don't think it's widespread, so feel free to not worry about it and prioritize other stuff. ;)


I do have some remarks, of course. (I'm in a technical mood/mode today.)
:thanks: for trying. Don't get your hopes up that I will actually understand it though. ;)


Chroma up-sampling is something best left to a custom mixer. The native surface blitting from Y'CbCr to RGB on GPUs have incoherent results. Newer nVidia models force a bilinear filter on doubling the dimensions of the chroma data, which can't be disabled. Older nVidia models, ATi and Intel models don't filter, so the chroma is resized with the nearest neighbor method. Of course, neither forcing bilinear filtering nor skipping filtering is a good solution. However, I can understand that adding a GUI option in the video section of the drivers with a range of chroma resizing filters that range from unfiltered to something like Lanczos256 would be rather much to ask from GPU driver developers.
The only thing I can do at the moment is integrating the shaders I've written in a similar way as the color management and dithering function, making in effect half a mixer. That would work okay as a user-selectable option, but not as an automatic one.
The other (preferred) option would be to discard the EVR and VMR-9 mixer and give the shared renderer part of VMR-9 (renderless) and EVR CP a custom mixer. The hard parts are that I've haven't seen any mixers with a GPL license around, I can't just write one on my own, without months worth of lessons in media handling like this in my spare time and lastly, I wouldn't know a good name for the renderer, as (renderless) and CP are what would remain of the original names.

I'm the one that pushed conversion to RGB32 or RGB24 to the very bottom of the mixer input priority list. All the current decoders are natively NV12, YV12, I420 and YUY2 anyway. With the conversion to RGB32 or RGB24, after having conversion from Y'CbCr to RGB, the resulting floating points are rounded to 8-bit integer. With some luck, there's some dithering involved (that can't be compared to the internal 32²||128² dither maps and randomized dithering methods). Anyway, this kind of conversion is pretty lossy. It's completely unacceptable for any renderer chain to be designed like that.
Conversion to RGB32 or RGB24 before the mixer is just a compatibility option for old GPUs that can't provide any suitable Y'CbCr surfaces for the VMR-9 or EVR mixer that for some reason demand such support.


A lot of this is too technical for me and over my head, because I don't know what goes on inside the renderer or even understand the mixer concept. I still don't quite understand why apparently the old method was bad and the new method is good when only the new method has blocky reds without shaders. I guess for other reasons then.

But let me try to guess/understand from an end-user's perspective, and please let me know if I'm even close to grasping this:

Are you saying that in old unaffected builds, like in 2833 and still in EVR Sync or plain EVR, when the renderer gets NV12 from the decoder (according to pin info) it performs a (high quality) conversion to RGB32 first and uses that for the "mixer input"? And you wanted NV12 mixer input and changed this to prioritize feeding the same NV12 colorspace the renderer gets from the decoder to the mixer in either 2837 (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=revision&revision=2837) or 2839 (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=revision&revision=2839) and not in 2863 (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=revision&revision=2863)? That is why the bad chroma is visible already in r2840?

The "YV12" shader was one of the first I've re-written for MPC-HC (last September). See the OP and the first few posts from the shaders thread for reference.
Obviously if you (re)wrote it you should get credited, and of course I take your word for it. I just said "by Leak" because I think I remember he posted the original in this thread a few years ago because of similar blocky reds with ATI issues. But I'm not even sure I remember that part correctly. I was using Nvidia at the time and didn't really pay attention.


Absolutely all current internal shaders can be replaced by a set I've written (and a selection of a few more). I highly doubt there will be anyone that will deny that the versions I've written are superior. I'll happily defend that statement if someone wants to challenge me.
I have no reason or intention to challenge that. I have only tried a few of your shaders.

The reason I think that particular "YV12" shader is the easiest solution for most people for the time being (which is maybe what you are responding to here?) is that it is embedded already in all builds, and so is easy to use. It fixes the blocky reds in EVR-CP and doesn't break anything (hardly any change at all) if you switch to already "not blocky" EVR Sync or RGB32 (Full/HQ) output from the decoder.

OTOH, if for example I use either of your optimized paths for fp/integer trios of shaders (fixes the blocky reds when present), they will (or at least it did for me) actually cause blocky reds in EVR Sync or with Full/HQ converted RGB32 from the decoder. So we have to remember to switch shaders when we switch settings. Of course if you know/recommend a better shader (or set of shaders) than the YV12 one that doesn't break anything when changing settings/renderers then I'm open to suggestions for my own use, but it will still be to complicated to recommend custom/external shaders for the average ATI/EVR-CP user with blocky reds until they are integrated IMHO.


Advanced deinterlacing methods are not exclusive to ATi hardware. The nVidia and (recent) Intel solutions include those, too. Software deinterlacing has included several advanced methods for more than a decade.
The current GPUs just prefer to do deinterlacing with NV12 input it seems. The deinterlacing capabilities of a GPU can be checked with the DXVAchecker program.

I don't know if that was meant for me as I never said anything different, and I did actually know that already. We have tested with DXVAChecker before. ATI needs NV12 for Vector Adaptive. Nvidia will work with YV12, NV12 and many more for their best "spatial-temporal" method. Not with RGB32 though. None of the software methods in ffdshow look as good as hardware. Yadif2x is pretty good, but has artifacts and increased CPU usage that can make a difference if already decoding by software/CPU. Dscaler ivtc mod is reportedly good for IVTC, but not much use for my interlaced content (which is 99% DVB/PAL).

When your tester builds are used, ATI's hardware deinterlacing with the internal MPEG-2 decoder looks noticeably better than in trunk builds with all of the EVR renderers. :) The decoder is outputting NV12 and not YUY2 as in the trunk builds, so "VectorAdaptiveDevice" (and "MotionAdaptiveDevice") can be used, while YUY2 is restricted to the third best ATI method (AdaptiveDevice). Maybe whatever change you made to accomplish that could be committed sooner than the other stuff, if it's not too integrated with your other features?

[Ger]

I've recently asked madVR users to run tests for me on their GPUs. The result is that all DX9 NVidia GPUs that have been tested have forced some kind of chroma upsampling with no way to turn it off. On the other hand, with ATI all GPUs have used nearest neighbor when using StretchRect with D3DTEXF_NONE. You can however make ATI GPUs use bilinear chroma upsampling by using D3DTEXF_LINEAR in the NV12 -> RGB StretchRect call.

Do you think that will fix the blocky reds in EVR-CP with no manually applied shaders? If it does you all know what my vote is, unless it ruins any significant future plans. ;)

Edit: Maybe something happened here (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc/trunk/src/filters/renderer/VideoRenderers/DX9RenderingEngine.cpp?r1=2837&r2=2836&pathrev=2837)?

[pirlouy]

You don't need to run the GUI itself all the time but you need it to be installed and you shouldn't kill it's backgroung processes (AMD External Events Service/Client Module...).

Of course, you can live without it, as you can live without the driver itself but you are only asking for trouble because it is needed for full functionality.
Honestly, I doubt this. CCC is optional, so I really think it's just a GUI. I install it anyway. But I have disabled all services and CCC, and I don't have problems.
Maybe I miss something, and you're right. But it would be cool to know EXACTLY what dependences are.

[mr.duck]

I have some experience with AMDs drivers. DON'T install the CCC and go to services control pannel and block all AMD Radeon related services from loading like external events blah blah. This setup gets best performance/fastest boot times and less problems (like changing AA mode and madVR doesn't work properly won't happen without CCC). I even worked out how to manually edit some of the settings in the registry to turn off all the sh!t video enhancements that ruins picture quality.

[CruNcher]

I've recently asked madVR users to run tests for me on their GPUs. The result is that all DX9 NVidia GPUs that have been tested have forced some kind of chroma upsampling with no way to turn it off. On the other hand, with ATI all GPUs have used nearest neighbor when using StretchRect with D3DTEXF_NONE. You can however make ATI GPUs use bilinear chroma upsampling by using D3DTEXF_LINEAR in the NV12 -> RGB StretchRect call.


Good to hear, thanks for feedback.

I guess you refer to the lossy Surface states in the madnv12test ?, which indeed according to your test just change depending on the Controll Panel settings but stay lossy overall though it might be possible to go deeper via the NVAPI into those settings or ask Nvidia to make them available their though i didn't tried to include madnv12test as a 3D application and change the 3D performance settings for it also the driver was on the default quality level (which is @ application settings though and should have no impact) when i supplied my test results.

1 strange thing for example is this:

Inverse telecine off:

D3D9 Surface StretchRect:
D3DFMT_R8G8B8: creating GPU texture failed
D3DFMT_A8R8G8B8: lossy (16-235)
D3DFMT_X8R8G8B8: lossy (16-235)
D3DFMT_A8B8G8R8: creating GPU texture failed
D3DFMT_X8B8G8R8: creating GPU texture failed
D3DFMT_A2R10G10B10: lossy (16-236)
D3DFMT_A2B10G10R10: lossy (16-236)
D3DFMT_A16B16G16R16: StretchRect failed
D3DFMT_A16B16G16R16F: lossy (16-235)
D3DFMT_A32B32G32R32F: StretchRect failed

D3D9 Surface VideoProcessor:
D3DFMT_R8G8B8: creating GPU texture failed
D3DFMT_A8R8G8B8: lossy (16-235)
D3DFMT_X8R8G8B8: lossy (16-235)
D3DFMT_A8B8G8R8: creating GPU texture failed
D3DFMT_X8B8G8R8: creating GPU texture failed
D3DFMT_A2R10G10B10: lossy (16-236)
D3DFMT_A2B10G10R10: lossy (16-236)
D3DFMT_A16B16G16R16: lossy (16-235)
D3DFMT_A16B16G16R16F: lossy (16-235)
D3DFMT_A32B32G32R32F: lossy (16-235)

Inverse telecine on:

D3D9 Surface StretchRect:
D3DFMT_R8G8B8: creating GPU texture failed
D3DFMT_A8R8G8B8: lossy (16-255)
D3DFMT_X8R8G8B8: lossy (16-255)
D3DFMT_A8B8G8R8: creating GPU texture failed
D3DFMT_X8B8G8R8: creating GPU texture failed
D3DFMT_A2R10G10B10: lossy (16-255)
D3DFMT_A2B10G10R10: lossy (16-255)
D3DFMT_A16B16G16R16: StretchRect failed
D3DFMT_A16B16G16R16F: lossy (16-191)
D3DFMT_A32B32G32R32F: StretchRect failed

D3D9 Surface VideoProcessor:
D3DFMT_R8G8B8: creating GPU texture failed
D3DFMT_A8R8G8B8: lossy (16-255)
D3DFMT_X8R8G8B8: lossy (16-255)
D3DFMT_A8B8G8R8: creating GPU texture failed
D3DFMT_X8B8G8R8: creating GPU texture failed
D3DFMT_A2R10G10B10: lossy (16-255)
D3DFMT_A2B10G10R10: lossy (16-255)
D3DFMT_A16B16G16R16: lossy (16-255)
D3DFMT_A16B16G16R16F: lossy (16-191)
D3DFMT_A32B32G32R32F: lossy (16-192)

How can this have an impact on chroma in the test, or can results differ per run ?
seems so i just enabled it again and get different results from the two previous ones hehe funny ;)

after reenabling Inverse Telecine:

D3D9 Surface StretchRect:
D3DFMT_R8G8B8: creating GPU texture failed
D3DFMT_A8R8G8B8: lossy (16-190)
D3DFMT_X8R8G8B8: lossy (16-190)
D3DFMT_A8B8G8R8: creating GPU texture failed
D3DFMT_X8B8G8R8: creating GPU texture failed
D3DFMT_A2R10G10B10: lossy (16-191)
D3DFMT_A2B10G10R10: lossy (16-191)
D3DFMT_A16B16G16R16: StretchRect failed
D3DFMT_A16B16G16R16F: lossy (16-178)
D3DFMT_A32B32G32R32F: StretchRect failed

D3D9 Surface VideoProcessor:
D3DFMT_R8G8B8: creating GPU texture failed
D3DFMT_A8R8G8B8: lossy (16-190)
D3DFMT_X8R8G8B8: lossy (16-190)
D3DFMT_A8B8G8R8: creating GPU texture failed
D3DFMT_X8B8G8R8: creating GPU texture failed
D3DFMT_A2R10G10B10: lossy (16-191)
D3DFMT_A2B10G10R10: lossy (16-191)
D3DFMT_A16B16G16R16: lossy (16-190)
D3DFMT_A16B16G16R16F: lossy (16-178)
D3DFMT_A32B32G32R32F: lossy (16-178)

:) So now the question would be how reliable are these measurements in real, or is Nvidias driver non deterministic ;) ?

[Damien147]

Also tested the chroma upsampling issue (blocky reds (http://i.imgur.com/1k7SI.png)) with that Nvidia laptop and the same monitor connected via HDMI, and it's not affected at all, so that is apparently also (still) an ATI-only issue.

In the meantime the first workaround, the "YV12 chroma upsampling shader", is a quick and easy solution for affected ATI/EVR-CP users.


This is the answer I've been looking.:thanks:

Is this (http://sourceforge.net/apps/trac/mpc-hc/ticket/1120) the patch that changed things?

I'm a noob and I can't understand exactly the description,when using ffdshow for decoding I get nv12 output in mpc-hc.This is intended according to the patch,right?
But when using mpc-hc for decoding on the same video I get rgb32 output with different but bad chroma result:confused:

[madshi]

How can this have an impact on chroma in the test, or can results differ per run ?
seems so i just enabled it again and get different results from the two previous ones hehe funny ;)

:) So now the question would be how reliable are these measurements in real ;) ?
The measurements should reliably show what the StretchRect operation produced. The results are stable with ATI and unstable with NVidia. I don't think it's a bug in madNV12Test. I think it just shows that with NVidia drivers, NV12 -> RGB StretchRect is not always reliable. Which means that madVR for example is never going to use NV12 -> RGB StretchRect with NVidia hardware/drivers.

[CruNcher]

Yep no doubt in that if your measurements are correct then it seems to be not reliable and should be replaced, also a interesting inside look into ATI and Nvidias Video Handling Level some oldshool ATI we are better then Nvidia in Video seems to be still alive deep down in the Driver also seeing some UVD 3 results lately makes me wonder if they didn't back on track also in Video after they run over Nvidia in 3D efficiency ;)

[Ger]

This is the answer I've been looking.:thanks:

Yeah, I think you asked some of the questions I was referring to in that post, so I'm glad it helped.

Regarding your other questions, my tests only show roughly when it happened. I'm no dev either, and I have no idea specifically what change caused it or why it was changed or why it is or isn't a good idea to change it again. That's what I'm trying to ask/understand myself. I'm just testing/reporting and speculating/asking based on the little tidbits I understand.

My theory right now based on what JanW and madshi said is the bilinear filtering vs. nearest neighbor and the changes in r2837, but I'm utterly clueless, so you don't wanna know what my changing theories are all the time. So please ask someone else, or just wait and see how it all develops. ;)

[JanWillem32]

@madshi and CruNcher: StretchRect is in EVR CP and VMR-9 (renderless) as an "all methods failed" backup solution. It disables all further shaders, 10- 16- and 32-bit surfaces, dithering and color management. It's been removed in EVR Sync for a good reason, as the problems with StretchRect are well known.

@Damien147: That's one of my older works. Im my builds I used the format merit list that was already in EVR sync as a base, and expanded the list to include all possible formats that the EVR mixer could accept.
I mostly wrote that patch in the link to eliminate the YV12/I420/IYUV to YUY2 conversion. Doing half chroma up-sampling before the mixer is just dumb. I added conversion to NV12 as a preferred option and set conversion to RGB32 as a backup if that fails.

@Ger: That code in the link was part of my first contribution to the renderer. It was mostly to fix the assignment of surfaces and the 10-bit output mode.
I didn't commit any of the visible shaders in the trunk build. I want to remove all them as a first step, and insert new ones with proper names.
The lack of chroma up-sampling has always been there for those that use NV12 output from external decoders, by the way. It's not that new.
For the problem with RGB32 input: once I figure out how to make message windows, I can add a simple warning message window to indicate that the video stream format in the file doesn't match the input stream of the mixer. (And of course add warnings if items in the renderer fail.)
The reason I don't dare to commit anything at the moment is because I broke the VSync offset function in my build and it's very hard to repair. The code for timing items is complex.

[madshi]

StretchRect is in EVR CP and VMR-9 (renderless) as an "all methods failed" backup solution. It disables all further shaders, 10- 16- and 32-bit surfaces, dithering and color management. It's been removed in EVR Sync for a good reason, as the problems with StretchRect are well known.
What is used instead for the YV12/NV12 -> RGB conversion?

[Ger]

The lack of chroma up-sampling has always been there for those that use NV12 output from external decoders, by the way. It's not that new.


No it's not a problem in r2833 or in EVR Sync when outputting NV12 from ffdshow to the renderer with no manual shaders applied, but it is in r2840. That's what I've been trying to tell you for a while now. It was broken in EVR-CP only, and in that revision range (2834-2840). That's why I'm saying several ATI owners are noticing a regression. That is also why I listed two suspected culprit revisions and maybe especially that last piece of code I linked to.

The situation with YUY2 output from decoder is exactly the same as with NV12. OK in EVR Sync and in old builds. Broken (as in very blocky) in EVR-CP 2840 and up.

It may not be quite as good as madVR or EVR Vanilla in those old builds or in EVR Sync, but it's much much better than EVR-CP in 2840 and later, and not that far away from the other two.

The YV12 shader makes a massive difference when it's broken/blocky and hardly any difference at all when it's already OK. See my previous posts for details on that. Unlike the YV12 shader, your optimized shader path inverts the situation. It makes blocky stuff OK and OK stuff blocky.

You have an ATI card right? Provided all ATI cards behave the same with this issue, which I'm assuming until I'm told otherwise, try feeding NV12 from ffdshow to EVR Sync in any build or to EVR-CP in 2833 (from my uploaded zip or from xvidvideo.ru) and see for yourself with a suitable red logo or something like that.

[v0lt]

@Ger
Bug appeared in version 2837. Here version 2836 and 2837 (http://www.mediafire.com/?6m45dkc837m7k). You can check out.

[Ger]

Thank you v0lt! :)

I confirm 2837 is the culprit. That was the revision I linked to last with the removed/changed stretchrect bilinear filtering stuff madshi was talking about, and one of the two on my first list of suspects.

Finally we're getting somewhere. :)

[JanWillem32]

@madshi: ARGB output is requested from the external EVR/VMR-9 mixer, as far as I can see. Both mixers don't limit or round the outputs, so values beyond the regular [0, 1] interval with floating-point conversions are left intact. The transfer matrix for the conversion is generally selected automatically by EVR. http://msdn.microsoft.com/en-us/library/ms694036%28v=vs.85%29.aspx I expect a similar item will be in VMR-9.

@Ger: http://forum.doom9.org/showthread.php?p=1463132#post1463132 I could also replicate that later on.
EVR sync uses StretchRect (unfortunately I just found that out, it's a bit hidden in the code). I haven't paid much attention to Sync in development. We could use a developer that can help integrate the sync clock into the shared EVR CP/VMR-9 (renderless) renderer where the entire renderer stems from. (And clean up its many flaws in the process.)
I've looked up what the YV12 shader does again. (I haven't looked at it in a while.) It converts an area of 9 pixels with an inaccurate, truncated bt.601 (SD video) matrix and averages all values. My "4÷2÷0 chroma blur for SD&HD video input on old and slow PS 2.0 hardware" shader at least blurs with bilinear filter, using 4 pixels with correct SD and HD color matrices. It indeed hurts quality a lot if the chroma input is filtered with a bilinear filter during color conversion and then filtered again by this type of shaders. (I use "blurring", as "up-sampling" is better reserved for the windowed scalers.)
I very much prefer no filtering to take place by default at all, than having to waste resources on a default or forced bilinear filter on chroma data. Options to up-sample chroma can be added like the regular scaling options. It will need a warning for those with a nVidia card not to enable that option.
Having swscale to convert every input format for the mixer to RGB32 as it was before, would be pretty bad. On low-end CPU's it wasted a lot of processing on the bilinear filtering, RGB conversion and rounding to 8-bit. Output of 10-, 16- or 32-bit color formats is impossible with this method, so the color accuracy also suffers (on top of losing the advanced deinterlacing filters available with NV12 in the mixer).

[madshi]

ARGB output is requested from the external EVR/VMR-9 mixer, as far as I can see.
So basically the conversion from YV12/NV12 to RGB is done by some internal Microsoft EVR/VMR code? So we don't know how it's technically done? Could be StretchRect again?

[JanWillem32]

It could be a modified StretchRect with custom color matrix support or some other interface with the video card's drivers. VMR-9 doesn't take any 4:2:2 formats in my case. Other than that, both mixers use a reasonably well-matching color matrix for both bt.709 and bt.601 automatically with various Y'CbCr inputs.

[madshi]

Ok, thanks, that's good to know.

[Casshern]

Hi Ger,

this behavior is intentional - before 2840 everything was converted to RGB32 before giving it to the mixer. This was probably done to avoid a lot of incompatibilites and had the advantage that the software routine used did some sort of chroma upsampling. This has been removed by Janwillem so that the mixer gets what the decoder outputs, you are now at the mercy of your videocard driver. Unfortunately AMDs driver do not upsample chroma. Another drawback is that you cannot use any Catalyst before 10.11 with the new MPC HC versions, which is extremely annoying as newer versions have the dreaded 99% load bug and the mouse lag bug. I can see where Janwillem is headed and agree with his goals and thank him for his efforts - but he could have left the RGB32 conversion as an option -> that would have made everybody happy.


No it's not a problem in r2833 or in EVR Sync when outputting NV12 from ffdshow to the renderer with no manual shaders applied, but it is in r2840. That's what I've been trying to tell you for a while now. It was broken in EVR-CP only, and in that revision range (2834-2840). That's why I'm saying several ATI owners are noticing a regression. That is also why I listed two suspected culprit revisions and maybe especially that last piece of code I linked to.

The situation with YUY2 output from decoder is exactly the same as with NV12. OK in EVR Sync and in old builds. Broken (as in very blocky) in EVR-CP 2840 and up.

It may not be quite as good as madVR or EVR Vanilla in those old builds or in EVR Sync, but it's much much better than EVR-CP in 2840 and later, and not that far away from the other two.

The YV12 shader makes a massive difference when it's broken/blocky and hardly any difference at all when it's already OK. See my previous posts for details on that. Unlike the YV12 shader, your optimized shader path inverts the situation. It makes blocky stuff OK and OK stuff blocky.

You have an ATI card right? Provided all ATI cards behave the same with this issue, which I'm assuming until I'm told otherwise, try feeding NV12 from ffdshow to EVR Sync in any build or to EVR-CP in 2833 (from my uploaded zip or from xvidvideo.ru) and see for yourself with a suitable red logo or something like that.

[Ger]

StretchRect is in EVR CP and VMR-9 (renderless) as an "all methods failed" backup solution. It disables all further shaders
That can't be true if EVR Sync is using it and EVR-CP was in r2836, since shaders are working in both cases.


10- 16- and 32-bit surfaces

OK, I'll buy that since I can get the 10-bit backbuffer in 2836, but only 8-bit surface. In 2837 I can get 10 and 16-bit surface. However, whatever quality improvement that is supposed to give it's negligible compared to the quality drop from 2836 to 2837 with no shaders. Out of all these new options, that is the really noticeable one, and it's in the wrong direction. Fortunately a shader can save the day for those who are lucky enough to know about it.


dithering


The option is only there in your builds and not in EVR Sync, so I wouldn't know, and I don't understand what what it does really. I was never able to see the difference anyway (not that I looked that hard or compared screenshots or anything). But dithering is apparently better than rounding for audio and I guess that applies to video as well, so I guess I'll have to believe that. Which dithering method do you recommend for general use? I used the static ordered one since it was selected by resetting the settings.


color management

Seems to work for me in 2836. Colors are less bright with it enabled, just like when it's enabled in your recent tester builds. I have no idea how "correct" it is, nor do I care as long as it looks vaguely acceptable to the naked eye, but there is a difference in 2836 with it on/off, that's for sure.


Having swscale to convert every input format for the mixer to RGB32 as it was before, would be pretty bad. On low-end CPU's it wasted a lot of processing on the bilinear filtering, RGB conversion and rounding to 8-bit.
CPU is hardly an issue. tetsou55 has said something along the lines of more than 5-year old CPUs not being supported officially, or non-SSE2. My CPU is actually 5 years old, and the difference between 2836 and 2837 is very small in terms of CPU use.

Output of 10-, 16- or 32-bit color formats is impossible with this method, so the color accuracy also suffers

Well, personally I couldn't care less about color accuracy as long as the colors seem subjectively reasonable to me. The average user certainly isn't calibrating his display, or even aware of what panel he's got. But I understand that people who are really interested in this stuff want accurate colors, so point taken.


@Damien147: That's one of my older works. Im my builds I used the format merit list that was already in EVR sync as a base, and expanded the list to include all possible formats that the EVR mixer could accept.
I mostly wrote that patch in the link to eliminate the YV12/I420/IYUV to YUY2 conversion. Doing half chroma up-sampling before the mixer is just dumb. I added conversion to NV12 as a preferred option and set conversion to RGB32 as a backup if that fails.
The internal software decoders are still doing that in current trunk builds though, by preferring YUY2. But other/external decoders are OK (or internal in your tester builds and the main decoder in bobdynlan's swscaler mod).


EVR sync uses StretchRect (unfortunately I just found that out, it's a bit hidden in the code). I haven't paid much attention to Sync in development. We could use a developer that can help integrate the sync clock into the shared EVR CP/VMR-9 (renderless) renderer where the entire renderer stems from. (And clean up its many flaws in the process.)

The reason I don't dare to commit anything at the moment is because I broke the VSync offset function in my build and it's very hard to repair. The code for timing items is complex.

OK. Thanks for the info. Does the broken vsync in your builds apply only to "Alternative Vsync" as you mentioned before, or to all vsync code in EVR-CP? Also, all vsync options in EVR Sync are untouched and OK right?

When/if EVR Sync and EVR-CP are merged, please keep as many vsync options as you can. EVR Sync with Sync Video to Display (http://www.ostrogothia.com/?page_id=1216) inserts a SyncClock filter and the audio renderer shows slaving info "graph clock" and works differently from all the other options. Even though it probably has other disadvantages, this is the only option that never freezes the picture on seek for me, so it's nice to keep the options, at least for debugging and working around such issues.

My other major issue with EVR-CP's vsync was hopefully fixed in r3009 thanks to Aleksoid.

Beliyaal who's behind most of the vsync code in EVR-CP seems to have moved on to other things, but the vsync code in EVR Sync was written by ar-jar/Arto well after the Beliyaal EVR-CP code because he wasn't quite happy with how EVR-CP did it, I guess. But when Arto upgraded from XP to Win7 his tearing issues were solved by Aero anyway, so he didn't see the point in working on EVR Sync anymore. At least that's how I understood his blog at the time. The point to all this is that maybe Arto would be willing to help out with problematic vsync issues if you ask him. At least he's answered questions on his blog not so long ago, and he seems to understand vsync stuff very well. The last sentence in his last blog post (http://www.ostrogothia.com/?p=1884) indicates he may be at least somewhat interested in working on OSS again.


I've looked up what the YV12 shader does again. (I haven't looked at it in a while.) It converts an area of 9 pixels with an inaccurate, truncated bt.601 (SD video) matrix and averages all values. My "4÷2÷0 chroma blur for SD&HD video input on old and slow PS 2.0 hardware" shader at least blurs with bilinear filter, using 4 pixels with correct SD and HD color matrices. It indeed hurts quality a lot if the chroma input is filtered with a bilinear filter during color conversion and then filtered again by this type of shaders. (I use "blurring", as "up-sampling" is better reserved for the windowed scalers.)

When I try to compile that shader with PS 2.0 or 3.0 I get:
C:\Windows\system32\memory(27,47): error X1516: not enough actual parameters for macro 'sp'
C:\Windows\system32\memory(27,47): error X3000: unrecognized identifier 'sp'

So again, is there another/better shader than the YV12 one that you can recommend that doesn't break anything with filtered (as in not more than adding a slight almost unnoticeable blur like the YV12 shader) or unfiltered chroma, any source res, any display res and any surface type? If not, then I'll stick with the YV12 shader for now.


I very much prefer no filtering to take place by default at all, than having to waste resources on a default or forced bilinear filter on chroma data. Options to up-sample chroma can be added like the regular scaling options. It will need a warning for those with a nVidia card not to enable that option.


So this would work like an embedded/automatic shader, right? This would be like enabling the YV12 shader (or something similar that works reasonable for all surfaces/filtered/unfiltered/resolutions) for ATI users, only from the options like the scalers? If so can it be enabled by default when an ATI card is detected, so the user doesn't have to know about the option and won't get bad chroma if unaware of this issue?

(on top of losing the advanced deinterlacing filters available with NV12 in the mixer).

This can't be true either. Hardware deinterlacing works just fine in EVR Sync and in r2836. I've been using it for years. Feed NV12 from ffdshow and get great quality VectorAdaptiveDevice with ATI. Feed YUY2 and get the third best AdaptiveDevice (still ATI). Nvidia would probably yield similar quality (unnamed spatial-temporal) for both of those colorspaces. Feed RGB32 from ffdshow and get no deinterlacing at all (ProgressiveDevice). You can check this for yourself with ffdshow, and change the flags (auto, force bob, weave) and field order on the fly, and see the visual difference immediately. It matches the results in DXVAChecker where you can see directly the deinterlacing device/method that is used.

Hi Ger,

this behavior is intentional - before 2840 everything was converted to RGB32 before giving it to the mixer. This was probably done to avoid a lot of incompatibilites and had the advantage that the software routine used did some sort of chroma upsampling. This has been removed by Janwillem so that the mixer gets what the decoder outputs, you are now at the mercy of your videocard driver. Unfortunately AMDs driver do not upsample chroma. Another drawback is that you cannot use any Catalyst before 10.11 with the new MPC HC versions, which is extremely annoying as newer versions have the dreaded 99% load bug and the mouse lag bug. I can see where Janwillem is headed and agree with his goals and thank him for his efforts - but he could have left the RGB32 conversion as an option -> that would have made everybody happy.

I guess we roughly agree then.

If we ignore the problem with old drivers for a moment, and it turns out he can add an automatic shader for ATI to fix the issue rather than having to revert to the old filtering, then that is maybe better, since 10-bit and higher surfaces can be used by those who care. Maybe even by me if I don't notice any downside (I've been running HFPP in JanW's builds lately with no issues - with FFPP and color management the GPU clocks increase though which I'm not interested in). I don't mind enabling something that's supposed to improve stuff according to more knowledgeable people, whether it's actually noticeable to me or not. Maybe I can get a placebo effect out of it at the very least. ;)

I still don't understand the above deinterlacing issue though. Why is hw deinterlacing only dependent on what the decoder outputs to the renderer, and not what the mixer gets internally if the deinterlacing happens in the mixer like JanW says, and the mixer gets RBG32 in old builds/EVR Sync. :confused:


@bobdynlan
Some feedback for your swscaler mod (running 3011 Black Edition at the moment):

Since JanW's changes seem to be some time away from making it to the trunk, any chance the options you added to the main decoder can be added to the MPEG-2 one as well? That's were I could really use those options. I'm especially interested in getting NV12 output for hardware deinterlacing (triggers better quality vector adaptive on ATI). The rest of the new options aren't that important to me, since there are other ways to work around the chroma thing.

Support for 4:2:2 sources and controllable hw deint flags like ffdshow has would be nice as well, since ffdshow also has some issues with LAV Splitter (crash on seek with libmpeg2 and chokes on DVB subtitles with both libmpeg2 and libavcodec) that aren't there in the MPC-HC internal libmpeg2 based decoder. But I guess that's not really related to what you've been doing.

Moving on from the wishes; I see the exact same behavior you described in the readme. Everything seems to work as intended, and I hope it will be committed.

I'm also very pleased to hear you're still planning to resurrect the GUI project. :thanks:

I suggest you start your own thread when it's ready for testing again though, specifically four your builds, so it hopefully doesn't get bogged down with endless unrelated general GUI discussions, like in the old GUI thread that was eventually locked.

[clsid]

I understand that a goal is to make MPC output the highest possible quality, but that should not make MPC worse/unusable for a large part of the user base. Everything that requires the use of shaders or other hardware dependent stuff should be optional, meaning that a shader shouldn't be used to fix something that used to work (reasonably) fine in the past without shaders. MPC should continue to work on older hardware.

I will repeat again what I said some time ago: it is unacceptable to force people to update to a specific new driver to be able to use (recent builds of) MPC. Not everyone is a nerd that hangs out at Doom9. Most users are barely able to install basic software, let alone update a driver. Moreover, with older hardware it often isn't even possible to update a driver.

If unconditionally reverting part of the changes from 2837 isn't possible due to new functionality, then the old behavior could be used conditionally. Here is some pseudocode:

bool useOldMixer() {
// check graphics card brand and driver version, return True if they are incompatible with new mixer implementation
// see DXVA compatiblity check for code that does a similar check
}

also add a hidden option "forceOldMixer" for testing purposes to manually force usage of the old mixer behavior.

if(forceOldMixer || useOldMixer) {
// old mixer behavior
} else {
// new mixer behavior
}Is there a list of OS/hardware/drivers that are known to fail (black screen) or give crap output?

The function useOldMixer() could just return false initially, and we can adapt it along the way based on bug reports.

[fastplayer]

rev3006 broke play/pause via left-click when hiding the menu.

[v0lt]

I propose to make a DirectShow mode the default for MOV-files (instead of QuickTime).
What do you think about this?

[v0lt]

rev3006 broke play/pause via left-click when hiding the menu.
I have works fine.

[fastplayer]

I have works fine.
It doesn't work for me, neither in XP or 7. It only does when the menu is not hidden.

[v0lt]

@fastplayer
I see a bug when there is only a frame and caption. Then operate as a "frame only" and "hide borders" (the mouse is used to move the window). It is wrong for "hide menu" mode. I'll see what can be done.
Thanks.

[Mercury_22]

It doesn't work for me, neither in XP or 7. It only does when the menu is not hidden.

Change your mouse PLAY/PAUSE key (to Middle Down)

[Ger]

I propose to make a DirectShow mode the default for MOV-files (instead of QuickTime).
What do you think about this?

I always set both QT and Real to DirectShow anyway (after installing QT Lite and RA) to get the OSD working, and most stuff I try seem to work for me, so I vote yes.

I don't know what (if any) the negative consequences are though, as I don't play much of that material.

Maybe clsid can comment, as I suspect he knows quite a bit about that stuff.

[v0lt]

@fastplayer
r3015: fixed play/pause via left-click when hiding the menu

I always set both QT and Real to DirectShow anyway (after installing QT Lite and RA) to get the OSD working, and most stuff I try seem to work for me, so I vote yes.

I don't know what (if any) the negative consequences are though, as I don't play much of that material.

Maybe clsid can comment, as I suspect he knows quite a bit about that stuff.
There may be problems with very old MOVs. But these files are very rare.

[clsid]

There is probably still stuff that is only playable using QuickTime, but with the recent improvements to the MP4/MOV splitter and the internal audio decoder, most MOV files should be playable with DirectShow. For example 3G2 on the other hand still requires QT.

The current framework selection on the formats page is not very flexible. It is currently also only not very obvious to end-users what the settings do and where to find them. I would suggest adding a new configuration page specifically for the frameworks and removing the dropdowns from the formats page. Something like this:

Options -> Playback-> Frameworks
[x] Use QuickTime framework for: [mov 3g2 3gp2 m4b] [RESETBUTTON]
[x] Use RealMedia framework for: [ra rm ram rt rv rmm] [RESETBUTTON]
So a checkbox for enabling use of a framework. A textbox with a list of file extensions. And a reset button to reset the list of extensions to internal defaults.
Shockwave (.swf) can simply be hardcoded internally.
The RTSP options from the Formats page can be moved to the new page as well.


The file extensions on the formats page also seem to be misused in other parts of the code that are unrelated to file associations. For example in the playlist code (to determine which files in a directory are media files). I suggest to add (four) dedicated internal lists of file extensions for that purpose (video, audio, image, playlist). Might also be a bit quicker than current code.

Once there is no longer any unrelated code depending on the lists on the Formats page, it becomes easier to rewrite the file associations code as well. Something I might do in the future.

[Ger]

A related wish that would make things a bit easier to configure: I'd like to see .mpcpl separated from the other playlists in formats. I always edit out all other playlist extensions from there, in order to use .mpcpl with MPC-HC, .m3u with audio players, .asx with WMP etc. Maybe adding a MPC-specific files (or MPC-specific playlists etc. if that's needed) category, like VLC does, and putting it there. MPC-specific extensions should be enabled by default I guess. I don't know if there are more of them.

[JanWillem32]

A small note on the on the chroma item:
We are discussing EVR CP, as I didn't change the status for VMR-9 (renderless) that never used the RGB32 conversions before the mixer. That means that VMR-9 (renderless) (on 3D surfaces mode) has always been with unfiltered chroma on all hardware, except recent nVidia GPUs.

@Casshern: In my builds I solved compatibility with older ATi drivers by adding conversions to NV12 as an option. It's not in the trunk build yet. RGB conversion before the mixer is still available for GPUs with compatibility problems with Y'CbCr surfaces. I hope that with updating swscale this conversion is fixed with more accurate options, as currently even SD and HD video color matrices are not passed to the convertor properly, along with other flaws.

That can't be true if EVR Sync is using it and EVR-CP was in r2836, since shaders are working in both cases.As far as I can see, EVR CP can't use StretchRect at all, that part of the code is reserved for VMR-9 (renderless) with the 2D surfaces mode. That's what disables shaders.
OK, I'll buy that since I can get the 10-bit backbuffer in 2836, but only 8-bit surface. In 2837 I can get 10 and 16-bit surface. However, whatever quality improvement that is supposed to give it's negligible compared to the quality drop from 2836 to 2837 with no shaders. Out of all these new options, that is the really noticeable one, and it's in the wrong direction. Fortunately a shader can save the day for those who are lucky enough to know about it.I believe it's one of the steps in the right direction. Trunk builds are meant for changing functions. Many updates are often required to make a large thing as a graphics engine to work properly.
For improving things, I've looked up the possibility of integrating a custom mixer to solve the chroma problem, along with other things. Note that I also consider the forced bilinear filter on nVidia hardware a problem.
The option is only there in your builds and not in EVR Sync, so I wouldn't know, and I don't understand what what it does really. I was never able to see the difference anyway (not that I looked that hard or compared screenshots or anything). But dithering is apparently better than rounding for audio and I guess that applies to video as well, so I guess I'll have to believe that. Which dithering method do you recommend for general use? I used the static ordered one since it was selected by resetting the settings.http://en.wikipedia.org/wiki/Dither It contains some very good images in the middle to bottom part of the page. Static ordered dithering used to be activated automatically with 10- and 16-bit surfaces. I only made it optional. The test mode is quite useful to see how a dithering mode works internally.
Static ordered dithering is the lightest option of three modes, so that's why it's in the "Optimal" profile. The random ordered method reduces the risk of creating visible patterns on plain surfaces and light gradients, but it's heavier due to the random turning, flipping and moving the position of the dither maps separately for red, green and blue. Both methods use a dithermap of 128² for FFPP and 32² for other modes. The random ditherer creates heavier (semi-random) noise and has no sampled map. It's mostly to provide a different type of post-processing.
There's no absolutely perfect option, people should just choose what type of dithering they can live with, as it will always generate noise.
Seems to work for me in 2836. Colors are less bright with it enabled, just like when it's enabled in your recent tester builds. I have no idea how "correct" it is, nor do I care as long as it looks vaguely acceptable to the naked eye, but there is a difference in 2836 with it on/off, that's for sure.Color management is for calibrated display devices with a .ICM profile installed system-wide. It's used to provide exact color matching of the rendered picture to the display device. For regular adjustments, the color control shaders can be used. I hope to integrate those in a while, since only the VMR-9 (windowed) renderer has color controls at the moment.
CPU is hardly an issue. tetsou55 has said something along the lines of more than 5-year old CPUs not being supported officially, or non-SSE2. My CPU is actually 5 years old, and the difference between 2836 and 2837 is very small in terms of CPU use.There are plenty of recent low-powered systems that really couldn't use EVR CP with software decoding of the 1080i/30 sample, but were fine with VMR-9 (renderless). It's still not completely even, unfortunately. Even when assuming that all CPUs have a lot more CPU power than those systems, there's currently no excuse for MPC-HC on default settings to be so much more CPU intensive than WMP12. There's a lot more optimizing in the code to do.
OK. Thanks for the info. Does the broken vsync in your builds apply only to "Alternative Vsync" as you mentioned before, or to all vsync code in EVR-CP? Also, all vsync options in EVR Sync are untouched and OK right?The main problem is the VSync offset function that's stuck at 0 internally. It doesn't matter if you don't use it anyway.
The other problem is pulldown. The EVR mixer can assist in dropping fake/duplicated frames in a 3:2 or other pull-down scheme, but the allocator-presenter is counting those frames as error frame drops, so it tries to purge and re-sync the mixer to try to correct it. That interrupts smooth playback, of course.
The last problem is the many conversions with integers, floats and doubles of the 100 nanosecond unit formats and the 1 second unit formats in the synchronization threads. A difficult programming problem, as it's mostly due to rounding issues in between synchronization items that are hard to trace.
Beliyaal who's behind most of the vsync code in EVR-CP seems to have moved on to other things, but the vsync code in EVR Sync was written by ar-jar/Arto well after the Beliyaal EVR-CP code because he wasn't quite happy with how EVR-CP did it, I guess. But when Arto upgraded from XP to Win7 his tearing issues were solved by Aero anyway, so he didn't see the point in working on EVR Sync anymore. At least that's how I understood his blog at the time. The point to all this is that maybe Arto would be willing to help out with problematic vsync issues if you ask him. At least he's answered questions on his blog not so long ago, and he seems to understand vsync stuff very well. The last sentence in his last blog post (http://www.ostrogothia.com/?p=1884) indicates he may be at least somewhat interested in working on OSS again.Thank you, I'll see if the management can convince him.
When I try to compile that shader with PS 2.0 or 3.0 I get:
C:\Windows\system32\memory(27,47): error X1516: not enough actual parameters for macro 'sp'
C:\Windows\system32\memory(27,47): error X3000: unrecognized identifier 'sp'
So again, is there another/better shader than the YV12 one that you can recommend that doesn't break anything with filtered (as in not more than adding a slight almost unnoticeable blur like the YV12 shader) or unfiltered chroma, any source res, any display res and any surface type? If not, then I'll stick with the YV12 shader for now.Over-filtering will always reduce quality and performance. I used to have a red-on black letter comparison picture in the OP between the YV12 shader and my very succesful first attempts to do it better.
The chroma blur shader requires a correction of "n" to "n.x, n.y". I probably forgot to test it after cleaning up some code. It's difficult to keep track of the currently 131 different shaders. That shader isn't the most popular item, anyway.
So this would work like an embedded/automatic shader, right? This would be like enabling the YV12 shader (or something similar that works reasonable for all surfaces/filtered/unfiltered/resolutions) for ATI users, only from the options like the scalers? If so can it be enabled by default when an ATI card is detected, so the user doesn't have to know about the option and won't get bad chroma if unaware of this issue?It's a back-up plan, but integrating the up-sampling and maybe chroma blur shaders with automatic switching for HD, SD, 4:2:0, 4:2:2 and 4:4:4 modes like the dithering function should be quite easy. The the EVR and VMR-9 mixer compatibility code can tell the renderer what format is being used.
Intel GPUs also skip chroma filtering by default, so there are 2 GPU brands to detect. I've never done this type of detection before, so I'll have to see if we can get that to work.
This can't be true either. Hardware deinterlacing works just fine in EVR Sync and in r2836. I've been using it for years. Feed NV12 from ffdshow and get great quality VectorAdaptiveDevice with ATI. Feed YUY2 and get the third best AdaptiveDevice (still ATI). Nvidia would probably yield similar quality (unnamed spatial-temporal) for both of those colorspaces. Feed RGB32 from ffdshow and get no deinterlacing at all (ProgressiveDevice). You can check this for yourself with ffdshow, and change the flags (auto, force bob, weave) and field order on the fly, and see the visual difference immediately. It matches the results in DXVAChecker where you can see directly the deinterlacing device/method that is used.I could never get external Y'CbCr input from ffdshow to up-sample in VMR-9 (renderless) and EVR CP without shaders. I had the same results as the pictures in the link of my earlier post.

[v0lt]

@clsid
I had similar ideas.

[fastplayer]

@fastplayer
r3015: fixed play/pause via left-click when hiding the menu
Confirmed. :thanks:

[tetsuo55]

@clsid
I had similar ideas.Ok then, you can go ahead and change it.


@Clsid: Can you give me an overview of everything you would like to see changed in mpc-hc?
As our biggest reseller you should have a bit more influence on future developments ;)

Maybe you could share your vision for ffdshow too? (but in its own thread)

[clsid]

@tetsuo55
Some ideas for MPC:
- Framework page (see discussion above)
- Remove dependencies of other code on Formats page (see above)
- Change Formats page name to File Associations
- Don't use groups of file extensions, but simple lists of individual file extensions. Use three lists: video, audio, playlist/other. This will simplify the file association code as well.
- Add file association options to installer, also create required reg keys for using the "Default Programs" functionality in Windows. I can do that one day if nobody else beats me to it.
- Improve file association code. Also separate for x86/x64.

- Move internal filters outside of the executable into a configurable location (subfolder by default). They will still be loaded without needing to be registered, so portability is kept intact. This was discussed yesterday in the LAVSplitter topic. Nevcairiel also likes that idea and it is even a requirement for easy integration for his filters.

- Automate the Frame Time Correction workaround. Detect when it is needed and apply it automatically.

- Unify the audio/sub stream selection. Always put it under the Play menu. Now its also under Navigate sometimes.

- Add an "enqueue" option to the playlist right-click menu for adding files.

- Don't dock the Playlist window (and other child windows) inside the MPC window, but let it dock to the sides of the main window. For example Winamp does that too.

- Add flip horizontal/vertical functions to View->Video Frame. Basically PnS rotate 180 degrees. (see Player->Keys). Could for example be mapped to Alt+numpad7/9.

- Separate settings for x86 and x64 builds.

- Only use the animated code paths in the subtitle renderer for formats that are actually animated. Should give nice performance boost.

There are just a few ideas from the top of my head. Most changes are relatively small and should therefore be doable for any dev that is willing to spend some time on MPC.

[madshi]

- Move internal filters outside of the executable into a configurable location (subfolder by default). They will still be loaded without needing to be registered, so portability is kept intact.
Yes, please.

The big question is if there are any devs willing to do these changes. They won't happen just by us wishing them to.

[tetsuo55]

Yes, please.

The big question is if there are any devs willing to do these changes. They won't happen just by us wishing them to.It's true that developers are scarce, but it does help to have a clear to-do list from which people who would like to work on mpc-hc can choose from.

[clsid]

nevcairiel might be willing to do that as it will allow integration of his splitters.

[mr.duck]

nevcairiel might be willing to do that as it will allow integration of his splitters.

That would be excellent. A very good idea IMO.

[Dstruct]

- Don't dock the Playlist window (and other child windows) inside the MPC window, but let it dock to the sides of the main window. For example Winamp does that too.

I prefer current MPC docking behaviour over Winamp's!

[Casshern]

@Casshern: In my builds I solved compatibility with older ATi drivers by adding conversions to NV12 as an option. It's not in the trunk build yet. RGB conversion before the mixer is still available for GPUs with compatibility problems with Y'CbCr surfaces. I hope that with updating swscale this conversion is fixed with more accurate options, as currently even SD and HD video color matrices are not passed to the convertor properly, along with other flaws.

Thanks!!!!!

[SamuriHL]

I'm very much in favor of the proposed changes, as well. Not that my opinion matters at all but I think moving the filters out of the exe should be a top priority so that people can "integrate" the filters they want to use and remove the ones they don't. Just a thought. :-)

[bobdynlan]

Just a personal concern - such drastic change from an all-in-one solution can be a killer blow to the project. At the very least, it should be backed up by some analysis - maybe alexins is able to help with that looking at xvidvideo.ru traffic. I'm willing to bet most people use the standalone exe and not only that, they also "clean up" translation and icons dll's...

Anyway, pushing this as the only way to integrate LAVF filters sounds like taking the easy route... but the outcome may not help MPC-HC.

[madshi]

Just a personal concern - such drastic change from an all-in-one solution can be a killer blow to the project.
?? In what way would it be any different to what we have now? Functionality would be *exactly* the same. It would still be an all-in-one solution in that sense that you download one package, don't have to install anything and it all just works. The only difference would be that it's not all in the exe, but in different files. But let's really SO unimportant.

[SamuriHL]

?? In what way would it be any different to what we have now? Functionality would be *exactly* the same. It would still be an all-in-one solution in that sense that you download one package, don't have to install anything and it all just works. The only difference would be that it's not all in the exe, but in different files. But let's really SO unimportant.

Exactly. The implementation details that were outlined in the LAV Splitter thread basically suggest that the filters used don't have to be registered, which means it can still be a very portable instance. This gives you more control over what to add/remove, not less. This should be seen as good news to those who don't want clutter on their machines.