MPC-HC tester builds for internal renderer fixes

[JanWillem32]

For making changes to the VMR-9 (renderless), EVR Custom Presenter, EVR Sync and subtitle renderers, I've been developing since December 2010. Because the main MPC-HC thread is for general discussion, I decided to make this thread to give users the opportunity to test changed or new renderer functions before finalizing them.
I already made some earlier tester builds and posted those on the main thread. From now on I'll post all of those in this thread. If anyone wishes to make suggestions, specific bug reports, or feature requests for the items that I'm working on, feel free to do so here. Bugs outside of the scope of this thread should be reported on trac: http://sourceforge.net/apps/trac/mpc-hc/ . Please avoid making duplicate reports on trac, by using the search function first.


Current items that are in the tester build that not in the trunk build:
- Improved color management and dithering, with many new options. This item was mainly written by the developers a_afra and janos666.
- Accurate detection methods for detecting the half and full floating point surfaces support.
- New resizers: Lanczos (3 variants), B-spline (2 variants), Mitchell-Netravali spline (2 variants), Catmull-Rom spline (2 variants), and Perlin Smootherstep.

Things I really want to solve:
- I already started on making it possible to change the display refresh rate when initializing the D3D Fullscreen Mode, but it's untested and not complete yet.
- Merge EVR Custom Presenter and EVR Sync. EVR Sync has some very useful synchronization options, but the main rendering path has not been updated for a while. I hope I can make the necessary changes to allow all functional items to be kept, while unifying the renderers.
- Solve multi-threading issues.
- Increase the efficiency and quality of the renderers and subrenderers.
- Add compatibility for the new resizers with rotation.

Notes for these builds:
- The x64 builds require a x64 Windows installation to run.
- AVX versions require Windows 7 with SP1 and a processor that can handle AVX instructions: http://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX
- SSE2 versions require a processor that can handle SSE2 instructions: http://en.wikipedia.org/wiki/SSE2#CPUs_supporting_SSE2

deviated from revision 4739;
x64 AVX: http://www.mediafire.com/download.php?zx62aa2tya3zva2
x64: http://www.mediafire.com/download.php?xpe5dsv0vpfyy69
x86 AVX: http://www.mediafire.com/download.php?w27vtvwebjdcxm7
x86 SSE2: http://www.mediafire.com/download.php?c1p7pd0cefp58de
x86 SSE: http://www.mediafire.com/download.php?s1jrb84qjh74mgh
source code: http://www.mediafire.com/download.php?3gggyhz21p3jmnm

deviated from revision 5050;
x64 AVX: http://www.mediafire.com/download.php?ekyojfpcmwlzact
x64: http://www.mediafire.com/download.php?0m0316dco7boo6t
x86 AVX: http://www.mediafire.com/download.php?q7t1k3cc554gy46
x86 SSE2: http://www.mediafire.com/download.php?pdctjj332xsx398
x86 SSE: http://www.mediafire.com/download.php?l2kbhmz65cwd5lt
source code: http://www.mediafire.com/download.php?ihdh20xezcnf6l9

deviated from revision 6995;
x64 AVX: http://www.mediafire.com/download.php?zjw1o4wd7gxg78d
x64: http://www.mediafire.com/download.php?afp7u88t5ry9ccq
x86 AVX: http://www.mediafire.com/download.php?ulgz40znq455shy
x86 SSE2: http://www.mediafire.com/download.php?kj66m6897nf2a8l
x86 SSE: http://www.mediafire.com/download.php?dp1qn6qdv77uafx
source code: http://www.mediafire.com/?zovvjrklb91g3sy

deviated from revision 7100;
x64 AVX: http://www.mediafire.com/download.php?8ag6rp41p4zznzx
x64: http://www.mediafire.com/download.php?kxbk27i64vt13v4
x86 AVX: http://www.mediafire.com/download.php?2o7zul5q8f3fs17
x86 SSE2: http://www.mediafire.com/download.php?l3963gk1rdug3o1
x86 SSE: http://www.mediafire.com/download.php?lld1wubouzoa1ru
source code: http://www.mediafire.com/download.php?cb1fltfpafn8dik

deviated from revision 7190;
(problematic x86 SSE version is only available in the development folder)
x64 AVX: http://www.mediafire.com/download.php?88hmyzk28dirvoe
x64: http://www.mediafire.com/download.php?blxt149mkogocad
x86 AVX: http://www.mediafire.com/download.php?t2gddkymt9x6mij
x86 SSE2: http://www.mediafire.com/download.php?ijs4cjj5b47d7s0
source code: http://www.mediafire.com/download.php?bz09ag24yoj9pus

deviated from revision 7313;
(problematic x86 versions are only available in the development folder)
x64 AVX: http://www.mediafire.com/download/cd2zi4d396dgad1/mpc-hc64_AVX_tester_dfr7313.7z
x64: http://www.mediafire.com/download/ssv1q395snxdq6p/mpc-hc64_tester_dfr7313.7z
source code: http://www.mediafire.com/download/mp2ybnmzath2wtm/mpc-hc_tester_dfr7313_source_code.7z

deviated from revision 7370;
x64 AVX: http://www.mediafire.com/download/db8h1bvamwbgexb/mpc-hc64%20AVX%20tester%20dfr7370r.7z
x64: http://www.mediafire.com/download/ew4wghxv5999v2k/mpc-hc64%20tester%20dfr7370r.7z
x86 AVX: http://www.mediafire.com/download/8kus57rbq8d0pba/mpc-hc%20AVX%20tester%20dfr7370r.7z
x86 SSE2: http://www.mediafire.com/download/g4yc2gp01dlh1fa/mpc-hc%20SSE2%20tester%20dfr7370r.7z
x86 SSE: http://www.mediafire.com/download/dfw1l5rs2djb7xz/mpc-hc%20SSE%20tester%20dfr7370r.7z
source code: http://www.mediafire.com/download/7vbhbrbwlgq1dqg/mpc-hc%20tester%20dfr7370r%20source%20code.7z

[namaiki]

How to use the new scaler? Just select any of the "Bicubic" resizer options under View-> Options-> Output?

[burfadel]

In regards to the D3D playback, how about when it changes to the next video that it doesn't need to reinitialise? I don't see any reason why it would needs to...

[JanWillem32]

@namaiki: Yes, indeed. I'll add proper naming in the Options screen once I've converted and added my current set of scaling shaders. There was only one slot open for use in the original renderer code, so I'll have to expand that section first to add more items later. The current one is a good example of one of the naturally sharpest scaling methods. It generally does a good job on content that's not too noisy.

@burfadel: I've actually looked into this quite some time ago. It bothers me too. There is nothing in the renderers themselves that forbids seamless playback. Both VMR-9 and EVR mixers support switching input video streams while the rendering process is paused. The controller part for the renderers makes any renderer shut down and start up again while transitioning between files. So far I haven't been able to find the specific code or even part that actually does this (or even know how it's formally called), so I haven't even had the chance of experimenting with changing this behavior.
Note that a true seamless playback will be a bit hard. There is always a file buffer involved, and buffering abridging 2 files for a completely seamless transition requires a very adaptive buffering method, which isn't available at the moment. This is also only possible when transitioning between two very similar files, e.g. playing a blu-ray disc playlist that uses chapters in separate files.

[suanm]

thanks to JanWillem32,i've downloaded the software you uploaded,once i'm available,i'll do the tests

[suanm]

JanWillem32,Would you like to tell me what Low Quality(64" points),Medium Quality(128" points) and High qulity(256" points) mean?

[JanWillem32]

The look-up quality for the color management is based for the main part on the size of the 3-Dimensional Look-Up Table (3DLUT). It contains the color correction data generated by the the color correction engine's output using the calibration profiles (.ICM files) with calibrated display devices.
A larger 3DLUT allows a more accurate interpolation for each of the red, green and blue components of the display, but in return it will be more demanding in video memory and the memory resources. Low Quality (64³ points) will use 2 MB, Medium Quality (128³ points) will use 16 MB, and High Quality (256³ points) will use 128 MB of memory.

[G_M_C]

Bedankt voor de testers Jan Willem.

Installed the latest immediately, seems to work as intended (like the previous ones). But mind you: I just use it as player for movies on my secondary screen.

The only thing i noticed is the hangup after stopping movie when using 10-bit out/D3D full-screen. I have to kill MPC-HT through the control panel. But this bug has been in ht builds since a long while now. And im used to it. Also, for me it is no problem, since my secondary screen is the one i use for the full-screen output, the MPC-HT window/process is therefor always accessible on my 1st screen.

[Virtual_ManPL]

I got "no video" (or you can also say video with one dominant color) when I use:
EVR CP/VMR9 (Renderless) + Binear (PS 2.0)
EVR Sync + Bicubics

Happens in all files. Decoder and splitter didn't make any difference.
Using 64bit MPC-HC.

[suanm]

The look-up quality for the color management is based for the main part on the size of the 3-Dimensional Look-Up Table (3DLUT). It contains the color correction data generated by the the color correction engine's output using the calibration profiles (.ICM files) with calibrated display devices.
A larger 3DLUT allows a more accurate interpolation for each of the red, green and blue components of the display, but in return it will be more demanding in video memory and the memory resources. Low Quality (64³ points) will use 2 MB, Medium Quality (128³ points) will use 16 MB, and High Quality (256³ points) will use 128 MB of memory.

I understand generally what you said above.I did a simply test just now for bicubic a=-1.00,ps=2.0 ;Low Quality(64" points) Spline4 Interpolation; Enable little Cms;EVP/CP.
Mpc-hc works so perfectly,too amazingly(no dropping frames at least,very smoothly). Video quality is as well as it's for madvr. Playback for Medium Quality (128³ points) is not smooth,though.Perhaps my video card is not powerful enough
PS:nvida 9400GT 400/800 ,256M+turbo256M;Amd trial core CPU

[neoufo51]

I got "no video" (or you can also say video with one dominant color) when I use:
EVR CP/VMR9 (Renderless) + Binear (PS 2.0)
EVR Sync + Bicubics

Happens in all files. Decoder and splitter didn't make any difference.
Using 64bit MPC-HC.
Confirmed with 32bit. Also, huge slowdown when you select any of the transfer curves types and you can't unselect them.

[suanm]

I do a test again with 720P video,Playback for Medium Quality (128³ points) is smooth,no dropping frames anymore.But playback with 1080p video is smooth just by choosing Low Quality(64" points).

[PetitDragon]

Hi JanWillem32 thanks for the test builds. However, I found all your builds after r3008 the renderer always hangs when auto switching display refresh rates (both using MPC-HC internal or Reclock). Is it possible to fix?

Thanks again for your help.

P.S. The try-out builds in xhmikosr and xvidvideo.ru sites don't have such problem.

[JanWillem32]

For the changed items in the renderer settings menu I'll write a guide. (I can simply copy-paste my previous post for one part, anyway).

@burfadel: I've heard from tetsuo55 that the part that reloads all filters when switching between files is the filter graph builder. It's currently configured to always unload every filter when a file closes and load every relevant filter when a file opens. If a function is added that evaluates if a filter can stay loaded on switching input files, we would have to check for compatibility with all usual splitters, codecs and renderers. I think this option will have to stay a bit longer on my wish list. However, if anyone volunteers for writing code for the filter graph builder, I can assist.

@G_M_C: Graag gedaan.
Dual screen support code is in many parts of the video renderers and their host. There have been some improvements recently, but it's not ideal yet. I'll see if I can make some improvements, I have to go over these parts of the code to fix a few multi-threading bugs anyway.

@Virtual_ManPL: I've only fixed one scaler for now. I have to edit all other scalers to fix an issue with 1:1 pixel mapping before I can enable those as well. At the moment, even the method for nearest neighbor scaling is wrong.
Once I have a working set of scalers and edited the options screen, I'll copy-paste the code into EVR sync.

@suanm: I found out that the Spline4 interpolation method can be very demanding on the GPU's memory system on samples with a lot of movement. I'm considering removal of this item if I can't correct that. Once I got the 256³-sized 3DLUT working, I didn't really see much improvement in image quality from this item anymore, anyway.

@neoufo51: All of the color management's menus need to have at least one option enabled to make it work. I still have to define some default settings, and optimize the code of the renderer settings menu in general.

@PetitDragon: I'll look into it, thanks for reporting it so clearly.

[G_M_C]

Has someone else noticed that when you look at the CTRL-J / stats screen, it wont seem to go away anymore (pressing CTRL-J multiple times doesnt remove the stats anymore) ?

And i only get the short stats screen (the one with only framerate etc, not the one with output/the graph etc).

(Win 7 64, running MPC-HT 32 bit)

[JanWillem32]

Same here, it's like if I've pressed a button two or three times, while in reality it's only once. I only get this in exclusive mode, and it can sometimes be solved after the first mouse click, but not always. I've had this problem for quite some time now (not only in the builds I modified). I wonder what part of the program it is that can make it so sensitive to keystrokes.
http://forum.doom9.org/showthread.php?p=1497176#post1497176
http://forum.doom9.org/showthread.php?p=1497469#post1497469

[G_M_C]

Same here, it's like if I've pressed a button two or three times, while in reality it's only once. I only get this in exclusive mode, and it can sometimes be solved after the first mouse click, but not always. I've had this problem for quite some time now (not only in the builds I modified). I wonder what part of the program it is that can make it so sensitive to keystrokes.
http://forum.doom9.org/showthread.php?p=1497176#post1497176
http://forum.doom9.org/showthread.php?p=1497469#post1497469

Ive gone back some builds to see. The stats/CTRL-J works as intended on my machine @ build 2964.

[mindbomb]

noob question: so ffdshow and madvr have seperate sections for chroma and luma scaling. Is the spline scaler here used for both chroma and luma?

another comment, i find that I have maximal gpu usage when scaling a 1080p image, but if I have a 1080i screen, why is there scaling going on?

and lastly, with disable desktop composition enabled, i get tearing, where as in the non tester builds, I don't get tearing.

I find that performance is adequate for spline6 scaling even on my lowly 4350, as long as aero is disabled

[cyberbeing]

Enabling lcms produces a 0-byte LUT3D file. Once MPC-HC is closed, all subsequent videos produce a black screen. Deletion of the 0-byte LUT3D fixes it, but it get automatically recreated next time you play a video.

lcms has no Default or Optimal settings. Nothing is check except for Spline4 and Black Point Compensation. (after deleting HKCU\Software\Gabest\Media Player Classic putting MPC-HC in a fresh state)

lcms Spline4 mode is unusable on my GPU (massive frame-drops), so Linear should probably be set as Default in lcms.

There is a 50% chance that at video playback start, MPC-HC hang indefinitely at 100% CPU usage when lcms is enabled.

Changing Vsync or Presentation settings while a video is playing, sometimes causes the video to distort into a checkerboard pattern, other times crash.

[ikarad]

For making changes to the VMR-9 (renderless), EVR Custom Presenter, EVR Sync and subtitle renderers, I've been developing since December 2010. .
Can we expect that you make a subtitle renderer without bug and full support of bluray subs (for this moment the support is very buggued) for mpc-hc?

[markanini]

The selectable dithering levels do wonders om less than stellar sources :)
Tell us more about the scalers, the Perlin one sounds intriguing.

[CruNcher]

I still have severe VMR9 Renderless issues :( when CPU load is high and high resolution video comes into play it has a tendency for me to drop frames fast :( i tried every option in both experimental/nightlies i don't get it under control as soon as CPU load is high it drops frames fast (Nvidia G92 9800 GT Forceware 270.71 WHQL XP SP3) :(
Really heavy it recently becomes with using SVP (Realtime Frame Doubling) http://www.svp-team.com/wiki/Main_Page as this loads the whole cores including GPU, is this maybe a priority issue of the internal management of VMR9 Renderless ?
I also tried to minimize CPU cycles in the background to a minimum doing absolutely almost no poling on anything it doesn't help :(

It's clear that VMR9 windowed is more performant but those dropping under heavy threaded load is really normal for renderless ?
MadVR really shows great performance vs VMR9 Renderless in those regards @ the same CPU consumption as soon as he implemented DXVA and customizable shaders i guess even VMR9 renderless will become useless for non Vista/7 users :)

Here is what i mean i don't understand it :(

http://img715.imageshack.us/img715/3230/vmr9renderlessissue.png

[toniash]

MadVR really shows great performance vs VMR9 Renderless in those regards @ the same CPU consumption as soon as he implemented DXVA and customizable shaders i guess even VMR9 renderless will become useless for non Vista/7 users :)
[/IMG]

customizable shaders with MADVR? How?

[JanWillem32]

@G_M_C: Thanks, I'll look into the revision series after that one. Unfortunately, I can't really see any obvious flaws in the patch data directly (just scrolling trough the revisions on trac).

@mindbomb: EVR and VMR output RGB from the mixer. I've been trying to integrate a custom mixer to get control over the Y'CbCr stages. I would appreciate some help from anyone familiar with some C++ coding to get that working, as with many other parts of the program that need some re-programming.
So far I've only managed to get some control over sub-sampled Y'CbCr on ATi hardware with 10-, 16- or 32-bit RGB output from the mixer. (Actually, it's because chroma is scaled by nearest neighbor with these three formats, that allows custom scalers with separate pixel shaders.) In all other cases, chroma is altered with only a standard bilinear filter, there's no real up-scaling then.
Chroma scaling in ffdshow and MadVR are two completely separate things.
In ffdshow 8-bit unsigned integer (technically an "unsigned char" or a "BYTE") Y'CbCr, intervals [16, 235], [16, 240] and [16, 240] are used with the same chroma down-sampled format (usually YV12 or YUY2) for both input and output. Chroma isn't completely scaled to 4:4:4 (no chroma down-sampling) on output usually.
In MadVR, I believe 16-bit floating-point (technically a "half") Y'CbCr is used, with probably the common floating-point intervals ([0, 1], [0, 1] and [0, 1] or [0, 1], [-.5, .5] and [-.5, .5]). Chroma is scaled preferably from half-resolution 4:2:0 of the video input resolution to the full (display) output resolution (4:4:4, of course).

A 1080i screen technically doesn't exist. In the past, there were CRT's that could build up interlaced input directly, but those became rarer in the 80's when TVs became bigger and directly projecting interlaced video became a problem. Matrix-based screens (LCD, plasma, SED and OLED technologies) build up all pixels in the screen at the same time, so direct output of interlaced content would create a very ugly picture. (I haven't seen any good deinterlacing from any TV, by the way. Even my projector is rather bad at it, but luckily it's 1080p natively and I can disable just about any kind of filtering I want in the controls.)
If you mean 1:1 pixel mapping, as in 1080p to 1080p, without "Keep Aspect Ratio" and "Correct Monitor/Desktop AR Diff" (note: this function is broken, as it's offset by one pixel), scaling will always be set to nearest neighbor automatically (even when rotating, that's a minor bug I still have to fix).
The usual fake-HD resolution is 1366×768. Although wrong, many manufacturers call that "1080i". The only correct resolution for both 1080p and 1080i is 1920×1080. 1080i just carries two fields of 1920×540 into a frame.
In my experience, interlacing video is bad for both the bit-rate of any normal digital encoding method and there's always an added risk of ugly interlacing artifacts. Even on old videotape or LaserDisc systems, progressive content was preferred if possible.

High GPU usage can be caused by a lot of things. It's usually a combination of a high input resolution, FPS, and output resolution that make up the base renderering load. Additional items in the rendering chain will add to that load. Scaling isn't a really heavy process (unless you use Lanczos16×16 or something similar).

Things that will require a lot more GPU processing than the base rendering load:
10-, 16- or 32-bit RGB surfaces are great for accurate processing, but a burden on video cards with a weak memory controller, or slow memory. (The GPU's themselves have been 32-bit internally for a lot of years already, DirectX 11 GPU's can even handle 64-bit.)
Deinterlacing can be very heavy, if you enable the advanced types in the video card's control panel. Unlike the DXVA decoder parts, deinterlacing is done on the GPU's shadercore, so it's a lot more "software" than "hardware".
Pixel shaders are executed almost directly on the shadercore (you can even read the assembly from the pixel shader compiler). Some external pixel shaders are very heavy (sharpening kernels are well known to be heavy), some take hardly any effort at all ("invert" or "grayscale", for instance). There are also internal pixel shaders. Currently there are internal pixel shaders for scaling and there's the final pass shader that does color management and dithering. The load of those shaders is dependent on your settings and working resolutions.
The last item is a bit technical, but I'll try to explain. If anything but full-range RGB output is used on output, renderer performance and presentation timing will be worse. For example: if limited-range Y'CbCr is used on output, the video card's drivers have to lock on to the full-range RGB backbuffer from the allocator-presenter to transform it, instead of doing a pass-trough. Locking the backbuffer is one of the slowest operations possible in any DirectX/OpenGL revision, and that's never going to change either.

I have massive tearing in windowed mode with my heavy processing chain, so I can't really test the part of "desktop composition enabled causes tearing".
The weird thing is that in exclusive mode, without any of MPC-HC's VSync options, I don't have tearing. I already tested this on a few computers and it seems to work fine (I do force enable VSync in the video card's control panel). I already know that the changes I made hurt the windowed mode VSync options. (VSync offset function is stuck at 0.) I'll add this one to the list to look at later on. My priority for the next release is to enable a set of at least 5 new scalers and add some improvements to the font renderer.

The spline6 scaler might be a bit more efficient than the "bicubic (of unknown type)" scalers. I enabled 2-pass scaling to resize using 6 pixels horizontally in the first pass and 6 pixels vertically in the second pass. The original bicubic scalers use 16 pixels in a 4×4 matrix in one pass.
For the scalers, I still need to improve the vertex operations to reduce the CPU load a bit (just optimization), and work out the list in the options screen.

@cyberbeing: I've made changes to the code structures of the color management. I'll also be adding message boxes later on for when errors occur (also in other sensitive parts of the rendering engine).
I also added all default settings for color management initialization, but I might change those later on again.
It might be that the saving option isn't UAC-proof, as it does create files in whatever folder MPC-HC is in. I have to test that. Would anyone be opposed to the idea to let it create those files in the "%USERPROFILE%\" folder or a sub-folder if that's true? Ideas are of course welcome.
I've also noticed that there are memory leaks when changing some rendering settings during playback. Those lead to crashes. I'll just have to improve the renderer clean-up for when critical settings are changed.

@ikarad: I'll be focusing on reducing the CPU load for text-based items first. Later on I can take a look at mixer items for bitmapped input, such as support for some blu-ray and HD-DVD subtitles. This is very low on my priority list. I'm not familiar with the streams where the subtitle images are packed into, so it will take me quite some time to even go through the documentation. The mixer code for the bitmapped subtitles isn't even that bad, it just needs an update for supporting all features.

@markanini: The higher random dithering levels are indeed for that purpose, as not everyone likes/can afford full deblocking, deringing, denoising, et cetera on all video inputs. I've described it earlier as an alternative method for handling video in the final pass. Regular dithering on "clean" video input is better off with one of the two ordered single-level methods.

@CruNcher: I'm well aware of high CPU consumption in any mode of the custom renderers. I've taken the first few steps to get the rendering engine not to overflow on multi-threading anymore. I've tried to optimize the normal rendering path by reducing the amount of items that are regenerated with every frame, and placing those at initialization. That didn't work out well for some items, I'll have to work on that. Also, I doubt that the VMR and EVR mixers will ever be as efficient as a custom mixer for the more advanced processing chains. In that perspective, MadVR does have a big advantage.

@toniash: bottom of the page: http://sourceforge.net/apps/trac/mpc-hc/browser/trunk/src/filters/renderer/VideoRenderers/madVRAllocatorPresenter.cpp
The official status "TODO" has been there for quite a while.

It might take a few days more, but I'll release another tester build soon. I've also written some new pixel shaders and optimized a few original ones, so I might release a v1.0 for the shader pack too.

[cyberbeing]

It might be that the saving option isn't UAC-proof, as it does create files in whatever folder MPC-HC is in. I have to test that. Would anyone be opposed to the idea to let it create those files in the "%USERPROFILE%\" folder or a sub-folder if that's true? Ideas are of course welcome.

This is on Windows XP with full-Administrative privileges, so that can't be the issue. The file is being written, just with no data in it. A permissions or WinVista/Win7 UAC issue would prevent the file from being created altogether.

Where are you storing the calculated data before being written? Memory? Temp file? I do have my Temp folders in a non-default location, but that shouldn't be an issue if you are using the TMP or TEMP environmental variables which point to the proper directories.

[JanWillem32]

The data is written from system memory. It's a direct copy from void *pBits, the container is a D3DLOCKED_BOX structure of a CComPtr<IDirect3DVolumeTexture9> object. There is no conversion as void* is the native data input for the fwrite() function in binary mode. The file is raw, without layout, header or footer.
http://msdn.microsoft.com/en-us/library/bb172569%28v=vs.85%29.aspx
Does color management work properly for you when switching the gamma settings? The change in gamma should be very visible.

[suanm]

[QUOTE=JanWillem32;1500312 It might take a few days more, but I'll release another tester build soon. I've also written some new pixel shaders and optimized a few original ones, so I might release a v1.0 for the shader pack too.[/QUOTE]

:thanks:
We are expecting new version will come up soon
:thanks: JanWillem32

[G_M_C]

:thanks:
We are expecting new version will come up soon
:thanks: JanWillem32

You could also be patient. JanWillem32 will post is when its done.

[JanWillem32]

I've updated some minor things (for dfr3104):
Re-initialization errors for the video renderer should be resolved for the main part.
UAC did indeed cause problems with the main executable in a secured (sub)folder, such as "program files" when generating a .3DLUT output file. I set %USERPROFILE% (root of the user's personal folder) as the storage location for .3DLUT files to solve that.
I improved the security and performance of the saving and loading method of .3DLUT files. The .3DLUT files generated by former builds are incompatible with this revision because of that.
I set some very basic defaults for the color management rendering settings. Those might need to be changed a bit later on.
I reduced the memory load by a small amount for the final pass and scaling sections.
I improved the point sampling and the two bilinear scalers a bit (they can't do a perfect 1:1 pixel mapping like the 2-pass scaler just yet).

I couldn't integrate the new scalers yet, because I couldn't get 22 translations updated with the automated scripts.
I was planning to add functional error messages for critical parts in the rendering engine. The message box I made shows the error message, but freezes the entire program. It's not included in this revision because of that.
There are plenty of other things I still need to work on...

[JanWillem32]

I've updated some more minor things (for dfr3114):
Some error messages were added. (I need to check their thread security, but it seems to be okay.)
I've improved the efficiency of the rendering engine, mostly the color management and the scalers gained a bit of performance.

[TheElix]

First of all, thank you for your great work on the best video player in the world. Unfortunately, I have been experiencing problems with your latest builds (3104 and 3112). It's kinda complicated, so first I state the problem itself and then write the details.
Problem: The video is not loading (the player is not responding).
Details:
- MPC-HC build 3104 overwritten by your 3104 test build.
- Renderers: EVR Custom, VMR-9R
- Video Decoder: Any
- Video file:
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 8 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 24mn 6s
Nominal bit rate : 1 500 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 23.810 fps
Original frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive

I hope this information will be sufficient to identify the problem.

[JanWillem32]

Okay, I know a number of flaws that can contribute to failure, can you test these things first?
-When there's not enough video memory available for the dithering and color management, the engine may get stuck.
-Color management can take a really long time to create a new 256³ points 3DLUT file.
-An ancient video card with an instruction set below PS 2.0a will choke on the new scaler.
-I've noticed some incompatibilities with my builds and the internal DXVA decoder now and then. (The internal&external software decoders are fine, external DXVA decoders work too.)
-I've changed some rendering settings, it might be that a reset to default values is needed in the registry.

[TheElix]

- I have HD6970
- I don't use 3DLUT
- Made a fresh install with resetting my settings
- Tried MPC's internal DXVA as well as several external DXVA decoders
Also, I think I've waited for 2 minutes for video to load before I assumed it hanged. If there's anything you want me to test, please, tell me.

As a side-talk I'd like to ask about Color Management function. Where does MPC-HC store information about Grayscale calibration? I've read a neighboring topic about yCMS and one of it's function is to approximate video's colors to perfection by taking your display's grayscale calibration data. I assumed the same is with your Little CMS. Otherwise, what is the point of it?

Also, I want to apoligize beforehand if some of my statements would come off as rude. It's not intentional. I'm not a native speaker.

[JanWillem32]

That rules out most items in that list...
The thing is, I can also get the player to hang, but it only seems to sometimes. It happens to me only when my harddisks are busy, I use the internal splitters and it happens more often than usual when I use a DXVA mode.
I can't replicate it with LAV Splitter active or when starting from an idle system with hardly any programs loaded. Also, in exclusive mode, a single frame is always properly presented, and video plays back normally after jumping to a frame by mouse or keyboard command.
On a modern machine, waiting longer than 10 seconds is useless. (That is, unless you are generating a large 3DLUT, as that even takes 20 seconds on its own on my system.) You really don't have to wait an entire 2 minutes to see if the program is frozen permanently.

Grayscales from the loaded .ICM display profile file are among the items weighed in the calibration, most certainly. That data isn't stored explicitly in the 3DLUT file or memory, it's only used during the building phase. The 3DLUT itself is raw R×G×B (matrix) volume texture data.

Don't worry about being impolite, a lot of people here are probably used to the language that compilers (and programmers for that matter) spit out.:p

[TheElix]

I know, I've been exaggerating with 2 minutes :P Well, it's always bad when you run out of options. There is clearly a bug in your test build because clean 3104 MPC-HC build loads that video alright.
My ICM profile is default, I have my HDTV plasma h/w calibrated. And I have measurements from ColorHCFR. Maybe you'll consider this as an option? Not everyone calibrates via s/w gamma curves.

[JanWillem32]

I would never advise to enable the default sRGB profile that ships with Windows, it's far from optimal with any display (it's even better to just disable everything).
Except for professional machines that receive data as a full XYZ colorspace input over SDI, HDMI or DP and transform that with a high-grade LUT, there's always a task for software renderers to adjust the color matrices of an input video to the output color matrices a display device has. The color management in EVR CP/VMR-9 r. simply reads the color matrix data from the .ICM profile activated on a display device (multiple devices on one system can be supported). I think that's a pretty proper way of doing color management.
There's full support for v2 and v4 profiles, as far as I know. It's not limited to profiles with only gamma curves data.
I do still have to add .ICM timestamps detection, to make sure that profiles are regenerated once someone re-calibrates, and for proper support of multiple devices, but that's something to implement later.

I still wonder why r3104 and later of my builds won't work at all for you and earlier ones did. I've changed a lot of items in that revision, but it's almost all in the scaler and color management/dithering sections.
Can you try to use LAV Splitters, disable all internal filters (hint: right-click on the filter list), use the nearest neighbor scaling option and without color management or dithering? I'd really like to eliminate this bug before it's buried underneath a ton of other code changes. (I'm hoping it's just a small thing.)
It's a bit odd that your system has problems with my builds. It's usually the older GPUs and IGPs that give problems if I try to implement new things. I have a HD4890 that will do just about everything I want, as long as I don't try to feed it YV12, I420/IYUV or certain kinds of RGB data trough the mixer. I would expect that a system with a shiny new card like yours to support at least the same features as mine.
Anyway, thanks for quick responses. I usually have to wait for days to get replies.

edit: I've got my system to fail every time I try to render with DXVA (internal or external), after starting a video render in a relatively heavy background process. The vanilla r3114 does properly start to render in that case, mine doesn't. I think it's another case of multi-threading errors again. I've had similar problems before, and I found out that some initialization threads ran up to 7 times back then, while they should only be run once. I'll just have to start debugging again...:(
Anyway, if anyone finds abnormalities with my test builds, please report them. The sooner I fix them, the better.

[TheElix]

Looks like we've spotted the problem. The file does start with dithering off. I can turn it on afterwise and the video will still play. But if I open the file with dithering option on the video won't open.
I would never advise to enable the default sRGB profile that ships with Windows, it's far from optimal with any display (it's even better to just disable everything).
You got me wrong here, I don't use sRGB icm profile. By default I meant icm profiles are off. My GPU's LUT is unaltered.

[JanWillem32]

Looks like we've spotted the problem. The file does start with dithering off. I can turn it on afterwise and the video will still play. But if I open the file with dithering option on the video won't open.Which one of the three types doesn't work? They are all pretty different.You got me wrong here, I don't use sRGB icm profile. By default I meant icm profiles are off. My GPU's LUT is unaltered.Good, better no profile than one that doesn't match. By the way, most types of profiles don't alter the GPU's LUT by default. Those profiles leave it up to color managed programs to take care of that. The needs of a color managed program varies a lot, as there are many modes for adapting color. Loading a default LUT on the GPU would not improve things.

I've made some bug fixes for dfr3114r. It no longer gets stuck on DXVA modes in my case, and I also lowered the CPU processing load by fixing some timing modes. This can affect VSync. (Downloads are posted in the OP.)

[TheElix]

Which one of the three types doesn't work? They are all pretty different.
I prefer 1 (Random ordered). But hey, I installed 3114r and now it works with it :) Thanks :)

What do you say about making it possible to choose between automatically using monitor's ICM profile and manually inputting grayscale calibration values?

[JanWillem32]

I prefer 1 (Random ordered). But hey, I installed 3114r and now it works with it :) Thanks :)I didn't expect that. Odd, but okay, as long as it works. I've already marked the sections I edited today as hazardous, to prevent future problems.What do you say about making it possible to choose between automatically using monitor's ICM profile and manually inputting grayscale calibration values?I'll have to read the manual on how to construct an interface for inputting other profiling data than the one currently in place. It took a while last time to read up on what data the different forms of calibration profiles hold and what the appropriate implementation schemes for those are. And even then, I was glad I only did the optimizing and profile exporting parts of the code.
As anyone might understand, I have to prioritize things. Adding complex new features like this takes a lot of time. If anyone wishes to co-develop some things like this, I'm always in for it, but I'll have to give current renderer issues and basic code maintenance priority.

[TheElix]

That's completely understandable. You may try to ask yesgrey on this forum for cooperation on this one. As I understand he's an author of his own color management algorithm here. And I won't bother you with this anymore :)

[suanm]

-Also, I want to apoligize beforehand if some of my statements would come off as rude. It's not intentional. I'm not a native speaker.

I thought you just were a native speaker in English.LOL:p,I feel you speak english fluentlyer and better than I do
.I worry about my english in which I don't state my questions clearly to others here:devil:

[TheElix]

That's a high praise coming from a native EL-speaker! Thanks. Yeah, I've noticed how foreigners can speak a more proper language that native speakers. That's probably because those who learn foreign language always treat it with great respect which is not always the case with native speakers. )
Bug report. On the abovementioned configuration.
1) There is one .mkv video that has 3 internal subtitles. It won't let you change the default subtitle on EVP CP no matter how hard you press 'S' button, lol.
2) Grey screen instead of video on EVR Sync. renderer O_O.

[suanm]

the last 3114 version is so unstable yet. while playback,screen is always black ,I don't know how to get video image. How difficult trying to use mpc-hc tester building better is! Looking forward to author's improving it

[G_M_C]

Jan, i want to report this:
I'm using R25 of your optimized shaders for chroma upsampling on floating point surfaces. I have a HD5770 running on Win7-64. I use MPC-HT 32 bit, your test version R2964 (where ctrl-j still worked as it should).

When i enable RGB colorcontrols (#define RGBColorControls 1) and set blue brightness slightly higher (#define BlueBrightness 0.1) I get a fully blue screen, like BlueBrighness was defined @ 10 in stead of 0.1.

[JanWillem32]

@TheElix: 1) I just tested a Matroska video file (MKV) that I muxed myself. It has basic text internally (SRT), and styled subtitles externally (.ASS file, no embedded items, like fonts). With both the internal MPC-HC and LAV Matroska file splitters, both items are properly working when selected in the "Play"->"Subtitles" menu. It might be that it's different with other formats, but basic switching is working properly. It could be that due to the "double/triple tap" bug in exclusive mode, the "S" button isn't working. Can you test this in windowed mode, using the mouse?
2) The first few EVR Sync updates are scheduled once I've edited the other rendering engine. The problem is that they are both sharing the same set of scalers. EVR Sync with nearest neighbor or bilinear scaling should still work.

@suanm: Those things happen. Shall we have a go and try to debug your situation? I might need to fix a specific bug for your problem in the code.
Can you fist try a reset to a basic "default" or "optimal" renderer settings? I've changed a few registry settings, so they might conflict a bit with the previous version.

@G_M_C: I've re-written that one some time ago. I'll release a v1.0 of the shader pack once I've written the derived functions from the prototype "sharpen complex, deband and denoise, r=5" (will be renamed, as sorting these files by name fails). I've already finished copyrights, categorizing into folders and basic code checking for all shaders, so it's just the final touch (at least, for a basic v1.0).

[G_M_C]

[...]

@G_M_C: I've re-written that one some time ago. I'll release a v1.0 of the shader pack once I've written the derived functions from the prototype "sharpen complex, deband and denoise, r=5" (will be renamed, as sorting these files by name fails). I've already finished copyrights, categorizing into folders and basic code checking for all shaders, so it's just the final touch (at least, for a basic v1.0).

Ahh, ok. I'll wait for the updates. Thanx in advance :)

[burfadel]

The prototype sharpen complex, deband, denoise shader seems to work a lot better than the old one :) I just don't know which is better to use, the dot or length one?

[suanm]

thanks,JanWillem32,I will do a test on this weekend as you said above."To reset to default or optimal renderer settings" keeps on my mind.I guess this test might be successful very much

[JanWillem32]

Because I've finally managed to integrate a few scalers, I compiled new builds. The double reset when desktop composition gets disabled should be fixed (that could cause a bit of flashing). I also lowered the initialization time, and made a few general rendering optimizations.

[Dstruct]

The look-up quality for the color management is based for the main part on the size of the 3-Dimensional Look-Up Table (3DLUT). It contains the color correction data generated by the the color correction engine's output using the calibration profiles (.ICM files) with calibrated display devices.

What about ICC files? NEC SpectraView software creates ICC files.


My default Windows XP system profile is called "NEC MultiSync LCD2490WUXi.icc" (hardware calibrated).


Build mpc-hc tester dfr3153.7z has problems here. Little CMS not working properly. Most of the time the picture just goes black. Sometimes I get it working by switching the lookup quality mode. But basically I have to disable it completely in this build.

Lookup table files "lCMS,vds=PAL,abl=bright,rit=per,trc=ppw,wpa=none,lqt=high,bpc=no,qfm=ui16.LUT3D" for example) are also empty (0 bytes)!


What is "Black point compensation"? Sounds like it should be enabled by default? What's "White point adabt state" for?

[Dstruct]

Enabling lcms produces a 0-byte LUT3D file. Once MPC-HC is closed, all subsequent videos produce a black screen. Deletion of the 0-byte LUT3D fixes it, but it get automatically recreated next time you play a video.

There is a 50% chance that at video playback start, MPC-HC hang indefinitely at 100% CPU usage when lcms is enabled.


Confirmed.

[suanm]

Hi,JanWillem32
why is your homepage download (Direct link for the x86 build: http://www.mediafire.com/?ytxw3hkxu41fxk9 ) unreliable?,I can't connect to this redirection anyway,whether you have blocked up the connection from other countries by firewall or not? expecting you can keep connection

[G_M_C]

Hi,JanWillem32
why is your homepage download (Direct link for the x86 build: http://www.mediafire.com/?ytxw3hkxu41fxk9 ) unreliable?,I can't connect to this redirection anyway,whether you have blocked up the connection from other countries by firewall or not? expecting you can keep connection

Just press the link to his mediafire page, and browse from there. The link is in his signature.


development folder, containing MPC-HC experimental tester builds, pixel shaders and more: http://www.mediafire.com/?r367kbp7p9but

[suanm]

Hi,G_M_C
according to your above mention,I open mediafire page,I don't find JanWillem32 's signature.can't find download address,too

[JanWillem32]

@Dstruct: Do earlier versions work? I really didn't change a lot for the final pass section this time.
.ICC and .ICM files are the same: http://www.color.org/faqs.xalter#p9
Also, the error message box I've made should show up top-left of the active monitor with the error message inside, if something goes wrong with the final pass in the latest 2 revisions (unless in exclusive mode). Maybe I should convert that thing to an exception item, so it can close the renderer if something goes wrong.
I'm planning to break the automatic renderer switching on failure function anyway. EVR-CP and VMR-9 r. will switch to VMR-7 r. on failure, for example. It happens without any notification.
A nice article on black point compensation (it should not be enabled in all situations): http://www.gamutvision.com/docs/blackpoint.html
I still have to completely figure out white point adapt state. In my case, I can only see differences between none (the same as with medium) and full with the absolute colorimetric rendering intent. The only logical white point adapt state with an absolute colorimetric intent is of course none, else it wouldn't be absolute anymore.
I also wonder if the saturation intent is even valid as an option in a video player, but that's another topic.

@suanm: As far as I know, the services by MediaFire are not blocked by ISP firewalls in general. I've seen that there are quite a few downloads, too. When downloading, I get about 170 kB/s.
Did you have any issues with the download links I posted in the past?

[cca]

I just downloaded rev3153, any hints as to which resizer does what? Or least what is the difference. Not familiar with the spline ones.

[JanWillem32]

I generally ordered them from least to most processing intensive.
For a nice pictured example, without the math in my "~interpolation methods, cubic B-spline" and "~interpolation methods, Catmull-Rom spline" files, see:
http://pixinsight.com/forum/index.php?topic=556.0
http://entropymine.com/imageworsener/demos/demos2.html
Too bad it's just pixel art, I would love a bigger comparison including windowed sinc filters. To make my order complete: on high-end, lossless photographic content, with transformations done in a proper colorspace, please.

[cca]

By the way, this build doesn't work with DVDs right, the Aspect Ratio is messed up. PAL DVDs, interlaced content.

[JanWillem32]

I can confirm this, but it's also the case with the reference r3158 I just downloaded. Someone also broke the "reset deinterlacing after seeking" function again.

[cca]

Ah, they broke it in the SVN? I use your builds for quite some time now and didn't notice :)

Also, I often get a blank screen and the program freezes when I try to open a video.

[JanWillem32]

:rolleyes:There's still some bits here and there to fix.
Anyway, I added timestamp support for the color management section, so that multi-monitor setups and updating profiles are no longer a problem. The timestamps are just a hexadecimal representation of the last modified time of the active .ICM/.ICC files.
For the other part, I've made some very big improvements in CPU and GPU performance during rendering. There might also be some benefits to memory usage. The only downside is the executable size, my builds are bloated for some reason, compared to the standard ones. I'll investigate why.

[CruNcher]

is dithering by default enabled in your test builds ? i see only values and the test mode but no (disable) ?

[ForceX]

I think 0 (Rounded) disables it. BTW, it shows Little CMS Enabled whether or not I turn it on or off.

[CruNcher]

Ahh thx :)
Btw their seems to be a issue with the Resize Pixel Shader in RGB24/RGB32 input/output) @ least they seem to fail after some seconds, strange bold color planes appearing depending on the color tones of the previous frame it seems over here :( they work fine @ least for YUY2 and YV12 input/output and also the normal pixel shader from the current mpc-hc tree don't seem to fail (tested emboss) with the combination of billinear resizer (no PS 2.0) and RGB24/RG32 Input output (so only the resize pixel shader seem to be affected by this).

System: Nvidia G92 (9800GT) XP SP3 VMR9 Renderless Forceware 275.27
Tested Revision: 3160

[JanWillem32]

@ForceX: That's a problem in the trunk, too. It's easy to fix, though. I just changed the wrong ON to OFF in MainFrm.cpp. Thanks for reporting. Quashing new bugs is pretty important.

@CruNcher: 0 is indeed off for the dithering. 0 is default, 1 (static ordered) is is set by the "Optimal" profile.
The behavior of both EVR and VMR mixers is unpredictable when it's fed a converted RGB input from Y'CbCr. My simple advice for the last few months is to not use converted RGB input, unless you have an early DirectX 9.0 GPU or older Intel IGP that really can't use NV12 or YV12 in VMR-9. I also know a lot of other problems with converted RGB input to the mixer. I simply regard those as completely unfixable.
Note that converting to just 8-bit RGB also limits the quantization in the case with 10-, 16-, or 32-bit surfaces. To be more exact:
10-bit surfaces can quantize 4 times as much,
16-bit surfaces can quantize at least 4 times as much, but might go up to at least 8 times as much, depending on hardware and software implementation,
32-bit surfaces can quantize at least 65536 times as much in theory, but since the calculation format is the same, the actual precision will be completely determined by the compounded rounding errors in the programming math.

I looked up what the white point adapt state is for, and it's indeed just a switch for usage with the absolute colorimetric rendering intent.

[CruNcher]

Oh didn't knew that it was just strange that they work on the current tree but fail with yours with RGB Input/output
I tried to see a difference between bicubic 1.0 PS2.0 and the other new ones by the best will i couldn't see it either upscaling/downscaling (double size)/(half size) i only recognized that the cubic seem to blur a little more but the catmulls look identical (on my display) in both cases to bicubic 1.0 as if nothing would change tried different input sizes (still have to look @ GPU utilization).

Bicubic 1.0 PS2.0 = 2%
Catmull-Rom Spline6 PS 2.0a = 4%

[JanWillem32]

I used plenty of parts from the old renderer. There were also lot of things re-written, so I really don't expect all parts to have the same behavior.
As I'm on this subject, does anyone still use the "Regular offscreen plain surface" or "2D surfaces" options with VMR-9 r. (the two options are actually the same thing in the current implementation)? These are legacy options from VMR-7 r. to give VMR-9 r. very basic subtitle, OSD and stats screen support, without any of the more advanced rendering options (scalers, shaders, vsync options, et cetera). It's very dated and inefficient by now, as the unused items from the regular rendering path are still completely loaded. There hasn't been any maintenance on this rendering path anymore for years now. I'll ask the same thing in the regular thread.
For the comparison of the scalers, I can make some pictures of difficult pictures to scale. The still image filter that is installed with Windows can open 8-bit .BMP and .JPG/.JPEG. If I convert some 8-bit .PNG pictures to .BMP, I can skip chroma interpolation, linearize the gamma, scale it up and down by a complex fractional amount, and just let people decide what to use. I know in what ways the different scalers manipulate pictures, but I think it's better to use pictures than words for that. Also, using whole, or even half factors to scale up or down will not fully represent the quality of a certain scaler.
GPU utilization for these very simple pixel shaders is a laugh if I compare it to some of my regular work. Even the processing load of the color management and dithering part with medium settings is a few times heavier than the spline6 scalers.

[suanm]

[QUOTE=JanWillem32;1504073@suanm: As far as I know, the services by MediaFire are not blocked by ISP firewalls in general. I've seen that there are quite a few downloads, too. When downloading, I get about 170 kB/s.
Did you have any issues with the download links I posted in the past?[/QUOTE]

yes,I have issues with downloading 3153 version(From http://www.mediafire.com/?ytxw3hkxu41fxk9) ,I don't open the MediaFire HomePage ,don't also open MediaFire page link you gave above.Now I don't know where I should connect to download your build 3153 and 3160 version

[JanWillem32]

That's odd. It worked for you a few weeks ago. Does anyone else have connection problems? If so, which file hosts do work for you?
Maybe we should wait a little while longer, maybe it will work again after a while. In the mean time, I can try to just e-mail the file. For spambot reasons, please handle requests with e-mail addresses by PM.

[ForceX]

Mediafire IMHO is one of the best ones out there since it allows you to download many files simultaneously without cooldown, and has resume support and its folder system is great. However, some people seem to have problems accessing that site. If you want to provide additional download support for them, you can use something like http://www.mirrorcreator.com/ which will upload a file to a bunch of file sharing sites for people to grab from. However, I suggest you keep the mediafire folder. Only thing that comes close to MF in terms of folder support is http://www.4shared.com/

[CruNcher]

I used plenty of parts from the old renderer. There were also lot of things re-written, so I really don't expect all parts to have the same behavior.
As I'm on this subject, does anyone still use the "Regular offscreen plain surface" or "2D surfaces" options with VMR-9 r. (the two options are actually the same thing in the current implementation)? These are legacy options from VMR-7 r. to give VMR-9 r. very basic subtitle, OSD and stats screen support, without any of the more advanced rendering options (scalers, shaders, vsync options, et cetera). It's very dated and inefficient by now, as the unused items from the regular rendering path are still completely loaded. There hasn't been any maintenance on this rendering path anymore for years now. I'll ask the same thing in the regular thread.
For the comparison of the scalers, I can make some pictures of difficult pictures to scale. The still image filter that is installed with Windows can open 8-bit .BMP and .JPG/.JPEG. If I convert some 8-bit .PNG pictures to .BMP, I can skip chroma interpolation, linearize the gamma, scale it up and down by a complex fractional amount, and just let people decide what to use. I know in what ways the different scalers manipulate pictures, but I think it's better to use pictures than words for that. Also, using whole, or even half factors to scale up or down will not fully represent the quality of a certain scaler.
GPU utilization for these very simple pixel shaders is a laugh if I compare it to some of my regular work. Even the processing load of the color management and dithering part with medium settings is a few times heavier than the spline6 scalers.

Fully Agree :) and yeah the GPU usage difference is marginal i mean 2% more if their can be a difference with some sources or in some situations doesn't hurt visualizing the difference would be ideal, i also zoomed in upclose into regions but couldn't see a difference, though obviously you lose overview over the whole frame that way.

[CruNcher]

@Jan
http://www.assassinationscience.com/johncostella/magic/

Did anyone tried yet to implement it as a Shader ?

[JanWillem32]

An easy one to write. This code might not be completely optimal, but I believe I interpreted the main function correctly. It's mostly a noise-resistant version of a bilinear kernel, with support in a third pixel. Note that it will blur in a 1:1 pixel mapping situation. For down-sampling, it can probably be compared to a cubic B-spline.
The problem with a windowed sinc function mentioned in that text is probably just Runge's phenomenon: http://en.wikipedia.org/wiki/Runge%27s_phenomenon. I'm quite familiar with it. The bicubic filter used in the example image is a pretty harsh one, but the A=-0.8 and A=-1.0 types in MPC-HC are that too.// (C) 2011 Jan-Willem Krans (janwillem32 <at> hotmail.com)
// This file is part of Video pixel shader pack.
// This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
// This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
// You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.

// prototype width resizer
// fractions, either decimal or not, are allowed
// set the magnification factor
#define Magnify (4/3.)

sampler s0;
float c0;
float c1;
#define sp(a, b) float4 a = tex2D(s0, float2(coord+b*fx*c1, tex.y));

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float coord = (tex.x/Magnify+.5-.5/Magnify)*c0;// assign the output position, normalized to texture width in pixels
float t = frac(coord);// calculate the difference between the output pixel and the original surrounding two pixels
// adjust sampling matrix to put the ouput pixel in the interval [Q2, Q2+.5]
int fx;
if(t > .5) {coord = (coord-t+1.5)*c1; t = 1.-t; fx = -1;}
else {coord = (coord-t+.5)*c1; fx = 1;}

sp(Q0, -1) sp(Q1, 0) sp(Q2, 1)// original pixels
return (pow(.5-t, 2)*Q0+pow(-.5-t, 2)*Q2)*.5+.75-pow(t, 2)*Q1;
}// (C) 2011 Jan-Willem Krans (janwillem32 <at> hotmail.com)
// This file is part of Video pixel shader pack.
// This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
// This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
// You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.

// prototype height resizer
// fractions, either decimal or not, are allowed
// set the magnification factor
#define Magnify (4/3.)

sampler s0;
float2 c0;
float2 c1;
#define sp(a, b) float4 a = tex2D(s0, float2(tex.x, coord+b*fy*c1.y));

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float coord = (tex.y/Magnify+.5-.5/Magnify)*c0.y;// assign the output position, normalized to texture width in pixels
float t = frac(coord);// calculate the difference between the output pixel and the original surrounding two pixels
// adjust sampling matrix to put the ouput pixel in the interval [Q2, Q2+.5]
int fy;
if(t > .5) {coord = (coord-t+1.5)*c1.y; t = 1.-t; fy = -1;}
else {coord = (coord-t+.5)*c1.y; fy = 1;}

sp(Q0, -1) sp(Q1, 0) sp(Q2, 1)// original pixels
return (pow(.5-t, 2)*Q0+pow(-.5-t, 2)*Q2)*.5+.75-pow(t, 2)*Q1;
}

[suanm]

thank you,JanWillem32,I have received the new version for mpc-hc tester building file you sent.I do tests,I have still questions that I get only black screen[not video image] with EVP C/P renderer mode,After I cancel "Enable little CMS" chosen button,I get video image,But I click "Enable little CMS" chosen button again,video image keeps playback.I don't know whether at the time mpc-hc tester building player keeps in "enable little CMS" mode or not? Because I don't see video image quality improved (or changed)

[janos666]

Do you have an idea why can't I use the overlay mixer anymore?


MPC Video Decoder::Output
Overlay Mixer::Output

Media Type 0:
--------------------------
Video: 320x240

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_Overlay {E436EB7F-524F-11CE-9F53-0020AF0BA770}
formattype: FORMAT_VideoInfo {05589F80-C356-11CE-BF01-00AA0055595A}
bFixedSizeSamples: 0
bTemporalCompression: 0
lSampleSize: 0
cbFormat: 1124

VIDEOINFOHEADER:
rcSource: (0,0)-(0,0)
rcTarget: (0,0)-(0,0)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 0

BITMAPINFOHEADER:
biSize: 40
biWidth: 320
biHeight: 240
biPlanes: 1
biBitCount: 8
biCompression: 0
biSizeImage: 0
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0030: 28 00 00 00 40 01 00 00 f0 00 00 00 01 00 08 00 (...@...đ.......
0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050: 00 00 00 00 00 00 00 00|00 00 00 00 00 00 00 00 ................
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0270: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
02a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
02b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
02c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
02d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
02e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
02f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0310: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0320: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0330: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0340: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0350: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0360: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0370: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0390: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
03a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
03b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
03c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
03d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
03e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
03f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0420: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0460: 00 00 00 00 ....


I am just wondering around the possibilities since I use a TV (a Samsung plasma) with my PC.
I think somebody somewhere said (it's far like an old dream...) that may be it's possible to output YCC 4:2:2 through the overlay surface if you also set the output to YCC 4:2:2 in CCC and you feed the overlay renderer with YCC.
Was it a false speculation?


What do you think about this whole question:

May be you already know that many of the HDTVs convert the RGB signal back to YCC 4:2:2 for image processing and those few TVs which has a real RGB mode ("PC mode" or whatever the manufacturer calls it in the user ODS...) usually switches to this mode with 1080p60 signal only. This mode may have other disadvantages too but it can not be used together with 1080p23 materials if you want smooth Blu-Ray playback. So you can choose between 2:3 FRC and proper 4:4:4 processing (probably true RGB in my case but may be YCC 4:4:4, I am not sure, it can wary between models...) or smooth playback.

My PDP has high bit depth image processing (and also has a PC mode but only for 1080p60 and that mode also reduces precision to lower the input lag, so I only use it for games...), so it is virtually transparent in my case. The reduced chroma resolution is visible on some test patterns but not that bad and there are no other conversion losses. On some other TVs however it can look really bad. (I almost give up on picking up a plasma TV when I tested some Panasonic models with RGB signals which has lower bit depth image processing and doesn't have an RGB or YCC 4:4:4 mode at all, like some Samsung models do.)

And here is this thing in the AMD drivers: YCC 4:2:2 output.
I know it is "fake" but I am wondering about what madshi said earlier about 16-bit output.
Do you know where this RGB->YCC conversion happens?
If it happens after the calibration LUT where the VGA dithers the output anyway, than may be it would worth a try to send out 16-bit RGB for the LUT, let the VGA to convert it to YCC and dither the output back to [whatever=8/10/12bit?]. May be it could slightly improve my setup too but it would definitely worth for Panasonic PDP owners.

And depending on how this built-in RGB->YCC conversion works, it may help if you resize the chroma map in only one direction before you output the RGB data.

God, those 8-bit gradient test patterns look awful on those expensive Panasonic PDPs if you feed them with RGB signal and many people doesn't even know how much better could it be if they feed them with YCC 4:2:2 signals to spare the content from a lossy conversion step...

----

Another concern could be that some HDTVs have built-in noise reduction algorithm which simply can not be turned off, plus PDPs use heavy dithering alone. So, I also fear about dithering noise (more than ever), and that's why I use EVR-CP now with simply rounded 10-bit output.
However I am not really sure if my VGA really outputs 10-bit through HDMI. It was sure with DisplayPort but the HDMI port is may be a DVI port and these VGAs dithers the 8-bit output of DVI.

[JanWillem32]

@suanm: I can replicate this problem with the color management if I temporarily remove my monitor's .ICM profile from the Windows color control panel. The color management freezes the player in that case. The error message the player should give in a message box isn't working properly yet. I'll find out how to get those working, as other problems and renderer crashes are also not properly reported because of this.
In the mean time, check if your color profile is installed and working properly, as that's the most likely culprit.

@janos666: A lot of text to work with this time. I'll try to answer your post in a somewhat logical order, and some more.

The two overlay variants work for me on analog D-SUB connection to my CRT, from an AMD HD4890 and on a single-link DVI connection to an old office LCD screen, from an Intel IGP. I can't get it to work with a HDMI device.

It's possible to set Y'CbCr 4:2:2 in the video card's control panel, but it's a double fake, as the backbuffer is strictly RGB 4:4:4. If an application would manage to disable driver/API interference and output data in a Y'CbCr encoded color model on the backbuffer, it would be a proper 4:4:4 Y'CbCr backbuffer.
I know three presentation options that maybe could do that. I haven't gotten to test any of these yet, though. The problems with the limited and full ranges also pose a problem. Limited ranges are mandatory to eliminate once you start processing in a floating point color format.

Slightly off-topic, but I really don't support the decision made to only implement 4:4:4 and 4:2:2 for HDMI, DP and the (legacy) HD-SDI. They should have either properly implement both common sub-sampled formats (4:2:2 and 4:2:0) or none (4:4:4 only).
There should be only one software or hardware entity that handles all chroma up-sampling.
Implicitly allowing two devices to do chroma up-sampling is just wrong. From the perspective of process engineering: you can never apply multiple differently built devices to handle a process of multiple vectors in multiple vectors and expect the same quality of output from each device.
In a more common perspective: one of the first things I did to MPC-HC's EVR CP mixer was disabling the forced conversions through libswscale to RGB32, and later the conversion to YUY2. Forcing pre-mixer conversions to something the mixer should take care of (converting to progressive 4:4:4 RGB) is simply destructive, seen that the mixers can do a lot better job at that usually (like I noted a few days ago). Although I did allow bit-compatible conversions between YV12, NV12 and I240/IYUV and I kept RGB32 conversions as a last resort option for if all bit-compatible formats failed (as some older Intel IGPs don't support any 4:2:0 formats in the EVR mixer at all). The original configuration of this item allowed conversion to YUY2 from 4:2:0 sources, so I removed that option. The "up-sampling" (I still refuse to call it up-sampling normally, as it's just a bilinear blur) used in that method involves 16-bit unsigned integer math on the CPU and dithering to 8-bit unsigned integers for writing to a YUY2 surface. That means that something else has to pick up that surface in another rendering stage to make the 4:2:2-based YUY2 4:4:4. Whatever method is used in that conversion, it won't be able to use all the data generated in the first conversion, it will interpolate in a different way and it will dither/round the output values in a different way. I consider that a bug in the workflow, and like the many other bugs in the file-to-user playback workflow I will try to eliminate it and make sure that new bugs don't occur.
For true 4:2:2 source images, it's a bit different matter, those get chroma up-sampling only once anyway.
Also, with a video player you have scaling in the process. The chroma sub-sampling grid of an input image will never match the one of an output image if the complete image is scaled.

The RGB to Y'CbCr conversion for HDMI and DP happens in the driver level interaction of the backbuffer. The backbuffer is locked after presentation (backbuffer interactions are slow, expect quite a few milliseconds of video delay) and converted to Y'CbCr by a matrix multiplication.

Many displays don't enumerate anything but 60 Hz in RGB mode (or something else, less than the display is really capable of processing). However, I've had good experiences in adding custom frame rates (although the NTSC 24/1.001, 30/1.001 and 60/1.001 fps modes can be a bit of effort to add). Nowadays the video card's control panels can even add a lot of modes, but I used to write monitor driver .INI files myself to get the same effect for nearly a decade (usually to get higher refresh rates).
I've also tamed a lot of misbehaving display devices though the (factory) service menu. Nearly all devices will not show all options through the regular menus, but once in the service menus, you can do a lot more. Some TVs only allow you to disable overscan for example in the service menus. With most TVs it's nothing more than using a combination of holding a button on the TV with the on/off button and typing in a 4-digit key-code with the remote. (No screwdriver required like in the 80's.)

Some quotes from the HDMI 1.0 specification about the three base color formats:
"If an HDMI Sink supports either YCBCR 4:2:2 or YCBCR 4:4:4 then both shall be supported."
"All HDMI Sinks shall be capable of supporting both YCBCR 4:4:4 and YCBCR 4:2:2 pixel encoding when that device is capable of supporting a color-difference color space from any other component analog or digital video input."
"All HDMI Sinks shall be capable of supporting RGB 4:4:4 pixel encoding."
I must note that there isn't much implied about 8-bit compared to higher bit depths in that part of the text.
A device that doesn't meet these criteria can't apply HDMI ports, HDMI logos, claim any HDMI interoperability, et cetera.

It's indeed possible to have a 16-bit output. To be more specific: it's possible to set quite a few DXGI color formats with DirectX 10 or 11 in this list for output: http://msdn.microsoft.com/en-us/library/bb173059%28v=vs.85%29.aspx . In DirectX 10 or 11 the display driver is fully responsible to convert the presented backbuffer by rounding or dithering the color data on it to a compatible output format. (With of course the limitation that windowed mode can only be 8-bit.) Dithering by a video card is at best a temporally changing 4×4 ordered dither of up to 8 states of the same pattern, but 4×4 static ordered dither is more common. This is done in simple programming math, no sampled dithermap is involved.
For RGB color data these are typically used:
DXGI_FORMAT_R32G32B32A32_FLOAT = 2,
DXGI_FORMAT_R32G32B32_FLOAT = 6,
DXGI_FORMAT_R16G16B16A16_FLOAT = 10,
DXGI_FORMAT_R16G16B16A16_UNORM = 11,
DXGI_FORMAT_R10G10B10A2_UNORM = 24,
DXGI_FORMAT_R8G8B8A8_UNORM = 28,
DXGI_FORMAT_B8G8R8A8_UNORM = 87,
DXGI_FORMAT_B8G8R8X8_UNORM = 88,
There are 32-bit integer types, but since pixel shaders (the typical units carrying out the colorizing parts) output 32-bit float, I think it's useless to work with color data in 32-bit integer formats, both for input and output.

CCC can perfectly well indicate if a device is connected using a HDMI or only legacy DVI. I don't know if there's a valid test for the actual bit depth other than a raw data capture of the sent video in TMDS signals and analysis of that. The program MonInfo can at least display the information the video card is receiving from the display device, you might get to know more from that.
In my case it was pretty easy to confirm: the 8-bit mode without dithering on the gradient shader has terrible banding, the 10-bit mode is a lot better. Both my display devices can't dither/make video noise on their own.
There was no advantage for using the 10-bit mode on the old office LCD screen I tested. It showed the same banding in 8- and 10-bit mode.

Now that you're here, I'd like to add XvYCC input support to the color management section. http://en.wikipedia.org/wiki/XvYCC http://msdn.microsoft.com/en-us/library/ff563113%28v=vs.85%29.aspx
There is material available, and it's quite compatible with the current rendering chain.
I've verified that the mixers are capable of outputting non-clipping color data (RGB values lower than 0, and higher than 1), with adequate accuracy in the quantization for both floating point surface types. (I suspect that the matrices have some minor truncation rounding errors, though.) I can alter the working surface format to change the normal working R'G'B' and RGB surface data to have normal intervals, instead of extended floating-point ones. That means intervals of [0, 1] for R'G'B' and RGB, intervals of [0, 1], [-1, 1] and [-1, 1] for Y'CbCr. The other interval variant of [0, 1], [-.5, .5] and [-.5, .5] Y'CbCr isn't very useful when working with floating point surfaces.
I'm wondering how to set up proper color management and rendering chain for such material. As far as I know, with all larger source gamuts, the absolute colorimetric rendering intent becomes more important. That's because when mapping a relatively large input gamut to a smaller output gamut for the display, compressing the ranges of the gamut will distort far to much visually, compared to clipping the source out-of-gamut colors.
Also, I've been thinking of matrixing all source materials to a linear full XYZ color space as working RGB surface. I'm very familiar with this format, and having a color space that can contain all possible other color spaces for video and images is a rather big advantage in terms of designing a rendering chain. It would eliminate separate 3DLUTs for each input format at the color management section. I can easily adapt color controls and several other filters that will handle each input color format in exactly the same way. For example: at the moment, the output of the color control shaders can't produce out-of-gamut colors, and the shifts in luminance, chrominance, composition and gamma are different for PAL, NTSC and HD formats. All other filters (shaders) that depend on color blending are affected in the same way.
One downside is that I'll have to split off a slim, basic 8-bit renderer with a limited feature set for older hardware, but I'm okay with that. (I wish I could have a peek at the Haali renderer source code for this.)
Another problem is the quantization limitation of the 16-bit floating point format. I don't know if it will cause visible artifacts on even a cheap TN LCD screen, let alone a high-end OLED screen.
What are your views on these subjects? (Input from other visitors of this thread is of course very welcome, too.)

[mindbomb]

is the dithering options only supposed to be used with the floating point processing options?

[janos666]

I know the service menu of my TV, there is nothing interesting in there except the ADC/WB calibration settings which I already reconfigured.

Custom monitor INF wouldn't help either, I can set my resolution to almost anything (the EDID is already "bloated" with many formats and some others work too if I "force" them with a D3DFS application).
The problem is that only 1080p60 triggers a real RGB (or possibly YCC 4:4:4?) processing inside the TV. But I obviously want to output 1080p24 when I watch Blu-Ray movies to achieve smooth motion (the PDP can run at 96Hz while fed with 24Hz) and this resolution triggers a different kind of internal processing which always converts everything back to YCC 4:2:2. And some TVs doesn't have an RGB or YCC 4:4:4 processing mode at all.

It's not the HDMI decoder chip, the TV usually accepts everything (YCC 4:2:2, 4:4:4 and RGB too) but it usually converts it back to YCC 4:2:2 for processing (scaling, gamut and gamma correction, white balance and all those "mighty magic muthef@ker features" in the user-OSD starting from thousands of virtual/digital noise/contras/black reducer/increaser tricks, etc)

That's why I think it could be a good idea to feed them with true 4:2:2 signals. I think it could make a noticeable improvement. Because unless this [ANY but YCC 4:2:2] -> YCC 4:2:2 conversion is done by a high precision internal processor, it's not a good idea to feed them with RGB (as I said, it is virtually transparent with my TV but I saw some expensive Panasonic plasmas which looks really bad with RGB input).

----

No, Absolute and Relative handle the gamut in the same way. The only difference between them is the white point handling (the Absolute intent corrects the WP too).
The Perceptual and Saturation intents are the tricky ones, but Perceptual is probably what you want with xvYCC. It compresses the gamut with less banding than Rel/Abs. (And I don't really know what Saturation exactly does in lcms.)

Yah, the XYZ space could be way big for usual video materials with float16 encoding. It's very big (many possible values will never appear) and the Y is linear. And you face the problem that you have to decide about how to linearize the gamma weighted RGB input.
But yes, it could make the CMS tasks more easy and may be more effective, so it may worth a try with float32.


---------

@mindbomb
The 10-bit integer surface mode can benefit from it as well if the output is 8-bit.

[CruNcher]

Yeah TV manufactures as well some Monitor ones should implement plain non post-processing modes, but they unfortunately like to brag with the advanced Post Pro they have either developed in house licensed or done in collaborative Research MSU(Yuvsoft) and Samsung are the best example here :( Hard to understand that their is no (turn everything off feature)

[JanWillem32]

@CruNcher: I totally agree. I wouldn't have bought my current (and a few past) display devices if I wouldn't be able to control a lot. With my CRT it's easy: all input, processing and output is analog. That does produce visible analog artifacts, but the digital parts of the processing chain are done on the video card, which is pretty easy to control in an almost absolute way. My projector has pretty decent default settings, and all filters are quite properly configurable, but there are no real 1:1 analog controls in the menu.
I once played with an LVDS (a digital interface, similar to DVI-D) driving unit for a laptop LCD screen. It had simple analog voltage input pins to create the digital to analog transfer function for the RGB matrices in the display, and was void of any digital processing. The backlight used a separate controller. Modern versions of such a driving unit can probably use programmable RGB transfer curves and a better frame buffer system.
I would most certainly like displays to give control over the analog driving parts, while the digital image processing controls are disabled. That shouldn't be too hard to implement. I wonder what professional equipment offers, as I can't think of a more demanding calibration task than the one for DCI certification.

@janos666: There are no chroma sub-sampled backbuffers possible. Any compatibility with 4:2:2 will have to be hard-coded into or next to the ramdac as a convertor for the 4:4:4 backbuffer. I'm not even sure that part will activate properly if an Y'CbCr 4:4:4 direct overlay-or-something is used. I can only set a few of the DXGI_FORMAT RGB items as backbuffer, all are 4:4:4.
I'll have a go with testing a larger processing gamut. I'll try to implement similar sliders for color controls as the VMR-9 items (Options, Miscellaneous tab), with a default gamma set to a basic 2.4.

@mindbomb: Single-level dithering is intended only for 10-, 16- and 32-bit surfaces with a relatively clean image in the processing pipeline for 8-bit output. The 10-bit display output mode doesn't gain much with single-level dithering from 16-bit surfaces, and nothing from 10-bit surfaces. The random dither can work with just about anything, but it will add several levels of random colored surface noise on gradients and single-colored parts (it features contour detection to dither less or do nothing on already noisy parts).

[suanm]

"@suanm: I can replicate this problem with the color management if I temporarily remove my monitor's .ICM profile from the Windows color control panel. The color management freezes the player in that case. The error message the player should give in a message box isn't working properly yet. I'll find out how to get those working, as other problems and renderer crashes are also not properly reported because of this.
In the mean time, check if your color profile is installed and working properly, as that's the most likely culprit."

Hi JanWillem32
I don't really know where and how to check my color profile you said above? tell me clearly where and how to check it,please.

[JanWillem32]

Copied from a link I posted a while ago:
All actions will be done at Color Management tab, which is accessible by right click on Desktop, and select Personalize on the contextual menu. Click on Display Settings link in the Personalization menu. In the Display Settings window, click on Advanced Settings… button. Then click on Color Management tab, and finally click on Color Management… button. You will need to select (tick) Use my settings for this device to be able to remove, change or set new color profiles.

If you use the classic view for the Windows control panel, the Color Management item is in plain view as a regular icon there.
Both Vista and 7 feature an extremely basic color wizard that can produce working profiles. You can't compare it to an actual hardware calibration device, but it's a nice tool for those that want to give display calibration a try. (However, it calibrates toward an sRGB profile. I'm personally not too fond of the 2.2 gamma setting.)

[JanWillem32]

I've had to bend over backwards for some of the fixes I made this time, but the results make up a lot. I do need to clean up and optimize the new code I wrote, and fix the new set of error messages, as some won't show up.
-I corrected some of EVR Sync's shader handling code, so that scalers and screenspace shaders should work better
-Pixel shader menus will now work even without a video renderer active
-VMR-9 r. can now use screenspace shaders
-I added a fix for a rare problem with a hanging still image when switching files in exclusive mode
-Not sure how and why, but aspect ratio correction seems to work again and exclusive mode is less oversensitive to keyboard commands (but not perfect yet).
-I added some optimizations for a shorter initialization time

[cca]

I wish someone would fix the DVD playback issues too, for now I have to use plain EVR :/ .But since it's an upstream issue, who knows when.

[JanWillem32]

I don't have much experience with DVD playback problems. As far as I know, DVD subtitles work, and playlists for .VOB files work fine. I'm only not too sure about menus, but that's something I really don't know how to work with. If I were better with GUI items I'd sooner add a few buttons for a toolbar in exclusive mode, anyway.

[cca]

I don't have much experience with DVD playback problems. As far as I know, DVD subtitles work, and playlists for .VOB files work fine. I'm only not too sure about menus, but that's something I really don't know how to work with. If I were better with GUI items I'd sooner add a few buttons for a toolbar in exclusive mode, anyway.

I was just referring to the specific renderer problem mentioned before, i.e. it doesn produce the right aspect ratio and the image is distorted.

EDIT: just tried your latest build, the issues I used to have with the AR seem to have gone!

[suanm]

Hi JanWillem32
Today is so lucky,I happen upon opening mediafire page ,download build dfr3204 immediately .my system is windows xp sp3,I don't find any of profile in the Color Management item on the Windows control panel, but sRGB Color Space profile. when I choose 'Enable Little CMS' function,Playing video becomes black screen(no video image). After Canceling 'Enable Little CMS' function,video image comes back(appears).So seems that there are some of little bugs on build dfr3204 software

[TheElix]

An easy one to write. This code might not be completely optimal, but I believe I interpreted the main function correctly. It's mostly a noise-resistant version of a bilinear kernel, with support in a third pixel.
Does it mean you can implement this Magic Kernel in the player? :eek: Because that example with vegetables was very impressive!
Got your latest build, gonna test everything now, including new scalers! This is like a revolution to me.
Can't say anything about complex things you and janos666 discussed but I have to say that there're more and more HDTV users who will be able to take advantage of these things. I also have Panasonic PDP (TX-PR42GT20).
A quick question: which is better to set as pixel format for me? Obviously not Full RGB because then I get crushed picture.

EDIT: Hmmm, I see virtually no difference between Bilinear (PS 2.0) and Cubic B-spline6 (PS 2.0a). Do you?
Bilinear (PS 2.0): http://rghost.ru/10315281/image.png
Cubic B-spline6 (PS 2.0a): http://rghost.ru/10315361/image.png

Bicubic gives sharpest picture but a lot of artifacts. Catmull-Rom spline6 is almost as sharp and gives a little less artifacts so I'll be using it for now.
What about Lancoz, any plans to implement it?

[Hera]

Does FullFP setting work? I am not getting any frame dropping with FullFP with these builds.

[Qaq]

Does FullFP setting work?
It does. Check OSD stats and jitter values for FFP and HFP.

[Hera]

It does. Check OSD stats and jitter values for FFP and HFP.

FullFP does not drop frames now per OSD stats.

Video visually is smoother with D3DFS still though.

[JanWillem32]

@suanm: Good to hear that you can access the site again. I know that the renderer will refuse to work if color management is enabled while there's no active color profile installed. That's the correct behavior. The problem is that the error message I wrote for it just doesn't show up. It should say: "color management failed to find the active display device profile (.ICM file)".

Does it mean you can implement this Magic Kernel in the player? :eek: Because that example with vegetables was very impressive!I still have to mess around a bit with the scalers. There's no absolute perfect one, so the best I can do is to implement a few good ones. I still have to analyze about 8 scalers of which I do have the code, but haven't seen how well it performs in a rendering engine. I've actually written only a small number of scalers myself yet. I have to analyze the filters carefully to uncover characteristics such as ringing, haloing, aliasing, noise resistance and posterization. I must admit, that's not easy for me. The two documents on the higher-order spline types took me hours to write, let alone analyze and implement.
Also, you've probably seen the names I give to my pixel shaders. If I would implement "Magic Kernel", It's going to need to be renamed to something at least 2 times as long.:pCan't say anything about complex things you and janos666 discussed but I have to say that there're more and more HDTV users who will be able to take advantage of these things. I also have Panasonic PDP (TX-PR42GT20).It's already difficult for software developers to get along with the internal hardware of PCs (drivers, interaction with other software, CPU/GPU performance and so on). External hardware is at a whole other level. I believe that the CRT TV my parents bought in 1994 behaved a lot better then most of the current TVs in the same price class today. Although it was limited to D-SUB and lesser analog connections, it behaved quite similar to a monitor after geometry adjustment.
A quick question: which is better to set as pixel format for me? Obviously not Full RGB because then I get crushed picture.The rendering engine can't deal with anything else than full range formats. The output is always full range RGB, too. If another color format is set in the video card's control panel, both quality and performance degrade because of the extra conversion step. I've never serviced a display device that really couldn't deal with full range RGB input. All TVs I've worked with in the last few years have options in the regular menus for using full range or are even hard-coded to use full ranges. (Getting overscanning disabled is a bigger problem.)EDIT: Hmmm, I see virtually no difference between Bilinear (PS 2.0) and Cubic B-spline6 (PS 2.0a). Do you?Cubic B-spline6 is the most noise and aliasing resistant of the current internal scalers. On the other hand, on very sharp contours, it's more blurry than a standard bilinear.Bicubic gives sharpest picture but a lot of artifacts. Catmull-Rom spline6 is almost as sharp and gives a little less artifacts so I'll be using it for now.
What about Lancoz, any plans to implement it?The internal bicubic forms are well-written and sharp, but indeed have the awful tendency to have a lot of aliasing and haloing.
In order of perceived sharpness (nearest neighbor omitted): bicubic A=-1.0, bicubic A=-0.8, Catmull-Rom spline4, Catmull-Rom spline6, bicubic A=-0.6, cubic B-spline6, bilinear, cubic B-spline4.
That doesn't say what scaling artifacts each creates. The 3 Bicubic forms are very sharp in general on rectangles, but score badly on interpolating diagonals or curves. For example, with the gray-on-gray text test, the bicubic A=-1.0 and bicubic A=-0.8 have so many artifacts, it's bad for readability. Catmull-Rom spline6 is a bit less sharp than bicubic A=-0.6 when scaling a grid of single-pixel rows and columns, that's just inherent to its nature.
I'll add some windowed sync filters later on. I'm already quite happy I could add 4 scalers in a short time. Developing these takes time, as there's hardly any code I can just copy directly into a pixel shader. (On top of that, the fold-down menu of the scalers is just very annoying to write. None of the translators have touched it either.)

@Hera: There are problems with memory management for textures in the renderer. I've solved a lot of them, so getting less frame drops is to be expected. Exclusive mode will always perform better than windowed mode, as there's simply a rendering obstacle less.
By the way, seeing your hardware (nVidia ION, ATi Radeon HD 4250M and nVidia GeForce 6600), can you really get a regular 1080p24 blu-ray video to render with FFPP? It's a bit demanding on memory bandwidth, which is often limited with low-end or older mid-end hardware.

[Hera]

4250M still crashes and burns; the whole system becomes unresponsive / quite laggy.
NV ION seems fine with D3DFS mode, not without it.


Also,
Overlay + no D3D + subtitles = black background of the graph.
Overlay text is all tiny for some reason.

[Qaq]

FullFP does not drop frames now per OSD stats.
I meant you can see 'FFP' in OSD. Also, you can see that FFP produces a bit bigger jitter value than HFP. At least I see (under XP), and that proves for me FFP is working. But I'm not sure someone is really see a visible difference in PQ between FFP and HFP. Anyone?

[JanWillem32]

When dealing with 10-bit output or better, a half can't really deliver enough precision for an accurate single-level dither. Next, there are a few rendering stages in the mixer, there are scalers, the final pass and I set a few pixel shaders. With every rendering stage, you have to write out to the next surface. If you set any other format than the calculation format, the output of each stage is rounded. Some of that rounding in a few stages can be quite degrading on the quality in the end.

[Qaq]

No doubts in math, I only wonder if thats visible or not. YUV>RGB, scaling are lossy convertions anyway. Personally, I love to use as mach precision as I can with my equipment. But sometimes I have to find an compromise to keep it working and watch some 'heavy' videos. With my ATI 5450 I have no problem with 1080p24, but those HDTV 1080i29 just drive me nuts sometimes. And here comes a problem that I just don't know a really good tool to measure the GPU loads. I tried GPU-Z, it showed ~57% GPU load while video playback was stuttering. Also, GPU-z doesn't show me VRAM load under win7. I don't even say about Bus load. It's hard to find the bottleneck without complete measurements.

[TheElix]

I ran sharpness & overscan test (http://narod.ru/disk/15684583001/5-Sharpness%20%26%20Overscan.rar.html) and got some disturbing results: http://screenshotcomparison.com/comparison/58782
EVR is the only renderer to pass the test. I don't know, maybe it's just my system. I would ask somebody else to run this test too.
BTW, JanWillem32, is there a possibility to include internal subtitle support in MPC-HC for EVR?

[JanWillem32]

@Qaq: I've also seen problems with interlaced content that features 3:2 pulldown. The current presenter threads try to predict frame times, but pulldown causes prediction to fail. Even when not using any Vsync options, that's still an obstacle. Trying to skip pulldown makes playback very jerky (understandable, since 1/3 of all fields is fake or duplicate). Any additional filters/options that make playback heavier than the minimum also seems to have a disproportionally big impact on the inaccuracy of the presenter.
With progressive video, I don't see these problems, even if my GPU peaks up to 95% load. I wish there was a way to implement a better version of the pulldown filter in the renderer, one that informs the presenter. It's probably okay too if the decoder performs pulldown without deinterlacing and reports 2/3 of the field rate to the mixer (with the correct flags for top and bottom fields).
A small side-note: the NTSC slowdown framerates of 24/1.001, 30/1.001 and such, will always be a bit tedious to work with. Setting 24 or 30 exact frames per second are a lot easier to time, and using 1.001 speedup or 1‰ frame duplication has a positive impact on performance.
I still have to find ways to get the subtitle renderer less jerky. Someone posted a simple SD video a while ago with some animated text subtitles (not even extremely fancy ones) that would just choke the renderer just before presenting each new line. I think it will take some time before that improves. It's a difficult item to work on.

@TheElix: I can't replicate the results in those pictures. The renderer will correctly use nearest neighbor filtering when performing 1:1 mapping. It looks like something is offsetting the picture in your case. It's been a while since I've seen this type of problem. You're sure that even the basic (older) renderers have the same problem?
I haven't worked with vanilla EVR yet, but it supports the OSD already, so subtitles should be possible.

[TheElix]

JanWillem32
I've asked at other places, and apparently, this is my pc-exclusive problem. I have the same blurry text as in the top right corner of the picture when I run other applications which use hardware acceleration (Firefox, java apps). For example: http://rghost.ru/10403441/image.png
If only I could determine the root of the problem and know where to ask. Sorry for a major offtop.
BTW, I have OSD enabled and I can't get subtitles to show in MPC-HC (without using external filters, of course).

[JanWillem32]

I was thinking of this topic: http://forum.doom9.org/showthread.php?t=159908 .
That one doesn't seem to be exactly the same, but it does have a few hints. Take a look at the system-wide font scaling options, the overscan settings in the video card control panel and maybe some of the 3D settings there, too.
Vanilla EVR doesn't have the extra connection to the subtitle renderer (yet), only the OSD renderer (and that one outputs screen-sized images only, so the picture is usually distorted).

[TheElix]

Problem FIXED!!! I turned off Morphological Filtering... -_-
Day-saving link: http://support.mozilla.com/ru/questions/796715

[Hera]

Are you going to merge EVR and EVR:CP then?

~30Hz 1080 content requires noDC and D3DFS options.

[JanWillem32]

EVR and VMR-9 are two standard renderers installed in Windows (or come along with the .NET package). "Custom Presenter" and "(renderless)" are presenter variants that borrow the mixer part, but don't use the default presenter. (They share the same presenter code.)
EVR Sync also uses the default mixer. For further improving the renderers, a custom mixer can be added. I would like that, but it's quite a big job.
30 Hz HD video, especially with interlacing is heavy indeed. Disabling the rendering of desktop items can indeed save just enough GPU power for smooth rendering.

[CruNcher]

Problem FIXED!!! I turned off Morphological Filtering... -_-
Day-saving link: http://support.mozilla.com/ru/questions/796715

Yep Elix this is from a user perspective a problem before Vista/7 you hadn't to take it into account bit since the GUI architecture changed entirely to Direct3D/2D/Write/Warp (DWM) you have to take this into account and their is no other way by either the Application Developers or the GFX Driver makers with their Profiles to adapt to this :) And there i see a big problem with different renderer with different requirement it will become funny handling this from 1 Application as Nvidias and ATIs management only works on the Application layer (executable to be exactly to make it decisions).

[G_M_C]

One question, im shure someone asked before but i cannot find the right answer.

I have downloaded and installed moninfo. It confirms my receiver/display device combination accepts 4:4:4 / 4:2:2 / RGB at 30 and 36 bit through HDMI. It also accepts xvYCC601 or xvYCC709.

Firstly, i would be interested in a xvYCC output option in MPC-HT.

Secondly, moninfo tells me what color format connection is possible, but is there any way to find out what connection is actually made, and what kind of color format is actually send over ?

[JanWillem32]

The currently rendered display color format can be indicated by dxdiag.exe. If the current display mode indicates "(32 bit)", it's X8R8G8B8.
Y'CbCr modes can be selected in the video card's control panel. If they're not there, it means only RGB can be used.
4:2:2 and 4:4:4 modes are different from each other in handling deep color modes (anything beyond 8-bit).
HDMI 1.3 and below allows 4:2:2 modes only with 8-bit color, 4:4:4 modes can be up to 16-bit. Flags are used to indicate compatibility.
HDMI 1.4a allows 4:2:2 modes with up to 12-bit color, but devices don't have to support it (the same behaviour as with HDMI 1.3 is allowed).
I must note that I don't know if any video card really supports pass-trough of deep color data in Y'CbCr mode. It's possible that it's limited to 8-bit color. I also haven't seen such a mode working yet.
Matrixing xvYCC sources to a working RGB surface is easy, I've already done that. The color management can be adjusted to this type of input easily.

[Qaq]

I must note that I don't know if any video card really supports pass-trough of deep color data in Y'CbCr mode. It's possible that it's limited to 8-bit color. I also haven't seen such a mode working yet.
Yeah, I start to think here could be a HDMI transmitter's limitation, since both AMD and Nvidia are affected according to this:
Q3) You said the xxLD450 supports 4:4:4, but I’m not seeing it, what's wrong? -OR- Why is the overall picture quality fuzzy, especially red colored text? (http://www.avsforum.com/avs-vb/showpost.php?p=19723268&postcount=647) :
After extensive research and experimentation by galneon and others, 4:4:4 sampling will not work if you use a direct HDMI->HDMI connection. For both Nvidia and ATI video cards, there appears to be something intrinsically wrong with the HDMI information exchange when HDMI video+audio is enabled, which forces 4:2:2. galneon's overall conclusion about this issue can be found here: link. If you want to read the entire chain of posts, start here: link. It is of interesting note that this problem is universal, and not just specific to the xxLD450.

Currently, there's only two workarounds. 1) Use your video card's DVI port with a DVI->HDMI adapter, or 2) Use the EDID Override fix . The EDID override disables the HDMI extensions which will force the TV to appear as a typical DVI monitor to your video card (as if you were using a DVI->HDMI adapter). However, by disabling the HDMI extensions, you no longer get audio over HDMI.
See also 5xxx/6xxx series: HDMI to HDMI connection forces 4:2:2 subsampling. DVI to HDMI connection proper 4:4:4 (http://forums.amd.com/game/messageview.cfm?catid=260&threadid=145310)

[JanWillem32]

Interesting, but a bit odd. I haven't tried a card from the 5xxx/6xxx series yet. My HD4890 and a simple HD4350 card I've worked with were both fine with HDMI output (both have active audio output). It's not like I wouldn't be able to see chroma artifacts, as I've used the grid shader as a basic test for quite some time already. I wonder what factors contribute to breaking the color formats. I must note that I always set full range RGB when it's available (all other formats are only converted from full range RGB anyway).

[Qaq]

There are also evidence that FullRGB is affected too. IMO, if both vendors have same bug, it's more likely not software but hardware (HDMI transmitter) bug.

[G_M_C]

The currently rendered display color format can be indicated by dxdiag.exe. If the current display mode indicates "(32 bit)", it's X8R8G8B8.
Y'CbCr modes can be selected in the video card's control panel. If they're not there, it means only RGB can be used.
4:2:2 and 4:4:4 modes are different from each other in handling deep color modes (anything beyond 8-bit).
HDMI 1.3 and below allows 4:2:2 modes only with 8-bit color, 4:4:4 modes can be up to 16-bit. Flags are used to indicate compatibility.
HDMI 1.4a allows 4:2:2 modes with up to 12-bit color, but devices don't have to support it (the same behaviour as with HDMI 1.3 is allowed).
I must note that I don't know if any video card really supports pass-trough of deep color data in Y'CbCr mode. It's possible that it's limited to 8-bit color. I also haven't seen such a mode working yet.
Matrixing xvYCC sources to a working RGB surface is easy, I've already done that. The color management can be adjusted to this type of input easily.

I'd like to go into the subject of xvYCC some more;

I'v been reading around on the interwebs', and get the idea the 10-bit/color output seems (on Ati's/AMD's) at least only possible on FireGL/FirePro cards. There is an softmod possible to recognize youe 'regular' radeon as a FireGL/Pro, but this is a bit of a hack.

In some earlier post you suggested that you could set output format to several possibillities without much trouble, including xvYCC.

Couple this with the fact that xvYCC is promoted on consumer grade appliances for a while now, and many if not all recent TV's / receivers etc. support it, and since you state that 'Matrixing xvYCC sources to a working RGB surface is easy', I come to the idea that trying to get xvYCC output (to HDMI) working in MPC-HT might be the way to go to get wide(er) gamut output of MPC-HT to a wide audience of users.

Do you think this to be a feasable idea or option ?

[Qaq]

Andy O said he saw "30 bit" in TV's OSD with 10 bit output option enabled in MPC. And AFAIR, he noted no difference w/ and w/o. He uses some ATI 5 or 6 series card.

[janos666]

See also 5xxx/6xxx series: HDMI to HDMI connection forces 4:2:2 subsampling. DVI to HDMI connection proper 4:4:4 (http://forums.amd.com/game/messageview.cfm?catid=260&threadid=145310)

It was an old driver bug which has been resolved since months. I just tested it today with a fresh beta driver I have.

Full Range RGB 4:4:4 pixel format:
Non-labeled HDMI input, Game mode OFF -> 4:2:2
Non-labeled HDMI input, Game mode ON --> 4:2:2
PC-labeled HDMI input, Game mode none -> 4:4:4 (may be still processed in YCC 4:4:4)

And I got exactly the same results after I changed pixel format to YCC 4:4:4 in CCC.

The levels are also seem to be correct in both Full RGB and [what? limited??] YCC. (There is no black crush and black isn't light gray...)


A strange thing: I have distorted colors (looks like RGB is only flagged as YCC or vice-versa but not converted) with PowerDVD 11 in HDMI 1.4 1080p24 3D mode when CCC is set to YCC output.


Despite the 4:2:2, I am using the TV with non-labeled input and I feed it with Full Range RGB because I can't do 3D CMS with PC games, and the TV doesn't offer gamut emulation in PC mode. And the gamut error is more noticeable than the 4:2:2 chroma sub-sampling (without the help of test patterns and cameras in macro mode...), plus the gamma and white balance is also more precise with calibrated hardware controls, so I don't really need a VGA LUT.

[janos666]

Andy O said he saw "30 bit" in TV's OSD with 10 bit output option enabled in MPC. And AFAIR, he noted no difference w/ and w/o. He uses some ATI 5 or 6 series card.

Turn off the dithering in MPC-HC and you will see the difference. Well... at least on a 8-bit gradient test pattern.

Do you know what was his pixel format setting in the CCC? (I guess RGB but who knows...)

I could never test if these cards output real 10-bit RGB or that is only the same dithering which they offer for single-link DVI.

[G_M_C]

Andy O said he saw "30 bit" in TV's OSD with 10 bit output option enabled in MPC. And AFAIR, he noted no difference w/ and w/o. He uses some ATI 5 or 6 series card.

It was an old driver bug which has been resolved since months. I just tested it today with a fresh beta driver I have.
[...]


That can be, but the number of consumer grade devices (read this as the 'great value for money devices' that average Joe buys) and ditto graphics boards that verifiably output or accept 10-bit / color will be much lower than number of the same grade of devices that support xvYCC (assuming the xvYCC output works offcourse). Cause the latter is supported in almost everything recent (even some smartphones support it). In my opinion that makes xvYCC the shurest option to get wide(r) gamut display to the masses.

[janos666]

Ah, well...

xvYCC is only available on my TV when I feed it with YCC signal. (It's grayed out with RGB signals which I think is logical enough...) And it basically does the same thing which happens when I set the Color Space option (which is available with RGB input as well) to Auto.
I set up the Custom mode for sRGB/Rec709 primaries instead. (The Auto cuts the green back too much in the Y direction.)

So, it would obviously require a real YCC output from the VGA card which would be very tricky if not completely impossible with today's hardwares and APIs (it would be a nice thing though, xvYCC or not...)
However AMD and nVidia both claims that their latest hardwares support xvYCC and DeepColor.

I think Jan would still work with RGB output and he only wants to support the wide gamut (xvYCC encoded) materials via the CMS engine (with the available gamut mapping methods).

[TheElix]

It was an old driver bug which has been resolved since months. I just tested it today with a fresh beta driver I have.
OH RLY? "Red" and "Magenta" are blurry and everything casts shadow on blue background here on HDMI-HDMI + Catalyst 11.6. Isn't this a sign of 4:2:2 chroma subsampling?
http://img.photobucket.com/albums/v293/nuker43/inputlag/TintBlueRGB.png?t=1287963155
Thanks to Qaq for pointing out the problem. I never though it could be solved.
*sigh* I spent all day on it and haven't solved it yet.

[fairchild]

OH RLY? "Red" and "Magenta" are blurry and everything casts shadow on blue background here on HDMI-HDMI + Catalyst 11.6. Isn't this a sign of 4:2:2 chroma subsampling?
http://img.photobucket.com/albums/v293/nuker43/inputlag/TintBlueRGB.png?t=1287963155

Yeah I tested this for shiz and giggles and on my plasma I can't get 4:4:4 regardless of pixel format and I even tried DVI to HDMI dongle. I always get red and magenta blurred. My plasma doesn't have a PC labeled HDMI port. Suffice to say, I'm pretty sure my TV can't do true 4:4:4, even though in moninfo it says it supports it.

Supports 36bpp........... Yes
Supports 30bpp........... Yes
Supports YCbCr 4:4:4..... Yes

xvYCC709 support......... Yes
xvYCC601 support......... Yes

[TheElix]

I even tried DVI to HDMI dongleYes, me too.
Suffice to say, I'm pretty sure my TV can't do true 4:4:4, even though in moninfo it says it supports it.

Supports 36bpp........... Yes
Supports 30bpp........... Yes
Supports YCbCr 4:4:4..... Yes

xvYCC709 support......... Yes
xvYCC601 support......... Yes
Same here.

Supports 48bpp........... No
Supports 36bpp........... Yes
Supports 30bpp........... Yes
Supports YCbCr 4:4:4..... Yes

xvYCC709 support......... Yes
xvYCC601 support......... Yes

I can't find myself giggling for some reason. But I've not given up yet until I manage to disable audio through HDMI as suggested. Any help here would be greatly appreciated!

[janos666]

Supports YCbCr 4:4:4..... Yes

I bet it "supports" it like a HD-Ready TV accepts an 1080i signal or an old monochrome analog TV displays the luminance signal and ignores the chroma information...

I tried it myself and it works for me. I could upload my photos but I don't think they are more trustworthy than my word because images could be faked as well... So believe me or not, but I think your should blame your TV instead of your VGA.

My current driver version is 8.86-110512a-119746E by the way.

[fairchild]

I bet it "supports" it like a HD-Ready TV accepts an 1080i signal or an old monochrome analog TV displays the luminance signal and ignores the chroma information...

I tried it myself and it works for me. I could upload my photos but I don't think they are more trustworthy than my word because images could be faked as well... So believe me or not, but I think your should blame your TV instead of your VGA.

If you re-read my post, I did blame the TV. I'll copy and paste again for you:

Suffice to say, I'm pretty sure my TV can't do true 4:4:4, even though in moninfo it says it supports it.

[janos666]

Sorry, that post was meant for TheElix but I mistakenly quoted the "Supports YCbCr 4:4:4..... Yes" line from your post (you both wrote this after each other).

[TheElix]

I have Panasonic GT20 (2010 model). I wonder if VT20 supports 4:4:4.

[fairchild]

I'm not sure if many plasma's do proper 4:4:4. I also have a smaller Sony LCD and it does true 4:4:4 but it has to be set in graphics mode.

[JanWillem32]

I've had a closer look at the matter of setting Y'CbCr on output. I had the same problem as before: invalid call errors. I'm not so sure my video card supports the Y'CbCr overlay function.
I'll have a try with my mother's laptop in a while, as that one has a HD5450M GPU. Let's see if solve that weird 4:2:2 problem.
I don't have enough time to answer everything else right now, I'll try that later.

[TheElix]

I just realized why my PDP doesn't support 4:4:4. This line in EDID:
Supports 48bpp........... No
Because 4:4:4 is 16 bits per channel, right?
And I apologize before JanWillem32 for being off-topic.

[Qaq]

It was an old driver bug which has been resolved since months. I just tested it today with a fresh beta driver I have.

Full Range RGB 4:4:4 pixel format:
Non-labeled HDMI input, Game mode OFF -> 4:2:2
Non-labeled HDMI input, Game mode ON --> 4:2:2
PC-labeled HDMI input, Game mode none -> 4:4:4 (may be still processed in YCC 4:4:4)

And I got exactly the same results after I changed pixel format to YCC 4:4:4 in CCC.
Just made a DVI-HDMI connection.
TV/RGB ('PC' input) - 'magenta' looks ok, so I suppose it's 444.
TV/YCC (all the rest) - 'magenta' is blurry.
I forgot to test 'PC' mode with HDMI-HDMI :devil: maybe you're right and this 'sub-sampling' bug occurs with YCC only, no matter of connection type. I'll test RGB input with HDMI-HDMI tomorrow.
The levels are also seem to be correct in both Full RGB and [what? limited??] YCC. (There is no black crush and black isn't light gray...)
Yeah, there is no problem here since CCC 11.2 has been realized.
Turn off the dithering in MPC-HC and you will see the difference.
Do you mean (0) rounding?
Do you know what was his pixel format setting in the CCC?
No, sorry. You better ask Andy O himself.

[janos666]

Do you mean (0) rounding?

Yes. (Only for testing...)

@TheElix
As much as I know none of the Panasonic PDPs do. The G20 is certainly not, and I read the same about the VT30.
Samsung PDDs do but only in PC mode. And it's a little problematic because PC mode doesn't support 1080p24 playback at 96Hz, like the YCC modes does.

[Qaq]

I don't have enough time to answer everything else right now.
We just discuss if we able to set properly our devices to see all of EVR CP/VMR improvments :devil: :)

[Hera]

I had D3DFS off. Right clicked on video and enabled D3DFS so the next movie will start fullscreen.
The thing is, the fullscreen mode seekbar showed up on the CURRENT video which was not fullscreen.

[janos666]

There is still some kind of clipping or overflow problem with the CMS (I guess it's your interpolation shader). Try to use this (http://www.mediafire.com/?bb37bv80g4jmzys) ICM profile. I think the problem will be obvious with the "4-Color Clipping" video from the "AVSHD 709 test disk" but it also appears on real video contents: you get primary or secondary colors instead of full white.

Otherwise it's nice to see that this latest MPC-HC test build is able to run with float32 and 123^3, static ordered settings on my laptop. It was far from possible some months ago. It has only a 8600M GT.

[kostik]

can someone plzz upload the latest version? Medifire is making me trouble downloading.
Thanks

[CruNcher]

@JanWillem32

I experienced something on Win XP and VMR9 Renderless in MPC-HC im not sure if its normal and it seems it's DXVA related (in this case Cyberlinks DXVA), i opened 2 instances of a MBAFF H.264 to compare them switching between them in Full Window Mode the 2nd instance of MPC-HC had visible Aliasing (not sure if it came from the bicubic resize or the deinterlacing failing, though read why i think it can't be the resizing further down)
I tried the same with VMR9 Renderless (same bicubic resize shader) and Lav Cuvid (directly via Nvidias Nvcuvid API + Deinterlacing directly not over the renderer and not via DXVA @ all) and the effect is not visible on VMR9 Renderless so i guess it can't be the Resizing but the Realtime Deinterlacing failing on the renderer for 2 simultaneously opened render instances ?
So is anywhere explained that the DXVA VMR renderer deinterlacing can only be used on 1 open renderer instance and will fail or can fail (Hardware dependent ?) on a 2nd one ?
Maybe it's also something in Nvidias Driver forcing it to fail (saving shader execution time, 2x 1080i 25i->50p on a old 9800 GT VP2) though i wonder why it works without issues then via their own API (practically same shader utilization + memory copy) also the complexity isn't so high @ all i tried to reduce it as much as possible and i can playback both without issues via Nvcuvid side by side.

So in the end i had to learn i can't reliable compare MBAFF results with 2 opened MPC-HC instances using DXVA (at least for now tested with Cyberlinks DXVA) though it will work without issues via Nvcuvid (Decoder) in XP and MPC-HC VMR9 Renderless, not sure either yet if Vista/7, EVR and DXVA2 would change something with this configuration here.

Though also crazy is i can't see the MBAFF failing @ playback of both 1080i 25i->50p streams simultaneously (DXVA) only if i seek in 1 instance and go directly to the same frame and compare them by switching i see the aliasing in the 2nd instance (the first instance is always correctly displayed without any aliasing) @ playback i can't see any aliasing @ all (GPU Load 31%, Video Engine Load 92%, Memory Controller Load 20%, CPU 2-4% Sandy Bridge system). If i try the same simultaneous playback with VP2 and Nvcuvid via Lav Cuvid its super slow though and both instances stutter like hell (memory copy seems to kill this for XP and 9800 GT overhead of Nvcuvid might be to high also optimization level for Lav Cuvid plays into this result most probably, Vista/7 and EVR might be more efficient here).

[JanWillem32]

@G_M_C: 10-bit output and xvYCC output are separate things.
10-bit output capable hardware has been around for some time. Indeed, the workstation cards have been capable for a much longer period, but there are plenty of regular video cards that can use it too.
http://en.wikipedia.org/wiki/Deep_Color
The two xvYCC standards are a "trick" to get more colors encoded inside 8- to 16-bit Y'CbCr: they use the same matrices as bt.709 [HD] and bt.601 [SD], but decode to [0, 255], [1, 255] and [1, 255] intervals, instead of [16, 235], [16, 240] and [16, 240]. This solution isn't as clean as the DCI and studio formats that have always been full range to begin with.
I'll have to see if I can get Y'CbCr and xvYCC encoding working for the video card output. I've only been able to correctly decode them to RGB so far.
As a basic answer: xvYCC modes can encode more colors than Y'CbCr, but it's still less than wide gamut RGB and XYZ encodes. Only the 10-bit output or better can eliminate banding, xvYCC and such can't help with that.

@Qaq: There's also little to gain by 10-bit or better input on devices with panels that are just 8-bit. Only the processor gets a better quality input in such a case, but it's inevitable that the panel will still show banding (or dithering).

@TheElix: HDMI 1.3 and below allows 4:2:2 modes only with 8-bit color, 4:4:4 modes can be 8- to 16-bit. Flags are used to indicate compatibility.
HDMI 1.4a allows 4:2:2 modes with 8- to 12-bit color, but devices don't have to support it (the same behavior as with HDMI 1.3 is allowed).

@Hera: If it were up to me, I'd allow immediate switching of the exclusive mode (it's not that hard to do). Unfortunately, the implementation in the options screen makes that a bit hard. I'm not sure if this will be fixed anytime soon.

@janos666: The interpolation is a simple bilinear:
s1 = tex3D(LUT3D, (s1.rgb*LUT3Dsize+.5)/(LUT3Dsize+1.));
float4 s1 == output register, fn tex3D == sampling function for a 3D sampling register, sampler LUT3D == sampling register holding the LUT3D texture, float3 from float4 s1.rgb == sampled pixel from the video, LUT3Dsize can be defined as 64, 128 or 256.
The format adaptation is required, because DirectX 10/11 maps the first and last pixels to 0 and 1, but DirectX 9 maps them to [0+.5*dx, 1-.5*dx].
In the case of a 256³ pixels 3DLUT this means that the the vectors are 257 units long inside [0, 1], the first pixel is at point (.5, .5, .5), the last is at point (256.5, 256.5, 256.5).
I don't think I've made an error in my calculations, but I can still check the LCMS settings. I can look up color data directly from the generated 3DLUT table with that profile you linked. I will do so soon.
The primary reason I've been updating the renderer is primarily because the original was so very inefficient. I've been making some progress it seems.

@kostik: That again... I'll upload a new version once I've produced a build that works reasonably. We'll see if that download poses a problem then and how to solve it.

@CruNcher: http://www.anandtech.com/Show/Index/4380?cPage=2&all=False&sort=0&page=11&slug=discrete-htpc-gpus-shootout
GPU's also have a maximum to what they can process in DXVA mode. It's already very well known that some low-end GPU's lack adaptive deinterlacing modes, because they don't have enough power on the shader core. It could be that your GPU can't handle the strain of two simultaneous decoding and rendering sessions (or the driver assumes that). Next, it automatically takes a step back in deinterlacing quality.

I've re-written the vertex management for the rendering engine. It wasn't easy, but I do have lower GPU, CPU and memory usage now.
The reason I've not yet released a build with it is because of the subtitle renderer. The subtitle renderer has a very big problem that causes unwanted swapping between video and system memory. I've yet to solve that. If it takes any longer to solve the problem, I'll make an intermediate build without the subtitle renderer updates.

[CruNcher]

@CruNcher: http://www.anandtech.com/Show/Index/4380?cPage=2&all=False&sort=0&page=11&slug=discrete-htpc-gpus-shootout
GPU's also have a maximum to what they can process in DXVA mode. It's already very well known that some low-end GPU's lack adaptive deinterlacing modes, because they don't have enough power on the shader core. It could be that your GPU can't handle the strain of two simultaneous decoding and rendering sessions (or the driver assumes that). Next, it automatically takes a step back in deinterlacing quality.

I know that very well, but GPU load is only 31% for both playing back @ the same time and 20% for 1 instance (both including bicubic MPC-HC shader) so their are massive gpu cycles in theory available only the VPU is loaded @ almost the max for 2 instances 91% 1 instance 48% that's why i find it strange that Nvidias adaptive deinterlace switching should take place on the 2nd render instance because of to low gpu resources available, though i will try this with more DXVA decoder and VMR9 renderless to see if its maybe Cyberlink Decoder dependent behavior, i would rather guess it's a VMR renderless and or DXVA limitation for now though never read about it, losing overlay yes depending on how much instances (i think max Nvidia driver limit is 4 for HD) but Deinterlacing was new.
And really strange @ playback simultaneously they look identical (though i better test with some MBAFF test patterns also, to be absolute sure) the problem only occurs when seeking frame by frame in both the 2nd instance then gets visible aliasing (that indeed could be overseen in motion) the first instance is ok (switching via ALT+TAB the aliasing only becomes visible in the 2nd opened VMR9 renderless MPC-HC instance @ the same frame, and @ playback both seem ok again (that indeed could be adaptive quality switching but GPU resources are still plenty available 70% so sure it could be also Nvidias driver assuming wrong here or maybe even GPU utilization playing no role @ all for the criteria of the switching algorithm, though hard coding that if 2 HD MBAFF streams are played @ the same time they never can be both vector adaptive deinterlaced seems not really efficient then and failing based on the stream complexity).

PS:
I've re-written the vertex management for the rendering engine. It wasn't easy, but I do have lower GPU, CPU and memory usage now.
The reason I've not yet released a build with it is because of the subtitle renderer. The subtitle renderer has a very big problem that causes unwanted swapping between video and system memory. I've yet to solve that. If it takes any longer to solve the problem, I'll make an intermediate build without the subtitle renderer updates.

Really great news, though with rendering engine you mean always everything above the renderer (color engine,dither engine,sync engine,shader engine) so not the VMR/EVR render and utilization performance itself ? :)

[JanWillem32]

If both instances are fine during playback, then there's no real problem. I know that the driver sometimes discards data during seeking (even with single instances). As long as the mixing is done in hardware by EVR or VMR-9, it doesn't matter if the source is DXVA or not in this case.

[CruNcher]

If both instances are fine during playback, then there's no real problem. I know that the driver sometimes discards data during seeking (even with single instances). As long as the mixing is done in hardware by EVR or VMR-9, it doesn't matter if the source is DXVA or not in this case.

Sounds not really good though then i don't understand why it works via Lav Cuvid (Nvcuvid) on VMR9 Renderless without Aliasing on the 2nd instance @ the same frame :( (Though Playback of both @ the same time is impossible obviously with it, compared to the DXVA input). Anyway i better really check this with a interlaced test pattern @ playback :(
Also the aliasing is not complete aliasing of the whole frame like you would expect from a interlaced 2 fields weaved playback it's just conditional aliasing @ a specific part of the frame that shows up in the 2nd instance (when switching between instances) though if you say it discards data randomly it might have discarded to deinterlace exactly that edge in the 2nd instance.
jesus il make a screen to visualize the problem that says more then 1000 words i guess :)


1st Instance
http://img84.imageshack.us/img84/2615/1stinstance.png

2nd Instance
http://img814.imageshack.us/img814/9189/2ndinstance.png

Input:
http://img851.imageshack.us/img851/4922/weaved.png

This was really making me crazy when comparing things then i realized it always happens on the 2nd instance ;)

[JanWillem32]

Instance 1 is an adaptive or a weave type of deinterlacing, instance 2 is bob (only a single field is shown, with its height doubled). A bob type is normal for progressive content, so I can understand it resets to this type and then start deinterlacing again when playback restarts.

[CruNcher]

Tried now with several DXVA Decoder all behave the same 1st instance adaptive 2nd instance bob with VMR9 Renderless
so till now only Nvcuvid seems to be able to force adaptive for multiple instances

[JanWillem32]

I can't really find documentation on Nvcuvid. I wonder if it correctly forces the mixer to deinterlace or does it by itself (color blending using an 8-bit 4:2:0 down-sampled Y'CbCr target surface really isn't my idea of proper rendering at all).

[Hera]

Is there a new build coming?
There is "something else" to (non-FP) stuttering - not sure whether it was something fixed in non-tester builds or something introduced in tester builds.

[JanWillem32]

My builds are a bit modified, and the original VSync code doesn't work too well with them. In my case, I still have tearing-free video in the three main modes. I just don't activate the regular VSync options.
Exclusive mode: D3D Full Screen Mode, 10-bit RGB Output, Full Floating Point Processing, Disable desktop composition (Aero).
Windowed mode with Aero: 10-bit RGB Output, Full Floating Point Processing.
Windowed mode without Aero: 10-bit RGB Output, Full Floating Point Processing, Disable desktop composition (Aero), Flush GPU Before VSync, Wait For Flushes. (The "Wait For Flushes" option delays one or two frames constantly, but it does present at a stable frame rate in my case.)

A new build is definitely coming soon. The vertex (draws the wire-frame models to render with) code hes been revised completely, the performance and efficiency gains are quite good. I'm only held back by the subtitle renderer: it copies every small rendered item from the video memory to the system memory, and makes a full-screen copy of every fully rendered frame to the video memory again for presentation. That's really inefficient, of course.

[TheElix]

Jan, I think you're aware of this but I wanted to remind you. I have an ATI card and I have this: http://screenshotcomparison.com/comparison/62400
Your shaders fix this but not everyone knows how to use them. So I think it should be fixed some time.

Any plans on implementing more advanced resizers? With some of these (http://www.cs.huji.ac.il/~raananf/projects/lss_upscale/sup_images/index.html) (esp. Glasner et. al. [2009] and Geniue Fractals (TM)) or others (http://www.cs.brown.edu/courses/csci1950-g/results/final/pachecoj/) properly implemented I doubt anyone watching SD video would want to switch back to other players.

[JanWillem32]

Nearest neighbor sampling is a valid way to scale images. It's not the most visually pleasing one of course, but neither is the usual bilinear filter.
When the ATi driver faces anything but the standard 8-bit surfaces for the EVR/VMR mixer output, it disables the bilinear filtering, and uses nearest neighbor instead. If I could simply force the mixer to use a custom scaler for chroma, I would have integrated chroma scaling shaders a long time ago (and I would have written a few other special scalers for it). Unfortunately, the mixer parts are rather inflexible. Any big mixer change would firstly require me to separate the VMR-9 r. and EVR CP renderers. Next, writing custom mixer items requires a good understanding of the DirectShow stages in the video mixing engine, and that's something I lack. It is possible to write, though. The two best examples: MadVR has a mixer that can handle YV12 and NV12, the Haali renderer can use YUY2 and RGB32.

New interpolation methods and porting already finished ones to the various filters that require it will take some time. I'm very busy with the subtitle renderer at the moment, and it's just horrible.
Also, new interpolation methods require a lot of documentation on the math, algorithms and programming before I can integrate something. That information is quite hard to come by.
I've seen a lot of code that feature very archaic programming for graphics processing. A lot of times I wonder if the programmer that wrote it ever heard of something basic as SSE or SIMD at all. I've even seen code that uses the slowest kind of integer math in the graphics processing code (CPU-based), like the code common for a 16-bit DOS program. When doing any graphics programming, parallelization, vector and matrix math is really important for performance, and no compiler will just magically convert code to really take advantage of these things automatically.

I'm a bit frustrated by the badly written code that I'm working on at the moment... I've been wanting to release a reasonably stable tester build for over two weeks already.

[TheElix]

Your post is very informative as usual, thanks. Don't give up on that code and Eureka will surely visit you. :)

[TheElix]

Jan, might it be possible to include a fix in the next version for being able to save Autochange fullscreen monitor mode settings? Because if you untick this option and close the player they will be reset to defaults.

[JanWillem32]

This is more a general issue of the options screen, but I can give it a go. Note that problems reported and handled on trac are generally solved and integrated faster than anything I write, though. I gave the shader menus some improved functionality some time ago, I guess this one shouldn't be too hard for me to fix.

[TheElix]

Thanks! :o I didn't know it was a general issue of MPC-HC's builds.

[TheElix]

Hey, Jan! This annoying issue has been presumably fixed: http://sourceforge.net/apps/trac/mpc-hc/ticket/1493
Be sure to include the fix in your next build!

[G_M_C]

Ahhh, that might also be the fix for what we discussed/noticed earlier;

Has someone else noticed that when you look at the CTRL-J / stats screen, it wont seem to go away anymore (pressing CTRL-J multiple times doesnt remove the stats anymore) ?

And i only get the short stats screen (the one with only framerate etc, not the one with output/the graph etc).

(Win 7 64, running MPC-HT 32 bit)

Same here, it's like if I've pressed a button two or three times, while in reality it's only once. I only get this in exclusive mode, and it can sometimes be solved after the first mouse click, but not always. I've had this problem for quite some time now (not only in the builds I modified). I wonder what part of the program it is that can make it so sensitive to keystrokes.
[...]

[JanWillem32]

That's very convenient. I was already planning to release a new revision, the fix for the "double tap" bug is a nice addition.

Anyway, I didn't get to integrate all fixes for the subtitle section and I still have to experiment a bit with the color management.
The new revision has an almost completely revised vertex setup and rendering loop. In my tests I saw quite good performance gains (it will be hard to get such dramatic performance increases like with previous versions, though).
Apart from the interaction with the subtitle and OSD renderers, the main renderer is in a pretty good condition now. I can start updating EVR Sync soon with some luck.

[TheElix]

Great! I'm eager to try out the new version. Should we expect an increase in FPS everywhere?

[JanWillem32]

I mostly saw a lower peak load with both CPU and GPU. It's because I removed and re-ordered some items that caused lagging in the rendering chain. The average load was only slightly less overall. Results can vary, of course. I mostly test the heaviest of settings, else my GPU will only nap most of the time during rendering. It also tends to crash if I try to set clocks below idle speeds, so I can't really simulate low-end video cards, or even IGPs. I generally just assume that if I get good results with my regular heavy rendering chain, every other setup benefits as well.
I also tweaked some of the timing items, but it's hard to see the effect of those. (My computer isn't a difficult case with VSync, lagging, buffering and such.)

[TheElix]

Reducing those peaks means one will have less rangom lags or stuttering during playback on a borderline sufficient hardware?
By the way, did you have the chance to look into a problem of saving Autochange fullscreen monitor mode settings?

[JanWillem32]

Borderline sufficient hardware should benefit form every little optimization, but it will be impossible to create something that has the same performance as the overlay renderer.
The autochange function for the exclusive mode is ready for integration once the link with the menu is formed. Editing the menus is rather time-consuming, so it will take some time before both changes are made for saving the options when the base autochange function is disabled as well as the making the function work in exclusive mode.

[Qaq]

Jan, I got system message "StackHash_0a9e" every time right after D3D close for last build. Win7, EVR CP.

[TheElix]

So the new version's out and I missed it! Jan, you could've reposted your link in the body of your message!
~gone testing~
Edit 1: Confirmed, crash on player's exit after D3D mode. Luckily after exit. :) Using SSE2 version.
You're doing tremendous job, Jan! The playback is as smooth as ever!
Doubling commands seem to be fixed!
Edit 2: About this new perlin smootherstep resizer. It seems to be introducing blockiness on edges. What's its purpose?

[Hera]

This is nice and smooth.
No crashes so far.

I have no idea what the new scalers are so I just switched back to bilinear...

Video is very smooth while panning, zooming.

[JanWillem32]

@Qaq: I've never seen errors with "StackHash_0a9e" before, but after a quick search they seem to be common. It seems to happen with some combinations of active programs. I've tried a few that were listed, but I can't reproduce the problem. I've used internal filters only, with both software and DXVA decoders on SSE2 and x64 versions.
Can anyone post a minidump, a copy of the error in the system event log (run "eventvwr"), or test what background programs conflict?
@TheElix: The Perlin Smootherstep was a proof-of-concept of a bilinear variant: http://en.wikipedia.org/wiki/Smoothstep .
I just liked the graph it makes, but I'm not very sure it's the most ideal for image interpolation. I just needed to get rid of one of the bilinear types and insert a single-pass resizer (nearest neighbor and bilinear are single-pass as well).
@Hera: All resizers have partially been re-written to require a bit more CPU and GPU resources at initialization, but require no external input data for scaling and positioning while running anymore. I've also updated the two-pass resizers to skip a stage if only anamorphic correction is applied. For choosing the right scaler, just try "View", "Frame", "Double Size" and a few times "Pan&Scan", "Increase Size" (or numpad 9). That will show most of a resizer's characteristics for general usage.

[G_M_C]

Jan, I got system message "StackHash_0a9e" every time right after D3D close for last build. Win7, EVR CP.

[...]
Edit 1: Confirmed, crash on player's exit after D3D mode. [...]

@Qaq: I've never seen errors with "StackHash_0a9e" [...]

I have not seen this error, neither on my primary screen (computer monitor) nor using my secondary (TV/external processor).
Using HPC-HT, SSE2, 32 bit on win64.
Currently using MS Windows build in video-decoders [DXVA], streaming audio to receiver/processor thu ffdshow tryouts (no audio processing done by MPC-HT, except formats not recognized by receiver).
Options: D3D full screen, 1080p, 'force 10 bit output'=on, Full floating point processing, your 'optimized shaders' 1,2 and 3. No color management/Litttle CMS disabled.

This latest version seems error-free to me, the CTRL-J problem is resolved, and i have not noticed other problems.

I can only find points that could be inproved;
- The 'CTRL-J" stats-screen could be better. The red text in the stats-screen is too small on my 1080p screen, i have to approach my screen to read it. Also the text on stats-screen has a shadow-outline that is too large imho; readabillity suffers because of it.
- Maybe the subtitle renderer could be improved, playback seems smoother without subtitles, but i cant put my finger on how or what exactly.

[Hera]

XP rig - EVR:CP (I have .NET installed),
I get to see (semi-corrupted) remnants of the previous video at the beginning of the new video.
If no previous video, just some odd corruption stuff.

Haali Renderer + Show OSD + Subtitles = Transparent Subtitles with white square background covering the video...

[JanWillem32]

@G_M_C: I'll take a look at the Stats screen again. I believe I can scale the text a bit, but the shadow is somewhat fixed (the font renderer is rather minimalistic). I'll have a try with the colors, like with the OSD and seek bar back in January.
I'm already editing the subtitle renderer, but I could use a lot of help with it. The output lag when rendering a new rectangle to fill is extreme with the subtitle renderer. Where the main renderer takes a few hundred of nanoseconds to respond to a cycle, the subtitle renderer will very often take more than 50 milliseconds to respond. That's enough to drop a complete frame every time. There's a lot of work to do to make it properly. For starters, I've recommended to split the bitmap and vector-based subtitle renderers up, as they are fundamentally different, and I think people would like some options other than the standard bilinear resizing (without gamma correction) for bitmap-based subtitles.
@Hera: That's caused by the graph builder. If the renderer is busy outputting the last frame, and the graph builder decides to dump the renderer, the half-rendered image corrupts. Until the first new frame is presented, the output tends to look like that. I've heard that disabling desktop composition may help. Presenting corruption during the first initialization of the renderer is odd, as the allocator-presenter will never call a present to the back buffer while the rendering engine is still busy. It might be a driver thing. You don't have any issues once first frame is presented, I assume?
I've indeed been editing the subtitle renderer a bit already to make it compatible with the new rendering path. There are special extra steps for the external renderers, and I guess I need to edit those some more. The problem with the Haali renderer is that I need to guess what settings it needs, there's no documentation or further development on it.

[Hera]

Ok, so I noticed this with an AVI on NV66 XP rig - MKVs worked fine... on NV ION W7 rig, I think I am getting double picture with everything.....
Note: I use Haali Media Splitter for everything...

Haali Renderer + .AVI = Screen seems split in center in four (more or less) equal parts, top right and top left show the (blurry) video (or... two copies of the video to be more precise... TOP LEFT CORNERS of the videos that is), bottom right and bottom left are corruption (Lines and *** on NV66 and Green on ION).

http://i1221.photobucket.com/albums/dd467/QueenHera/OddHaaliIssue.png

[JanWillem32]

How nice, I've exposed a bug with the internal decoders. I've used the new rule set to never convert 8-bit 4:2:0 Y'CbCr to 8-bit 4:2:2 Y'CbCr before the mixer, but always fall back to 8-bit RGB output if YV12, I420/IYUV and NV12 fail. The trunk build still allows a very ugly conversion to YUY2. The rule set I applied is similar to the one used in ffdshow tryouts. The default settings for any recent ffdshow tryouts build will correctly output "RGB32" by default to the Haali renderer (can be seen in the renderer's OSD).
The problem is, for some reason the Haali renderer sees YUY2 input with the internal codecs, but is served YV12 instead. I wonder why the internal codecs won't force "RGB32".

[G_M_C]

How nice, I've exposed a bug with the internal decoders. I've used the new rule set to never convert 8-bit 4:2:0 Y'CbCr to 8-bit 4:2:2 Y'CbCr before the mixer, but always fall back to 8-bit RGB output if YV12, I420/IYUV and NV12 fail. The trunk build still allows a very ugly conversion to YUY2. The rule set I applied is similar to the one used in ffdshow tryouts. The default settings for any recent ffdshow tryouts build will correctly output "RGB32" by default to the Haali renderer (can be seen in the renderer's OSD).
The problem is, for some reason the Haali renderer sees YUY2 input with the internal codecs, but is served YV12 instead. I wonder why the internal codecs won't force "RGB32".

You might want to report this to the developers, maybe coss-post also in the 'regular' MPC-HT thread ?

[TheElix]

Hm, your latest build (I'm using SSE2 version) is apparently conflicting with LAV Audio Decoder on bluray content (.bdmv). No audio and fast-forwarded playback. Everything's normal with in-built audio decoder. It also plays normal with LAV a.d. on the latest standard build.

[TheElix]

Also, green screen on this video:
General
Complete name : F:\ANIME\Rurouni Kenshin\Rurouni Kenshin 02.avi
Format : AVI
Format/Info : Audio Video Interleave
File size : 272 MiB
Duration : 23mn 34s
Overall bit rate : 1 613 Kbps
Writing application : VirtualDubModRus 1.5.10.2 (build 2540/release)
Writing library : VirtualDubMod build 2540/release
Video #0
ID : 0
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.2
Format settings, CABAC : Yes
Format settings, ReFrames : 16 frames
Codec ID : h264
Duration : 23mn 34s
Bit rate : 1 150 Kbps
Width : 640 pixels
Height : 480 pixels
Display aspect ratio : 4:3
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.156
Stream size : 194 MiB (71%)
Writing library : x264 core 64 r994M b35a044
Encoding settings : cabac=1 / ref=16 / deblock=1:1:1 / analyse=0x3:0x113 / me=tesa / subme=7 / psy_rd=0.6:0.0 / brdo=1 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-2 / threads=6 / nr=0 / decimate=0 / mbaff=0 / bframes=16 / b_pyramid=1 / b_adapt=1 / b_bias=0 / direct=3 / wpredb=0 / bime=1 / keyint=250 / keyint_min=25 / scenecut=40(pre) / rc=2pass / bitrate=1150 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30 / aq=0

[JanWillem32]

I've taken a look at the problems with the interaction with the Haali renderer, it will take time to get it fixed. This isn't my area of specialization, and others didn't know how to correct it quickly, either. I think I fixed the problem with the Haali renderer's OSD+subtitles, but it could use more testing.
The problem with the LAV audio decoder is a complicated one, I could only reproduce it with the internal splitters, not with LAV splitter active. It deserves additional inspection.
A moment ago, I've uploaded tester build dfr3391. There are a few nice improvements to rendering speed, but the initialization speed is now much lower when resizing the active window. I've updated the stats screen to render fullscreen white text. I'll try to make it faster next time. There's a minor bug with the fullscreen windowed screen. When the player bar is showing, the view is compressed vertically with nearest neighbor scaling. In it's normal invisible state, there's no problem.

[Hera]

Ah you mean
"With experimental build 3391, new video files are opening pixelated and very upscaled and a bit to the right - to fix this resize window"

[JanWillem32]

Ah, in your case the renderer initializes faster than other parts under the filter graph... The renderer receives data on what the size of the current window opening is from other parts. I don't know if I can optimize those, but I can probably fit in a pause function while the window size item is still undefined. It won't happen with the exclusive mode, as that one always spans the full screen.

[Hera]

Wow, you weren't kidding about needing to make the stats screen "faster next time" - O.o
In my opinion, the previous version was easier to read and looked better.

[JanWillem32]

Making the text adaptive to the window width and changing bold text for a bit wider text when the horizontal resolution is below 1120 works very well in my opinion. On the other hand, I don't know if the white text with a black outline and shadow is optimal, either. I'd rather use one obnoxious color, so that it doesn't have to draw the two parts for the outline and shadow anymore.

[TheElix]

In my opinion, the previous version was easier to read and looked better.I dunno, the new version looks better for me than the previous one, in my opinion.
http://rghost.ru/14668731/thumb.png (http://rghost.ru/14668731.view)
I've found another problem. D3DFS + Autochange fullscreen monitor mode = crash on player's closure. It happens when the player tries to restore previous resolution.

[JanWillem32]

The coupling of the D3DFS + Autochange fullscreen monitor mode function is still wrong. It's currently handled by an item hosted by the main menu, instead of natively in the renderer. It's pretty high on my to do list, but this menu section isn't easy to edit.

[cca]

Have to pass on ver. dfr3391, keeps hanging while trying to open the video and takes too long to switch to windowed full screen. The statistics screen is so slow that causes the video to lag some times too.

[Hera]

It makes sense if you are far away from the screen, large font is good. But up-close, information is presented better when it is smaller - more compact.

Have to pass on ver. dfr3391, keeps hanging while trying to open the video and takes too long to switch to windowed full screen. The statistics screen is so slow that causes the video to lag some times too.

The statistics screen has always had influence on the performance - which could be noted by the graph in the bottom right, now it is more pronounced - I get ~11 FPS on ~24 FPS video with the full statistics for example.

[G_M_C]

I dunno, the new version looks better for me than the previous one, in my opinion.
http://rghost.ru/14668731/thumb.png (http://rghost.ru/14668731.view)
[...]

I think it looks better too, it is much more readable (the dark red wasn't very readable on black background, something that happens often on movies with aspect-ratio other than 16:9)

Thanx Jan Willem for looking into my wish for this :)

[JanWillem32]

I wish I could use a DirectX 10/11 font renderer. That would also make it possible to use translated Unicode strings for rendering, on top of the efficiency. The current stats screen is drawn by rendering the ASCII table of a font in software mode, and then make the video card render a list of mini-textures. Anyway, I can probably edit some parts. For efficiency I can set one draw operation for the text only, and remove the black outline and shadow. What color should I use for the text? Or does someone have a clever idea for a better stats screen?

[Hera]

Subtitles seem a lot sharper in this build for me, is the maximum texture resolution setting still functional?

[JanWillem32]

No, it isn't. I've made the vertex management of the subtitle engine compatible with the main renderer. The resolution setting and the rounding to a power of 2 setting won't work anymore, else the subtitles would become scaled by nearest neighbor. The old method is still in place to serve as compatibility mode to other renderers only, until these are updated. Work on the subtitle engine is slow, but I've at least gotten this to work. There were two passes active of bilinear filtering, disabling one is a very good start.

Something I totally forgot to tell: I've added the two Mitchell-Netravali cubic resizers. http://de.wikipedia.org/wiki/Mitchell-Netravali-Filter (Sorry, I can't find a quick overview with pictures naming the 3 main BC-splines in English.)

[cca]

Another regression I forgot to mention, I can no longer play DVDs with the latest build. The video is completely distorted, it appears like it displays only a zoomed part of it.

[Qaq]

VMR9r chain is broken - black screen, zeros in filter properties. For xvid at least.
Should I use mixer option for VMR9r? Playback seems more jittery with that option enabled.

[mindbomb]

Another regression I forgot to mention, I can no longer play DVDs with the latest build. The video is completely distorted, it appears like it displays only a zoomed part of it.

i tried with a 1080i h264 video file and got a similiar effect, maybe it has something to do with interlacing?

[cca]

i tried with a 1080i h264 video file and got a similiar effect, maybe it has something to do with interlacing?

That's probably it, a similar thing had happen with an older build some time ago but was fixed later.

[tetsuo55]

To be on the safe side, did you guys reset the MPC-HC settings?
So much has changed on this build that an old setting might be messing around.

[mindbomb]

i didnt.

[cca]

Me neither, but it is easy to do so if needed, I keep them in an .ini anyway.

[Qaq]

To be on the safe side, did you guys reset the MPC-HC settings?
Done. Now VMR9r (XP) shows the picture in windowed mode but changing to fullscreen freezes the player no matter of selected scaler.

[JanWillem32]

It's busy in here today... I'll take a look at the list of problems, but for what I've seen on the main thread, the trunk r3391 also had some problems. If a few of those problems are fixed, I'll gladly upload a new tester builds set.
I believe I've just solved that old problem with black screens on exit. It does need more testing, but if it works, I can finally set the 10-bit mode to activate automatically if the video card allows it.
I think I can make the stats screen faster by drawing only the white text and using the background of the jitter graph to darken the entire screen. Is that a good idea (for only the full stats screen)?

[TheElix]

The coupling of the D3DFS + Autochange fullscreen monitor mode function is still wrong. It's currently handled by an item hosted by the main menu, instead of natively in the renderer. It's pretty high on my to do list, but this menu section isn't easy to edit.Guys like Underground78 and Aleksoid1978 in MPC-HC thread are pretty knowledgeable about the menu thing. I am pretty sure they won't mind lending you a hand (or advice at least) in this matter. I'm sure they'll be happy to hear your thoughts on autochange fullscreen monitor mode function (if your methods are applicable on the base version in this case).

I think I can make the stats screen faster by drawing only the white text and using the background of the jitter graph to darken the entire screen. Is that a good idea (for only the full stats screen)?I think, why not. Ctrl+J screen isn't made for movie viewing purposes anyway and VSync graph uses it, so...
And thanks for the new resizer, it's my favourite now. :)

[JanWillem32]

I've finally had some success with one part of subtitle section. The subtitle renderer is still very heavy in CPU usage, but it's now much better timed. Because the blending stage for subtitles is now included in the actual video renderer code, subtitles are now included with the color management and dithering stage.
For bitmap-based subtitles, I still need to fix a few things before the regular resizers can be used on them. Currently all bitmap-based subtitles are scaled by a bilinear filter.
I'm also very satisfied with the changes I made to the stats screen. The performance is now a lot better.
About the internal codecs and splitters, these are currently being improved in another branch of MPC-HC. So, I'll review problems with the internal splitters and codecs in by builds for after those have been renewed in the main code.
I've updated the status for the normal VSync items in the OP:
- I broke the three regular VSync functions (they can even crash the player when enabled). A sort of VSync in windowed mode without desktop composition can still work with the "Flush GPU Before VSync" and "Wait For Flushes" functions enabled.
Windowed mode with desktop composition enabled and the exclusive mode will VSync perfectly well on their own. Some statistics generated previously by the VSync code parts are broken, as well.

[Hera]

Crashes 100% of the time with D3D fullscreen enabled (opening a file - I do not use V-Sync) on ION rig, investigating...

Yep with brand new settings as well. D3DFullScreen + Nvidia ION = More or less instant crash.

Love the CTRL-J performance though and I am now testing with subtitle animation enabled.


Problem signature:
Problem Event Name: APPCRASH
Application Name: mpc-hc.exe
Application Version: 1.5.2.3423
Application Timestamp: 4e24c5a1
Fault Module Name: mpc-hc.exe
Fault Module Version: 1.5.2.3423
Fault Module Timestamp: 4e24c5a1
Exception Code: c0000005
Exception Offset: 005154a6
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

Read our privacy statement online:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409

If the online privacy statement is not available, please read our privacy statement offline:
C:\Windows\system32\en-US\erofflps.txt

[JanWillem32]

I did change two initialization items specific to the exclusive mode, so I can build versions without one of those two once I have some time to spare.

[TheElix]

Hm, refresh rate in statistics screen seems to be broken: http://rghost.ru/15053711/image.png
Why do you turn off VSync and all its options and flushes by default? Because you 'broke' it?

[janos666]

And because they seem to be optimal for the exclusive mode (and the exclusive mode seems to be optimal for playback)?

[JanWillem32]

Enabling the VSync options on my main system locks up initialization half of the time, and makes (re-)initialization very slow. The statistics generated by the VSync threads have been off for a while. On top of that, the functions don't work for me anymore. With the normal VSync options enabled, I get tearing in windowed mode with desktop composition enabled and in in exclusive mode. (Those two can simply use the system timers to VSync by default, anyway.) The windowed mode without desktop composition also keeps tearing in my case unless I set it to wait for flushes.
For the initialization problem with the exclusive mode, this might work: ---. It's an edited SSE2 version, I can adjust the other two versions as well, if this one works.

[TheElix]

Strange, I have no tearing (here are my renderer settings http://rghost.ru/15053711/image.png).
Jan, I've been wondering, why don't you include your shaders in your build? It sucks to be inputting your shaders anew so often.

[JanWillem32]

If the output refresh rate closely matches the input fps, VSync doesn't have to do much, either. In my case, it has to deal with 24/1.001 to 80 Hz. It used to work, but not anymore.
I'll have to make a selection of what shaders to add.
In the mean time, you can simply use REG EXPORT to make a backup of any registry item, and also subfolders of it.
REG EXPORT "HKCU\Software\Gabest\Media Player Classic\Shaders" "%USERPROFILE%\Desktop\shaders.reg"
REG EXPORT "HKCU\Software\Gabest\Media Player Classic" "%USERPROFILE%\Desktop\settings.reg"
(%USERPROFILE% is a system variable, you don't have to fill it in yourself.)
The resulting .reg file can simply be executed to add items to the registry. You can also review and edit some of its contents in notepad. I've done this often to transfer or backup settings.

[TheElix]

Chroma interpolation is a must. Some variants of sharpen complex too.

[JanWillem32]

I'll see what I can implement after talking to the rest of the team. I'll certainly remove all the present ones at least. Another problem is that quite a few shaders are to be installed in the renderer, as options in a menu.

Can anyone with an nVidia video card that had crashes before, when activating both the exclusive mode and 10-bit output test this build? ---
It should successfully initialize with a 10-bit backbuffer and an 8-bit display format. (10-bit display output on an nVidia card should only work with recent Quadro models and a DisplayPort connection.)

[Hera]

D3DFS works now again.

[JanWillem32]

With which one of the two edited versions do you mean?

[Hera]

I think that ones in post #200 & #196 work.

[JanWillem32]

Did enabling the 10-bit output in exclusive mode crash the player?

[Hera]

Did enabling the 10-bit output in exclusive mode crash the player?

Well I don't use that setting but yes, yes it did.

[JanWillem32]

Thank you, although that means that I still have to fix that problem. I've used several methods to detect 10-bit display output capability already, and none of them work.

[TheElix]

What's up with subtitle renderer? On same settings in MPC-HC:
EVR CP: http://rghost.ru/15318001/image.png
madVR: http://rghost.ru/15318061/image.png
(don't mind Russian, haha)

[JanWillem32]

Can I have a sample of the .ASS, .SSA or ,SRT embedded item?
I haven't seen distortions like that yet, and as far as I know, the same sampling and alpha blending render states are used.

[TheElix]

These are external .srt, nothing irregular.
1
00:00:11,596 --> 00:00:14,098
Как веснушки эти ненавижу я

2
00:00:14,223 --> 00:00:17,059
И вздыхаю, только новую завижу я.

3
00:00:17,393 --> 00:00:19,729
Любовь на плечи тяжким грузом давит,
Basically, your version has no shadows and a very thin outline for some reason.

[JanWillem32]

The .SRT text subtitle works for me (saved as UTF-8). The text looks as it should.
What settings do you have in the "Default Style" tab of the options menu? What do you see during playback in the "Play", "Subtitles", "Styles" menu? Does editing the style or using "Reload" under "Play", "Subtitles" work?

[TheElix]

Here're my settings (http://rghost.ru/15422941). I've always used them and have never experienced this before.

[JanWillem32]

Does the same layout for the default font appear during playback in the styles menu?
The next question would probably be about how does it fare with styled .SSA or .ASS subtitles, but I'll probably have to look for a suitable sample for that...

[Sievert]

Hi JW

Would chroma interpolation shaders work as efficient on interlaced sources?
If using NV12 output in the decoder, either dxva or software, is it correct to use "optimized for floating point surfaces" in the case you're using Full Floating Point Processing? Can you elaborate on the use of the 3 chroma shaders available, depending on the Presentation settings?

Thank you for your work so far.

[TheElix]

Here're embedded styled subtitles.
EVR CP: http://rghost.ru/15469531/image.png
madVR: http://rghost.ru/15469571/image.png

[JanWillem32]

@Sievert: Chroma up-sampling is normally done as one of the first things in a mixer (sometimes several stages before deinterlacing). Only the weave and bob deinterlacing types don't interpolate in a way that it distorts chroma. That means that the chroma up-sampling "trick" I made can be used to up-sample original 4:2:2 sources with weave and bob deinterlacing types. For the vertical stage of 4:2:0, the sampling distance has to change from 2 to 4 pixels to make that one work, too. The problem is that bob deinterlacing exists only as a last resort for if a previous deinterlacer failed. Weave is normally only activated on sources that are progressive-inside-interlaced. There are 3 common types of this (ignoring NTSC 1/1.001 rates at the moment): 24p or 30p content inside 60i, or 25p inside 50i. Many TV streams feature actual "hard" interlacing, generated by converting 60p to 60i and 50p to 50i. Those can't be weaved without heavy artifacts, so most deinterlacers do an adaptive form of frame interpolation.
The chroma interpolation shaders I wrote are an imperfect solution to the problem. I have plenty of filters ready to make all mixer stages work without those of EVR or VMR-9. I just never managed to get either of both output a completely unprocessed sample for me to work on. It would be very nice to be able to choose the resizers for chroma up-sampling, video image and bitmap-based subtitles. (That last one is in a testing phase.) The same thing for other filters, such as color controls, too.
For when it matters, I've made special shaders for when FFPP and HFPP are enabled. Those make more efficient use of the format. For the new line of chroma interpolation shaders, I'm only keeping the optimized forms, and the single-pass bilinear filter.

@TheElix: The blending stage looks okay to me. The only thing I can think of is that something is overwriting the styles. Can you check the "Styles" menu? You can also reset all settings temporarily by using :
REG EXPORT "HKCU\Software\Gabest\Media Player Classic" "%USERPROFILE%\Desktop\settings.reg"
REG DELETE "HKCU\Software\Gabest\Media Player Classic"

That way, full settings are saved as settings.reg on the desktop, and the registry is cleared. You can always run the settings.reg to set up the old settings again.

[kostik]

Hey!
When playing a movie with CMS enabled I get strange "color artifacts" specially on white . Tried disabling and changing settings in CMS and nothing helps but disabling the CMS. Tried disabling 10 BIT, playing in FS mode, nothing works.
see please the pics .
Thanks

[JanWillem32]

Some time ago, janos666 sent his profile so I could see it too. I believe it's the gamma + matrix type profile that's giving problems. I use a XYZ LUT + matrix profile and had never seen the problem of that type of color artifacts before. We are already assessing whether it's a problem in the implementation, or if there's something wrong in the profiles themselves. I'm not very sure yet what it is, unfortunately.

[kostik]

Some time ago, janos666 sent his profile so I could see it too. I believe it's the gamma + matrix type profile that's giving problems. I use a XYZ LUT + matrix profile and had never seen the problem of that type of color artifacts before. We are already assessing whether it's a problem in the implementation, or if there's something wrong in the profiles themselves. I'm not very sure yet what it is, unfortunately.

Where can I find a good profile with d65 and 2.2 gamma?
Can some1 upload pls.

[JarrettH]

I haven't tried these builds, but do you know when the new resizers will be incorporated? Right now there's just bilinear and bicubic right?

[Hera]

IMO, when this work will be incorporated, I think a new major release is justified (post-testing on main branch).
Any work on fixing the pixelated upscaled video when opening a file the 1st time?

Been testing subtitles with animation turned on,
- Only one file I know caused the EVR to stutter
- When there are supposed to be animated subs on top while at the same time on the bottom stationary subs, stationary subs blink when top subs animate karaoke style (need to test against VLC or something... eww, but will do it... for science!)
- When subs are on the screen (not animated, not even changing) - the graph is a bit more bumpy

[JanWillem32]

@kostik: Device color profiles are unique for each device. They normally don't last much longer than a month, too. The people that don't have a hardware tristimulus colorimeter or spectrophotometer can still use applications to generate a basic profile.
Windows 7 has one integrated: http://windows.microsoft.com/en-US/windows7/Calibrate-your-display . There are plenty of other applications that can help set up a display device, too. I must note that many are set up for a video gamma of 2.2, while video is encoded in studios at gamma 2.4. (It's a bit of a user preference, though. I've had pretty impressive results on even my gamma 2.6 monitor.)

@JarrettH: The list of resizers is to be expanded even a bit more. The resizers I made will never work with the version of the rendering engine that's in the trunk build. Integration of these new resizers will be simultaneous with this version of the renderer.

@Hera: The "pixelated upscaled video" problem is actually pretty old. The trunk build does it too, but that one doesn't re-use it's vertex data for every frame cycle. The problem is that the first frame is generated with a completely wrong rectangle. Was I correct in my assumption that the exclusive mode does initialize correctly?
I've made performance optimizations again for the subtitle blending part and VSync, so those things might help smoothing out the rendering speed. I'll do some quality checking later, when I'm free today.
A few months ago, a video in the main MPC-HC thread was posted that caused that blinking issue with my PC, too.
I unfortunately don't have it anymore. (It was a video with Latin LTR letters on the top and bottom sides and Kanji TTB ideographs on the side. It was only a SD video, but had karaoke animation that dropped about one in four subtitle frames for me. It featured some Halloween theme made out of animated computer-drawn cutsheets. I think the name referenced an apple.) Samples like that are very welcome.

[ForceX]

A few months ago, a video in the main MPC-HC thread was posted that caused that blinking issue with my PC, too.
I unfortunately don't have it anymore. (It was a video with Latin LTR letters on the top and bottom sides and Kanji TTB ideographs on the side. It was only a SD video, but had karaoke animation that dropped about one in four subtitle frames for me. It featured some Halloween theme made out of animated computer-drawn cutsheets. I think the name referenced an apple.) Samples like that are very welcome.
lol xD Not Halloween theme, it's a fanmade Touhou video. I just happen to have that video. I do believe you mean this: http://www.megaupload.com/?d=SB6Y47LD

There are two animated subtitle tracks, the Complex karaoke one is the killer. I use it for my sub rendering stress test.

[JanWillem32]

Thank you, it's indeed still really heavy, but it only causes jitter of less than half a frame time on the latest development alpha. As there are 3 backbuffers, I have have more than 1 buffer to spare at any time.
The load on the subpicture buffer is great, too. This is the only video I have that can use up the 4 buffers I usually set. I don't have blinking animation anymore.

[Hera]

That one works just fine.

Here is a sample,
http://www.megaupload.com/?d=2MHYM170

exclusive mode does initialize correctly

[CiNcH]

Hi Jan,

I am just fooling around with your test builds a little bit. Where is one supposed to find your scaler shaders in the SVN? I just recognized that you have your own branch but can't find the scalers in there..

I also recognized that you have put a lot of your shaders under GPL lately. Guess that this does not mean that an application that can make use of those shaders also has to be under GPL, right? The way I understand a shader is that it is a self-contained program without a binary link to the application. Would you agree?

[JanWillem32]

The branch broke after a failed update. It did contain the set of resizers at one point. http://pastebin.com/Gn7Rq2ap
The GPL license is simply to exclude the information I generated from being taken by commercial works. This can by applied to any text, it doesn't really have to be application code. The license allows usage of the information for personal use and with other projects under compatible licenses.

[JanWillem32]

A lot of changes this time.
The Vsync functions are fixed. I'd still only use them in windowed mode without desktop composition, though. The automatic ones for the exclusive mode and windowed mode with desktop composition are pretty fine when used on their own.
I optimized allocation for the subtitle renderer, so that it can compensate for changes in frame rate even further. For example, when 3:2 pulldown is active.
I've tried to fix the issues with the video window size not initializing correctly. That might need more work in specific cases. (If someone knows a trick for this, please tell me.)
As there were a few bugs specific for x64, I've addressed those.
I've started the code merging with EVR Sync (still broken resizers, except for nearest neighbor). The few EVR mixer updates should provide some more reliability and maybe some faster code.
I'm in discussion of revising the image saving functions, color controls, a display rate changer for the exclusive mode, internal pixel shaders and hopefully a fix for the problem with the color management.
(Extra developers for some C++ code are very welcome, indeed.)

[Hera]

The pixelated upscaled gardbage video issue is not fixed.
Resizing doesn't always fix this issue either,
aside from the fact that resizing is slow.

Now it is *worse* - video fully stuck, fully stuck stretched (sometimes like someone set vertical resolution to 32k or something), fully stuck purple (purple happens before the video starts with your builds).
I managed to fix the purple and sound issue by skipping around.
Oh and subs play fine post-resize, when video is stuck.

D3D fullscreen stopped working now as well. Video is vertically stretched beyond belief - I see subtitles and vertical lines dancing.
Cannot be fixed by seeking around.

Haali is still broken. :/
All external codecs work with Haali though.
EDIT: No... my bad. No new issues with Haali, just internal filters.

EDIT:
This may be an issue with bilinear, switching to bicubic results in normal D3DFS. Will edit post further with additional details.
EDIT: It may help. I noticed opening the same file twice sometimes opens it fine the second time (non-D3D FS). On the other hand I had it open the second time with purple borders to each size and chugging at 10Hz
I managed to get D3D FS to work: either it has something to with resizer, turning off desktop composition, or pure random.

EDIT: I reset all the settings to default. Ran file - upscaled, pixelated, etc.
Then I turned on HFPP and the video fixed itself.
So toggling the Floating Point Options in Windowed mode seems to fix the video.
Toggling V-Sync in D3DFS does not do much.

EDIT: Purple borders, they were black before! Ugly.

Using bicubic + D3DFS seems to avoid the issue, without D3DFS - there is still an issue. Nearest Neighbor also works.

[cca]

Completely fails to open DVDs with the PS2.0a resizers, hangs or crashes.

[clsid]

Why are you merging code with EVR Sync? I thought the plan was to replace the existing custom renderers with a new one?

I think you are complicating things for yourself by trying to fix things with all features enabled. Implementing the renderers from scratch, one feature at a time, would probably be more structured and give a better end result.

Something like this:
1) Rip out the current custom EVR/VMR-9 renderers.
2) Implement a basic custom mixer (no shaders, d3d fullscreen, vsync, 10bit, or other fancy stuff yet). One renderer based on EVR, one on VMR-9. Code can of course be shared.
3) Implement subtitle support
4) Implement shader support. First for resizing. Then custom shaders.
5) Extend mixer with 10bit stuff.
6) Implement VSync algorithms.
7) make things work with refreshrate changing
8) Implement D3D fullscreen. But ask yourself this, is it worth doing this step. Perhaps it is better to let users use madVR for this functionality?

[TheElix]

But ask yourself this, is it worth doing this step. Perhaps it is better to let users use madVR for this functionality?Gimme DXVA and hardware deinterlacing with AMD cards then I'll think.

[JanWillem32]

@Hera: Thanks for testing so many things. I only wish I could open the debugger on every problem you face, to look inside the program. Sadly I can't reproduce all of the problems reported.
For the issue with Haali in combination with the internal codecs, I can't do much. I'm waiting for the branch for the internal codec fixes to finish. That one should have a better set of conversion options. Since the Haali renderer doesn't accept any 4:2:0 input natively, it usually depends on those converters.
I wonder why the initialization for the video and window rectangles fails in in some cases. I never changed any of the code for those parts. Maybe I should.
I can take a look at the one-pass resizers, I might have made an error specific for those two.
That switching HFPP fixes some things makes sense, as it triggers a full renderer reset (including even the mixer).

@cca: The VOB files I tested worked fine, can I have a sample? I might need to add an extra check for this case.
The resizers are automatically compiled to the maximum available target (PS 2.0, 2.0a, 2.0b or 3.0) in all cases. All two-pass resizers should have similar rendering properties.

@clsid: When janos666 suggested to make color the color management compatible with MadVR, I dismissed the idea. I don't intend to either use MadVR or re-create the rendering path of MadVR. I do have plans to change the working color spaces for the internal working surfaces, but that will have to wait after splitting up the renderers. (Working with an XYZ color space will require HFPP or FFPP to be enabled at all times, 8- or 10-bit integer surfaces just won't work. A lighter renderer can be added to fill the gap for the low-power or older systems.)
When a custom mixer is made, I automatically won't need VMR-9 anymore. EVR might still be useful for if Media Foundation interfaces are to be used. Otherwise, I won't need EVR, too. A custom mixer is on my wish list, but any earlier attempts to create one failed completely.
The internal renderer is in a pretty good condition. (EVR CP and VMR-9 r. share it, only the mixer is different). Once EVR Sync receives a similar rendering path as EVR CP, I can take a look at creating the VSync functions as switchable items, so I can merge them to one EVR custom renderer (and share them with VMR-9 r.). That should save a lot of trouble when working on the renderer.

[cca]

Nah, turns out if I try a couple of times it will start, but the video is messed up, regardless of the resizer selected. It's like it displays only the upper half of the frame zoomed. I think the problems with interlaced videos (which my DVDs are, PAL interlaced ones) persist. Still all versions since 3329, which works fine, are having these "hang" issues and are useless for DVD playback with the new renderer patches since they cannot display the video properly. Seems ok with simple 720p videos though.

[janos666]

Something like this:
1) Rip out the current custom EVR/VMR-9 renderers.
2) Implement a basic custom mixer (no shaders, d3d fullscreen, vsync, 10bit, or other fancy stuff yet). One renderer based on EVR, one on VMR-9. Code can of course be shared.
3) Implement subtitle support
4) Implement shader support. First for resizing. Then custom shaders.
5) Extend mixer with 10bit stuff.
6) Implement VSync algorithms.
7) make things work with refreshrate changing
8) Implement D3D fullscreen. But ask yourself this, is it worth doing this step. Perhaps it is better to let users use madVR for this functionality?

Well, interesting to see the different opinions. My suggestions would be:

0: Leave the current renderers as is (well, finish the last few patches but don't start anything new based on them).
1: Start to write a new basic mixer: Nothing fancy, just something what can connect to the decoders, receive the YV12 data and pass through the unmodified 8-bit YCC 4:2:0 data to the renderer.
2: Once you got rid of the EVR mixer, start to build up a new DX11 renderer from scratch: quality and simplicity over anything else.

And yes, make it FP-only with intermediate XYZ step, like:
8-bit decoded YCC 4:2:0 -> FP16/32 linearized YCC 4:2:0 -> YCC 4:4:4 -> FP16/32 XYZ and do the additional resize and any custom filtering here -> FP16/32 RGB -> 8/10-bit dithered RGB output.

People with old hardwares already have the stock EVR mixer and renderer and here is this EVR mixer based custom renderer with many tweak-able functions.
But I think you need to to get rid of the EVR stuff if you want to target the "absolute high quality" grade. And I think it could be much more simple if you don't resist to support the old hardwares with the new renderer. (People with old hardwares already have many options but supporting the wide range of hardwares makes things much more complicated...)

Yes, it would be basically something like "recreating madVR" but with open source code. (+ 10-bit output and de-interlace functions ; if madVR won't have those function already when it will be usable...)

* De-interlacing should be done before the chroma resize.

--

And if there is any chance to do it then a separated renderer with real YCC 4:2:2 output (without anything else but a chroma resize step) would be nice too. But I know it probably won't happen any time soon (lack of hardware and driver support...) But what if we ask AMD about the possibilities with their current hardwares which support "fake" YCC 4:2:2 output already? I think there should be a way to fill the RGB buffers with the YCC data and tell the driver to output it as YCC 4:2:2 -> just like now but without the internal matrix conversion... (maybe by telling the driver to use our custom matrix or another hard-coded one for this task...)

[Hera]

Is the fonts supposed to be more blurry (less crisp) with the Haali Renderer?

[JanWillem32]

I'd love to write for a DirectX 11 renderer, and indeed the VMR-9 and EVR mixers are a bit of a problem with that (they won't synchronize with anything but DirectX 9). I would love direct write access to the RAMDAC (analog), TMDS (HDMI and DVI) and Mini-packet (DisplayPort) controllers. Unfortunately, neither DirectX or the display driver currently allow handles to those directly. The only thing I can output is a full-range 4:4:4 RGB surface back buffer. The back buffer is either directly signaled to the RAMDAC, TMDS, and Mini-packet controller as full-range RGB in 8-, 10-, 12-, or 16-bit depth, else it's converted by the display driver before sending. (I've only seen some 14-bit standards for cinema, broadcasting and studio interfaces, like the SDI links. The higher bit depths than 10-bit are available for DirectX 10 and newer.)

@Hera: The Haali renderer should use the texture resolution given by the subtitle menu option. The EVR CP and VMR-9 r. renderers in my build disregard the texture size options in the menu to prevent resizing in software mode by nearest neighbor. (There's still an alternative path for bitmap-based subtitles that includes resizing by the video card. I've added pixel shaders to this step in an experimental alpha build.) That could explain the difference.

[CiNcH]

I have yet another question, something that I do not fully understand...

I get some proposed media types from the EVR mixer. A DXVA connection provides X8R8G8B8 and NV12. But is there really a difference whether I set either of those as the mixer's effective output type? I mean I am handing the mixer a DX surface which is being filled with video data. Such a surface can't be NV12, can it? So what I am getting from the mixer is always RGB, isn't it?

[JanWillem32]

The list for the EVR mixer proposals are all input types, the output type and mixer working surface are bound to the D3D surface you set as output. It's indeed true that I've only seen RGB as output from the EVR mixer.

[CiNcH]

The list for the EVR mixer proposals are all input types
Hmm, you mean input for the mixer? So the output of the decoder?

I think you ask the mixer to get its output types via IMFTransform::GetOutputAvailableType (http://msdn.microsoft.com/en-us/library/ms703812(v=vs.85).aspx), so what you can get from the mixer as input for the presenter and then you set one of them. But it does not make sense to ask the mixer for NV12 due to DX surface limitations..

[JanWillem32]

It's the MediaFoundation or DirectShow stream output, so it's an input to the mixer (indeed from a decoder). NV12 is a valid surface type, hardware support for it is pretty good, too.
I recently edited this section, it starts at the moment at "CEVRAllocatorPresenter::GetMediaTypeMerit" :
https://sourceforge.net/apps/trac/mpc-hc/browser/branches/renderer_fixes/src/filters/renderer/VideoRenderers/EVRAllocatorPresenter.cpp

[CiNcH]

So when the presenter calls IMFTransform::SetOutputType (http://msdn.microsoft.com/en-us/library/ms702016(v=vs.85).aspx), it actually sets the decoder's output? And what the presenter gets from the mixer is always RGB?

From the code:
: (guidSubType == MFVideoFormat_RGB32)? 600// always rank RGB types lower than the rest of the types to avoid the many problems with RGB conversions before the mixer
Do you remember the chroma upsampling error with my HD 3650 we once discussed? I think that this is the discrepancy to the MS Standard EVR. MS Standard EVR gave me interpolated chroma while the MPC-HC custom presenter did not. I think it is a matter of what you set there and who performs the chroma upsampling (at least with ancient GPU's).

I may dust my HD 3650 off and try it out.

[janos666]

I would love direct write access to the RAMDAC (analog), TMDS (HDMI and DVI) and Mini-packet (DisplayPort) controllers.

Unfortunately, neither DirectX or the display driver currently allow handles to those directly.The only thing I can output is a full-range 4:4:4 RGB surface back buffer.

The back buffer is either directly signaled [...] else it's converted by the display driver before sending.

I am thinking about a relatively simple nonstandard solution.

The current AMD driver can convert the RGB backbuffer data to YCC and output it through the HDMI output.
They currently offer YCC 4:4:4 and YCC 4:2:2 modes.

What I say is that we may request a third driver mode: either an "YCC 4:2:2 passthrough" (which takes the significant values from the RGB 4:4:4 framebuffers and outputs them as YCC 4:2:2 without any addition conversion, like the current RGB->YCC matrix...) or a "Custom" mode which could be specified by the software (this way we could output both YCC 4:4:4 and 4:2:2 but I don't see the point in outputting YCC 4:4:4 because my concern is that many HDTVs convert everything back to YCC 4:2:2, so YCC 4:4:4 isn't better than RGB 4:4:4, and it would be more complicated...)

Do you think it makes sense to ask AMD about it? (I think their "driver team manager" is reachable with a mail - not a real tech guy but more like a "customer<->programmer relations guy", but he can ask the programmers...)

[JanWillem32]

@CiNcH: Nearest neighbor chroma fitering is a mixer output type problem. It happens when you set any other working surface for the mixer than X8R8G8B8 on ATi hardware. The issue is still present with the 10-, 16-, and 32-bit surfaces. (Not that I really care about it, I have better filters than the bilinear filter used by the hardware.) A custom mixer should eventually solve that. In the mean time, four types of custom pixel-shaded resizers should fill in the gap.

@janos666: I'd indeed like that.
I'll have to a close look at the functionality detection part, of course. Alternative output modes are also only going to work with exclusive mode, too. Careful attention must be used to re-initialize the desktop afterwards (remember the black screen issue after exiting 10-bit mode in the past).
The development team already has a few connections with hardware manufacturers. Quite a few fixes have been made because of code recommendations in the past. I'll see what I can dig up in due time.

[CiNcH]

So also when you try to set NV12?

[JanWillem32]

Sure, if the input format is chroma down-sampled and the working surface is X8R8G8B8, it's upsampled by a bilinear filter before RGB conversion in the mixer. With other working surface types, it's not.
The same thing goes for example with YUY2.

edit: I released a new build version.
It should at least fix an issue with the color management not initializing properly and make the single-pass resizers work again.
I added some checks for testing window sizes and detecting monitor changes.

[CiNcH]

Sure, if the input format is chroma down-sampled and the working surface is X8R8G8B8, it's upsampled by a bilinear filter before RGB conversion in the mixer. With other working surface types, it's not.
I even had the problem of skipped bilinear interpolation with X8R8G8B8 surface type with a HD 3650, see here (http://forum.doom9.org/showthread.php?p=1463132#post1463132).
With Standard EVR, chroma is interpolated. The point is that I think that Standard EVR sets the output type to RGB and not NV12, which solves the missing chroma interpolation for ancient GPU's.

[ForceX]

Subtitle positioning breaks when using internal subtitle renderer with VMR-7 renderless/Haali/madVR when resizing window. :/

With EVR CP/VMR9 Renderless, on my machine there's a definite gap when changing the window size while it seems to switch to nearest neighbour for a moment before it seems to reinitialize and resize. This is rather disruptive, and I believe this lack of reinitializing with Haali/whatever is the cause of the subtitle error. Can you fix it?

Edit: Actually the subtitle positioning error doesn't happen with your dfr3557 build, and since I don't have a vanilla MPC-HC build higher than 3557, I can't say if it is due to changes in the trunk going from 3557 to 3571. :(

[Hera]

Anyone experiencing an issue where most subtitles disappear?
For example someone posted Tohou Bad Apple MKV a few pages pack and with 3571 SSE2 I only get only the subtitles on the right of the screen.
Going back to default formatting seems to show the bottom subtitles.

Will update post if issue is on my side.
EDIT: Resetting settings doesn't work. Some subtitles simply do not show up, you can force them to with default formatting option.
Oh and opening the same file twice and changing subtitle options when playing can result in player crashing / not responding.

EDIT: Oh and might add that D3D + Bilinear PS 2.0 works. For Windowed, no luck. Opening the file twice fixes the issue though.

EDIT:
EDIT: Windowed more is much worse in performance, it is kinda crazy.

Oh yeah and Subs for Haali are bleeping HUGE and thus do not even fit on screen.

[ForceX]

Anyone experiencing an issue where most subtitles disappear?
Subtitle issues only happens with renderers not being worked on by JanWillem.

For example someone posted Tohou Bad Apple MKV a few pages pack and with 3571 SSE2 I only get only the subtitles on the right of the screen.
Going back to default formatting seems to show the bottom subtitles.
EDIT: Resetting settings doesn't work. Some subtitles simply do not show up, you can force them to with default formatting option.
Oh yeah and Subs for Haali are bleeping HUGE and thus do not even fit on screen.

Happens if you resize the window. Should be fine on the first opening size.

EDIT: Oh and might add that D3D + Bilinear PS 2.0 works. For Windowed, no luck. Opening the file twice fixes the issue though.
Works fine here in Windowed mode. Amusingly, trying to use Exclusive mode simply results in a crash for me.

[liquidsmoke]

Jan, with regard to ticket:1629, I just tried to extract one of your builds posted on mediafire with winrar:

! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in Authors.txt
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in COPYING.txt
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpc-hc64.exe
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpciconlib.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.br.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.by.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.ca.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.cz.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.de.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.es.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.fr.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.he.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.hu.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.hy.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.it.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.ja.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.kr.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.nl.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.pl.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.ru.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.sc.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.sk.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.sv.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.tc.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.tr.dll
! C:\Download Buffer\mpc-hc64 tester dfr3571.7z: Unknown method in mpcresources.ua.dll

[Hera]

Subtitle issues only happens with renderers not being worked on by JanWillem.


Happens if you resize the window. Should be fine on the first opening size.


Works fine here in Windowed mode. Amusingly, trying to use Exclusive mode simply results in a crash for me.

Well EVR: Sync is even more broken.
EVR:CP, as of 1.5.3.3571, doesn't show many subtitles.
Those that are shown are properly positioned.

Resizing Haali Doesn't help. The subtitles are blow up and unusable with Haali Renderer.
EDIT: Or smaller, or fully missing somewhere. Positioning and Size for Haali seem broken.
Touhou bad apple the animated khanjii shows up smaller and more to the center for example.
It is weird.

D3D:FS works just fine for me. When Windowed mode is like "Nah man, Nah, your CPU is teh sux" D3D:FS is like "Challenge Excepted"

[ikarad]

Good morning,
What are the differences between janwillem32 build and standard build about subrenderer?

[JanWillem32]

@CiNcH: Older versions of MPC-HC used A8R8G8B8 for 8-bit textures, that caused the issue. Using converted RGB before the mixer causes quite a few problems, apart from the inherent precision loss compared to the working surface types that have better precision than8-bit.

@ForceX: I didn't edit any parts of the DirectX 7 subtitle renderer, so breaking VMR-7 r. is pretty odd. I also didn't edit many things for the external renderers this time.
I've set the rendering engine to not reset more than once every half a second, to prevent multiple resets when resizing a window. I can lower it a little bit, but not much, else it tends to crash a lot.
Is the crash in exclusive mode a new development?

@Hera: Des the initialization of the video rectangle on opening a video in windowed mode work now? I've added specific detection code inside the renderer for detecting the rendering rectangle area this time. (But I'm not sure it will work when extra toolbars like the playlist are visible.)
Do you get more than 3% deviations in the frame rate during normal playback? I've set the the main renderer to reset the subtitle renderer every time the frame rate changes more than 3% above or below the previous value.

@liquidsmoke: Older versions of Winrar can't unpack LZMA2 compressed files in 7z archives.

@ikarad: I've mostly been trying to get the timing for generating a subtitle texture and its blending phase corrected. I've also written code for blending the texture in at a specific phase in the rendering process, to allow color management and dithering on it.

[Hera]

Windowed Mode Pixelation,
http://i1221.photobucket.com/albums/dd467/QueenHera/EVRCP.jpg

Subtitles not showing up (except for the ones on the right),
http://i1221.photobucket.com/albums/dd467/QueenHera/EVRCP_SubsIssue.jpg

Haali Subtitle Placement Issue,
http://i1221.photobucket.com/albums/dd467/QueenHera/Haali_SubsIssue.jpg

EDIT:
Media that has subtitles that are not animated (no visual difference at all with "Allow Animation When Buffering")
- checking the "Allow Animation When Buffering" decreases performance by a lot.

Increasing Subtitle Resolution effectively made subtitles crispy for Haali renderer as well, with bright jaggy edges
- is that because I have AA forced off?

[CiNcH]

@CiNcH: Older versions of MPC-HC used A8R8G8B8 for 8-bit textures, that caused the issue. Using converted RGB before the mixer causes quite a few problems, apart from the inherent precision loss compared to the working surface types that have better precision than8-bit.
At least the surfaces I was creating for the samples have always been X8R8G8B8 and I was also suffering from skipped chroma interpolation.

Can you name the problems when setting the output type to RGB?

Do you know in which case the media type attributes 'MF_MT_YUV_MATRIX' plays a role? I guess only if I set the output type to RGB?

[ForceX]

The crash for Fullscreen Exclusive seems to be related to enabling the 10 bit RGB output option. It works when in Windowed mode but crashes for FSE. I never actually use FSE so it's no big deal. Vanilla MPC-HC gives a D3DERR_NOTAVAILABLE error and falls back to the default Video Renderer in a sort of an exclusive mode, which is rather silly.

This is what happens with Haali:
First open, http://i.imgur.com/jXQWw.jpg
Maximize window: http://i.imgur.com/257ta.jpg
Restore: http://i.imgur.com/p2KYm.jpg

Same thing happens with VMR7 Renderless, but it also gets some random black lines: http://i.imgur.com/aQZPE.jpg

None of these subtitle problems occur with the vanilla MPC-HC r.3577

[ikarad]

@ikarad: I've mostly been trying to get the timing for generating a subtitle texture and its blending phase corrected. I've also written code for blending the texture in at a specific phase in the rendering process, to allow color management and dithering on it.
Thanks.
I though that you had made a new subrenderer or correct the bugs of subrenderer of MPC-HC.

[JanWillem32]

@Hera: Still the same thing with failing to initialize video and window rectangles, I see. I wonder which one of the dozens of functions in the code is failing in these cases. (Which are also shared between all the renderers.)
The GDI font rasterizer has basic software anti-aliasing. Other than that, the subtitles are resized by a bilinear filter if not desktop-sized already.

@CiNcH: RGB input to the mixer disables most internal EVR filtering stages (those are meant for Y'CbCr). Deinterlacing often fails. One of the typical problems is that the mixer will fail converting 8-bit RGB to another RGB format, resulting in a rainbow of colors everywhere. Setting the decoder to output RGB will cause precision loss if it has to convert to RGB. (I haven't seen any that can convert to the normal floating-point types yet.) From another point of view, if the output is ditherered, setting a lot of video filters afterwards is a disaster because of the added type of noise.
For making xvYCC work with the default EVR mixer, input must be a xvYCC type and the output must be a floating point type (as output is generated beyond the normal [0, 1] color intervals).
If the decoder is of a DXVA type, I also wouldn't know if chroma would be filtered if you forced X8R8G8B8 instead of NV12, or if any type of filtering stage inserted after the decoder would be handled properly for that matter. (I haven't seen any DXVA implementations support more than these two surface types yet, but it's technically possible.)
The MF_MT_YUV_MATRIX attribute is usually set upstream (like most items, actually). For regular work only bt.601 (SD formats) and bt.709 (HD formats) matter. For what I've seen from the normal get function, I never have to set it myself. Many formats for video streams include a marker for this item, VMR and EVR can use that. Else, it's set by estimation from the video size.
The mixer code in the trunk still includes commented out code to force the usage of one of the matrices, along with some other items.

@ForceX: Nvidia video cards expose 10-bit RGB output capability, but refuse to actually set it in most cases. It's an annoying issue. I can't disable the setting based on the detected hardware brand, as the Nvidia Quadro cards can accept it. I've written five different detectection methods already, and none of them work unfortunately. (Note that only the exclusive mode can set 10-bit RGB display output.)
I indeed have to do something about the error message handling. Informing the user about that a setting failed and what to do is more reasonable than that simple message. I also very much dislike that another renderer is started if the selected one fails.
It's not a sort of exclusive mode, by the way. Windowed messages like that can't display in exclusive mode. What you saw was a regular windowed fullscreen.
The common problems with the geometry aside, the lines for the VMR-7 r. are caused by the orientation of a texture. DirectX 7 requires a single pixel offset to the top left, DirectX 9 doesn't. I intentionally removed the adaptation, as it causes a wrong positioning of subtitles in DirectX 9. (The code is shared.)
I've requested removal of the DirectX 7 custom renderer and subtitle renderer in January. It will take some time and some discussion with the development team.

@ikarad: The GDI software renderer isn't exactly my cup of tea. I'd love to implement the standard DirectX 11 font renderer, though. The introduction pages on it are very nicely done, and the code seems easy enough: http://msdn.microsoft.com/en-us/library/ff729481%28v=vs.85%29.aspx
I don't really know what to do with the problems reported with bitmap subtitles. Both for blu-ray and HD-DVD support isn't what it should be.

A lot of work for me this time, it seems. At least I can replicate the problems with the subtitle geometry this time, so I can debug that.

[ForceX]

PotPlayer seems to use gdipp (http://code.google.com/p/gdipp/) for smooth font rendering.

[Hera]

I might have fixed the subtitles not showing up issue (not the pixelated issue or the Haali subtitle issue) by restarting.

Still, I don't see why performance should degrade significantly when enabling animation for non-animated subtitles. :confused:
More of an issue with things like MS DTV-DVD & LAV CUVID type codecs and non D3DFS.

[JanWillem32]

I've tried to tweak a few minor settings, solve the subtitle positioning problem, and replace the window detection mode. If this detection method actually works, please tell me.

[ForceX]

The subtitle issues with other renderers seem to be fixed now. :) The only issue I could find was that with VMR 9 renderless the subtitle in this file: http://www.fileserve.com/file/JKY5wZe seems to twitch a lot more than it should, compared to EVR Custom/Haali.

Oh and when in non-exclusive full screen, putting the cursor at the bottom to bring out the seekbar results in the video to get shrunk, instead of the seekbar appearing layered on top of the video.

[JanWillem32]

I'll take a look at that file's internals, thank you. I know that the fullscreen windowed mode has a problem with all toolbars. It's because the fullscreen windowed mode causes the player to only report the full screen size area, and not the working area to the renderer. This issue doesn't happen in the regular windowed mode, so I think it should be easy to solve.

edit: The sample file has ASS subtitles inside. It has text shifting for every frame where a subtitle is active (not the normal type that uses karaoke tags). Naturally, this is pretty taxing on the subtitle renderer.
I wonder why you would have a specific issue with VMR-9 r.. EVR CP and VMR-9 r. use the same renderer, only the mixers are different. There's a bit more processing for timing items with EVR CP, but that shouldn't matter too much.
Another thing I've noticed was the frame rate. It's set to 23.95502 Hz, which is very unusual, and too low for EVR CP to lock it to 24/1.001 Hz.
Enabling VSync also causes dropped frames, late frames and a very high jitter statistic, even on my PC.

[Hera]

Yes that detection method seems to work much better.

[JanWillem32]

Well, finally one part of the geometry problems fixed. :)
I've also just added some code for detecting off-target frame rates for EVR CP, it seems to work okay with that video sample.

[ForceX]

Well the subtitle twitching/jumping in VMR9-r problem doesn't exist on your 3557 or your previous 3571 build. I think the positioning code just can't keep up enough with this type of subtitle which repositions in every frame, and therefore causes the twitching while it tries to correct itself. Why it only happens with VMR 9 r and not EVR-CP, I don't know. It doesn't seem to be a GPU load issue, though. I turned off all shaders, Vsync and used Bilinear resizer and it still happens. It doesn't seem to be a driver issue either, as I just tried it with integrated Intel graphics and it's the same thing.

BTW, do the options 10 bit Output and Half/Full FP processing affect VMR9r or are they just for EVR-CP? Because I just tried those with VMR9r on the Intel graphics and the video works but EVR-CP fails horribly. xD

[JanWillem32]

The subtitles are rendered by a single CPU thread that exports it to a texture on the video card once done. The video card only copies subtitles to a post-resize surface, with the option of bilinear resizing for if the source doesn't match the target window size. For EVR CP and VMR-9 r. I've forced text renders to always use the window size, so resizing only matters with bitmap subtitles. In essence, only bitmap subtitles can be affected by any video card settings.
I changed the a part of the ordering in the code for detecting the requirements for a device reset. I can make a few variant builds to see if some other type of ordering solves it.

The VMR mixer allows more software emulation for when the GPU can't do certain video operations. EVR demands that all image processing is done on the GPU. It's logical with the rendering layout, EVR has more render stages and is a bit more complex.

[JanWillem32]

A build of the x64 version this time, it only lacks language files. (I didn't have time to update them all.)
The x86 builds broke after I merged in the subtitle fixes from the trunk.

Improvements:
-I increased the efficiency and accuracy of the geometry math by a lot.
-The problems with the CM have been solved. Because of changed settings (and because I accidentaly put the time stamp in reverse order before), new 3DLUT files have to be generated. You can delete the old ones in the user root folder.

Bugs:
-The internal software codecs sometimes use up 100% CPU time of a single thread. I don't know why, but this is a newly introduced problem.
-Resizing by using "double size" and then zooming further to 2.25× crashes on all resizers for me.
-The initial synchronization bug is back. It was introduced in the trunk build.
The audio renderer starts immediately after opening a file, ignoring the initialization time for the slower video renderers.
The effect is that audio plays normally with a black screen, until the video renderer is ready. Once the video renderer is ready, video is played back at the absolute maximum speed, and locks out user commands until done.
(I noticed it when I was rebuilding some test 3DLUT files, which take while.)

[Jtacdf]

Hi JanWillem32, just tried out your 3600 x64 build. Would like to report some stuff and feedback.

1) I can confirm the cms issue is finally fixed. No more weird out of gamut colors.
2) Forcing text to render at window size is not such a good idea IMO. E.g watch a anime with complex softsub ass in D3DFS at 2560x1440, it choked my pc at some point since subtitles are only rendered on a single thread.

3) Since 3423 where you included subtitles in the cms and dithering pipeline, enabling full/half fp causes ass subtitles with black outline to appear like this:
http://i197.photobucket.com/albums/aa315/Jtacdf/MPC-HC%20samples/WrongOutlines.jpg

Disabling fp or using 3329/3391 with fp enabled, it would be rendered correctly like this:
http://i197.photobucket.com/albums/aa315/Jtacdf/MPC-HC%20samples/RightOutlines.jpg
Heres a sample.
http://www.mediafire.com/file/2wtnxuy0ae9zp9w/%5Bgg%5D_Ao_no_Exorcist_-_06_%5B26E1DD02%5D%20Sample.7z

4) Timing of ass subtitles seems to be a little off. It's more apparent on sample like this that is timing sensitive:
http://www.mediafire.com/file/6b0fgpbvet7bbfe/%5BDoki%5D%20Suzumiya%20Haruhi%20no%20Yuuutsu%20%282009%29%20-%2008%20%281920x1080%20h264%20BD%20FLAC%29%20%5B79EC4B68%5D%20Sample.7z
Again it only works correctly on 3329 and 3391.

Sorry if the post seems a little long. I wanted to be as detailed as possible.

[JanWillem32]

I can't undo the binding of the resolution to window size with a dynamic backbuffer size and frame swap queue. (When I first enabled that, subtitle blending broke, so I solved that with some custom geometry and some other code.) Any optimizations will have to be done inside the subtitle renderer (or replace it). It can be made lighter by disabling the animation while buffering function. (It doesn't update every frame in that case.)
I can't replicate the failed alpha blending at all. What happens with colored items? What is indicated in the subtitle styles menu during playback? Does disabling the post-resize shaders, the dithering and color management help? (That places the blending step in about the same place as it was before.) Does blending on 10-bit working surfaces work? (With dithering or color management enabled.)
Timing of subtitles has become more problematic with the 4-frame render queue (it used to be only 1) and the failing internal clock that only seems to push the audio renderer correctly (recent development in the trunk build, I'm not happy with it). I think I should change some fundamentals in the interface to and from the subtitle renderer, but with sharing the subtitle renderer with 5 others, that will be tricky. (I've broken geometry and blending for other renderers a lot of times already.)
If the subtitles seem to be shifted forward or backward constantly by an exact number of frames, I can correct it by applying a timer shift. That will need some testing.

I have a request for testing this time. I've been updating the mixers of the shared renderer for a while now, and I was wondering if there's any difference in the behavior between the EVR, VMR-9, RealMedia and Quicktime mixers. The DirectX 9 RealMedia and Quicktime mixers are pretty underdeveloped, but should still show something on x86 builds. Could someone look at the specific problems of these two?

[Jtacdf]

Well, good thing that the subs are not slowly drifting away. They only appear slightly ahead of time constantly.

Hmm. Strange that you can't replicate the problem even though someone before me had reported it.
http://forum.doom9.org/showpost.php?p=1514770&postcount=207

Anyway, here are more screenshots with stats.

With FP, no shaders
http://i197.photobucket.com/albums/aa315/Jtacdf/MPC-HC%20samples/WithFP.jpg

With no FP, no shaders
http://i197.photobucket.com/albums/aa315/Jtacdf/MPC-HC%20samples/NoFP.jpg

Nothing, no shaders
http://i197.photobucket.com/albums/aa315/Jtacdf/MPC-HC%20samples/Nothing.jpg

But the problem goes even further then that. Overwriting the ass sub with mpc-hc internal default shows that FP also breaks the border style settings.

With opaque box, no FP, no shaders
http://i197.photobucket.com/albums/aa315/Jtacdf/MPC-HC%20samples/OpaqueBoxNoFP.jpg

With opaque box, FP, no shaders
http://i197.photobucket.com/albums/aa315/Jtacdf/MPC-HC%20samples/OpaqueBoxWithFP.jpg

[JanWillem32]

That the subtitles are a bit early is understandable. The subtitle renderer asks for the current difference in time between frame 0 and the the one projected to in the queue. The internal timer currently synchronizes only properly with the audio renderer, so it's set to a pretty absolute "now". For the video renderer which creates frames for a future present, I have to add a guess value of the difference between now and when that frame should be presented in the future. The amount of frames ready in the queue is dependent on the rendering workload, it varies from 1 to 4 frames. Estimating the future presentation time is pretty difficult.

Does the failed alpha blending seem to happen on any other color than black?

I've tried to set up a few rendering states, hoping it helps for this case. Variant 1 changes one small thing, variant 2 adds a few other alpha blending states.

[Jtacdf]

Both s1 and s2 fix the sub alpha issues. Thanks!
Now only the sub timing issue is left.

EDIT: After doing more testing on the sub timing sample, VMR-9 renders it perfectly fine. So the timing only affects EVR-CP.

[JanWillem32]

Good to hear that, I'll revert the changes made for variant s2 and keep those stated in s1. There are 92 states that I can possibly declare, if I remember it correctly, and there are multiple targets for those, too... It could have been a bigger problem to find the right solution.
ForceX has a problem with VMR9 r. and subtitles, Jtacdf has a problem with EVR CP and subtitles, and as usual, I can't replicate any problems at all. Back to some more guesswork, then. :p

[ForceX]

My subtitle twitching issue in VMR9r is mostly gone in your 3600 x64 build. It still happens, but much less frequently.

[tetsuo55]

Hey Janwillem,

Which trunk regressions are you talking about? what revisions?

[CruNcher]

How to get the decoder displayed in the OSD ? also the newest builds fail here seems to be a scaling issue (input gets extremely huge) VMR9 Renderless Bicubic and XP (touch from inside)
The last test build that works ok is mpc-hc SSE(2) tester dfr3329 all the newer ones show this extreme huge scaling issue (zoom)

[JanWillem32]

@tetsuo55: I've tried to find the reason of the failing timer. A quick glance over some past revisions didn't help. I might find a solution later, but can't really work on the program code now. I'm staying over at my parents' house, so I can visit my grandmother in the hospital a few times.

@CruNcher: The decoder name is reported by EVR CP in the stats screen. I only wonder why the current system was chosen. Normally, decoder information is given by the graph builder, not the mixer. The normal overview on all filters is in "View", "Filters".
The intermediate build in #261 seemed to work well for Hera: http://forum.doom9.org/showthread.php?p=1518095#post1518095 . That one doesn't work for you?

[CruNcher]

Nope i either see no Video @ all and the current background mirrors itself or i see a Video playing back extremely zoomed (VMR9 Renderless,YUV Mixing)
Yeah i wish someone would include it directly in the Debug OSD by reading it from the Graph it's a pain to allways need to click through the menu to see it :(
Also that 1 Dialog blocks the whole player interaction is a pain sometimes

[JanWillem32]

Okay, I'll just try method number 6... (Only included in the SSE2 version, and I'm not really sure if it will work.)

I've decided to have a go with AVX. I didn't write any packed AVX code yet, but it might be interesting to try if MPC-HC reacts well to the AVX compiling arch on a base level.
Little CMS was updated from the main code. The most notable change is the handling in the part for the white point adapt state (only used with an absolute colorimetric rendering intent).
The timing problem has been fixed.
I've made some great performance fixes this time. If the window size detection method works, I can move on to merging more code with EVR Sync.

[CruNcher]

immediately crashes on execution :( (Sandy Bridge) XP

[ForceX]

For whatever its worth, the AVX build also crashes on Win 7 x64 (however, my CPU does not have AVX support). The SSE2 build crashes when trying to display subtitles with external renderers. SSE build works ok.

However, subtitle positioning on the Bad Apple video breaks if you resize the video window. Subtitles are rendered over the window surface instead of on the video surface. Also, subtitles currently being animated also stop animating after a resize until the next line appears. Does not happen with other renderers or vanilla branch VMR9r/EVR-cp.

[nevcairiel]

AVX instructions are only supported on Win7 with SP1, it'll never work on XP - and i guess there are no checks if the CPU even has it. :p

[Jtacdf]

Well, the avx/sse/sse2 version works for me. Still awaiting on the sub timing issue. However, I'm experiencing crashes with all the latest build after 3391. With 10-bit RGB output enabled, trying to open a new file causes mpc-hc to crash. Works fine on all version with it disabled.

[ForceX]

I'm experiencing crashes with all the latest build after 3391. With 10-bit RGB output enabled, trying to open a new file causes mpc-hc to crash. Works fine on all version with it disabled.
Confirmed.

[JanWillem32]

A few little changes:
-added decoder name to the stats screen in VMR-9 r.
-improved frame rate detection, and linked that to the subtitle timers
-added subtitle geometry reinitialization after a device reset
-made the exit sequence a bit shorter, maybe it helps to prevent crashes
-ranked AYUV with merit 0 for EVR CP, to prevent activation of the EVR software emulation mixer

[Jtacdf]

3652i fix the sub timing issue for me.

EDIT: Still experiencing crashes upon trying to open a 2nd file. With everything off in the renderer settings and no shaders, does not crash at all.

[TheElix]

I'm currently back to the primary builds until some things get better. For example,
1) VSync is worse in new builds, I can't get stable 3:2 pulldown. And even 1:1 doesn't work as smooth as before. =(
2) It takes a lot longer for new builds to load video. It searches videos slower (even with super-fast AVSplitter). Some performance issues when changing window size (or changing between window-fullscreen).
3) Subtitles with thin outlines and no shadows. (I don't know if it was fixed in the latest version)
4) Occasional crashes.
Overall, it doesn't look like a step-up from the primary builds for me anymore. Please, don't get upset with my words. I know you're trying to build some things anew and in order to do that you must break some old things to the ground. It's just that for some reasons I can't tolerate those things that I mentioned. But I'm constantly viewing this topic and I'll definitely be back with some testing. =) Thanks for your efforts!

[Jtacdf]

@TheElix
If you read the previous posts, the issues with subtitles is already fixed.

[JanWillem32]

VSync will be a bit of a problem. The original code clashes a lot with the queue. I've only had stable results while using the video card's standard (pretty much absolute) VSync in exclusive mode, or with that of the desktop composition (in both cases meaning that the three internal VSync modes are disabled). I wonder how well the Sync clock in EVR Sync reacts to it once first-level code integration is done. Pulldown should not have any relation with the VSync functions, though. Dropping the duplicate frames for pulldown (+deinterlace) is a mixer task.
The longer loading time is because of the difficult relationship with the graph builder. Priorities are set up a bit wrong, and gapless playback is made impossible by it. (All renderers are closed and re-opened with every new file.)
The performance issue with window resizing is by choice. I only set up checking for changed settings twice per second (includes changed window sizes). I've set up the parameters during a normal rendering loop to be set up once, and be re-used after that, as that's the normal state for a renderer. For configuring custom window sizes and resizing settings some preset mode could be made to switch things at once. (Maybe for positioning the window, too.)
I've verified that some crashes happen when resizing. The link to some external renderer functions and subtitle renderer host has a memory corruption problem that causes it.
I can't replicate the problem with crashing on switching files. With how the graph builder treats the video renderers during a switch, I'm not surprised it does, though.

I'm glad that the subtitle timing is okay again. It's not an easy task to edit code that shares functions for 5 renderers. (Soon a few less, I hope.)

[JohnLai]

Hmm... question, how do cubic B-spline4, Mitchell-Netravali cubic4, Catmull-Rom spline4, cubic B-spline6, Mitchell-Netravali cubic6, Catmull-Rom spline6 perform in term of quality and speed compared with default bi-cubic -1.00?

Quality = color, sharpness, blur etc
Speed = gpu utilization especially on low end gpu

[CruNcher]

Hmm the whole VMR9 is unstable here it either crashes on load of the Video or shows this mirroring of the Desktop effect, switching to VMR7 Renderless and it plays fine :( (maybe because i have everything Vsync related disabled ? )
Reset to default Rendering Settings and Optimal Settings also has 0 effect on this crash and mirroring issue (seems also it doesn't activate Vsync @ all) so still tester dfr3329 is the last version that works with VMR9 for me (XP) (Nvidia Geforce GTX 460)

[Hera]

Crashing between files is probably due to all the worthless re-initializing...

[ForceX]

Reinitializations are extremely disruptive and adds frustration to user experience. Nothing beats smooth, constant playback, regardless of resizing and whatnot. General people will notice responsive seeking and smooth playback more than a shift in colors. If at all possible, you should try to eliminate all reinitializing.

Moving on, in 3525i subtitle scaling is messed up after resizing the window.
Non-resized: http://i53.tinypic.com/10s6ttu.png
Resized: http://i56.tinypic.com/2r5xhc4.png

[CruNcher]

Crashing between files is probably due to all the worthless re-initializing...

Its not crashing between files here its rather a random thing on load it either crashes or shows this mirror effect of the desktop in the Video Playback Window (instead of the Video content) before that in the previous test builds it showed the Video extreme zoomed in but at least it didn't crash it only seems to happen on a VMR9 surface VMR7 seems not affected.
I guess the problem is something NT 6 specific and doesn't work on NT 5 or some problem with the 460 GTX

[Jtacdf]

It crashes when switching files for me, it crashes at random for CruNcher. At any rate, it still crash :p

@JanWillem32
Will this be a main priority for you to fix? Seems to be quite a major issue.

[janos666]

Just a tip for plasma TV users:

I had fears that the aggressive dithering of my PDP (these panels have very few real color shades) may interfere with the dithering noise added by the renderer.

The most noticeable banding comes from the range expansion, and I guessed the TV doesn't really mind if it works from limited or full range input (everything is processed and dithered anyway, but it happens with fairly high quality...), so I used the [0,255]->[16;235] shader and re-calibrated my TV for limited range RGB input.

The rounded 10-bit limited RGB gives me slightly better result than dithered 8/10-bit full RGB (it's most noticeable on dark shades which are always noisy, and some lighter shades looks a bit less noise now).
I guess it's something like "you can't paint a designed-to-be-random noise with another and different designed-to-be-random noise".

---

It reminded me...
@JanWillem32: Did you talk with the team about asking that nonstandard YCC driver mode from AMD?

[TheElix]

The most noticeable banding comes from the range expansion, and I guessed the TV doesn't really mind if it works from limited or full range input (everything is processed and dithered anyway, but it happens with fairly high quality...), so I used the [0,255]->[16;235] shader and re-calibrated my TV for limited range RGB input.Can you explain how the same exact colors/shades of grey can give you less dithered (read: noisy) picture if it's on the same panel? Because I can't. I tried using TV levels as video output range with [16, 235], [16, 240], [16, 240] to full range for SD&HD video input shader. And saw no differences on my calibrated plasma. Maybe you were anticipating good results?

[janos666]

@TheElix

The near-black shades look a little bit more distinguishable from each other and the shades around ~20% looks a little bit less noisy (I guess they are just more distinguishable as well).

The TV uses noise to visualize the missing color shades but that doesn't mean it was intended to be recognizable by humans. The same applies for the dithering in the renderer. The dark color shades need heavy internal dithering, so it's doubtful if the TV can paint a nice noise pattern with it's noise. I think I got something noisy with ~8-bit effective precision (after distorting the original dithering from the renderer), but that's not enough for the expanded levels, so it wasn't too smooth.

I saw and calibrated the same plasma model for somebody who had a desktop media player with YCC output option. I noticed his set produces slightly better near-black scale than mine. Now, with limited range, they are closer (hard to tell without seeing them next to each other, though...).

[TheElix]

On a properly calibrated PDP you will generally see more clean/less noisy images (especially in darker grayscale patterns) because the red, green and blue components are mixed equally. On a non-calibrated plasma you may take a picture of pure black screen with 1/600 shutter speed and see how much red/green/blue dots are appearing in the picture whereas there should be none.
The method you're talking about may affect positively some shades of gray while introducing even more noisy picture for other shades of gray (because of different methods (video card processing and shaders) of levels expansion, I assume). It would require extensive testing to get objective comparisons. Otherwise, you just have to believe in it or not.

[janos666]

I think it's easy to believe.

I guess we can assume the TV is optimized for limited range (EU/US-SD/HDTV and DVD/Blu-Ray sources all have limited range YCC content - except some nonstandard Asian BDs with weird levels - if the rumor is true, but that's their problem...) but I think a PDP doesn't really mind because it has very limited linear graduation and heavy dithering anyway (not like an LCD screen with 256 -or may be 64, or even 1024- physical analog states).

The original Y range is limited, the RGB expansion is only required for PC displays which are optimized for full range content.

Of course, the limited range RGB is not perfect either because the chroma range is different in YCC and the YCC->RGB conversion isn't cheap either, but the 10-bit output grants us some extra precision (without additional dithering noise on the source side).


Try to disable the dithering with 8-bit output. The limited range RGB will be reasonable but the expanded RGB output will look awful with gradient test patterns.
Next time do it with 10-bit output: the expanded level RGB won't be as smooth as it could be with dithered 8-bit (but it will be much better).
But if you skip the level expansion (well, undo it -but in high precision- in this case ; at least until we have a custom mixer...) then 10-bit RGB should be enough to get reasonable result (the TV alone isn't perfect anyway...).


May be it's only placebo, but I prefer the undithered limited range 10-bit RGB output over madVR's dithered 8-bit RGB (but it's only reasonable with limited range output because the expansion needs more precision than 10-bit).

[JanWillem32]

-I've solved some fundamental problems in the subtitle texture management
-there should be less crashes by the subtitle renderer when resizing a window (typically error no. 6025, needs some more work)
-the subtitle renderer should have better geometry reinitialization after resizing a window.
-I've revised the renderer exit sequence, it should be able to properly switch from 10- and 8-bit exclusive modes to windowed mode and properly switch between files
-I've changed the presentation layout of the windowed mode to an additional swap chain, this allows somewhat faster resizing in windowed mode (it still resets only up to 2 times per second, and it will still resist resizing when a video is playing, but I'm working on fixing that)
-I've started to do on some repair work on the VSync functions (again), mostly to get multi-threading more efficient

Did you talk with the team about asking that nonstandard YCC driver mode from AMD?I've only heard about the D3D Ex overlays the last time, and that's not what I'm looking for. I'll try to find out more from the hardware manufacturers and other parties for information in a while, when I have the time and a testbed to actually test and debug code for such a function.

[Stephen R. Savage]

JanWillem32, this probably doesn't have to do with any code you've written, but could you look into this:

On my Intel X3100 GMA, which has ridiculously bad drivers (most things D3D-related cause crashes/BSOD), when I use EVR-CP with D3D Fullscreen, the graphics drivers crash on exiting fullscreen, but EVR-Sync and MadVR can be used in exclusive mode without problems. This happens in both trunk and your tester builds.

Do you have any ideas what EVR-CP could be doing differently to trigger this?

Edit: Also, would it be possible to implement a seamless switch between exclusive fullscreen and shared windowed mode like MadVR does? D3DFS GUI support has never worked, making it hard to seek in exclusive mode.

[Hera]

Noticed that bringing up the seek bar (non D3D, but fullscreen mode) resizes the video.
This, now, produces a pause and squishes the video. Neither of the two are wanted. GUI should be drawn on top of video.

[JanWillem32]

@Stephen R. Savage: If the exit method of EVR Sync works, I can simply copy-paste it. The code of the shared renderer is pretty much the same as EVR Sync, except for the mixer parts and the Sync clock. I'll test if it works on a debug build for me. If it does, I'll upload a quick build.
I've been wanting to edit the switch to exclusive mode for a while, too. I'll ask if that's okay while the exclusive mode still can't be closed by an on-screen close button. Last time, people thought it was too risky for new users.

@Hera: I've asked how to make the seek bar and menu bars in the fullscreen windowed mode behave like the right-click menu. I also think it's wrong that those currently shrink the drawing area, instead of overlapping it.

[CruNcher]

-I've solved some fundamental problems in the subtitle texture management
-there should be less crashes by the subtitle renderer when resizing a window (typically error no. 6025, needs some more work)
-the subtitle renderer should have better geometry reinitialization after resizing a window.
-I've revised the renderer exit sequence, it should be able to properly switch from 10- and 8-bit exclusive modes to windowed mode and properly switch between files
-I've changed the presentation layout of the windowed mode to an additional swap chain, this allows somewhat faster resizing in windowed mode (it still resets only up to 2 times per second, and it will still resist resizing when a video is playing, but I'm working on fixing that)
-I've started to do on some repair work on the VSync functions (again), mostly to get multi-threading more efficient

x86 SSE: http://www.mediafire.com/?nzdzn958ghnhz5z
x86 SSE2: http://www.mediafire.com/?piw9pcb278dccnn
x64: http://www.mediafire.com/?8a819jj1b46imit

I've only heard about the D3D Ex overlays the last time, and that's not what I'm looking for. I'll try to find out more from the hardware manufacturers and other parties for information in a while, when I have the time and a testbed to actually test and debug code for such a function.

Puhh stable again doesn't crash and output is correct no zooming no Desktop mirroring :)

[CiNcH]

I just had a look at the old scaler pixel shader (e.g. the old Bicubic) integration into the D3D renderer code. Vertex texture coordinates are not normalized when using those. Why is that? I thought that texture coordinates in D3D always had to be normalized!?

[JanWillem32]

@CruNcher: That's good to hear.
I've verified that my PC still throws the memory reference at 0 error when switching files, so that problem isn't completely solved. It's about 1 in 8 times. I'm still working on that.

@CiNcH: The vertices only have to be normalized to the interval [0, 1] if neither vertex or pixel shaders adapt it. In the case of the resizers, the texture coordinates are changed inside of the pixel shader before sampling the texture (which indeed uses the interval [0, 1]).

[CruNcher]

Though it now beahaves crazy anyways it now doesn't crash or shows odd behaviour when using Software Rendering but as soon as i try to get it Display (VMR9 Renderless + YUV Mixing) via either a DXVA or Nvcuvid based Decoder it crashes on load of that file Software Decoder like Lav Video, ffdshow or others work :(

[JanWillem32]

VMR-9 mixer mode gave me some problems in the past. Have you tried to disable it?

[CruNcher]

VMR-9 mixer mode gave me some problems in the past. Have you tried to disable it?

Nope crashes as soon i try to render something Hardware accelerated no matter if Mixer mode on or off or Yuv Mixing :(
The Beahaviour is really crazy it plays 1 time Software rendered and then even Hardware but in the next try it crashes severall times and then it works again, really weired it's really like a lottery Game :D

Hehe the probability that something Software Decoded plays without a crash though is higher then Hardware accelerated and if something played Software Decoded the probability that right after playback playing something Hardware accelerated works without a crash is quiet High , though after that it becomes random again :D

Also it seems only VMR9 Renderless is affected VMR9 windowed and VMR7 Renderless doesn't crash either way Software/Hardware Playback (absolute stable)

Ahhh i tried something i unchecked "10 Bit RGB output" it was checked and after that even Software playback always crashed checking it again started the Randomness again :)

Thoug i cant be even sure that this was a real experience or Random as it now crashes again even with Software playback all the time on load with "10 Bit RGB output" checked, just to crazy :D

PS: Wow now the MPC-HC window just closed no crash the application just terminated itself :D

[JanWillem32]

VMR-9 windowed is an almost completely external object in a system DLL. VMR-9 renderless is only using the mixer part of it, the rest is completely internal. I'd love to get rid of the mess of external mixers for EVR Sync, EVR CP and VMR-9 r.. (There are also external parts for the RealMedia and Quicktime components, but I haven't even completely tested those in my builds.) A custom mixer component would save me a lot of trouble with debugging this kind of thing, and make all the resources of the mixer controlled in the player itself.

Have you tried to delete the entire registry key and/or remove the .INI file to reset all settings? (Make a backup first.)
Some settings from the trunk build or older versions might conflict.

[CruNcher]

Reinitialization doesn't help its just luck if it plays something without crashing on load with VMR9 Renderless in the current test build :(
3 times ok (even used closed) 4th time crash

[JanWillem32]

Let's try a debug build.
These builds are really slow, usually fail at rendering subtitles, and usually don't have the same bug characteristics of a regular build, but they might indicate what's going wrong in some cases.
You can capture system traces with DebugView (no setup required at all): http://technet.microsoft.com/en-us/sysinternals/bb896647 .
Other status indications are recorded in the system log. Run "eventvwr.msc" to view those.

[Stephen R. Savage]

@Stephen R. Savage: If the exit method of EVR Sync works, I can simply copy-paste it. The code of the shared renderer is pretty much the same as EVR Sync, except for the mixer parts and the Sync clock. I'll test if it works on a debug build for me. If it does, I'll upload a quick build.
I've been wanting to edit the switch to exclusive mode for a while, too. I'll ask if that's okay while the exclusive mode still can't be closed by an on-screen close button. Last time, people thought it was too risky for new users.

@Hera: I've asked how to make the seek bar and menu bars in the fullscreen windowed mode behave like the right-click menu. I also think it's wrong that those currently shrink the drawing area, instead of overlapping it.

Thanks. I look forward to a test build, as this has been bothering me for a while (though, of course, all blame originates at Intel).

Couldn't you make videos still start windowed even when D3DFS is turned on? Just have it switch to exclusive on fullscreen when the option is toggled and to normal fullscreen otherwise.

[Jtacdf]

@JanWillem32
After testing 3652r, here are some feedback.

Switching between files in D3DFS 10-bit does not crash anymore, but after sometime opening/closing several files, I experience the old black screen issue upon closing.
I will still experience very random crash once in a while when switching files.

[tetsuo55]

Thanks. I look forward to a test build, as this has been bothering me for a while (though, of course, all blame originates at Intel).

Couldn't you make videos still start windowed even when D3DFS is turned on? Just have it switch to exclusive on fullscreen when the option is toggled and to normal fullscreen otherwise.Please also open a support ticket over at Intel and your motherboard manufacturer's brand.
Intel puts high priority on fixing issues with mpc-hc in their drivers, but they cannot fix what they don't know about.

[JanWillem32]

@Stephen R. Savage: I'll try to work on a function to simply switch the exclusive mode on a user command first. It's unfortunately buried deep in some menu structure. Like the four other functions I want to add to the menus, it will take some time. Editing those is pretty new to me, and I can't always get them to work.
@Jtacdf: That sounds like a good chance to try the debug build. Maybe you can find anything useful from the system traces and logs with it.

[Jtacdf]

@JanWillem32
I've narrowed down the source of my issues. Seems to be the mpc-hc internal sub renderer thats causing it.
From this post,http://forum.doom9.org/showthread.php?p=1519639#post1519639, I thought I might as well disable the internal subtitles renderer.
After opening/closing more than 10 files, I could not replicate my issue at all until I enable the sub renderer and just like magic, black screen after 2-4 files.
Tested on debug sse2 3652r and 3652r sse2 normal build. Both responded in the same manner to this issue.

[Stephen R. Savage]

Please also open a support ticket over at Intel and your motherboard manufacturer's brand.
Intel puts high priority on fixing issues with mpc-hc in their drivers, but they cannot fix what they don't know about.

The X3100 has been out of support for a long time -- there hasn't been a driver update since Windows 7 originally released. Same with my laptop model that came with it.

[CruNcher]

Let's try a debug build (x86 SSE2): http://www.mediafire.com/?zqsdshhep64564p .
These builds are really slow, usually fail at rendering subtitles, and usually don't have the same bug characteristics of a regular build, but they might indicate what's going wrong in some cases.
You can capture system traces with DebugView (no setup required at all): http://technet.microsoft.com/en-us/sysinternals/bb896647 .
Other status indications are recorded in the system log. Run "eventvwr.msc" to view those.

Nothing unusual just the whole Graph search dshow finding the right Splitter/Decoder and then after VMR initialization the crash no info about that as it crashed their :(

[tetsuo55]

The X3100 has been out of support for a long time -- there hasn't been a driver update since Windows 7 originally released. Same with my laptop model that came with it.You can always try, intel even has support through a chat-client on their website. Once enough people contact them about an issue they will act.

[tetsuo55]

And your laptop is probably out of warranty?

If it came with Win7 then you might still have a chance depending on the manufacturer. Like in the case of my company (we dont make computers), we are forced to provide firmware updates for the hardware we sell regardless of actual warranty of said hardware. Even if its 10 years old.

Some other manufactures might follow the same guidelines.

[CruNcher]

@JanWillem32
could you upstream your VMR9 OSD changes (current Decoder Display) to MPC-HC trunk and would it be possible to add Splitter and Audio Decoder ? :(

[JanWillem32]

I can add any function that doesn't change a renderer stage to the trunk build. The current decoder information is imported from the mixer pin, that only has video information. To import information from other pins I'd have to add completely new code to read information from the filter graph parts. I'm not too keen on editing that just yet.

[JanWillem32]

A full set this time, with only small changes from the previous version.
I've made some minor optimizations to the render queue, VSync functions and resource management.
Because of the changes to the renderer queue, I can now add temporal functions. Ideas and information for improving or making new temporal functions are very welcome.
The first I've added is the "Constant Frame Interpolator". It's a heavy filter that interpolates frames to match the screen refresh rate, using a windowed function on 4 (nearly finished) frames. I'm still looking at optimizations for reducing artifacts and to improve its speed.
This function has some special properties:
-Linear input from a custom pixel shader is required. The subtitles are automatically adjusted with a gamma 2.4. The output from the interpolator is adjusted by 1/2.4 to match.
-"VSync", "Accurate VSync" and the "GPU Control" settings are incompatible with this filter, as these (currently) interrupt the rendering queue.
-As usual, exclusive mode will have a much better control over timing all frames.
-Because of heavy color blending operations, enabling "Half Floating Point Processing" or "Full Floating Point Processing" is advised.
-Color management and dithering is applied after the interpolation step when enabled.
-The custom pixel shaders, subtitles, stats screen and OSD are not updated for every output frame.
-The tearing test can be used to see if frames are presented at every screen refresh.
-When the display frame rate is close to the video frame rate (a factor of 1.5 or less), artifacts will be severe.
-One of the most visible artifacts is the fade-in&out effect in paused mode.
-Another type of artifact can be seen as a faint trail, following moving objects on screen.

[JanWillem32]

I found several memory/other resource leaks inside the renderer core, I've been trying to solve those. The EVR and VMR-9 mixer parts will probably need a similar inspection. I didn't find anything special inside of EVR Sync's code for creating or destroying devices in fullscreen mode, that would explain the lack of crashes on exit. The exit sequences for the mixer and renderer parts are almost the same, only the sequences of the VSync functions are very different.

[Hera]

Will these "temporal functions" delay the merging your fixes with trunk?

[JanWillem32]

I've written a few basic deinterlacers and two types of frame interpolators ages ago. Integration and writing menu functions did take some time, but it should work properly now.
I can start merging changed renderer stages, settings and other items that are sensitive to problems, once I've repaired the on-line version of the branch I'm working on, verified that my builds are at least at or below the general problem level of the version in the trunk and I can convince the development team that my code is ready to go into the trunk. Non-critical functions that are not yet 100% optimal are okay to add, as long as these don't break the critical ones.

[Jtacdf]

@JanWillem32
Here are some feedbacks on 3682r

3682r AVX seems to fix the black screen on closing files and the random crash. Thanks!
Congrats for taking the first step in adding a dedicated hardware/gpu constant frame interpolation.
Just a suggestion, but you might want to have a few presets for different types of video unless you can get it perfect in a single preset. Trailing Artifacts is of course very obvious with fast action scenes.

[nevcairiel]

While i understand the fun in implementing new and exciting features, if you don't finish the fixes and cleanups first, and produce a new version *without any regressions*, your changes will *never* be merged into the trunk.

Just saying.

[Hera]

Crashes on exit on netbook.

[JanWillem32]

@Jtacdf: Good to hear that. It was quite a lot of work to edit the subtitle renderer's exit sequence. It had a problem with properly deleting items in video memory.
Are the AVX instructions any good with floating-point heavy math in MPC-HC? I can't test it, but maybe you can test if the CM is any faster when generating a 256³ LUT.
I can add presets easily, once I've found some more information about different implementations and the math/code used for those. I didn't find much yet, and it was all pretty obscure.

@nevcairiel: It's been about a month since I could actually reproduce a reported problem myself. The only fixes I've made lately are by guessing what was causing the problems. The only thing I've really broken is EVR Sync, and that's only because the code merge is incomplete. I was so bored that I've even started to work on the ISubPic parts and the actual subtitle engine. I also have several other extra functions lined up: a background color selector, an extension for the frequency changer for the exclusive mode, 15 color controls, a new function for saving fully-rendered images from the renderer and some video mixer parts. Except for the mixer parts, the only implementation issue I have is that I don't really know how to add them to the menus.

@Hera: Which version do you use? Is it in exclusive mode only? Are there any errors reported (also look in the system log)? Is this a new problem?

[Jtacdf]

@Jtacdf: Good to hear that. It was quite a lot of work to edit the subtitle renderer's exit sequence. It had a problem with properly deleting items in video memory.
Are the AVX instructions any good with floating-point heavy math in MPC-HC? I can't test it, but maybe you can test if the CM is any faster when generating a 256³ LUT.
I can add presets easily, once I've found some more information about different implementations and the math/code used for those. I didn't find much yet, and it was all pretty obscure.

There isn't any visible difference I could see in speed between the AVX and SSE2 version. I just thought that AVX might run quicker. Guess I assume wrong.
Both took about 7 seconds to generate a 256³ LUT. At any rate, 7 seconds is a big step up from the 'feels like forever' generating when CMS LUT was first introduced in your build.
FYI, 128³ LUT generated immediately when I open a file.

[JanWillem32]

Well, I guess you wouldn't notice any speed gains at 7 seconds. It's probably the writing of the file that's producing by far the most delay. The CM is set up to specifically prefer output of continuous files. It takes a while to find and allocate a continuous 128 MB with the operating system and the file system, and then write the file at that location.
For other people using the CM and still think it's a little bit slow, I'll try to make it multi-threaded in the future.

[G_M_C]

While i understand the fun in implementing new and exciting features, if you don't finish the fixes and cleanups first, and produce a new version *without any regressions*, your changes will *never* be merged into the trunk.

Just saying.

QFT

Inderdaad, één ding tegelijk.

Renderer improvements + shader work first, maybe combined with subtitles. These tings are useful for most people. Other things like CMS affect progressively less and less people. Adding features can be done later.

[CiNcH]

@JanWillem32,

did you ever profile compiling a shader? I am just curious because the renderer code still performs string replacement and shader compiling each and every frame cycle.

[Hera]

Crash on exit STR,

1. D3DFS
2. Open File
3. ALT-F4


Problem signature:
Problem Event Name: BEX64
Application Name: mpc-hc64.exe
Application Version: 1.5.3.3682
Application Timestamp: 4e51a488
Fault Module Name: mpc-hc64.exe
Fault Module Version: 1.5.3.3682
Fault Module Timestamp: 4e51a488
Exception Offset: 00000000009dd3a8
Exception Code: c0000005
Exception Data: 0000000000000008
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1033
Additional Information 1: 415d
Additional Information 2: 415d47caa1eae30530a1465331992e7f
Additional Information 3: de4a
Additional Information 4: de4a8cb134c5e1df28e33fa8c2c8c7d1

Read our privacy statement online:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409

If the online privacy statement is not available, please read our privacy statement offline:
C:\Windows\system32\en-US\erofflps.txt

[JanWillem32]

@G_M_C: Actually, I also have 2 other projects I'm working on, and I also have hobbies (including actually using MPC-HC for media, of course). Generally, the added features simply work fine. The biggest issue reported at the moment was reported by Hera. And even with that problem, I consider the flaws in the trunk build somewhat worse.

@CiNcH: The pointers to the pixel shaders are regularly evaluated to check if compiling is necessary. I actually wanted to improve the compiling system to use more string replacements. The current system uses registers to pass the size of the texture to the shader:
float4 c0 contains width, height, frame counter, clock in seconds
float4 c1 contains 1/width, 1/height, 0, 0
A more efficient model would be to use string replacement for the static width and height, as those can be integrated into the shader assembly itself:
float4 c0 contains frame counter, 0, 0, 0
float4 c1 contains clock in milliseconds, 0, 0, 0
#define width _WIDTH_
#define height _HEIGHT_
For the resizers and the final pass section this is already in use. (With some extras.) The problem for custom pixel shaders is that it would break compatibility with other players.

@Hera: Thanks for the error report. I can't replicate the problem, but BEX errors are usually related to memory buffer overflow problems, so I'll search for those first. Is this issue new? Does the same happen with the internal key commands for exit (default Alt+X) and close (default Ctrl+C)?

[Hera]

Can't reproduce without D3DFS using ALT-F4.
Can't reproduce with ALT-X or CTRL-C.

Not sure if new.
EDIT: Exists in 3652
EDIT: Exists in 3600

[JanWillem32]

Thank you. So it seems the player tries some sort of unsafe quick exit when using Alt+F4, but uses a normal exit with the key commands. I wonder how I could debug this. I'll first take a look at what the player does differently with Alt+F4 compared to Alt+X. I hope it doesn't take too much work on the main framework or the graph builder to solve it this time. If the method is really unsafe, I think the trunk build has to be patched as well, as I didn't edit these parts of the code at all.

[nand chan]

Does this build of MPC-HC contain any changes to the internal subtitle renderer?

There seems to be a bug with the official version when fullscreening on a 1920x1200 display, where bitmap subs are displayed 60 pixels too high (as if the video was top-bound).

[JanWillem32]

I've fixed quite a few things indeed on the highest level of the subtitle parts (and broken many parts in the process, as you can read in this thread). Currently, I've been able to reproduce two problems specific to the geometry of bitmapped subtitles:
-If I use WinKey+left or WinKey+right to position the player half-left or half-right on the screen with Windows 7, the bitmapped subtitle is compressed and shifted in a wrong way on screen (similar problem as you describe). This is a low-level geometry issue. I haven't changed those parts of the code yet.
-If two instances of bitmapped subtitles should be displayed (blu-ray has this capability), only one is presented. That's probably a problem on a somewhat higher level.

I've been trying to separate the parts responsible for bitmapped and vectorized input. Both need very different approaches to rendering. It's unfortunate that the two are currently mixed. The subtitle renderer really needs a team of developers again.
An issue with vectorized subtitles can be seen with my version of EVR Sync (I know it doesn't render correctly). The vectorized renderer tries to make a rectangle that will fit all subtitle parts of one frame in a single picture, using the CPU to perform the blending with 4-bit, 6-bit and 8-bit RGB samples (horrible color quality indeed). Sending each element and let the GPU do it's work on layering them onto the destination picture would be a lot better. It avoids using the big, empty texture parts. Using the vector renderer of DirectX 10/11 would also be nice.

[nand chan]

I've fixed quite a few things indeed on the highest level of the subtitle parts (and broken many parts in the process, as you can read in this thread). Currently, I've been able to reproduce two problems specific to the geometry of bitmapped subtitles:
-If I use WinKey+left or WinKey+right to position the player half-left or half-right on the screen with Windows 7, the bitmapped subtitle is compressed and shifted in a wrong way on screen (similar problem as you describe). This is a low-level geometry issue. I haven't changed those parts of the code yet.
-If two instances of bitmapped subtitles should be displayed (blu-ray has this capability), only one is presented. That's probably a problem on a somewhat higher level.

I've been trying to separate the parts responsible for bitmapped and vectorized input. Both need very different approaches to rendering. It's unfortunate that the two are currently mixed. The subtitle renderer really needs a team of developers again.
An issue with vectorized subtitles can be seen with my version of EVR Sync (I know it doesn't render correctly). The vectorized renderer tries to make a rectangle that will fit all subtitle parts of one frame in a single picture, using the CPU to perform the blending with 4-bit, 6-bit and 8-bit RGB samples (horrible color quality indeed). Sending each element and let the GPU do it's work on layering them onto the destination picture would be a lot better. It avoids using the big, empty texture parts. Using the vector renderer of DirectX 10/11 would also be nice.

Just tested it using your latest build,

Now, bitmaps are aligned /vertically/ but they're 60 pixels too far to the right, heh.

Edit: I spoke to soon, it was set to “touch window from outside” instead of “touch window from inside”. The same problem occurs, 60 pixels too high, when it's set correctly.

Also, some interesting observations:
- If setting the frame to “half size” or “double size”, it lines up perfectly, but at “normal size” it doesn't.

[JanWillem32]

Is the behavior the same with the shared renderer (VMR-9 r., EVR CP, DirectX 9 QT, DirectX 9 RM) and the other renderers? (The geometry parts are different.)

[nand chan]

Is the behavior the same with the shared renderer (VMR-9 r., EVR CP, DirectX 9 QT, DirectX 9 RM) and the other renderers? (The geometry parts are different.)

The behavior is the same (60 pixels too high) using VMR-9, EVR CP, EVR Sync, Haali Renderer as well as madVR using both your build 3682 and the vanilla 3696.

[Jtacdf]

Hmm. I don't have any problem on screen aligment with bitmap based pgs subtitles.

@nand chan
Have you check the aligment and margins setting in mpc-hc? Mine are a value of 20 for all setting and the position subtitle relative is a tick.

[nand chan]

Hmm. I don't have any problem on screen aligment with bitmap based pgs subtitles.

@nand chan
Have you check the aligment and margins setting in mpc-hc? Mine are a value of 20 for all setting and the position subtitle relative is a tick.

Changing the number seemingly has no effect, changing the screen alignment also seemingly has no effect (I'm guessing these are overridden by positioned ASS subs).

If “position subtitles relative to the video frame” is fully checked, subs appear 60 pixels too high.

If it is half-checked (filled out) or not checked, then subtitles appear too tall, but otherwise in the right position (they get stretched to the full 1920x1200 surface)

[Jtacdf]

What about the max texture resolution for subtitles? As far as I know, it will resize the subtitles to whatever chosen resolution on vanilla build.
Setting it to desktop on my monitor possess no problem for me, it has a aspect ratio of 16:9.
You have a monitor that has a aspect ratio of 16:10, might that be the issue here?

[nand chan]

What about the max texture resolution for subtitles? As far as I know, it will resize the subtitles to whatever chosen resolution on vanilla build.
Setting it to desktop on my monitor possess no problem for me, it has a aspect ratio of 16:9.
You have a monitor that has a aspect ratio of 16:10, might that be the issue here?

Same thing happens when rendering to 1920x1080, with or without round up to powers of two.

If I set the subtitle resolution to 1920x1080 and choose not to position subs relative to the video frame, I get a vertically stretched subtitle again, in all renderers.

I've mentioned in my first post that I'm using a 1920x1200 monitor, which has an aspect ratio of 8:5.

[Jtacdf]

8:5 is also called 16:10 or vice versa.

[JanWillem32]

I've edited the renderer settings menus. It was very long overdue this time, and I actually wanted to edit some more things. Because I'm pretty bad at editing these menus, please carefully check if things work. There weren't any big changes in the renderer this time.
New features in the renderer settings menus:
-Better descriptions of renderer features in the menus
-Using 8-bit RGB surfaces disables some of the more advanced renderer features.
-Using any of the 3 other surface types enables internal conversion to linear RGB.
-Added a basic chroma up-sampling fix for ATI hardware. This menu should gray out during playback when using video cards of other brands. Other than that, it doesn't have any automatic detection for interlaced, 4:4:4, 4:2:2 or 4:2:0 inputs. This item is intended as something temporary, no OSD messages are provided.
-Linear conversion on the video input can be disabled, to allow the user to insert it manually. (For example when combining color controls.) The chroma up-sampling fix can not be enabled together with this option (the menu should gray out properly).
-Added several different sizes as options for the color management's lookup table. As an effect, files have to be renamed to work with this revision. Replace "low" by "64", "med" by "128" and "high" by "256" to make previous files compatible. Select the correct size of the lookup table in the menu to prevent defaulting to 64³.

[Superb]

I wonder... What are the known issues of your build vs. the current trunk of MPC-HC? (i.e. did you introduce new bugs?)
I've read the first post, and the only thing I see is:
"Solve multi-threading issues." - originally created by your build? or the vanilla one?

[CruNcher]

@Jan i moved to Win7 now

Can all this be improved http://forum.doom9.org/showpost.php?p=1522467&postcount=18094 ?

the Vsync stuff seems to be a big problem with Aero (DWM) :(

Your build doesn't show this with EVR Custom as by default Vsync is off, but it has the same problematic with this 29.xxx sample in terms of flickering on EVR sync and Slideshow on EVR Custom (and when moving the window it updates slow without Aero and much faster with Aero) :(

This is the problem that started me off to test all this http://forum.doom9.org/showpost.php?p=1522460&postcount=5126 the sample is also included

Also non of the Floating point, Half Point, RGB Rendering stuff would work on SB all these options endup in a black screen.

[Hera]

There is something wrong with your GPU dude. Also V-Sync and Aero seems redundant.

Somewhat on-topic, does ATi/AMD GPU DXVA performance depend on core/shader/ram speeds or is it separate like PureVideo HD?

[Jtacdf]

@CruNcher
Most of the rendering settings works for me on sandy bridge. Are you using a nvidia gpu or intel igp?
Anyway, your sample seems to be a pal interlaced 25fps video. Might the flickering you see be the interlace line? It looks pretty smooth to me when hardware deinterlacing on my ati gpu is enabled.

@Hera
If you are just decoding video without any PP, then DXVA performance should not be affected by any core/shader/ram speeds of your gpu as it has a dedicated silicon.
However, if options in CCC video settings like advanced quality, deinterlacing, etc, are enabled, they will use shaders on your gpu.
The more shaders you have on your gpu, the more options you can use without affecting smooth playback.

@JanWillem32
With you adding ati video chroma upsampling fix as a rendering option, setting it to any 4:2:0 option, seems to be the similar as "special 4÷2÷0 to 4÷2÷2 intermediate cubic B-spline5 chroma up-sampling" shader?
With any 3 surface type enabling internal linear RGB output, it makes "#define LinearRGBOutput 1" redundant?
IMHO, you should have some documentation on your tester build so that users (like me) do not get confuse with all the rendering options.

[JanWillem32]

@Superb: I did indeed create a few bugs. While working on the VSync items, I broke several items/modes several times because of various reasons. The new resizers don't support rotation (flipping does work). The bars in the fullscreen windowed mode shrink the window size, instead of overlapping the window (not an issue in the exclusive mode). And of course, big renderer changes also imply new issues. This thread has grown to this size mostly because of all the bug reports and fixes.
The trunk build has its share of errors. It's mostly that the main Paint cycle of the renderer has poor performance and lacks a decent rendering queue. I've written a lot of new&borrowed code to fix those things.
The multi-threading issues were already there, and are very hard to solve.

@CruNcher: The internal VSync code is hard to correct. I've been editing it today again, and it's still problematic.
The default setting of all VSync options unticked simply enables the 4-frame queue of the presenter, with a device VSync setting of presenting a frame at least one refresh cycle. It works perfectly well for both windowed mode with desktop composition enabled and the exclusive mode, with a little bit of help in timing frames to refresh cycles in an ordered manner. The only problem is the windowed mode without desktop composition, as the device can't deal with the large distortion in the timing in this mode on its own.
I'll test your samples a bit more, but files are a bit demanding indeed. The 50 Hz interlaced PAL TV sample has broken time stamps on every frame and the opening and ending data slices are incomplete (I demuxed the file).
Even on my setup I can't get it to render at 50 Hz with the VSync functions enabled.
I wonder why the options for 10-, 16- and 32-bit surfaces won't gray out in your case if the GPU doesn't support it.

@Hera: The decoder is in a separate ASIC. Only the memory and base clocks are shared with the rest of the core, but that's not much of a problem. The bottleneck is always when the shadercore is activated for heavy tasks, such as deinterlacing.

@Jtacdf: I've simply integrated the 1-2-3 shaders with some optimizations and set the output to linearize RGB. The gamma adjustments for the subtitles and on output are automatic.
For a manual setup, disable the linearization step for the video input and set the custom pixel shaders. Enable linear RGB output in the shader that performs the Y'CbCr to RGB color conversion.
Documentation of the functions is indeed a bit hard to do with the renderer settings menu. It doesn't allow extra text to explain anything.

[CruNcher]

There is something wrong with your GPU dude. Also V-Sync and Aero seems redundant.

Somewhat on-topic, does ATi/AMD GPU DXVA performance depend on core/shader/ram speeds or is it separate like PureVideo HD?

Hmm maybe the Driver who knows but i certainly see these behaviors with MPC-HC in windowed mode with Aero and Vsync ON depending on the FPS of the Input Video with a 60 Hz Refresh rate when Moving the MPC-HC window while playing back this causes the whole move animation and refresh of the MPC-HC window to stutter on Aero (mouse actions are to late rendered latency becomes obvious), it doesn't happen with Jans Builds as Vsync is by default off
and about the Performance it depends how the resources are being used shaders dependency first comes into action when PP is applied either in Direct3D/Direct2D/DirectWrite/Warp/OpenGL/OpenCL/Cuda or Pixelshader(DirectCompute) form though then also memory becomes important as the data additionally created has to be transmitted (bandwidth) and then it depends if the transmit path is short (IGP) or its longer (Discrete) so in general many factors play a role in overall performance.

Williamete,Sandy Bridge, AMD APU, ION1/2 (also IGP solutions on mainboards but it depends on the chipset if it's directly connected or not) have the smallest transfer paths so that overhead is very small and should be especially preferred for example rendering Aero also the Performance of the Decoder should be better and create less CPU overhead then a Discrete path does (see nevcariels DXVA benchmark from Intels SB Decoder compared vs Nvidia on a Discrete Card and even vs the improved VP5) :)



@CruNcher
Most of the rendering settings works for me on sandy bridge. Are you using a nvidia gpu or intel igp?
Anyway, your sample seems to be a pal interlaced 25fps video. Might the flickering you see be the interlace line? It looks pretty smooth to me when hardware deinterlacing on my ati gpu is enabled.

Intel IGP: Core I5-2400 Intel HD2000




@CruNcher: The internal VSync code is hard to correct. I've been editing it today again, and it's still problematic.
The default setting of all VSync options unticked simply enables the 4-frame queue of the presenter, with a device VSync setting of presenting a frame at least one refresh cycle. It works perfectly well for both windowed mode with desktop composition enabled and the exclusive mode, with a little bit of help in timing frames to refresh cycles in an ordered manner. The only problem is the windowed mode without desktop composition, as the device can't deal with the large distortion in the timing in this mode on its own.
I'll test your samples a bit more, but files are a bit demanding indeed. The 50 Hz interlaced PAL TV sample has broken time stamps on every frame and the opening and ending data slices are incomplete (I demuxed the file).
Even on my setup I can't get it to render at 50 Hz with the VSync functions enabled.
I wonder why the options for 10-, 16- and 32-bit surfaces won't gray out in your case if the GPU doesn't support it.

Yes but the 50 hz sample (that one was to show a problem with lav splitter and microsofts DXVA2 decoder, that the internal MPC-HC splitter doesn't show (macroblocking)) was actually not really meant being problematic with this.
The Film sample sample.ts is what creates major problems here with Vsync and other samples Aero rendering problems with Vsync On i guess it's better if i try to visualize the issue (Evr Sync= Flickering, EVR Custom = Slideshow, System Renderer(EVR) = OK) in a Realtime Video i hope that's easier and not so demanding as it was on XP (my first try of doing high performance Desktop Recording DXVA 60 fps directly into H.264 on XP (the overhead from Process Explorer 0.5 ms was also problematic losing some frames) http://mirror05.x264.nl/CruNcher/pperf/) with DXVA1
Have to recheck but with your build it was actually grayed out i meant with the default trunk it was shown and when tried to be used ended up in a black screen.

I will try to encode the issue directly on Intels Encoder of from the Aero Desktop into H.264 :)

[Hera]

Ah, weird,
Radeon 4250 + anything but 8-bit output = blackscreen now - except for the graph - the graph works showing that Radeon 4250M is lagging with 16-bit ??

Will report more tomorrow.

[ForceX]

Ah, weird,
Radeon 4250 + anything but 8-bit output = blackscreen now - except for the graph - the graph works showing that Radeon 4250M is lagging with 16-bit ??

Will report more tomorrow.
You seem to need to have a pre-resize shader on for it to work. Use the default pass-through shader as a pre-resize shader.

[JanWillem32]

I noticed that a few days ago. The bilinear chroma up-samplers were set in the wrong spot in the renderer chain (those are the only ones that are single-pass).

[CruNcher]

@JanWillem32
I made a Quicksync & Aero powered Video of this EVR Sync & Custom issue with the sample.ts http://mirror05.x264.nl/CruNcher/mpc-hc/

[JanWillem32]

That's not even close to how badly the internal timing/VSync functions performed in some of my alpha builds.:D
There are a few factors that can cause problems in this case.
One factor is the color format. EVR CP is in your case accepting RGB32, EVR Sync is accepting YUY2.
Both color formats are pretty rare to find in actual video. Most videos are Y'CbCr 4:2:0, these two formats are not.
Common formats for progressive Y'CbCr 4:2:0 video are: YV12, I420/IYUV and NV12. For interlaced video only NV12 is commonly used.
To get surfaces from Y'CbCr 4:2:0 to Y'CbCr 4:2:2 (YUY2) or RGB X:4:4:4 (RGB32), a color conversion step before the mixer is required. That's bound to cost performance and quality compared to the direct input of a compatible format to the mixer. It's even worse if the source is interlaced.
I wonder what is forcing this conversion.
Other factors that count are the integrity of the file container or file streams (your other sample was pretty broken in this aspect), and the load on the renderer itself. The default settings with the trunk build are bad, and the renderer was in a bad state when I first started to work on it.

[JanWillem32]

I've added motion adaptive modes to the frame interpolation. The 3 filters are equally (very) heavy, just with different parameters, and should have better quality than the basic form.
I've also been tracing the exit sequences of various parts, and found multiple problems (mostly outside the renderer parts). It will take some time before those are fixed.
Lastly, I added some minor optimizations.

[Hera]

EDIT: On Radeon 4250M, performance is better than ION. Frame Interp is way too much processing it seems though.
EDIT: 8-bit locked as well

Can't switch from 8-bit integer surfaces on ION? Expected behavior?

Previous version, with the new menus, allows me to do this.

Found a way to force it - laggs like hell for some reason, seriously like hell. I would have probably had to hard reboot my netbook if I went with 32-bit ...

Last version that appears to work just fine with Output A32B32G32R32F and A16B16G16R16F: 1.5.3.3682
Next version gives a black screen with these and makes system almost completely stuck.
Current version gives picture and makes system almost completely stuck.

I am going to restart and see if that fixes the performance issues.

EDIT: Yeah, performance did go DERP DERP
EDIT: Why am I seeing V-Sync in the Statistics when I have V-Sync disabled?

[JanWillem32]

Too many immediate bugs in this build... I've scrapped it.

[CruNcher]

@jan this is to funny

http://forum.doom9.org/showthread.php?p=1523337#post1523337

see how i fixed the telecine issues on MPC-HC EVR Custom (with HD2000), bellow that :P

the sample is available here http://home.halden.net/mordor/evil_trees.7z

No go with Hardware Playback though tried virtually everything and Directvobsub causes DXVA2 to fail :(

[KoD]

Hi, I've just tried the r3698 x64 build, and it has a very odd behavior:

- EVR Sync mode does not show the video image, but only a white/gray surface, while the audio is playing
- EVR CP mode displays the video image properly only when using 8 bit surfaces, or any of the higher bit surfaces but with "Disable RGB gamma linearization" on, otherwise a gray video is shown instead of the video image, with audio playing normally, and subtitles being rendered on top of the gray video also correctly and on time; unfortunately, disabling the RGB gamma linearization for higher than 8 bit surfaces completely destroys the gray balance of the image, the image is washed out, so the high bit surface modes are actually unusable
- when using EVR CP, it's best to disable "VSync", otherwise playback is not smooth at all; "Alternative Sync" causes awful tearing; "Accurate sync" is the only option that gives smooth playback, but playback is smooth even when no VSync option is enabled at all (VSync is not forced in the Nvidia Control Panel either)
- not using D3D Full-screen mode causes small jerky spikes of the playback, but that's the case with the official MPC build as well

This build can only show the image correctly when using EVR CP with 8 bit surfaces, in D3D full-screen, and with VSync disabled (or AccurateVsync enabled). Any other mode is useless. :(

The resizing algo I'm using is the old bicubic one, so nothing special.

The official MPC build is less picky, and I'm actually running that one in EVR Sync mode (Sync video to display), in full-screen mode for best playback.

I'm using Win7 x64 OS running on a dual-core laptop (so, the CPU is not that powerful to hide any issue like it's the case with more powerful ones), and a 9600M GT GPU.

These builds really need more people to test them. ;)

[JanWillem32]

I revised many menu items to fix the latest set of bugs, and in the process I got rid of some useless ones. I rearranged the VSync, jitter and other functions around the standard present method for better performance. The present method for the frame interpolator is still incompatible with "Alternative VSync" and "Flush GPU before VSync". In my case it also requires D3D fullscreen exclusive mode, else frames are dropped (can be seen using the tearing test).

[Hera]

Well... on the positive side, you fixed the renderer settings.
It still fully kills ION performance with anything but 8-bit surfaces.

[CruNcher]

@jan

here are some hardware performance data :)



HD2000:

Windows 7 x64 Service Pack 1
Intel(R) HD Graphics Family

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

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

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

DXVA Surface VideoProcessor:
D3DFMT_R8G8B8: creating GPU texture failed
D3DFMT_A8R8G8B8: lossy (1-255)
D3DFMT_X8R8G8B8: lossy (1-255)
D3DFMT_A8B8G8R8: creating GPU texture failed
D3DFMT_X8B8G8R8: creating GPU texture failed
D3DFMT_A2R10G10B10: lossy (1-255)
D3DFMT_A2B10G10R10: lossy (1-255)
D3DFMT_A16B16G16R16: lossy (1-255)
D3DFMT_A16B16G16R16F: lossy (1-255)
D3DFMT_A32B32G32R32F: lossy (0-0)

D3D9 Surface speed test:
NV12: upload 277 fps, download 15 fps, trick download failed
YV12: upload 150 fps, download 19 fps, trick download failed
A8R8G8B8: upload 148 fps, download 7 fps, trick download failed

DXVA Surface speed test:
NV12: upload 310 fps, download 15 fps, trick download failed
YV12: CreateSurface failed
A8R8G8B8: CreateSurface failed

A8R8G8B8 Texture speed test:
default: upload 263 fps, download 147 fps
dynamic: upload 261 fps, download 10 fps, trick download 152 fps



9800 GT

Windows XP Service Pack 3
NVIDIA GeForce 9800 GT

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)

DXVA 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

DXVA 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)

D3D9 Surface speed test:
NV12: upload 440 fps, download 554 fps, trick download failed
YV12: upload 76 fps, download 17 fps, trick download failed
A8R8G8B8: upload 431 fps, download 262 fps, trick download failed

DXVA Surface speed test:
NV12: upload 442 fps, download 555 fps, trick download failed
YV12: upload 76 fps, download 17 fps, trick download failed
A8R8G8B8: upload 429 fps, download 261 fps, trick download failed

A8R8G8B8 Texture speed test:
default: upload 462 fps, download 414 fps
dynamic: upload 535 fps, download 9 fps, trick download 258 fps

460 GTX:

Windows XP Service Pack 3
NVIDIA GeForce GTX 460

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

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

DXVA 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: lossy (16-178)

DXVA 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)

D3D9 Surface speed test:
NV12: upload 687 fps, download 917 fps, trick download failed
YV12: upload 867 fps, download 21 fps, trick download failed
A8R8G8B8: upload 459 fps, download 366 fps, trick download failed

DXVA Surface speed test:
NV12: upload 688 fps, download 912 fps, trick download failed
YV12: upload 873 fps, download 21 fps, trick download failed
A8R8G8B8: upload 456 fps, download 370 fps, trick download failed

A8R8G8B8 Texture speed test:
default: upload 453 fps, download 526 fps
dynamic: upload 870 fps, download 9 fps, trick download 318 fps


also trying your build currently

[Hera]

Interesting is the difference between NV ION and Radeon 4250M:

Before the menu changes:
4250M: 16-bit OK, 32-bit NO GO
ION: 16-bit OK, 32-bit OK

After the menu changes:
4250M: 16-bit OK, 32-bit NO GO
ION: 16-bit NO GO, 32-bit KILL ME NOW

Also frame interpolator kills 4250M performance, causes severe ghosting (even of the Info Graph!), and makes things a bit too bright. I cannot compare on ION as only 8-bit and 10-bit seem to work ATM.

The ATI Up-Sampling Fix Options are editable for NV ION.
I think your NVIDIA detection system is broken.

[CruNcher]

@ Jan
This FFdshow Quicksync Decoder http://forum.doom9.org/showthread.php?t=162442 (done by a Intel Dev) fixes the DXVA2 EVR Custom issue http://mirror05.x264.nl/CruNcher/mpc-hc/ with my sample.ts on Quicksync :)

No Vsync no Exlusive mode just Aero and Quicksync :)

http://img706.imageshack.us/img706/8000/novsyncjustaeroquicksyn.png

[ikarad]

Where can I post bug for your test build?

[JanWillem32]

@Hera: Can you test the previous version on the ION with "gamma conversion of video RGB to linear RGB for floating point surfaces" set pre-resize, "gamma conversion of linear RGB to video RGB for floating point surfaces" set post-resize, and subtitles disabled?
The only change in the renderer that could cause a slowdown is that I've forced these two shader passes (plus one extra on the subtitle pass) for 10, 16 and 32-bit surfaces.
The frame interpolator is much too heavy for low-end video cards. Once it starts dropping frames, it only creates artifacts.
I just tested the detection system for the menu option, it correctly grays out during playback in my case. I can't gray the items out before the renderer is active.

@CruNcher: Does everything seem to be fixed by that decoder (such as the color format and timing)?

@ikarad: Here will be fine, as long as it's specific to what I've implemented. The usual bug reports should be posted on trac.

[ikarad]

@ikarad: Here will be fine, as long as it's specific to what I've implemented. The usual bug reports should be posted on trac.

Thanks
a bug with subrenderer in mpc-hc is specific at your version or not?

[Hera]

I only see an option to "Disable RGB Gamma Linearization" -
Checking that does allow me to use "16-bit Floating Point Surfaces" without any obvious frame dropping.

Disabling subtitles does nothing.

[CruNcher]

@Hera: Can you test the previous version on the ION with "gamma conversion of video RGB to linear RGB for floating point surfaces" set pre-resize, "gamma conversion of linear RGB to video RGB for floating point surfaces" set post-resize, and subtitles disabled?
The only change in the renderer that could cause a slowdown is that I've forced these two shader passes (plus one extra on the subtitle pass) for 10, 16 and 32-bit surfaces.
The frame interpolator is much too heavy for low-end video cards. Once it starts dropping frames, it only creates artifacts.
I just tested the detection system for the menu option, it correctly grays out during playback in my case. I can't gray the items out before the renderer is active.

@CruNcher: Does everything seem to be fixed by that decoder (such as the color format and timing)?

@ikarad: Here will be fine, as long as it's specific to what I've implemented. The usual bug reports should be posted on trac.

Nope the timing for that evil_tree sample is still wrong (the timing for my sample.ts is perfect 23.976 like in the screenshot above) compared to Software Playback.
The mixer still shows RGB32 as output and input is NV12 (default) from that FFDshow Quicksync Decoder.

PS: After looking @ the bugs i looked more into efficiency and i almost fall of my chair http://forum.doom9.org/showthread.php?p=1523906#post1523906 ;) (the current overhead is huge)

[JanWillem32]

@ikarad: You're referring to the failure in the subtitle renderer to combine multiple bitmapped subtitles? I know what's causing it, but it's a bit hard to edit.

The host for the video and subtitle renderers is ISubPic (called by the graph builder). It has subtitle delegates for DirectX 7, DirectX 9 and VSfilter. There's no way I'm going to work on all three of those. I already have permission to remove all internal DirectX 7 items. I'll remove VSfilter from my branch completely once I start working on the subtitle renderer, it should never had a share in ISubPic in the first place. That part of VSfilter is always compiled into MPC-HC because of that, but nothing in the internal code uses it. VSfilter can be preserved by a full split in projects.
Once I only have to edit 2 parts of one subtitle renderer (vector and bitmapped graphics), I'll also break compatibility with all video renderers (again), except the shared renderer and maybe EVR Sync (once I've merged code to it). I'm not going to just edit the subtitle renderer without changing its interfaces, the fundamental flaws are just too big for that.
For reference on what's going wrong, see EVR sync with vector subtitles in my builds. If a subtitle of one line is to be rendered, the subtitle renderer exports a texture with that one line, and hardly any translucent parts around it. If a subtitle of one line in the top and one line in the bottom of the screen is to be displayed, it exports one picture with both lines and a lot of translucent filler in between both lines. The subtitle renderer can't export multiple textures to the video renderer.
If I compare that to the stats screen, it's a different case. When the video window is initialized, the font for the stats screen is rasterized with the correct size, and a texture+geometry set for each glyph are exported to the video card. The stats screen itself generates a sting of text, which is converted to vertex data linked to the set of textures. Only the vertex data is sent to the video card, to order it to blend up to a few hundred textures to an output surface during the rendering of the video. The vertex data is usually under a KB, no additional surfaces or textures are generated. The subtitle renderer regenerates one A8R8G8B8 texture with every frame, so in the case of a 1920×1080 output, it can send a 1920×1080×32÷8÷1024÷1024 = 7.91015625 MB texture with every input frame (it skips rendering if there's no subtitle to display). On top of that, the subtitle renderer also only uses a single-threaded approach to rendering glyphs and only uses the CPU in a pretty dumb way to paint the glyphs onto the subtitle textures.

I know what code I have to edit to get things working properly. However, that will be a major change to the code, and needs a lot of testing. I'm okay with editing superficial parts of the subtitle rendering system, like I've done for a while already. I won't be editing more fundamental parts while "internal renderer fixes" isn't in the trunk.

@Hera: I meant setting two pixel shaders. I suspect the ION can't handle the two or three extra rendering stages for linearizing the gamma internally.

@CruNcher: I've demuxed that evil_tree sample, and the video track is reported as completely broken when muxing it again to MKV (nothing reported during demuxing this time). A mixer input of NV12 is perfectly all right with interlaced Y'CbCr 4:2:0 video like this. I assume the stats screen reports "Mixer format: Input NV12, Output X8R8G8B8"? I thought I removed the setting to display alternative names for formats like "RGB32" some time ago.

[nevcairiel]

@CruNcher: I've demuxed that evil_tree sample, and the video track is reported as completely broken when muxing it again to MKV (nothing reported during demuxing this time).

mkvmerge has some issues muxing telecined MPEG content, which may account for the breakage.

[JanWillem32]

Ah, I'll try to detect and remove the pulldown to test. Thanks for the hint. If it's really a problem with pulldown, it's a mixer issue.

[ikarad]

@ikarad: You're referring to the failure in the subtitle renderer to combine multiple bitmapped subtitles? I know what's causing it, but it's a bit hard to edit.
.
I don't know if it's the same problem but I speak about this problem
https://sourceforge.net/apps/trac/mpc-hc/ticket/48#comment:20

[JanWillem32]

That's indeed the one I'm referring to.

In regard to the evil trees sample, I've removed the pulldown, the flags were set rather wrong. The damaged parts of the stream are now clearly visible when enforcing a strict mode. That explains why I kept getting pauses during playback with all renderers I tried. The original stream was 24/1.001 fps progressive as 48/1.001 fps weave interlaced.

[Xaurus]

In regard to the evil trees sample, I've removed the pulldown, the flags were set rather wrong. The damaged parts of the stream are now clearly visible when enforcing a strict mode: http://www.mediafire.com/?5y2wtp5j0pxehu9 . That explains why I kept getting pauses during playback with all renderers I tried. The original stream was 24/1.001 fps progressive as 48/1.001 fps weave interlaced.

JanWillem,

What program did you use to remove the pulldown of the evil_tree sample?
I would like to convert it to progressive and be able to watch it without problems but I've yet to find (free) suitable software.

[JanWillem32]

That's easy: pulldown.exe.
The command line syntax to re-order the internal fields to 48/1.001 fps weave interlaced is:pulldown.exe input.m2v output.m2v -norff -nopulldown -aspect_ratio 16:9 -drop_frame false -prog_frames p -prog_seq i -tff odd -framerate 23.976This will use a non-strict mode, so the broken parts visible in the version I uploaded will not be so visible, it will simply skip fields instead. Using pulldown.exe doesn't convert the video data itself, so the conversion is lossless (and really fast). Re-encoding the video to a true progressive will be slow and lossy. I don't recommend it, as the damage to the split chroma planes in 4:2:0 video will be quite severe and the damaged parts may may pop up as artifacts during the encoding process.
After using pulldown.exe, I used mkvmerge to combine the tracks again. For the video track, a manual override to 24000/1001 FPS is recommended (mkv has better internal timing than a raw .m2v). For the audio track, I correctly set the delay reported during demuxing. For the small sample it was +5 ms, I believe. The new mkv video played very well at 24/1.001 fps (weave deinterlacing was automatically used by the mixer).
If you need any help with the command line, demuxing or muxing, I'll gladly help.

[Xaurus]

JanWillem,

Thanks alot for your information. What tools do you use to demux a m2ts or ts file? Do you know if tsMuxer leaves the quality untouched?
The reason I ask is because the original files are in .ts

I have downloaded mkvtoolnix and it seems very nice, but alas it doesn't support ts files so this will be used when packing it together again.

As for pulldown.exe, I found 0.99d, do you know if this is the latest version?

Thanks!

[JanWillem32]

There are several tools you can use for a standard demux, tsMuxer or eac3to will work fine. A demux doesn't alter any video data, so you don't really have to worry about that. I also used pulldown.exe v0.99d.

[janos666]

I have a problem with 3709: I can't use your shader to convert the full range RGB to limited range RGB for display output.
I guess it has something to do with the new built-in linearization and gamma weighting steps.

Everything looks fine with zero custom shaders and the optimal renderer settings preset.
1: If I tick the "Disable RGB Gamma Linearization" then it actually looks linearized
2: If I add the level conversion shader the grayscale gets horrible: obviously wrong gradation and oviously wrong levels
- If I do both then it's just worse.

I tried different combinations (ticked and unticked Disable RGB Gamma Linearization combined with custom linearization and/or gamma weighting shaders) but I couldn't find any working set, nor I could fully figure out the nature of the problem.
But I guess you forgot to disable a gamma processing shader with the "Disable RGB Gamma Linearization" and you didn't consider level conversions when you placed these shaders in the chain.


I think you should include a level conversion shader in the menu and place the conversion at an appropriate place to make it work until it's sorted out.

[janos666]

Ok, problem isolated: It's in you latest pixel shader pack. The limited->full and full->limited shaders are both limited->full.

Hovewer, it still needs some attention. If I want level conversion then I have to disable the built-in linearization step, apply the chroma resizer (ATI fix) as pre-resize and the level conversion as post-resize shaders and add a gamma linearization shader at the end because the gamma weighting step is hard-locked at the very end of the chain.

One solution would be to write a new level conversion shader which works on the linearized RGB data and the other is to place the current level conversion shader at the very end of the chain and place a trigger in the options to activate it.

[JanWillem32]

Don't worry, I've been planning to add the level conversion shader code to the final pass for a while already. When compressing levels with a post-resize shader, the subtitles, OSD and stats screen won't be converted. On top of that, I've adjusted the random dither to always expect linear RGB input for its noise/edge detection, so any level changes should not be included with that.
The basic layout for the renderer;
8-bit mode: mixer output (obligated), pre-resize shaders, resizing/positioning (obligated), post-resize pixel shaders, subtitle blending, stats screen blending, OSD blending, present (obligated).
10-, 16-, or 32-bit mode: mixer output (obligated), chroma fix + gamma linearization, pre-resize shaders, resizing/positioning (obligated), post-resize pixel shaders, linear gamma subtitle blending, stats screen blending, OSD blending, gamma de-linearization (obligated) + color management + dithering, present (obligated).

I'm also trying to implement a proper way to eliminate resizing/positioning if it's not required. It's a bit of a waste if you're watching a 1080p video with 1:1 pixel mapping to the screen. The resizing/positioning step does properly disable the resizer pixel shader to only use nearest neighbor in that case. There are also special cases for skipping one of two passes when a two-pass resizer is used with only horizontal or vertical resizing.

[G_M_C]

JanWillem, sorry if this question hes been put before;

You've adapted the renderer to be able to output 10bit. Do you builds also suport 10 bit input, straight to output ?

[Qaq]

Jan, did you test your builds under XP?
I' stick with XP last few weeks and can't get normal playback since 3329. Just tried 3709 SSE. No matter if I reset renderer settings to default or optimal, its only shows black screen. Thats too sad cause I use XP often and want to follow the development. I'm an ATI (5450) user.

[JanWillem32]

@G_M_C: Within D3D there are color formats for Y'CbCr and RGB, with various precision and ordering. In reality these all resolve to some device buffer format with parameters set for the device so it can convert the buffer to 32-bit floating point values when sampling from that buffer. The RGB types are usually pretty much the same as the buffer form, and support for over a hundred different configurations for precision and ordering is very common.
The Y'CbCr types are more difficult. Because of chroma down-sampling, the resolution of the Y' channel isn't the same as those for Cb and Cr. The driver simply can't assign a buffer in the same way as for RGB. There's also the issue of color conversion. For each Y'CbCr texture, the video card's driver has to provide methods to convert it to RGB.
Therefore the support for Y'CbCr formats is very limited, there's only NV12 for 4:2:0, YUY2 for 4:2:2 and UYVY for 4:2:2.
Nvidia video cards additionally support YV12 and I420/IYUV for 4:2:0 progressive video. Older Intel video cards are known to not support any 4:2:0 formats. This can all be seen using DXVA Checker.
These formats are all 8-bit, and I don't see driver support coming for any other formats anytime soon.

For VMR-9, the mixer has a few emulation options for supporting some 8-bit Y'CbCr types not supported by the device driver, this is not the case for EVR.
Both mixers will happily skip some internal conversions if the input format is the same as the output format (X8R8G8B8, A2R10G10B10, A16B16G16R16F or A32B32G32R32F). Conversion from one RGB format to another by the mixer alone will often fail, though.
10-bit or better input from RGB surface types isn't much of a problem.
10-bit or better input from Y'CbCr surface types isn't happening with these mixers with the current video card drivers.

It's possible to create a custom mixer to allocate RGB surfaces and write raw Y'CbCr data on it. A custom mixer has to handle all Y'CbCr surface conversions by itself, instead of letting the video card driver do it. That does allow other formats to be used. Examples of custom mixers can be found in Haali Renderer (YUY2 and RGB32 input) and MadVR (several modes).

@Qaq: I don't have a license for Windows XP for either of my computers. Are you sure it's since 3329? I can't even remember what I exactly changed after that one, it's so long ago.
Do you get any warnings or errors (also look at the system logs)? Does it happen in both windowed and exclusive mode? What can you see in the filters section? Do you get any audio or subtitles? Can you force a screen to render by activating the stats screen and pause/unpause? Does deleting all settings in the registry and external .INI help?
Do others have this specific problem?
We might need a debug build or session to solve this problem.

[janos666]

10-bit or better input from Y'CbCr surface types isn't happening with these mixers with the current video card drivers

I remember that mixer output is strictly RGB now because Cb and Cr levels were incorrect with YCC type mixer outputs.
Was the renderer in that particular test builds set to ask more than 8-bit YCC input from the mixer?

If it could also be a VGA driver and not MS Windows EVR related bug and bitdepths also played a role then may be we should check it again if a proper 8-bit YCC output is possible from the mixer now. (It was a relatively long time ago...)

[JanWillem32]

I've tested some of the Y'CbCr types as output quite some time ago, as expected the mixers won't work with those as output. It would be rather wrong to make the mixer use those anyway. The bit depth and reading/writing speeds of those types is pathetic.
The EVR "16-235" item was removed for two reasons: it compressed RGB levels to [16, 235] after the mixer color conversion stage, instead of trying to create something similar to Y'CbCr [16, 235], [16, 240], [16, 240], and the internal rendering stages are for full range RGB or R'G'B' (gamma requirements vary from type to type). The internal workings of the mixers are a bit silly, the only way to access the values below 16 and above 235 or 240 (for xvYCC for example) is by using floating-point surfaces. The values are then written beyond the regular [0, 1] floating point intervals.

[Hera]

With bad-peforming builds, using 8-bit surfaces,
1. Pre-Resize Denoise = Bad Performance just like 16-bit floating point surfaces
2. Post-Resize Sharpen Complex 2 = Bad performance when window is maximized - but not when just resized by dragging corner.

Shaders also lagg like hell on 1.5.3.3682 (build which has great HFP and FFP performance)

[G_M_C]

@G_M_C: Within D3D there are color formats for Y'CbCr and RGB, with various precision and ordering. In reality these all resolve to some device buffer format with parameters set for the device so it can convert the buffer to 32-bit floating point values when sampling from that buffer. The RGB types are usually pretty much the same as the buffer form, and support for over a hundred different configurations for precision and ordering is very common.
The Y'CbCr types are more difficult. Because of chroma down-sampling, the resolution of the Y' channel isn't the same as those for Cb and Cr. The driver simply can't assign a buffer in the same way as for RGB. There's also the issue of color conversion. For each Y'CbCr texture, the video card's driver has to provide methods to convert it to RGB.
Therefore the support for Y'CbCr formats is very limited, there's only NV12 for 4:2:0, YUY2 for 4:2:2 and UYVY for 4:2:2.
Nvidia video cards additionally support YV12 and I420/IYUV for 4:2:0 progressive video. Older Intel video cards are known to not support any 4:2:0 formats. This can all be seen using DXVA Checker.
These formats are all 8-bit, and I don't see driver support coming for any other formats anytime soon.

For VMR-9, the mixer has a few emulation options for supporting some 8-bit Y'CbCr types not supported by the device driver, this is not the case for EVR.
Both mixers will happily skip some internal conversions if the input format is the same as the output format (X8R8G8B8, A2R10G10B10, A16B16G16R16F or A32B32G32R32F). Conversion from one RGB format to another by the mixer alone will often fail, though.
10-bit or better input from RGB surface types isn't much of a problem.
10-bit or better input from Y'CbCr surface types isn't happening with these mixers with the current video card drivers.

It's possible to create a custom mixer to allocate RGB surfaces and write raw Y'CbCr data on it. A custom mixer has to handle all Y'CbCr surface conversions by itself, instead of letting the video card driver do it. That does allow other formats to be used. Examples of custom mixers can be found in Haali Renderer (YUY2 and RGB32 input) and MadVR (several modes).
[...]

Thanx for the in-depth answer. It clarifies things for me. To make sure though we understand each other: My reason for asking this question was much simpler.

Atm many decoders offer higher than 8-bit output. CoreAVC has released it's new version that does it too, LAV and ffdshow being others. Also x264 is available in higher than 8 bit versions, preparing to extent this to 4:4:4 in the future. And because of this 10-bit encoded video is starting to appear (Anime-type movies are named).

So an ability to recognize and accept higher than 8 bit input, and rendering that input without loss of quality (or as less loss of quality as possible), to me personally, seems something important for the near future.

And that is why / where my question came from :)

[pirlouy]

JFYI, I tested one of your builds today, at work: deviated from revision 3709; x86 SSE2.

EVR Custom** and WMR9** cause a crash at startup, when launching a file.
I don't know if it's linked but I have a Intel Gpu from motherboard (don't remember the version), and EVR Custom** and WMR9** cause a crash at startup, when launching a file.

Sorry, maybe it's useless for you, but it's just in case you try to improve the stability...

[JanWillem32]

@Hera: If a single extra shader pass produces that kind of a problem, there's simply not much processing headroom left. Those two shaders are pretty heavy though. The three passes I added are more like the "BT.601 -> BT.709" shader in terms of instruction and sampling count.

@G_M_C: I've been wanting to replace the mixers with a custom one for a while already, to overcome these kinds of problems, but that's pretty hard if you know very little about DirectShow programming.

@pirlouy: I actually have very little information about the processing capabilities of older video cards and previous generations of IGP types. I think it's hardware vertex processing that's the culprit here, but I can't simply assume that. I'll try to look for a tool that can check a video card's DirectX 9 caps so it can be tested, else I'll write something for it myself.

[pirlouy]

No problem.
But it's just in case it's meant to replace the current EVR Custom renderer. It will have to work with these old IGP (not that much old, since there's a Core 2 processor), so there should be a (default ?) option for these cards. Of course, it's just for debug, I won't watch a movie with this computer...

[Traps]

So where is it possible to download latest nightly builds? The ones at XvidVideo.ru are more than 3 weeks old and the ones at xhmikosr.1f0.de aren't any newer.

[JanWillem32]

@pirlouy: The wikipedia page on the GMA series notes that hardware vertex processing is only really available with recent models. I really didn't know that, but I assume normal DirectX 10 functionality from devices far too easily, anyway.
@Traps: Those links on the first page of this thread are the only ones I actually manage. Others will choose different times to release builds. The latest alpha revision is 3714, by the way.

[Snarko]

Hello, thanks for the these builds.

I was wondering if it would be possible to dejudder 24p to 60hz in the manner suggested by scharfis_brain here: http://forum.doom9.org/showthread.php?p=946699#post946699. Instead of interpolating frames, it uses a specific field pattern to remove judder of 24p material when played back on 60hz screens. While I can use it in avisynth, I don't have the horsepower to play back 1080p that way. If it could be offloaded to the GPU like the frame interpolator is, it should be no problem, as it should be less calculation heavy than frame interpolation, and my video card can handle the basic form of that.

Is this doable? Any interest in incorporating it?

Thanks again.

[JanWillem32]

I can try, but previous attempts to interpolate frames with only a bilinear filter looked awful. It will probably need some work. (The current adaptive frame interpolators do use a bilinear filter, but only on the pixels where no movement was detected.)

[Hera]

So
32f surfaces + 1080p animated subtitles + old build == 16f + simple subs + trunk << 8bit + denoise OR shaper + No Subtitles == 16f surfaces + No Subtitles (new builds) < 32f(new builds)
? Or something similar?

[bledd]

Hey guys,

Any idea why the xvidvideo.ru doesn't seem to be getting updated any more?

All your hard efforts are greatly appreciated

[CruNcher]

@jan

http://forum.doom9.org/showthread.php?p=1525288#post1525288 :D

[Hera]

Same behavior with NV 6600 + XP + EVR + 16F - newer builds offer worse performance.

Internal Filters still do not work with Haali Renderer.... O.o

[JanWillem32]

@CruNcher: I'm not much of a GUI programmer. I've tried to add a few extra buttons to the shared OSD+exclusive mode seek bar item, but I failed at that. I would indeed like some improvement for the exclusive mode controls. However, importing a different GUI for it would mean losing compatibility with the current OSD. I don't know if I can add something to intercept the messages that are sent to the OSD, to display in the new GUI. I can guarantee that vanilla EVR and VMR-9 (windowed) won't have compatibility for a more complex system, these two can only import bitmaps to overlay over the video.

@Hera: I've taken some time to think about it, and came to a conclusion.
In the past I've allowed many configurations, and left all quality settings open for the 8-bit mode. Likewise, didn't force any anything extra for the 10-, 16- and 32-bit modes. I changed that.
The 8-bit mode doesn't allow color management, dithering and frame interpolation anymore. Those are heavy filters that don't belong in a rendering chain set up for compatibility with low-end and older systems.
The 10-, 16- and 32-bit modes allow the extra filters to be enabled. I've set these up for quality, forcing gamma correction to prevent darkening artifacts by filter passes in the rendering chain. The previous default of doing nothing with the precision these surfaces offer would be a waste.
I'm perfectly fine how it is now. The 8-bit mode has compatibility for low-end and older systems, the 10-, 16- and 32-bit modes are for quality, which requires both more compatibility and processing power from the system.
I've said before, that I wouldn't edit the internal codecs anymore, as people are busy importing new revisions of codecs and such to the main branch. (Without much progress for a while, I'll ask for an update on this when someone is around in the MPC-HC IRC channel.) Currently both my builds and the trunk build won't work properly with Haali renderer, as both serve the wrong color format. It's less visible in the trunk build, as it can serve YUY2, but that's still the wrong format.

[Hera]

So without using dithering || frame interpolation || color management, 16f offers no advantages?
I was informed without 16f/32f gradients are not as smooth (in situations where source is not at fault).

Hopefully Haali renderer will get worked on due to CoreAVC.
:)

EDIT: How come with Haali Renderer the subtitles seem video size resolution and not screen size resolution?

[JanWillem32]

The 10-, 16- and 32-bit types will improve the input and output quality of all filter stages, from the mixer, to the resizer, to the ditherer or to any other stage. It does require proper usage of the filters of course. Dithering level 31 can be rather unsightly, for instance.
I've simply made the 10-, 16- and 32-bit types a bit heavier by forcing a common gamma linearization filter on it.

I don't know what exact settings the Haali renderer passes to the subtitle renderer by default, including the setting for subtitle texture size. (I do know that Haali renderer never changes the default 25 fps setting for the subtitle renderer, though.)
https://sourceforge.net/apps/trac/mpc-hc/browser/trunk/src/filters/renderer/VideoRenderers/DXRAllocatorPresenter.cpp
In line 90 is the subtitle renderer's texture size setting for the Haali renderer. The "desktop" size setting for the subtitle renderer's settings menu should work properly if "m_ScreenSize" is properly set.

[Snarko]

re: scharfis_brain's dejudder script:

As I understand it, the method does not rely on frame interpolation proper at all. It just plays frames back at a pattern so that each frame repeats evenly like so: AAxBBCCxDDEExFFGGx, with each x being a blend of its adjacent frames. I'm not sure if it's something that even can be done at the renderer level, but trying it on 720x480 video (what my CPU can do in real-time) in avisynth via ffdshow generates judder-free playback at 60hz from 24hz material. His post gives the script.

[JanWillem32]

The "x" frames are blended, so these require a method. There's quite a variety of interpolation methods, a .5 previous and .5 next frame blend would be a linear interpolation. A cubic b-spline would be: 1/48, 23/48, 23/48, 1/48. A Mitchell-Netravali cubic would be: -5/144, 77/144, 77/144, -5/144. A Catmull-Rom spline would be: -1/16, 9/16, 9/16, -1/16. (I've simply copied these from the documentation I've written.) There are lots of other methods as well, of course. The problem with this scheduling method is that the center point in between two frames is precisely the point of least certainty. That means that it's the most likely of producing artifacts (which are very visible with just a linear blend).
I placed the current frame interpolator in the end of the end of the renderer chain, just before the final pass (gamma correction, color management, dithering) and the tearing test. It operates at window size. It never presents any input frames directly, all frames are interpolated using the timing of the video fps to the display refresh rate ratio. (I have a 2048×1536 80 Hz CRT, the adaptive frame interpolator is a really expensive filter in my case. For 1080i/30 video even 3D clocks are insufficient with my regular filter chain.) Even with the method you describe, it won't be a cheap filter. The amount of operations and filters in the chain are only slightly less than the "basic" method I implemented. It still requires 60 fully renderered frames per second, ordered, timed and presented in the rendering queue (there's no way this will be compatible with alternative VSync or GPU flushing). I'll have to try, test and try again, just as usual, to get a proper filter out of it.

[Snarko]

Ah yes, I was glossing over the import of the frame blending.

The benefits to me seem to be: any artifacting should occur only on that 1 blended frame, and it plays back at effectively the film frame rate (no "soap opera" effect) (of course this is no benefit if that's precisely the effect you're looking for).

Anyway, thanks for any work you do or don't do on it. Just the gamma correction, color management, dithering and various resize methods is already a big plus and much appreciated.

[mindbomb]

hey, idk if no one noticed because you guys all use direct 3d fullscreen mode, but the seekbar overlay causes unecessary resizing of the picture.

[TheElix]

The benefits to me seem to be: any artifacting should occur only on that 1 blended frame, and it plays back at effectively the film frame rate (no "soap opera" effect) (of course this is no benefit if that's precisely the effect you're looking for).Yes, I'd love to see that.

[CruNcher]

Ehh did you see that JAN :)
http://msdn.microsoft.com/en-us/library/hh404562%28v=VS.85%29.aspx#process_video_resources_with_shaders

Also here you can see how i would wish MPC-HC to look like in the future UI wise :)

http://forum.doom9.org/showthread.php?p=1526274#post1526274

you can say that the Potplayer Devs might borrow a lot but their integration work is awesome also their Skin engine (XML based) is second to none (though i wonder if they borrowed that somewhere too ;) ) :)

[JanWillem32]

The Direct3D 11.1 features you are pointing at are just resource binding functions, they just produce a COM pointer. Functions like that have been around for a while. The title above it sounds juicier than the functions, indeed.
I'd love to be a bit more skilled with GUI items, so I can add some improvements. The "Renderer Settings" menu could definitely use a better menu window (with explanations of all functions).
I also borrow a lot of code. There are code samples for a lot of functions all over the Internet. Of course, a lot of it needs careful evaluation for flaws and optimization.

[janos666]

I've tested some of the Y'CbCr types as output quite some time ago, as expected the mixers won't work with those as output.

Do you think that anything changed in the public Windows 8 developer preview build (regarding EVR)? (I am not even sure if anybody reported these bugs to MS. :p)
I think I volunteer to check it out at the weekend. Do you still have those test builds you used? (I don't have MSVC'10 on my PC right now to create them for myself. But I can install it if you deleted them already.)

[JanWillem32]

I only keep a changelog and up to four published revisions. Using the EVR mixer isn't an ideal situation. It's a black box with a link to the video card's drivers. When using some of the filters implemented in there, any other format than X8R8G8B8 is known to fail. Luckily the two basic types (color converter and deinterlacers) are known to work properly with all current drivers on several types of RGB surfaces.

[nand chan]

Any plans on adding additional audio renderers?
I'm currently using ReClock in pass-through mode (all audio / framerate processing is disabled), but it fails to connect to WASAPI exclusive mode for 24 bit audio.

Native bit-perfect support for WASAPI exclusive or ASIO would be a great thing to add to MPC-HC, so we don't have to spend half an hour making sure ReClock doesn't mess up our streams just so we can use WASAPI/ASIO.

[Qaq]

I'm currently using ReClock in pass-through mode (all audio / framerate processing is disabled), but it fails to connect to WASAPI exclusive mode for 24 bit audio.
I doubt it's ReClock's fault. Try the same format with other app (i.e. foobar2k) and you'll see.
24 padded to 32 should work with HDMI. My soundcard accept any format from ReClock. If XP's HDMI driver messes channels on my PC, it messes with Foobar2k/KS too, not only with ReClock/KS.
ReClock is not perfect, but has too much useful features, so it's hard to beat him.

[nand chan]

I doubt it's ReClock's fault. Try the same format with other app (i.e. foobar2k) and you'll see.
24 padded to 32 should work with HDMI. My soundcard accept any format from ReClock. If XP's HDMI driver messes channels on my PC, it messes with Foobar2k/KS too, not only with ReClock/KS.
ReClock is not perfect, but has too much useful features, so it's hard to beat him.

Works fine in foobar2000.

Either way, I solved it - seems I needed to pad to 32 bit. Apparently foobar2000 does this automatically. The more you know!

(I don't use HDMI either, that's just silly. I use S/PDIF over RCA like a normal person)

[JanWillem32]

I've actually worked on the SoundTouch parts and the MPC-HC audio renderer. It's a bit difficult to work with, though. SoundTouch will only work on 1- or 2-channel audio (it's the only part that can resample at the moment). The MPC-HC audio renderer had a few problems with both WASAPI and DirectSound modes. I believe I included the fixes in the experimental dfr3724. (Note: WASAPI is only working for Vista and newer.) In my case WASAPI only works with 16-bit input audio (multichannel 7.1 works, though), and it won't connect to my software DSP, so I just use waveout. Connections to HDMI have never been a problem in my case, by the way. I do prefer the software DSP to get rid of the on and off switching between tracks and for up-mixing.

[Qaq]

nand chan, yes, 24 in foo is "24 padded to 32" actually.

[cca]

Seems the latest build is much improved since my last attempt to use this experimental branch, but I still cannot play interlaced material (DVDs), the video is messed up. Works fine for everything else.

[JanWillem32]

Can you give more information about the problem? Such as: how the artifacts look, settings, codecs, other filters, DVD menus, anything else that might influence this.
I know that the internal MPEG2 codec has a problem playing back anything if the DXVA MPEG2 codec type is enabled, even if left unused (DXVA detection problem).
Do you have a sample? It might be be one of the mixer settings.

[JanWillem32]

I've added a background color button on the Miscellaneous page, it's a basic menu of the selected color and 16 presets. (Ideas for using that color palette are very welcome.)
The brightness of the color output can be different from the sample because of the gamma setting, color controls or color management.
For old video cards without hardware vertex processing, software processing was added.
Minor SIMD efficiency fixes were added for the VSync code (not included in the SSE version).
I've re-written parts of the subtitle interfaces for better efficiency.
I've optimized internal data ordering, resulting in smaller builds.
I've copied the EVR CP mixer statistics methods to the renderer code, making the VMR-9 stats screen more informative.
LCMS was updated recently. So far I've seen changes to the white point adapt state item (only active with absolute colorimetric intent).
There are no real new functions in this revision, so it's mostly maintenance. I'm looking into integrating some shaders, multi-threading the color management function and making the refresh rate changer somewhat more compatible with the renderer.

[kerimcem]

Can you give more information about the problem? Such as: how the artifacts look, settings, codecs, other filters, DVD menus, anything else that might influence this.
I know that the internal MPEG2 codec has a problem playing back anything if the DXVA MPEG2 codec type is enabled, even if left unused (DXVA detection problem).
Do you have a sample? It might be be one of the mixer settings.

yes problem mpeg2 video vob files mpc crash closing mpc ..

[cca]

Can you give more information about the problem? Such as: how the artifacts look, settings, codecs, other filters, DVD menus, anything else that might influence this.
I know that the internal MPEG2 codec has a problem playing back anything if the DXVA MPEG2 codec type is enabled, even if left unused (DXVA detection problem).
Do you have a sample? It might be be one of the mixer settings.

Can't really provide a sample, my DVD ripping skills are rusty as hell. It's a DVD from Star Trek: Voyager Region 2 PAL, but the same happens with my other DVDs.
The problem is not MPC's codecs, I don't use them anyway, I use ffdshow.
The interesting part is that even if I uncheck the "Set interlaced flag in output media type" in ffdshow, so that the stream appears progressive, it still doesn't play properly.

The artifacts appear on the form of wrong aspect ratio, the image extended vertically and it's bottom part outside the screen. It's almost like the resizer gets confused and displays only part of the actual image, the top 2/3s of the frame.

[JanWillem32]

Is it both VMR-9 and EVR CP affected? Do the resizing settings work as they should? Can you try disabling "View", "Video Frame", "Keep Aspect Ratio"? I don't think that will really help (once the mixer starts messing up anamorphic detection, the renderer can't do a proper job anymore). Anamorphic video problems are unfortunately common. Both EVR and VMR mixers require double-checking for it, else mirroring and wrong metrics with some types of formats occur.
I'll try to find a sample. My current samples all seem to work fine with both renderers.

[janos666]

I can confirm that anamorphic resolutions aren't handled correctly by EVR-CP. 1440x1080 remains 4:3 with EVR-CP while madVR 0.74 corrests the aspect ratio to 16:9 (the metadata indicates 16:9 display AR). But it's easy to "fix" by setting the AR to 16:9 manually for these videos (on the other hand, madVR doesn't do any de-interlace but EVR does a reasonable job with MBAFF).

[nevcairiel]

The only difference is that madVR is not supposed to do deinterlacing (yet), yet EVR would be supposed to show the AR properly. :p

PS:
MBAFF is only a encoding used in H264, once its decoded, it doesn't matter anymore what interlaced encoding was used. Either its interlaced, or its not. :)

[janos666]

MBAFF is only a encoding used in H264, once its decoded, it doesn't matter anymore what interlaced encoding was used. Either its interlaced, or its not. :)

Oh, sorry. Yes, the result of the decoding is a line interleaved video and madVR also works fine when the display mode is 1080i25 (except the old sync problem with interlaced display modes).
By the way, here is a 10 sec sample of this anamorhic MBAFF video (http://www.mediafire.com/?ub3h7628nc171i9) (if somebody would check the AR correction problem).

[cca]

Is it both VMR-9 and EVR CP affected? Do the resizing settings work as they should? Can you try disabling "View", "Video Frame", "Keep Aspect Ratio"? I don't think that will really help (once the mixer starts messing up anamorphic detection, the renderer can't do a proper job anymore). Anamorphic video problems are unfortunately common. Both EVR and VMR mixers require double-checking for it, else mirroring and wrong metrics with some types of formats occur.
I'll try to find a sample. My current samples all seem to work fine with both renderers.

Keep Aspect Ratio has little effect, rather makes things worse if I uncheck it. VMR-9 crashes *immediately* if I try to use it, I can't check! The resizing controls respond, but resize the distorted frame that is visible, I cannot use them to correct the AR as part of the image is just not visible anywhere.

[JanWillem32]

I've tried to simplify the code for the aspect ratio correction (the organization is still pretty bad, though). I've also revised the "View", "Options", "Output" tab (needs a bit more work). Maybe it will work better now. (I can't replicate the problem reported.)
Intermediate builds, I didn't bother to update all translations this time.

[cca]

I've tried to simplify the code for the aspect ratio correction (the organization is still pretty bad, though). I've also revised the "View", "Options", "Output" tab (needs a bit more work). Maybe it will work better now. (I can't replicate the problem reported.)
Intermediate builds, I didn't bother to update all translations this time.
x86 SSE2: http://www.mediafire.com/?3eaakd4kql9ulab
x64: http://www.mediafire.com/?2w3thvx3unhz3uc

No change here. Here's the difference I can see:
Distorted version:
http://img703.imageshack.us/img703/392/badframe.th.png (http://imageshack.us/photo/my-images/703/badframe.png/)

Normal version that should appear:
http://img101.imageshack.us/img101/9897/goodframe.th.png (http://imageshack.us/photo/my-images/101/goodframe.png/)

You can see the lower part of the frame missing completely, not recoverable with the resize controls.

[JanWillem32]

I thought I had to edit the code for the aspect ratio correction. The DVD Navigator pin is an entirely different thing. Finding a small sample DVD with menus to download that isn't copyrighted was very hard.
Anyway, editing the function that passes trough the video size and aspect ratio was easy. Starting the actual debug session to test if all values are passed trough properly turned out to be a lot more trouble.
For those familiar with programming:
-The "Open DVD..." menu triggers 8 errors even before actually doing anything. These can all be ignored, but it's not very elegant programming of course.
-On connecting the DVD Navigator pin, the renderers are asked to send geometry data and receive a bitmap to display, regardless how far the renderer is actually initialized. (Fails quite often for this reason.)
-On failure, the DVD navigator closes its own thread, and restarts it again in an endless loop.
-When a previous instance failed, and the position data was still saved to the registry/.INI file, a race condition starts on re-opening and the DVD navigator is always stuck in an endless loop.

I was already wondering why it was taking so long for blu-ray menu support. If people were trying to re-use the DVD Navigator as a template, it will take another decade of programming indeed...
I've worked on the subtitle renderer, that doesn't have the most ideal code. Today I found a part with even worse malfunctioning.

[ForceX]

VMR9r has an issue with subtitles where they'd appear slightly before the designated time, especially the typesetting. Also, in quite a few past builds including dfr3733, the sentence which is to be displayed next, would flash in current time for a moment before it resets to the current one. This has however gone down quite a lot in dfr3733i, based on preliminary testing.

And for some reason RGB32 input doesn't work with VMR9r, gives a black screen. Works fine in EVR CP, though.

[JanWillem32]

The change in timing that can be seen in the stats screen is applied to the two timing units of the subtitle engine, too. (It's a basic set of the current video FPS and the frame time in 100 ns units.) I've changed a lot of timing items for the subtitle renderer, because it always seemed to lag a bit. If there are samples of subtitles that get wrong timing because of that, I'll happily look at them.
Converted RGB is known to fail often, both mixers have trouble with it. I usually check if the Windows still image filter still works with a standard BMP file. For video, I don't bother to test anymore.

[Keiyakusha]

Hi! Is there any plans on integrating this changes to vsfilter (http://www.cccp-project.net/forums/index.php?topic=5976.0)? As I understand this is not multithreaded version and without addition of any new extensions to the subtitles formats (which are bad, as we all agree), just improved.

[JanWillem32]

Sure, both VSfilter and the DirectX 9 subtitle host can use a lot of patching (we don't have to bother with DirectX 7 anymore). I've already changed some things in the alpha code, a subtitle patch was already integrated recently, and it's a good thing to have more patches underway. The development team welcomes patches, and just as with my code, testing is very welcome, too. On request, I'll happily help with things. See for example the big patch to the color management and dithering. I've been taking good care of the optimization of the code, keeping track of changes to lCMS and discuss changes to the MPC-HC code.

By the way... Did adding software vertex processing help anyone with older DirectX 9 IGPs?

[cca]

Used the test build a lot the last couple of days, except the DVD issues it seems it has VSync issues as well, it' impossible to playback smoothly a 30 (29.97) fps video even when Reclock is matching the video fps to the screen (60Hz). The trunk builds on the other hand work fine with the build-in VSync and Reclock.

Another thing, if disable Aero and enable Alt-Vsync, the video is unwatchable, stutters like crazy.

[JanWillem32]

VSync has been an issue from the start. For exclusive mode, the DirectX built-in presentation scheduler works fine, and trying to perform VSync in windowed mode while Aero is active is absolutely pointless. I've already disabled Alternative VSync for that case, maybe I should do the same for the exclusive mode. Windowed mode without Aero does need a VSync implementation in the program, but trying to make the old VSync code compatible with my code is very hard. The old VSync code can't deal with scheduling up to four frames in the future (that automatically makes it incompatible with the frame interpolator, too). I've been looking at VSync methods that can deal with scheduling or drawing adjustments for the old GDI windowed mode, but it has been rather hard.
I'll take a look at compatibility with Reclock. I don't have any experience with it, but I'll try.

[cca]

VSync has been an issue from the start. For exclusive mode, the DirectX built-in presentation scheduler works fine, and trying to perform VSync in windowed mode while Aero is active is absolutely pointless. I've already disabled Alternative VSync for that case, maybe I should do the same for the exclusive mode. Windowed mode without Aero does need a VSync implementation in the program, but trying to make the old VSync code compatible with my code is very hard. The old VSync code can't deal with scheduling up to four frames in the future (that automatically makes it incompatible with the frame interpolator, too). I've been looking at VSync methods that can deal with scheduling or drawing adjustments for the old GDI windowed mode, but it has been rather hard.
I'll take a look at compatibility with Reclock. I don't have any experience with it, but I'll try.

My experience over the years indicate that some kind of VSync method is needed even in windowed mode with Aero, otherwise the video is just not smooth.

As I am stuck at 60Hz refresh rate, the 24Hz videos are always a little jerky but I'm used to it. When I play 30fps videos though, exactly 1/2 of the refresh rate, I expect the result to be silky smooth when I use ReClock, since it matches the actual frame rate to be exactly the half of the real refresh rate of my screen.
As I said, in the trunk builds that works, but VSync is also needed to be on. Disable it, and you get the same results I get with your build, the video jerks from time to time. More accurately, it's like periodic stuttering. Sometimes it starts to stutter continuously and I have to pause and resume, as Vsync is absent the video cannot recover it's timing.

Long story short, VSync is needed on windowed Aero mode even if theory says no, the tests say otherwise.

An interesting point, ReClock has it's own VSync implementation (besides the frame rate matching it does), don't know really how it works but I tried it and it seems to help with your build.

[JanWillem32]

What you describe isn't exactly VSync, but it's part of frame time scheduling. I didn't change the scheduler code for EVR CP much yet. It's a bit difficult to get this part right.
http://msdn.microsoft.com/en-us/library/bb172585%28v=VS.85%29.aspx
I've been looking at ways to allow users to set the D3DPRESENT_INTERVAL value or sequences for the renderer. I don't know if an automatic or manual function would suit best.
I'm very familiar with the typical stuttering. I have a CRT with an somewhat varying 80 Hz analog input. (The input of the projector is a little more stable.) Until frame interpolation, I've always had some interruptions now and then, regardless of renderer.
I had my eye on the frame scheduler of EVR Sync at first, but modifying it won't be easy.
VMR-9 requests one frame at a time for processing, and returns it when it's about time to present it. EVR requests as many frames there are free in the mixer texture buffer and won't return until all are filled, so the mixer code in MPC-HC has to try to spread those frames out over time. By default, I've set the renderer to D3DPRESENT_INTERVAL_ONE, just assuming that the mixer's scheduler code does a good job, and the main paint loop doesn't have to schedule anything on its own.
In your case D3DPRESENT_INTERVAL_TWO should work better (with a safety release to D3DPRESENT_INTERVAL_ONE on dropped frames and glitches).

[ForceX]

Here's a case where typesetting appears before designated time in VMR9r: http://i.imgur.com/XqOln.jpg
Timing works ok in EVR CP: http://i.imgur.com/ZdAov.jpg
Here's how it's supposed to look, which is about a second after the above scene: http://i.imgur.com/s5NU7.jpg

The sub file is here: http://www.mediafire.com/?1sk9x3vaa17w241

[cca]

What you describe isn't exactly VSync, but it's part of frame time scheduling. I didn't change the scheduler code for EVR CP much yet. It's a bit difficult to get this part right.
http://msdn.microsoft.com/en-us/library/bb172585%28v=VS.85%29.aspx
I've been looking at ways to allow users to set the D3DPRESENT_INTERVAL value or sequences for the renderer. I don't know if an automatic or manual function would suit best.
I'm very familiar with the typical stuttering. I have a CRT with an somewhat varying 80 Hz analog input. (The input of the projector is a little more stable.) Until frame interpolation, I've always had some interruptions now and then, regardless of renderer.
I had my eye on the frame scheduler of EVR Sync at first, but modifying it won't be easy.
VMR-9 requests one frame at a time for processing, and returns it when it's about time to present it. EVR requests as many frames there are free in the mixer texture buffer and won't return until all are filled, so the mixer code in MPC-HC has to try to spread those frames out over time. By default, I've set the renderer to D3DPRESENT_INTERVAL_ONE, just assuming that the mixer's scheduler code does a good job, and the main paint loop doesn't have to schedule anything on its own.
In your case D3DPRESENT_INTERVAL_TWO should work better (with a safety release to D3DPRESENT_INTERVAL_ONE on dropped frames and glitches).

I thought already to try to use the interpolation feature but alas, if I have it enabled the player displays a black frame and hangs. What is interesting is that if I enable it while a video is already playing it doesn't hang.

[JanWillem32]

For all three latest issues, I'll just start debugging. I've already made a little bit of progress with the DVD menus (I fixed one of the endless loops).

[JohnLai]

Anyone has 'no sound' issue when using MPC Audio Renderer with build 3733 64bit?

[clsid]

MPC Audio renderer is buggy and incomplete. It should not be used.

[JanWillem32]

I've been experimenting with that one for a bit. The original code didn't allow changing WASAPI mode, mine does (it was easy to fix). The MPC Audio Renderer is hopelessly dated compared to other versions of this project. The reason you're probably not getting audio is because WASAPI was activated on 32-bit float or 24-bit integer audio (it chokes on that). The trunk version just silently reverts to the default audio renderer. No errors are displayed, it's only visible in the filters menu.

[JohnLai]

OK.....so...any chance of fixing the error of stackhash when exiting D3D mode? I reported it on the other thread, but still isnt fixed as build 3733.

[Hera]

Yep MPC still crashes...

[JanWillem32]

Does that crash on exit still only occur when using something else than the regular commands for "close" and "exit"?
I think the exit command by a regular Alt+F4 isn't intercepted properly. My version of the renderer does have a lot stricter exit sequence that could indeed crash if interrupted.
About nasty crashes, the main deadlock by the DVD Navigator was solved. I think I should patch the trunk build for this one.
I'm very glad this one was found, as all custom internal renderers are vulnerable to this risk. The aspect ratio problem was only a very minor side-effect.

[Hera]

ALT-F4 is common
Possibly once (just once) coming out of sleep
Opening a second file on XP (noticed when testing 16f performance)

[cca]

Maybe a matter of habit but I always try to close MPC-HC with the Alt+X combination and not Alt+F4.

[JohnLai]

I paste what I wrote much more earlier in past.
First, for 'exit' command, set 'modifier' to none and 'key' to nothing. Set the 'mouse' to 'Left double click'.
Second, make sure mouse setting for 'fullscreen' command is set to 'none'.
Now, play any video file with D3D mode enabled and left double click to exit. The crash will happen.

One of the developer said he cant diagnose the issue because stackhash error didnt occur with debug build.

[JanWillem32]

The default MPC-HC compiler settings for debug builds are very different from release builds. Not even regular SSE is set for x86 builds and many optimization options that are common for even debug builds are not set as well. I use very different settings for debug builds, with one profile for optimization and one for bug checking.
I can replicate the problem with these very specific settings, so I'll have a go with this issue. Debugging for the DVD playback and the frame interpolator worked out very well, I hope it turns out well for this case, too.

edit: I solved it, now just some more testing...

[JanWillem32]

It does seem I did a lot today, but I was actually sick most of the time. :( The changes to the code just worked out well, with only little effort. :)

-the Output tab of the Options screen has been cleaned up, so check your settings before opening any videos
-improved (mostly simplified) the aspect ratio to video size detection
-fixed several problems with handling window paint calls, DVD menus were most affected
-fixed window exit sequences, the exclusive mode was most affected
-revised OSD bitmap loading for better efficiency and better support of window resizing
-added limited color ranges conversion to the color management menu
-revised the safety release and timing system for the constant frame interpolator (please report if it works or fails)
-edited the timing for the VMR-9 r. subtitle scheduler part (please report if it ever needs any more adjustments)
-tried to edit the VSync code again, messed up the monitor refresh rate detection, but it works better anyway

todo:
-make the menu stills for the DVD navigator update twice per second (like the paused mode) to refresh the first background-colored screen, and keep up at least a bit with WM_PAINT messages from the system
-try Reclock

[cca]

It does seem I did a lot today, but I was actually sick most of the time. :( The changes to the code just worked out well, with only little effort. :)

-the Output tab of the Options screen has been cleaned up, so check your settings before opening any videos
-improved (mostly simplified) the aspect ratio to video size detection
-fixed several problems with handling window paint calls, DVD menus were most affected
-fixed window exit sequences, the exclusive mode was most affected
-revised OSD bitmap loading for better efficiency and better support of window resizing
-added limited color ranges conversion to the color management menu
-revised the safety release and timing system for the constant frame interpolator (please report if it works or fails)
-edited the timing for the VMR-9 r. subtitle scheduler part (please report if it ever needs any more adjustments)
-tried to edit the VSync code again, messed up the monitor refresh rate detection, but it works better anyway

todo:
-make the menu stills for the DVD navigator update twice per second (like the paused mode) to refresh the first background-colored screen, and keep up at least a bit with WM_PAINT messages from the system
-try Reclock

Actually it's dfr 3734. Anyway, much improved but the DVD menus need some work, you already know that anyway. The frame interpolator doesn't crash now, good.
Get well soon!

[nand chan]

Do you know how the builds at http://xhmikosr.1f0.de/index.php?folder=bXBjLWhj are compiled? SSE/2? Any optimizations?

Also, if you're not using any internal renderers other than the subtitle renderer (LAV Video + ffdshow + madVR + ReClock are being used otherwise), would it make a big performance difference?

More importantly, will it make a big performance difference for the subtitle renderer?

[nevcairiel]

Changing the compile settings in MSVC does not influence the performance much. Any time critical algorithms needs to be written in assembler if you want to take advantage of SSE, the optimizations the compiler does are usually not all that great.

I suppose they are compiled with the default settings, which is SSE1, but no SSE2. Like i said, this does not affect manually written ASM code.

[nand chan]

Changing the compile settings in MSVC does not influence the performance much. Any time critical algorithms needs to be written in assembler if you want to take advantage of SSE, the optimizations the compiler does are usually not all that great.

I suppose they are compiled with the default settings, which is SSE1, but no SSE2. Like i said, this does not affect manually written ASM code.

Is the sub renderer written as assembly?

Isn't it compiled using MinGW?

[nevcairiel]

The subrenderer is compiled with MSVC, afaik. I think it contains some parts in ASM, but overall its rather inefficient and bad code. :)
The only thing really compiled with MinGW is avcodec.

[JanWillem32]

There are also intrinsic functions that can be used to write packed SSE code (and generally have the same readability as assembly). I do check the assembly generated, but I'll let the compiler handle the rest, such as inserting pre-load operations. I don't write assembly directly. A little sample of this from the VSync code (both code paths do the same thing):#if _M_IX86_FP != 1// SSE2 code, don't use on SSE builds, works correctly for x64 and AVX
__m128d x0 = {m_dMonitorHeight, m_dMonitorHeight*m_dDetectedRefreshRate};
static const __m128d x1 = {1.0/3.0, 0.003};
__m128d xa = _mm_mul_pd(x0, x1);// output is: low (a) 1.8 ms, high (b) 33% of Time
__m128d xb = _mm_shuffle_pd(xa, xa, _MM_SHUFFLE2(0, 1));// swap high and low doubles
__m128d xc = _mm_min_sd(xa, xb);
static const double px2 = 5.0;
static const __m128d x2 = _mm_load_sd(&px2);// note: high register set to zero uses MOVSD, instead of MOVAPD
__m128d x3 = _mm_max_sd(xc, x2);
#ifdef _M_X64
__int64 MinRange = _mm_cvtsd_si64(x3);// rounding cast value to __int64
#else
int MinRange = _mm_cvtsd_si32(x3);// rounding cast value to int
#endif
#else
double a = 0.003*m_dMonitorHeight*m_dRefreshRate;// 1.8 ms
double b = m_dMonitorHeight/3.0;// 33% of Time
double c = (a < b)? a : b;
ptrdiff_t MinRange = static_cast<ptrdiff_t>((c > 5.0)? c : 5.0);// 1.8 ms or max 33% of Time
#endifI might have to revise it sometime. I'm not entirely happy with the VSync code. This is just converted original code, I personally don't like to use "1.8 ms or max 33% of Time". It's too rigid for varying connection types, refresh rates, refresh rate stability and screen sizes.

[nevcairiel]

Intrinsics mostly convert 1:1 to ASM operations, its just easier to interface with the C parts.

I wrote all custom algorithms in intrinsics in LAV Video, mostly because inline assembly doesn't work in x64 compiles. The code is exactly the same as inline assembly, except that you do loops and variable handling in C, instead of assembly.

[nand chan]

Do you think you could use/add a mirror that supports hotlinking, eg. omploader.org (or others)?

I want to download the tester builds from within a program, but downloading from mediafire would require me to implement some extremely cumbersome virtualization logic to bypass the silly download page.

[JanWillem32]

I actually find MediaFire quite convenient with bulk multi-uploading to multiple folders. The host doesn't seem to be blocked by national firewalls and such as well. How much of my folder are you actually trying to download that would need a controller program? The standard packages are less than 5 MB. With download speeds of 230 kilobyte per second over here, items of that size should be done within a minute. With slightly more than 100 downloads for dfr3734 alone, it seems to work well for most people. I don't mind switching hosts, but I prefer to have a good reason for it. I've had the current set of folders for a while, too.

[golagoda]

Dropbox is easy to use and supports hotlinking. Especially with Windows explorer (and nautilus, for linux) integration.

You need to install the program to upload things to it though.

[nand chan]

I actually find MediaFire quite convenient with bulk multi-uploading to multiple folders. The host doesn't seem to be blocked by national firewalls and such as well. How much of my folder are you actually trying to download that would need a controller program? The standard packages are less than 5 MB. With download speeds of 230 kilobyte per second over here, items of that size should be done within a minute. With slightly more than 100 downloads for dfr3734 alone, it seems to work well for most people. I don't mind switching hosts, but I prefer to have a good reason for it. I've had the current set of folders for a while, too.

I'm just trying to download the “mpc hc SSE2 tester dfr3734.7z” file (or whatever the latest version is).

If you have your reasons for not providing a mirror then I will respect that, it'll just take a day of reverse engineering to hack through the mediafire download page.

[JanWillem32]

What exactly isn't working? Is it because of security settings that the download link doesn't show up, or doesn't the link itself seem to work?

On another note, the frame interpolator has been broken the last few revisions, the render target is messed up, reducing the output quality. I'm currently fixing it, along with doing some performance optimization.

[JanWillem32]

I've just fixed the frame interpolator. It's a lot better-looking, smoother (see the tearing test) and mostly, more efficient. I added a big amount of code for it, and it was well worth it.
I'm thinking that an intermediate form in between the basic and adaptive types might be useful (the code from the basic type with the bare minimum for artifact removal from the adaptive type). Could people here show some GPU performance data to compare the required processing power of the two current types? I'm still experimenting with various forms. The case of a frame exactly in between two other frames is still difficult to get reasonable results for. I've been looking at deinterlacing techniques (those also have to do this, but for another reason and line-based), but all I seem to get are the typical artifacts.
I've also fixed a nasty subtitle invalidation bug and improved some geometry code.

[cca]

I've just fixed the frame interpolator. It's a lot better-looking, smoother (see the tearing test) and mostly, more efficient. I added a big amount of code for it, and it was well worth it.
I'm thinking that an intermediate form in between the basic and adaptive types might be useful (the code from the basic type with the bare minimum for artifact removal from the adaptive type). Could people here show some GPU performance data to compare the required processing power of the two current types? I'm still experimenting with various forms. The case of a frame exactly in between two other frames is still difficult to get reasonable results for. I've been looking at deinterlacing techniques (those also have to do this, but for another reason and line-based), but all I seem to get are the typical artifacts.
I've also fixed a nasty subtitle invalidation bug and improved some geometry code.

Will try the build latter today. In the mean time, my observations with the previous build are not so good, it seems EVR-CP is unable to produce smooth video in any windowed mode, in Aero is just jerky, without Aero it's smoother but has tearing problems, VSync is no go, completely broken slows the video to a crawl. Only mode with decent flow is the exclusive D3D fullscreen (vsync off, still broken).

[ForceX]

Unfortunately the typesetting appearing before time issue in VMR9r isn't fixed yet; moreover in dfr3740 subtitles don't even show up in VMR9r and EVR CP unless you disable and enable it within the player.

And the lut3d profiles created by dfr3734 and 3740 creates garbage images. Using the tester dfr3733-generated files works ok.

What exactly isn't working? Is it because of security settings that the download link doesn't show up, or doesn't the link itself seem to work?

I think he wants to automatically download the latest file from within a program, and because mediafire doesn't have direct linking to files, he can't.

[janos666]

I am not sure but I think the frame interpolation is still broken. At leas my test videos are much smoother with 24fps@96Hz (4:4 FRC by the TV, no interpolation) than 24fps+interpolation@60Hz (according to CCC, my GPU load is <5% with the precise method). Frame interpolation usually creates "soup opera effect" which I hate just as much as the artifacts (interpolation errors) but your method seems nothing like that. I see some minor artifacts but the motion isn't smooth, sometimes even worse than 24fps@60Hz.

[G_M_C]

I am not sure but I think the frame interpolation is still broken. At leas my test videos are much smoother with 24fps@96Hz (4:4 FRC by the TV, no interpolation) than 24fps+interpolation@60Hz (according to CCC, my GPU load is <5% with the precise method). Frame interpolation usually creates "soup opera effect" which I hate just as much as the artifacts (interpolation errors) but your method seems nothing like that. I see some minor artifacts but the motion isn't smooth, sometimes even worse than 24fps@60Hz.

Can you really output 96fps to the TV; i.e. is 1080p (or whatever resolution) @ 96 Hz an option / mode available through CCC ?

[janos666]

Can you really output 96fps to the TV; i.e. is 1080p (or whatever resolution) @ 96 Hz an option / mode available through CCC ?

No, the output is 1920x1080p24. It's just the TV which applies 4:4 FRC and runs the plasma panel at 96Hz (full-field) refresh rate (Samsung calls it CinemaSmooth). The frames are repeated four times, the 2011 models doesn't even offer any frame interpolation modes. (But I don't miss it. The only drawback of 96Hz is the higher MLL - compared to 60Hz 0.045vs0.060 cd/m^2).

I can't go above 60Hz with the input frequency, except the 720p60 3D mode which is 2x720p60. I don't know if anybody made a hack to trigger this mode but use it without the shutter glasses in 2D to get real 120Hz. It wouldn't worth it anyway.

The limiting factor here is the HDMI 1.4 standard, 1080p60 is practically the best you can get. Too bad because it would be so cool to play some PC games in FullHD3D and 60Hz for both eyes (on this plasma, not on those TN LCDs...). 720p 3D is too blurry for me and 1080p30 makes every games unplayable.

[JanWillem32]

@cca: Timing frames is rather new to me. It was a nasty suprise that the original Vsync and scheduling code broke. I've had to patch it everywhere to get it to even work at this level. I wish we had developers for helping with this part of the code.

@ForceX: I can't replicate the problem with default disabled subtitles at the moment. I'll try some more. Is there something in your setup that might cause this to happen?
I can replicate the timing issue in VMR-9. The timer has a few rounding issues and VMR-9 doesn't have the best scheduler. Does a constant subtitle delay help in your case for VMR-9? It might just need a dirty patch for a few frames delay.
The LUT3D problem has been solved in this release. It was mostly a data alignment issue that was easily solved.

@janos666: The "soap opera effect" should be really visible. It's indeed likely that the interpolator fails in your case. Less than 5% GPU usage with the past releases seems unlikely with such a heavy filter. It features a few safety features to avoid choking the renderer, so one of those is probably deactivating the feature.
As for refresh rates; http://en.wikipedia.org/wiki/Hdmi .
For 1920×1080 on HDMI 1.3 and 1.4, overhead removed:
(24-bit) 8160000000/1920/1080/24 = 163.966 Hz
(30-bit) 8160000000/1920/1080/30 = 131.173 Hz
(36-bit) 8160000000/1920/1080/36 = 109.311 Hz
(48-bit) 8160000000/1920/1080/48 = 81.983 Hz
Not all receivers can handle the full capacity, though. But it's not a limitation in the standard.

For the new builds, I've lost the change log... I've at least worked on fixing the 3DLUT generator, on a major changes in the frame rate detection and the frame interpolator. All three parts need some performance optimization, but integrating the final pass shader into the frame interpolation shaders was a good start. I didn't test everything very thoroughly this time, so please keep a previous version ready as a backup (and report what's wrong, please).

[janos666]

As for refresh rates; http://en.wikipedia.org/wiki/Hdmi .
For 1920×1080 on HDMI 1.3 and 1.4, overhead removed:
(24-bit) 8160000000/1920/1080/24 = 163.966 Hz
(30-bit) 8160000000/1920/1080/30 = 131.173 Hz
(36-bit) 8160000000/1920/1080/36 = 109.311 Hz
(48-bit) 8160000000/1920/1080/48 = 81.983 Hz
Not all receivers can handle the full capacity, though. But it's not a limitation in the standard.

Oh, now that you say... I didn't consider they doubled the maximum TDMS clock with the 1.3 revision. I just compared it with DVI which needs dual-link to offer 1920x1080p120.

According to Moninfo, the maximum allowed TMDS clock is 225Mh on my device.
8160000000/1920/1080/24/(340/225) = 108.5 Hz
It means 50fps for both eyes should be possible and I think it would be enough to play RPG games (and may be FPS games as well if you are only looking for occasional fun and not "sport"...).

And 120Hz would also be possible with YCC 4:2:2 output format (the TV doesn't offer 4:4:4 mode in 3D anyway).

[cca]

dfr 3751 has a serious problem here when paying windowed with Aero on, this happens:
http://img137.imageshack.us/img137/5658/tempy.th.png (http://imageshack.us/photo/my-images/137/tempy.png/)

Actually the same with aero off, still windowed.

[JanWillem32]

@janos666: Good luck with trying out custom profiles. I do advise to keep a second monitor next to it, for in case you get a black screen. That happens often when trying custom refresh rates. Don't take 225 Mhz as an absolute maximum. Many devices can handle a bit more than they actually report. I've made a few profiles for monitors, and the maximum is rarely a multitude of 5, like often reported.

@cca: That bug has been there for months already. It's caused by the destructor of the subtitle allocator. It doesn't take it well when resizing a window when a subtitle is being pre-loaded.

[cca]

@janos666: Good luck with trying out custom profiles. I do advise to keep a second monitor next to it, for in case you get a black screen. That happens often when trying custom refresh rates. Don't take 225 Mhz as an absolute maximum. Many devices can handle a bit more than they actually report. I've made a few profiles for monitors, and the maximum is rarely a multitude of 5, like often reported.

@cca: That bug has been there for months already. It's caused by the destructor of the subtitle allocator. It doesn't take it well when resizing a window when a subtitle is being pre-loaded.

well in this build happens consistently *every* time, it's unusable. Testing a bit, even on files where it doesn't crash the subtitle *do not show*. This build is rather broken...

[ForceX]

I actually mistook the lack of subtitle issue for something else. The subtitles disappear if you resize the player. Because my MPC setup always resizes the window while opening a file, it seemed the subtitles did not work. Setting it to maximized and opening files afterwards made me realize my mistake.

What does the Subtitle option Delay Interval do? -_- I thought it was for delaying subtitles but it doesn't seem to do anything and it doesn't even accept negative values so it can't be that.

[CruNcher]

@jan
maybe you know whats going on http://forum.doom9.org/showpost.php?p=1529716&postcount=128 ?

[Hera]

Subtitles need to be reloaded to be displayed when not using D3DFS

[upyzl]

Subtitles need to be reloaded to be displayed when not using D3DFS

same problem

but previous 3733 doesn't...

[cca]

Subtitles need to be reloaded to be displayed when not using D3DFS

99% of the subtitles in the anime I watch are embedded in a .mkv file, they are not external to be reloaded.

[ForceX]

99% of the subtitles in the anime I watch are embedded in a .mkv file, they are not external to be reloaded.
I think he is referring to this:... in dfr3740 subtitles don't even show up in VMR9r and EVR CP unless you disable and enable it within the player.


I've found out that the subtitles disappear if you resize the window during playback, and only way to bring it back is disabling and enabling subtitles in the player.

[CruNcher]

@Jan
do you have also a idea why it shows YUY2 the input should be NV12 according to ffdshow-quicksync
http://forum.doom9.org/showpost.php?p=1529823&postcount=137

[VenomousNinja]

Yes, external subtitles doesn't work for me too.

[CruNcher]

@Jan
another one http://forum.doom9.org/showpost.php?p=1529877&postcount=139 ;)

[JanWillem32]

I've just solved the subtitle issue (superficially, as what the subtitle renderer does is still very wrong). I'll have a go at helping to debug ffdshow-quicksync, thank you for the reference CruNcher.

[nand chan]

Do you think you could attempt to tackle the subtitle position bug (http://img690.imageshack.us/img690/2899/subpos.png)? To recap some of the information:


Only happens using the MPC-HC internal renderer
Only happens on a 16:10 (or other non-16:9) monitor
The image is exactly 60 pixels too high, equivalent to half of the extra height 1920×1200 offers
Only happens for bitmaps, regular subtitles are all correct
Only happens in fullscreen mode, windowed modes are fine
Happens with all renderers that support the ISR, including madVR, EVR CP, EVR Sync, Haali and VMR-9
Happens regardless of texture resolution settings (here's what happens (http://img810.imageshack.us/img810/148/subposlo.png) if I lower it from “Desktop” to some low-res 16:9 format)
Happens regardless of buffer/animation settings
Happens regardless of the screen alignment & margins settings
Only happens if “Position subtitles relative to the video frame” is turned on (but if I turn it off, all other subs are misaligned and the bitmap is too large
Happens regardless of “correct monitor/desktop AR difference” setting
Changing the “override aspect ratio” settings changes the offset as well (in windowed mode)
If I change the video frame mode to “half size” or “double size”, it's aligned perfectly (even in fullscreen mode)
If I change the video frame mode to “touch window from outside”, its aligned vertically (with the stretched image), but offset to the right (in fullscreen mode)
If I change the video frame mode to “stretch to window”, it's too far down


Confirmed episodes for which it happens: Very beginning of [CoalGirls] and THORA releases of Bakemonogatari episode 1, as well as some scenes in the [CoalGirls] release of Katanagatari (in the last episode)

[CruNcher]

I've just solved the subtitle issue (superficially, as what the subtitle renderer does is still very wrong). I'll have a go at helping to debug ffdshow-quicksync, thank you for the reference CruNcher.

in this matter i experience something rather strange not sure but the jitter behavior of the test builds EVR-CP is definitely different from the main builds with ffdshow-quicksync in a window with the OSD on it shows the low normal jitter of .4xx ms (same as with mpc-hc main) but as soon as i maximize the window it goes up to 2 ms and then very slowly recovers the same for Fullscreen (Aero On). It also looks like the Test builds do some kind of internal Mode change as the aspect ratio changes for a second if this jitter spike occurs.


Here is it visually in the 3 steps:


Windowed:

http://img689.imageshack.us/img689/4669/windowed.png

Maximized:

http://img88.imageshack.us/img88/1875/maximized.png

Maximized: after some time time into playback (changes proportional over time)

http://img189.imageshack.us/img189/1368/maximizedaftersometime.png


PS: It seems if i stop playback i can force the Jitter to lower instantly without waiting, also i only get a output @ all @ 8 bit integer the other modes 10,16,32 cause a black screen of the video content sound plays.

Other render modes then 8 bit integer result:

http://img696.imageshack.us/img696/7491/blackscreen.png

[CruNcher]

This is also one of the craziest things i experienced so far :D

http://img710.imageshack.us/img710/842/wtvfunny.png

The Microsoft WTV continues to playback though it's closed, the chain this opens up is crazy full of filters too (Microsoft ones) :D

[JanWillem32]

@nand chan: I looked into this problem, and it was surprisingly simple to fix.
http://sourceforge.net/apps/trac/mpc-hc/browser/trunk/src/Subtitles/RTS.cpp
The incompletely implemented functions were "clip" and "iclip". It was marked in the source as incomplete (main reason I could fix it so easily). I wonder why previous developers left it in that state.
We'll have to evaluate if the patch I created is problem-free, so it can go into the trunk build.

@CruNcher: The trunk build creates textures at screen resolution size. I changed that to active window size. Whenever the active window size changes, all active window-sized textures, geometry data and subtitle renderer parts are released and re-created. That simply takes moment.
The problem seen in the third picture is indeed a very annoying one. The video card can handle A2R10G10B10 surfaces, but a filter in the video processor chain can't. This isn't a renderer problem (else you wouldn't even get to see the stats screen at all). Many filters implemented by a video card's driver are known to cause black screen output. With older drivers of my video card, I had black screen output as well when enabling some "quality options" (normal filters like the deinterlacers and color conversion never had this problem in my case). The renderer never receives an error if the video processor fails, by the way.
The issue in the fourth picture should only come up rarely. When the graph receives a quit command, it doesn't force the loaded filters to unload immediately, it only sends messages to the filters to quit and unload. When a filter continues to feed a renderer, it won't stop.
I get it often when I'm working with a debug build and break execution of the program with the debugger to inspect the running process. Breaking causes a timer gap, so the renderer tries to catch up with the "lost" time. It's indeed annoying, but if exiting the program proceeds normally, it's harmless.

[nand chan]

@nand chan: I looked into this problem, and it was surprisingly simple to fix.
http://sourceforge.net/apps/trac/mpc-hc/browser/trunk/src/Subtitles/RTS.cpp
The incompletely implemented functions were "clip" and "iclip". It was marked in the source as incomplete (main reason I could fix it so easily). I wonder why previous developers left it in that state.
We'll have to evaluate if the patch I created is problem-free, so it can go into the trunk build.

This is actually great news, it means the age old problem that has been plaguing the ISR is now a non-issue!

I tested the updated build and it seems to work fine, that is, I was able to go through a heavily typeset episode (the same bakemonogatari ep) without noticing any positioning problems, and it fixed the bug I reported.

The reason why the previous developers left it like that is probably because nobody gives half a damn about MPC-HC's subtitle renderer, that's the sad state of things.

The only issue that remains to be fixed now is the fact that madVR doesn't color correct subtitles, but that's his problem.

[JanWillem32]

There's not a lot to color correct, actually... The subtitle renderer could write 8-bit RGBA in its current color format (already a nasty limitation), but the renderer calculates in 6-bit, and to make it worse, the primary font drawing is only 4-bit. I would simply have used SSE code for writing rectangular 32-bit float textures for each element, and let the GPU blend each part (or even just use the standard DirectX 10/11 rasterizer instead, but that won't work for people with an old GPU or on Windows XP).
There are two other issues with the output in general. When importing non-RGB subtitles, the color format is converted by the subtitle renderer. Any sort of color conversion is a video renderer task for the blending stage.
The subtitle renderer multiplies all of its color output by 1-alpha. This seems to work reasonably well for VSfilter and 8-bit surfaces, but lowers color and blending quality of semi-translucent pixels. When the video renderer tries to blend it with sensible settings, darkening artifacts appear where these pixels are blended in.

What I've patched today was the formatted text parser. Its code is sub-optimal, but it at least doesn't require a lot of processing compared to the rasterizer and other pixel rendering parts.

[nand chan]

There's not a lot to color correct, actually... The subtitle renderer could write 8-bit RGBA in its current color format (already a nasty limitation), but the renderer calculates in 6-bit, and to make it worse, the primary font drawing is only 4-bit. I would simply have used SSE code for writing rectangular 32-bit float textures for each element, and let the GPU blend each part (or even just use the standard DirectX 10/11 rasterizer instead, but that won't work for people with an old GPU or on Windows XP).
There are two other issues with the output in general. When importing non-RGB subtitles, the color format is converted by the subtitle renderer. Any sort of color conversion is a video renderer task for the blending stage.
The subtitle renderer multiplies all of its color output by 1-alpha. This seems to work reasonably well for VSfilter and 8-bit surfaces, but lowers color and blending quality of semi-translucent pixels. When the video renderer tries to blend it with sensible settings, darkening artifacts appear where these pixels are blended in.

What I've patched today was the formatted text parser. Its code is sub-optimal, but it at least doesn't require a lot of processing compared to the rasterizer and other pixel rendering parts.

Interesting information, but that's not really related to the issue I'm experiencing. (Of course, if you can improve the quality of the subtitle renderer, I'm all for it!)

The problem is that when you use color management to apply significant changes to the color, for example converting something from BT.709 color space into something like Adobe RGB, or applying gamma correction (I correct mine to 2.5), the result is something like this (http://img839.imageshack.us/img839/2249/colorsubs.png).

There's also a problem, in yet the *same* bakemonogatari episode, where the entire frame is covered with a red subtitle - if you're doing something like translating from BT.709 to a wide gamut color space, the red will appear far, far too red than it should be for sRGB, which means that the frame will not only fit into the video but also be annoying on the eye. It's even worse for green, which will look like plastic.

[Hera]

Haal is black screening now... for everything and for all codecs.

[ForceX]

Haali works fine here, but unless I enable "Disable RGB linearization", I get a black picture in EVR CP/VMR9r with >8bit surface, but subtitles/typesetting etc. appear.

[JanWillem32]

I've fixed the linearization functions (I misplaced one curly brace) and fixed another subtitle renderer initialization bug.
I'll have to look into the issue with Haali renderer. With basic settings it seems to reasonably work for me.
I'll have to think about adding color controls to the video renderer, so it can alter the combined subtitles with video image (like the color management and dithering). I wasn't planning to add any color controls on top of those of EVR and VMR-9, though.
These builds have a new present method for Windows 7 and newer (FlipEx). I'd like to ask how well it works with getting the image in windowed mode to the desktop swap chain, in terms of timing, efficiency and such. I'll try to make the reset-on-resize function a bit faster later on.

[cca]

Last 3 days I was trying madVR, only to discover it fails the same way EVR-CP failed in these experimental builds. Specifically, it cannot present the frammes in a timely manner when the video played is 24fps but the screen 60Hz, resulting in jerky motion, something like microstuttering. The trunk EVR-CP can do this perfectly, so the video is fluid, even if an effect like a 3:2 pulldown is visible.

I will try the latest tester build 3752 during the weekend, the EVR-CP in these builds is my only hope for some decent video quality apparently.

[CruNcher]

The 64 bit EVR-CP crashes immediately after loading the 32 bit SSE2 works, also the performance of the old FlipEX code here seems better with both ffdshow-quicksync (memory copy) and Cyberlink DXVA2 (direct) switching (resize) times with 3752i are better 3752ir causes a long (delay) and so a big audio glitch @ the switch (resize), perceptional this already hurts in 3752i a little (compared to the trunk) but in 3752ir it is unacceptable worse because its not seamless anymore (only video) but audio glitches also here now.


PS: The heaviest crash i got so far with 3752ir EVR-CP running Firefox 10 (GPU) in the background trying to switch from window to full window, doesnt happen with 3752i testing in both cases 10 rapid switch cycles (window,full window,fullscreen).

http://img97.imageshack.us/img97/5750/heaviestcrash.png



Trunk 3752 32bit MPC-HC EVR-CP result:

http://img207.imageshack.us/img207/6963/trunkfullresult.png

Tester 3752i 32bit MPC-HC EVR-CP result:

http://img840.imageshack.us/img840/7060/testerfullresult.png


Yep i got the rendering of the Text in Trunk back under control it seems to have repaired itself after installing the DirectX redist that came with RAGE :)

[cca]

More or less what CruNcher says, performance is much better in this version, those damn stutters seem to be almost gone, just the change between window and fullscreen is very slow and causes crashes at times.

[JanWillem32]

@cca: I was looking at the internal timing functions, and I found out that the timer functions are typically difficult to manage.
Some manufacturers disable HPET in the BIOS by default or set it to 32-bit, instead of the normal 64-bit mode. CPU throttling options are sometimes also to blame.
Can you see in your system BIOS if HPET is enabled correctly?
Can you test if disabling CPU throttling helps? You can temporarily disable it in the the Windows control panel. Under "Power Options", select the "High Performance" power plan to disable power-saving options. A nice article on this:
http://www.howtogeek.com/howto/windows-vista/disable-power-management-on-windows-vista/
If changing settings for power management helps, you might need to update some drivers or fine-tune the power settings to a more balanced state.
Some extra reading materials on HPET (for convenience, I left out the programmer's resources):
http://en.wikipedia.org/wiki/High_Precision_Event_Timer
http://www.virtualdub.org/blog/pivot/entry.php?id=106
http://www.reghardware.com/2006/07/04/amd_dual-core_tweak_tool/

@CruNcher: It's a multi-threading issue for the paused mode. I've solved it already.
I'm trying to fix switching in between files with the 10-bit display mode enabled, and making the reset sequences less annoying for the next batch.
I've also added a pause command to allow the video renderer to take some time to finish its first paint loop, for example when creating a new file for the color management.

[CruNcher]

@cca: I was looking at the internal timing functions, and I found out that the timer functions are typically difficult to manage.
Some manufacturers disable HPET in the BIOS by default or set it to 32-bit, instead of the normal 64-bit mode. CPU throttling options are sometimes also to blame.
Can you see in your system BIOS if HPET is enabled correctly?
Can you test if disabling CPU throttling helps? You can temporarily disable it in the the Windows control panel. Under "Power Options", select the "High Performance" power plan to disable power-saving options. A nice article on this:
http://www.howtogeek.com/howto/windows-vista/disable-power-management-on-windows-vista/
If changing settings for power management helps, you might need to update some drivers or fine-tune the power settings to a more balanced state.
Some extra reading materials on HPET (for convenience, I left out the programmer's resources):
http://en.wikipedia.org/wiki/High_Precision_Event_Timer
http://www.virtualdub.org/blog/pivot/entry.php?id=106
http://www.reghardware.com/2006/07/04/amd_dual-core_tweak_tool/

@CruNcher: It's a multi-threading issue for the paused mode. I've solved it already.
I'm trying to fix switching in between files with the 10-bit display mode enabled, and making the reset sequences less annoying for the next batch.
I've also added a pause command to allow the video renderer to take some time to finish its first paint loop, for example when creating a new file for the color management.

Nice :) in regards to hpet timer issues and how to identify them easily http://www.xtremesystems.org/forums/showthread.php?179044-Real-Temp-New-temp-program-for-Intel-Core-processors&p=4731014&viewfull=1#post4731014

[cca]

Thank for the suggestions, here's my 2 cents: I built the system myself, also use linux on it so I can already tell you it has 4 32bit HPET timers on it, enabled. Disabling power management just to play a video is not acceptable, my quad core consumes a lot of power in full clock mode. Also, the current VSync implementation in the trunk builds works fine for years now, why both of you are blaming my system all of a sudden? That VSync algorithm never drops a frame or produces stutter. Also let me remark this: this kind of slight stutters are not so visible when you watch movies or normal series, but in my case 99% of the time I watch *animation*. In the case of animation the slightest jerk or stutter is immediately noticeable. This is the reason that years ago I was one of the first users of ReClock, I could see dropped frames where no one else could.

I got the same attitude from the madVR users, "it must be your system or you". Well, MPC-HC's current EVR-CP works FLAWLESSLY even with postprocessing shaders enabled. madVR does not. The EVC-CP of this test builds does not. Nothing more to say.

[JanWillem32]

I should have pointed out in my previous post that I've changed some original timer functions for HPET equivalents. (Before I knew that the HPET system is rather flawed in some cases.) I don't mind changing things, but I do need to find out what to change first.
Anyway, how does the trunk build fare when VSync and flushing functions are disabled in the two windowed modes and the exclusive mode for both EVR and VMR-9? (Each uses different timing modes. Now with adding FlipEx mode for Windows 7 with Aero enabled, I've also added yet another mode.)

[cca]

I should have pointed out in my previous post that I've changed some original timer functions for HPET equivalents. (Before I knew that the HPET system is rather flawed in some cases.) I don't mind changing things, but I do need to find out what to change first.
Anyway, how does the trunk build fare when VSync and flushing functions are disabled in the two windowed modes and the exclusive mode for both EVR and VMR-9? (Each uses different timing modes. Now with adding FlipEx mode for Windows 7 with Aero enabled, I've also added yet another mode.)

Urgh, VSync disabled? So I gave it a go, the results I get seem to be a lot like your build, random skips and stutters. As for the exclusive mode produces similar result with the windowed, random jerkyness but I did not observe tearing at least.

EVR and VMR9 gave the same results from what I can see.

I do not know precisely how the VSync works in the trunk builds, but it is doing a very successful job at eliminating all random phenomena for me. Without it, it's the same with the rest of the renderers I tried, random motion problems.

The most recent change you did with the FlipEx helped a lot, but not quite there yet.

[CruNcher]

If you use High Performance does it still stutter, do you have a sample that shows the biggest problems for you in motion i guess @ 60 hz ?

Windows Power Management plays a big role when it comes to fluid video Playback unfortunately, not so for DXVA but with memory copy going on Power saving can be a bad thing Balanced also seems to work fine but Power Saving to fullest isn't really worth it compared to the back fire (especially with DWM Aero and it's continuous memory copy). Though it also Depends on the CPU,GPU architecture alot Sandy Bridge is in those regards very efficient in switching (and it even switches without anyone really noticing it even in High performance most standard stuff hasn't the resolution to show it ;) ) and latency reduction, tough measuring with EVR-CPs OSD in general is a problem the text output itself consumes a fair amount of cycles (continuous timer firing) and causes itself latency. Windows 8 and WDDM 1.2 should improve this though further :)

I switched to Sandy Bridge early on and i can say in those regards it's top it saves power like crazy without really hurting the Performance and if i think about haswell it shivers down my spine how efficient that must be :)

@ Balanced SNB system result

http://img195.imageshack.us/img195/1843/balancedj.png

OSD overhead:

http://img254.imageshack.us/img254/3318/currentresosdoverhead.png

Graph only:

http://img844.imageshack.us/img844/386/currentgraphonlyoverhea.png

[cca]

Here's mine:
http://img190.imageshack.us/img190/9639/wintimer.jpg (http://imageshack.us/photo/my-images/190/wintimer.jpg/)
System was always set to Balanced anyway.

[CruNcher]

cca could you provide some of the animation scenes you have issues with (samples) :) ?

[cca]

cca could you provide some of the animation scenes you have issues with (samples) :) ?

Umm, all you need is any recent anime release encoded in H.264. This one for example (http://mazuisubs.com/171)

[CruNcher]

@cca

if that isn't stable i dunno what could be :) not 1 glitch flawless motion no problems, though this is 3752i not 3752ir

http://img10.imageshack.us/img10/1082/crazystable.png

and now the craziest ;)

Process Explorer run the whole time with a 0.5 ms timer, the GPU Spike comes from Firefox D2D Gif Animation rendering, i love SNB and NT 6, i guess i will top it off running ID tech 5 windowed ;) :D

[Hera]

With animation, you can only notice stuttering with panning / zooming scenes / 3D-animation.
2D animation many times is simply is 0/1/0/1 for things like mouth movement so you really cannot notice stuttering.
Additionally, some encodes introduce stuttering (stuttering that happens with all codecs and renderers).

I do not notice any renderer-imposed stuttering. :/

Offtopic: GIF performance is a long standing Firefox bug introduced and reported during Firefox 4 development and will probably be fixed by Firefox 10 or 11.

[CruNcher]

With animation, you can only notice stuttering with panning / zooming scenes / 3D-animation.
2D animation many times is simply is 0/1/0/1 for things like mouth movement so you really cannot notice stuttering.
Additionally, some encodes introduce stuttering (stuttering that happens with all codecs and renderers).

I do not notice any renderer-imposed stuttering. :/

Offtopic: GIF performance is a long standing Firefox bug introduced and reported during Firefox 4 development and will probably be fixed by Firefox 10 or 11.


it is fixed but CPU wise it came back shortly as a regression but is fixed again https://bugzilla.mozilla.org/show_bug.cgi?id=595671 it's a wild ride with it ;)
Tough you should look @ it carefull it's GPU usage not CPU usage ;) the bug was about high CPU usage that maxed out old CPUs really fast and even caused unacceptable high CPU usage on Multicores, though if you compare with current Chrome they push the load to IO which seems far from nice ;).

And yep a bad encode also can cause problems see evil tree as perfect example you need a very specific playback chain to play it flawless which makes rarely sense todo and better fix it like jan did fixing it's pulldown :)

The best testing Horizontal and Vertical fluidness is pushing a lot of different Ken Burns @ it ;)

i watched this complete Anime and didn't saw any problem with it's motion also in zooms and pans and there are a lot of different pans zooms and ken burns here with different speeds.

[cca]

Hehe, I know about the stutters already in the animation itself, the difference with them is that they are reproducible every time you view the video. The ones I notice are obviously always in panning scenes, and they are *not* the same every time you view the specific scene, hence they come from the renderer.

@CruNcher: I do not doubt it is stable for you, but it is not for me. I can view the same scene 10 times, and some times it will be stable, sometimes I will see jerkyness. That is too random and not how a proper renderer should behave. The only renderer to date that is 100% predictable in my own system is the current EVR-CP in the trunk builds.

What I do in the specific video I gave you is this: I fast forward to 19:30 and watch the panning scenes there ( :D ) then I rewind again back to 19:30 and watch again. Sometimes smooth, sometimes not. And me disappointed every time it happens.

EDIT: forgot to add: I do not rely on stats and numbers, I fall for this trap with madVR. They say no glitches and everything smooth. But it is not. I do my tests visually only, my only instrument are my own eyes.

[CruNcher]

Hehe, I know about the stutters already in the animation itself, the difference with them is that they are reproducible every time you view the video. The ones I notice are obviously always in panning scenes, and they are *not* the same every time you view the specific scene, hence they come from the renderer.

@CruNcher: I do not doubt it is stable for you, but it is not for me. I can view the same scene 10 times, and some times it will be stable, sometimes I will see jerkyness. That is too random and not how a proper renderer should behave. The only renderer to date that is 100% predictable in my own system is the current EVR-CP in the trunk builds.

What I do in the specific video I gave you is this: I fast forward to 19:30 and watch the panning scenes there ( :D ) then I rewind again back to 19:30 and watch again. Sometimes smooth, sometimes not. And me disappointed every time it happens.

EDIT: forgot to add: I do not rely on stats and numbers, I fall for this trap with madVR. They say no glitches and everything smooth. But it is not. I do my tests visually only, my only instrument are my own eyes.

let me try something i guess this is perfect to test something new, and yes never trust anything else then your eyes OSDs and stuff are nice but they are influenced and some times can be even the cause for issues themselves ;)
And so i can only tell that i stay with AERO for me and my Configuration it's perfect and i don't seem to need any exclusive modes so far :)

And yep debuging issues like you experience is not easy though Microsoft is working hard to provide solutions for this currently you have to go deep down and analyze the system to find the cause but in the future it will be much easier :)

[Hera]

With latest builds I am getting issues, (netbook)
- Crashes when opening files with EVR:CP {1.5.3.0 (3752ir)}
-- MPC:HC resizes itself for the video size, states "Playing [DXVA]", doesn't show video and crashes {1.5.3.0 (3752ir)}
- Doesn't crash with EVR {1.5.3.0 (3752ir)}
- Black Screen with Haali which fixes itself if I seek (aside from the video being messed up still obviously) {earlier than 3740 - not present on XP}
- Doesn't crash when opening EVR and THEN switching to EVR:CP and opening the file again {1.5.3.0 (3752ir)}
- Before restarting, it blackscreened for EVR:CP {1.5.3.0 (3752ir)}


Problem signature:
Problem Event Name: APPCRASH
Application Name: mpc-hc.exe
Application Version: 1.5.3.0
Application Timestamp: 4e8e1107
Fault Module Name: mpc-hc.exe
Fault Module Version: 1.5.3.0
Fault Module Timestamp: 4e8e1107
Exception Code: c0000005
Exception Offset: 001b86c2
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

[CruNcher]

http://www.mediafire.com/?fitumy3c9qf3p31 <- :) no fraps direct H.264 DWM Transcoding (including Pixel Shader) (speeduped to show the motion) ;)

[Hera]

You know what I think I might be getting stuttering/dropped frames every time a new line of subtitles get loaded. :|

[JanWillem32]

For these builds, I've mostly tried to solve the nasty bugs in the intermediate versions. I added the presentation timer of the frame interpolator to the new present method. (Really, this sounds like something more complicated than it actually is.) It's enabled for Vista and onwards in full screen exclusive mode and for 7 and onwards in windowed mode with Aero enabled. I improved the reset function on resizing by a lot. I've also made some optimizations for this mode when frame interpolation is active. (Although it still can't do the full 80 Hz in my case, but I need the exclusive mode for pretty much anything, anyway. For others it might work.)
I've also been analyzing the VSync thread. It will take some time to fix it again. Its standard endless loop that constantly analyzes the active monitor's raster status has a CPU usage that's far beyond the normal amounts. I don't know yet why. It's difficult to trace.
The FlipEx mode will leave the last presented frame behind in the active window, and it seems to be impossible to clear it. For now, I've added an extra present when closing the renderer that simply paints a black screen. I hope to find a proper clearing method later on.
I probably forgot something in addition to this all, I hurried to build these during breakfast time today :rolleyes:. I'll comment on previous posts and PMs later today.

[cca]

For these builds, I've mostly tried to solve the nasty bugs in the intermediate versions. I added the presentation timer of the frame interpolator to the new present method. (Really, this sounds like something more complicated than it actually is.) It's enabled for Vista and onwards in full screen exclusive mode and for 7 and onwards in windowed mode with Aero enabled. I improved the reset function on resizing by a lot. I've also made some optimizations for this mode when frame interpolation is active. (Although it still can't do the full 80 Hz in my case, but I need the exclusive mode for pretty much anything, anyway. For others it might work.)
I've also been analyzing the VSync thread. It will take some time to fix it again. Its standard endless loop that constantly analyzes the active monitor's raster status has a CPU usage that's far beyond the normal amounts. I don't know yet why. It's difficult to trace.
The FlipEx mode will leave the last presented frame behind in the active window, and it seems to be impossible to clear it. For now, I've added an extra present when closing the renderer that simply paints a black screen. I hope to find a proper clearing method later on.
I probably forgot something in addition to this all, I hurried to build these during breakfast time today :rolleyes:. I'll comment on previous posts and PMs later today.

It shall be tested of course, when I get back home. Weekdays are loaded with work :/

[cca]

Unfortunately the new build brought this error:
http://img88.imageshack.us/img88/4654/errorosi.png (http://imageshack.us/photo/my-images/88/errorosi.png/)

Subsequent tries result in instant crashes, or, if I try a simple .avi, the playback stays paused, doesn't autostart.

[golagoda]

It's been working fine for me as always at least ;)

[CruNcher]

Wow jan that is some strange new behavior the video plays ok though after switching which still is heavily delayed and glitchy it doesn't stop anymore the funny thing it doesn't plays like the .wtv thing normal but a long time in slow motion the pause button is pushed and it continuous in slow motion very odd i wonder if i can record this :) :D

Wow it goes hi wire ???

Ok so it happens as follows

1, Drag and Drop like normal nicetest.ts into the MPC-HC tester window
2. it doesn't instantly plays it back but pauses ?
3. When clicking play it starts to playback in slow motion with heavy glitches opening the OSD looks crazy and when pause is pushed it stops but the video plays in slow motion in the background and audio stutters like crazy :P

hmm is it correct that mpc-hc SSE2 tester dfr3753 shows as version 1.5.3.0 ?

[JanWillem32]

I've made the access to the virtual subtitle renderer interfaces a bit more robust and improved the timing initialization functions for both the video and subtitle renderer.
The initialization functions are still a bit vulnerable to resizing immediately after opening. This can be caused by the "View", "Statistics" item or the playlist bar, for example. These items change the size of the video window after the renderer starts, so it immediately resets itself. The same type of problem can be observed with the full screen windowed mode's main bar.
I've added an optimization to the general paint speed. When not hindered by rendering a subtitle, alternative VSync or frame interpolation, paint time should be about 10% lower than before.

[golagoda]

I've made the access to the virtual subtitle renderer interfaces a bit more robust and improved the timing initialization functions for both the video and subtitle renderer.
The initialization functions are still a bit vulnerable to resizing immediately after opening. This can be caused by the "View", "Statistics" item or the playlist bar, for example. These items change the size of the video window after the renderer starts, so it immediately resets itself. The same type of problem can be observed with the full screen windowed mode's main bar.
I've added an optimization to the general paint speed. When not hindered by rendering a subtitle, alternative VSync or frame interpolation, paint time should be about 10% lower than before.

x64: http://www.mediafire.com/?qjxmdfbt1fj3ymo
x86 SSE2: http://www.mediafire.com/?6i89id0m4vfp16g

Will use and test out the x86 SSE2 later today, thanks for these builds and keep up the great work ;)

[CruNcher]

yep the new version has problems with to fast close and open that causes the slow motion start it doesn't pause anymore on load though :)
ok once it's stable starting without slow motion, open the OSD causes a small hickup for say 10 seconds then it's fine :)
Switching to full window is still ok small glitch then fine but switching to Fullscreen causes it to go slow motion hi wire again.
Also it crashes some loads randomly it seems, most loads though after the first you either get slow motion or crash and it's hardly stable.


changing to fullscreen (it doesn't recover here anymore) :

http://img24.imageshack.us/img24/4181/fullscreenhiwire.png


So in my (Aero) use case for now 3752i EVR-CP was still the most stable (the only issue was the on demand size switching compared to trunk but it is seamless no glitches their) of the testers so far with (Intel HD Graphics DXVA2, Driver: 2509)

3752i (perfectly stable if on demand resize needs to be)
3752ir (started the problems)
3723 (still issues)
3754i (still no good,even worse hardly recovers @ all, crashes randomly)

[JanWillem32]

@golagoda: Always nice that some users are easy to please. :)
@CruNcher: Let's have another try (or a few more, this is a new present mode after all).

I've fixed the alternative VSync code for the GDI windowed mode.
For the FlipEx mode I've improved the detection rules. I hope this will clear up most issues with crashes and errors in the animation speed. The jitter graph will show saw-tooth graphs just above the middle line when its scheduler is delaying frames. This might show up less often when the full screen statistics are shown, as the text drawing commands increase the paint time by a few extra milliseconds.

[watchman]

Hello. I don't know if this is right thread to post a request about subtitle renderer, but I saw on the first page that you also are working on improving it.

I'd be really happy if it's possible to implement option similar to "Position subtitles relative to the video frame", but without resizing the font. The point of this is to always have subtitles above the bottom black bar with all combinations of monitor/source video aspect ratios, but preserve predefined font size.:thanks:

[JanWillem32]

Can you please specify that in more detail? I can't really imagine a way I could make this work in general.
For bitmapped subtitles, such as those on DVD and blu-ray, I can only change the size, position and aspect ratio of the entire image. There's no embedded data on the actual font size or subtitle position inside these types.
For the plain text subtitles, it should be possible to set one font size, independent from the window size. It would then behave the same as the OSD (including the clipping behavior on smaller window sizes).
For styled text subtitles, font size, formatting and positioning data is written in the file itself. All items are given in window coordinates, so resizing with this type gives the same problem as with the bitmapped types; all positions will be scaled and offset, and entire lines/items can be pushed outside the window area.

[watchman]

Can you please specify that in more detail? I can't really imagine a way I could make this work in general.
For bitmapped subtitles, such as those on DVD and blu-ray, I can only change the size, position and aspect ratio of the entire image. There's no embedded data on the actual font size or subtitle position inside these types.
For the plain text subtitles, it should be possible to set one font size, independent from the window size. It would then behave the same as the OSD (including the clipping behavior on smaller window sizes).
For styled text subtitles, font size, formatting and positioning data is written in the file itself. All items are given in window coordinates, so resizing with this type gives the same problem as with the bitmapped types; all positions will be scaled and offset, and entire lines/items can be pushed outside the window area.

I'm sorry, I probably did not post all the relevant info. I was talking about external file plain text subtitles (.srt for example).


Here is a simple example how it works now (with "Position subtitles relative to the video frame"):
When playing 4:3 video on 16:10 screen, subtitles have correct font size and are n pixels from the bottom of the screen (because there are simply no horizontal black bars)

When playing movie with cinematic aspect ratio on 16:10 screen, subtitles are n pixels above the bottom black bar, but font size is much more smaller and subtitles are almost impossible to read.


This is how it works without that option checked:
Subtitles always have same predefined size and are n pixels above the bottom of the screen, so if I want to have them inside video frame, I have to change the "Bottom" value for every different screen/source aspect ratio, because black bars have always different height.


With predefined/correct font size I just mean settings in mpc-hc font options in Subtitles / Default Style -> Font.

All I asked is just to provide some "automatic horizontal positioning relative to video frame", which will simply lead to always having subtitles inside video frame n pixels above the bottom of the video frame.

With n I mean "Bottom" value in Screen Alignment & Margins options

/edit: I found that subtitles are resizing with video and looks like it's somehow related to screen resolution/video resolution ratio. So to be even more specific, I was talking about case when video is resized to FS (as it looks like that mpc font settings are apllied to this case). Downscaling subtitles with video frame relative to screen resolution is cool indeed and I have no intention in asking to change it :)

/edit2 "A picture is worth a thousand words":
Here are two screenshots of what I was writing about. Hope it will make everything clear :)

How it should look every time: http://imageshack.us/f/827/correctp.png/
How it looks with black bars: http://imageshack.us/f/88/toosmall.png/

[cca]

@golagoda: Always nice that some users are easy to please. :)
@CruNcher: Let's have another try (or a few more, this is a new present mode after all).

I've fixed the alternative VSync code for the GDI windowed mode.
For the FlipEx mode I've improved the detection rules. I hope this will clear up most issues with crashes and errors in the animation speed. The jitter graph will show saw-tooth graphs just above the middle line when its scheduler is delaying frames. This might show up less often when the full screen statistics are shown, as the text drawing commands increase the paint time by a few extra milliseconds.

x64: http://www.mediafire.com/?23fn9b9m6q4alqo
x86 SSE2: http://www.mediafire.com/?c01602kwqpjay4v

Sounds promising, will try it later today.

[CruNcher]

@golagoda: Always nice that some users are easy to please. :)
@CruNcher: Let's have another try (or a few more, this is a new present mode after all).

I've fixed the alternative VSync code for the GDI windowed mode.
For the FlipEx mode I've improved the detection rules. I hope this will clear up most issues with crashes and errors in the animation speed. The jitter graph will show saw-tooth graphs just above the middle line when its scheduler is delaying frames. This might show up less often when the full screen statistics are shown, as the text drawing commands increase the paint time by a few extra milliseconds.

x64: http://www.mediafire.com/?23fn9b9m6q4alqo
x86 SSE2: http://www.mediafire.com/?c01602kwqpjay4v

Hehe i take that as a compliment ;)
much better still glitches slightly (especially the audio glitching is annoying) at resize but stability and jitter recovery are ok again :)

http://img191.imageshack.us/img191/3184/glitchu.png

[Matching_Mole]

For bitmapped subtitles, such as those on DVD and blu-ray, I can only change the size, position and aspect ratio of the entire image.

It existing already a way to change the position and the size of bitmapped subtitles? If not, do you plan to implement one day?

Thanks for all your great work.

[cez4r]

Hi! There are 2 problems under XP with 3 latest builds: 3753, 3754i and 3755i.
1) small bug: with checked option to store settings to .ini file, these builds insert many empty keys under: HKEY_CURRENT_USER\Software\Gabest\Media Player Classic.
The 3751 and 3752ir versions don't do this.
2) big problem w/ EVR-CP: there's long opening and no rendering of files, and MPC-HC stays in memory after closing (after "playing" files).
It's OK with 3751 and 3752ir versions. I have an ATI IGP HD4290.

[Hera]

notebook:

Resizing seems to take longer.
And the really annoying thing is that the seek bar in fullscreen mode resizes the video all the time.
I also tried enabling 16f surfaces and that caused the player to crash - did not happen again though.

[JohnLai]

Problem : I just noticed ur build is unable to load subtitle if it are external idx and sub.

[nand chan]

I'm afraid I haven't quite understood the “ATI Video Chroma Up-sampling fix” option yet.

If I set it to, say, “4:2:0, Mitchell-Netravali cubic5”, and input YV12, does that mean that chroma information gets upscaled to 4:4:4 using that filter, then both get upscaled using my chosen luma filter?

I'm asking because I've just finished switching from madVR to EVR-CP but I'm still curious about this option. In madVR, I could set the chroma and luma scalers separately, so I could use a softer scaler for chroma and a sharper one for luma. Am I correct in assuming that I will get the same behavior with this option?

What about nVidia users, why can't they have separate chroma upscalers?

Edit: Also why does it start paused if you open files from the menu?

[Hera]

There is a spike every time a new subtitle line is loaded and noticeable frame dropping because of this.

If no stuttering is {A,B,C} then what I am seeing is {A,C} or {A,B,A,C} or {A,B,A,B,C} if subtitles get loaded at B
I think this is new; subtitle performance regressed, before I only noticed issues with animated subtitles.
Recently got frame dropping when showing a few lines of subtitles - never had this issue before.


I think you broke subtitle buffering or something.

[nand chan]

Also, are there any plans on including support for P010 or other 10-bit formats as input?

[nevcairiel]

As i understood it, the EVR is not really equiped to deal with 10-bit input formats.

[nand chan]

As i understood it, the EVR is not really equiped to deal with 10-bit input formats.

Why not? It handles 32 bit floating point textures and processing just fine, and it can output 10 bit A2R10G10B10 to the display in D3D fullscreen mode. The only thing it's lacking is 10 bit input, but all dithering, post processing etc. is done with 32 bit precision then dithered down to 10. (Which is more than madVR will probably ever be capable of)

[Mangix]

madVR does processing in 48-bit IIRC and scales down to 8-bit. 10-bit output is missing only.

[nand chan]

madVR does processing in 48-bit IIRC and scales down to 8-bit. 10-bit output is missing only.

By 48 bit you mean 16 bit. 16 × 3 = 48, because there are three channels. There's no such thing as a 48 bit floating point number. If you want to do it that way, then EVR-CP would be 96 bit.

[nevcairiel]

Why not?
Because that part is handled in the EVR mixer, which is a completely separate part to the presenter which does all the other things you speak of.

The mixer is still the vanilla Microsoft Mixer, which is quite limited. It even doesn't properly support 4:4:4 AYUV input.
It only supports formats that are natively supported by the hardware as texture formats, which may include 32-bit float, but only in RGB space, not in sub-sampled YUV.

To add all these missing features, one would have to rewrite the whole mixer, as you can't just "extend" the built-in mixer. EVR is not a design suited for such advanced tasks, once you have replaced the mixer and the presenter, you could as well just get rid of the remaining minor parts of EVR, and write a new renderer from scratch. JanWillem looked into 10-bit input a while ago, and concluded that its currently out of reach.

In comparison, writing a Presenter to replace the default presenter is easy, the mixer is the hard part.

EVR is really just a wrapper around the hardware, with the addition to run pixel shaders on the content, but it'll never reach a flexibility or feature set a stand-alone renderer would be capable of.
It also has alot of other serious limitations, mostly regarding dynamic format changes and RGB levels. For example, EVR is incapable of dynamically switching its input pixel format, which means if its not possible to probe the best pixel format before decoding, you'll end up down-converting the video because EVR failed at dynamically switching to the best format. There are quite some other difficulties with it, but thats one of the bad ones. :)

PS:
I still think 32-bit float is just wasted computational power. The actual output is 8 (or maybe 10) bit. What good is creating a intermediate result in 32-bit precision?
More bits = more better, right? :)

PPS:
If this is all about the subtitle issue, why not just work on fixing that situation? :d

[nand chan]

Because that part is handled in the EVR mixer, which is a completely separate part to the presenter which does all the other things you speak of.

The mixer is still the vanilla Microsoft Mixer, which is quite limited. It even doesn't properly support 4:4:4 AYUV input.
It only supports formats that are natively supported by the hardware as texture formats, which may include 32-bit float, but only in RGB space, not in sub-sampled YUV.

To add all these missing features, one would have to rewrite the whole mixer, as you can't just "extend" the built-in mixer. EVR is not a design suited for such advanced tasks, once you have replaced the mixer and the presenter, you could as well just get rid of the remaining minor parts of EVR, and write a new renderer from scratch. JanWillem looked into 10-bit input a while ago, and concluded that its currently out of reach.

In comparison, writing a Presenter to replace the default presenter is easy, the mixer is the hard part.

So basically, I have to keep inputting NV12? Wouldn't it be possible to, say, upscale P010 -> Y410 then convert that to RGB32 (A2R10G10B10) in software, and pass the RGB32 texture to the EVR mixer, and have it convert that to a 32 bit floating point texture?

EVR is really just a wrapper around the hardware, with the addition to run pixel shaders on the content, but it'll never reach a flexibility or feature set a stand-alone renderer would be capable of.
It also has alot of other serious limitations, mostly regarding dynamic format changes and RGB levels. For example, EVR is incapable of dynamically switching its input pixel format, which means if its not possible to probe the best pixel format before decoding, you'll end up down-converting the video because EVR failed at dynamically switching to the best format. There are quite some other difficulties with it, but thats one of the bad ones. :)

If mixed with the idea above that could become a non-issue, just always pass RGB32.

PS:
I still think 32-bit float is just wasted computational power. The actual output is 8 (or maybe 10) bit. What good is creating a intermediate result in 32-bit precision?
More bits = more better, right? :)

Always. I'm doing a lot of post processing so I want my bits. :(

PPS:
If this is all about the subtitle issue, why not just work on fixing that situation? :d

Nah, it's not about the subtitle issue. I've given up on that, with the conclusion that all subtitle renderers are shit. Oh, I should mention that EVR-CP color corrects subtitles properly unlike madVR, so that's another plus!

[nevcairiel]

You could convert to rgb before but you would have to do that in software - so you could as well do so in the decoder or a post processor. Maybe one could teach EVR to do it on the surface somehow, but it would require quite some rewriting (up to some point where it really isnt EVR anymore :))

IHMO, Your best option really is to write your favorite chroma upscaler in C or ASM and let me use it in LAV Video. :)

[nand chan]

You could convert to rgb before but you would have to do that in software - so you could as well do so in the decoder or a post processor. Maybe one could teach EVR to do it on the surface somehow, but it would require quite some rewriting (up to some point where it really isnt EVR anymore :))

IHMO, Your best option really is to write your favorite chroma upscaler in C or ASM and let me use it in LAV Video. :)

Never done graphics processing in ASM though, nor have I really worked with SSE2, the FPU etc. or any of that. x86 ASM is such a mess. I'll have to give it a try sometime though.

Then we'd basically have the best case scenario as far as I'm concerned:

1. LAV Video uses libav to decode the Hi10P source into P010
2. LAV Video uses a nice Mitchell-Netravali upscaler to pull this up to Y416
3. LAV Video uses its matrix information from the source to convert this to R16G16B16 or similar
4. LAV Video dithers this down to X8R8G8B8 RGB32
5. VSFilter paints its subtitles ontop of this RGB32 stream
6. EVR mixer accepts the RGB32 and transfers it to the VRAM as 32-bit floating point
7. all additional post processing, color management, upscaling, shaders etc. etc.

The only weak link in this process would be VSFilter for forcing dithering down to 8 bit, but with the correct algorithms this is basically bit perfect (compared to first post processing, and then dithering).

Edit: Doesn't swscale already have the code for Mitchell-Netravali?

[nevcairiel]

Edit: Doesn't swscale already have the code for Mitchell-Netravali?

It does have a bicubic scaler on which you can adjust the B and C arguments freely, which looks alot like a Mitchell-Netravali filter from all the coefficients used.
I do however not know how well the bitdepth is preserved if i ask it to convert 420p10 to 444p16, for example.

This would require some investigations - also regarding its speed.
Before i do that, what values for B and C would you prefer anyway? Default is B=0, C=0.6

[nand chan]

It does have a bicubic scaler on which you can adjust the B and C arguments freely, which looks alot like a Mitchell-Netravali filter from all the coefficients used.
I do however not know how well the bitdepth is preserved if i ask it to convert 420p10 to 444p16, for example.

This would require some investigations - also regarding its speed.
Before i do that, what values for B and C would you prefer anyway? Default is B=0, C=0.6

I haven't done such extensive testing. I just used whichever values madVR has for that option (which doesn't allow changing the B/C parameters). I doubt I'd notice it much since it's only for chroma information though.

I think it would be better to write a custom implementation (and test it well) before turning to something as large/bloated and dubious (eg. faulty depth algorithms) as swscale.

Edit: I looked at the paper, seems like Mitchell & Netravali recommend 1/3 for both

Edit 2: Seems like swscale is practically too slow for realtime usage when working with 444p10 and similar. It would probably also be best to pull up to 420p16 yourself then just do a conversion from 420p16 to 444p16, if anything. That way you can assure it doesn't do stupid shit or destroy the levels.

[Hera]

/\
Golden audio jacks discussion.

[nand chan]

/\
Golden audio jacks discussion.

When you spend more time tweaking your players and obsessing about quality than you spend actually watching things, these things sort of matter.

Ps. I use golden plated 6.35mm TRS connectors, any smaller should not be used due to the possibility of cross-channel interference.

Pps. @nevcairiel: Aren't you on any IRC channels? I find discussion on doom9 to be a bit too slow tbh.

[nevcairiel]

Pps. @nevcairiel: Aren't you on any IRC channels? I find discussion on doom9 to be a bit too slow tbh.

I'm on the #mpc-hc channel on freenode

[CruNcher]

When you spend more time tweaking your players and obsessing about quality than you spend actually watching things, these things sort of matter.

Ps. I use golden plated 6.35mm TRS connectors, any smaller should not be used due to the possibility of cross-channel interference.

Pps. @nevcairiel: Aren't you on any IRC channels? I find discussion on doom9 to be a bit too slow tbh.

Audiophiles and Videophiles are sometimes good if they involved in the development a good mix of Film Video and Anime Videophiles isn't bad but they should never dictate development goals entirely that would be catastrophic ;)

[Nevilne]

As seen on hydrogenaudio :)

[JanWillem32]

@watchman: I'll take a look at the basic text subtitle renderer later on. Right now I didn't really find the exact code that handles these things. The subtitle renderer code lacks comments, proper file naming and organization unfortunately. I'll have to spend some time to analyze some parts.

@CruNcher: That's a lot better. I've started working on solving the audio issue (it's caused by improper multi-threading). It's a bit hard to do for me since I'm really not used to handling GUI items like the window frames used for the player. For example: the alpha version that allows fast switching from and to exclusive mode messes up the window size when returning to windowed mode. I have no idea why yet. I'll upload a build later to show what I mean (and for some crash testing).

@Matching_Mole: There is an option to override placement for subtitles, but I'm not very sure it will work properly. So far I've even seen that one type of bitmapped subtitle is always stretched to the window size (aspect ratio correction broken).

@cez4r: Thank you for noticing, I would never have guessed issues with registry settings.
The second issue probably needs a bit more analysis, I'll look up which one of the changed items could be causing this.

@Hera: Optimization for the new present mode isn't completely finished yet. The reset initialization in the renderer for resizing a window is fast, but the main window tread takes forever to respond properly and alter the rendering device (just a reset on the software port to the DirectX interface, not the entire graphics driver).
I've noticed the spikes from the subtitle renderer too. When fixing the Alternative VSync item, I've changed the order of where a frame is presented to what it was in the trunk build. I'll change it back once I'm sure that it doesn't break the brittle Alternative VSync function.

@JohnLai: Only when the .idx and .sub combination is external? I'll have to test and see. I did have a few problems getting the blu-ray and VOBSUB renderers to behave properly in a sense of the subtitle renderer's normal read/write schedule. That probably caused it.

@nand chan: The chroma scalers are specialized resizers for 2× height and width. Luma isn't scaled.
After resolving the chroma 'bug', the colorspace is converted to R'G'B' or linear RGB, which is used for general resizing in a later stage. It only applies to ATi at the moment, as both Intel and Nvidia force bilinear filters in the video processor's black box of the VMR and EVR mixers.
At a later stage I'll try to implement a better color space for gamut consistency (XYZ or xyY most probably). For now linear RGB suits the renderer fine. I was already glad to get rid of the gamma distortion.

About the mixers, I'm indeed not very happy with those. If I only knew how to pull a DirectShow or MediaFoundation pin and get raw bits out of it, I would have added a few custom mixer modes a long time ago. Creating working surfaces for the raw data to transfer to is reasonably easy, but I can't find any proper guides on handling pins. Both EVR and VMR obscure it completely, in many cases you can't even get the original stream information properly from the current mixers.
A minor exception to that rule is the DXVA helper device for EVR CP and Sync. It allocates proper NV12 surfaces on the video card, and then throws those into the mixer...

[nand chan]

@nand chan: The chroma scalers are specialized resizers for 2× height and width. Luma isn't scaled.
After resolving the chroma 'bug', the colorspace is converted to R'G'B' or linear RGB, which is used for general resizing in a later stage. It only applies to ATi at the moment, as both Intel and Nvidia force bilinear filters in the video processor's black box of the VMR and EVR mixers.
At a later stage I'll try to implement a better color space for gamut consistency (XYZ or xyY most probably). For now linear RGB suits the renderer fine. I was already glad to get rid of the gamma distortion.

But what's the difference between the 4:2:0 modes and the 4:2:2 modes? Do I have to select the right one based on what input I get? Why can't it do this automatically?

[JanWillem32]

Once I've found a stable method to read such things, I will. It's currently something the renderer does without consulting the mixer. VMR-9 doesn't expose much information about what it receives from its pins, EVR a bit more if you continuously query its mixer COM pointers, but both are pretty bad at it. I would need to read from the filter graph builder to get proper information like in the filters menu. There are no interfaces linking the renderer to it unfortunately, so that makes it quite a bit harder.

[nand chan]

Once I've found a stable method to read such things, I will. It's currently something the renderer does without consulting the mixer. VMR-9 doesn't expose much information about what it receives from its pins, EVR a bit more if you continuously query its mixer COM pointers, but both are pretty bad at it. I would need to read from the filter graph builder to get proper information like in the filters menu. There are no interfaces linking the renderer to it unfortunately, so that makes it quite a bit harder.

Here are two example builds that can switch between windowed mode and exclusive mode on the fly. Not for general usage. I wonder how I should fix that window?
x86 SSE2: http://www.mediafire.com/?r36sq36676ti432
x64: http://www.mediafire.com/?zv9zjsnwr4whn8o

If you do manage to get this to work somehow (just create your own interface for the same code that the Filters menu uses?), it would make the process trivial, since the required information can simply be pulled from biCompression (or read from pbFormat at offset 0x58, length 4)

Creating working surfaces for the raw data to transfer to is reasonably easy, but I can't find any proper guides on handling pins

Do you know how madVR and Haali's renderer do it? You could probably inspect/mimic/borrow code from those. It would be real nice to see software conversion to RGB32 added to EVR-CP (optional, of course), since that would probably make it the best renderer currently available - especially if it supports 10-bit.

On that matter, does EVR's in-house mixer support X2R10G10B10 input at all?

[CruNcher]

Once I've found a stable method to read such things, I will. It's currently something the renderer does without consulting the mixer. VMR-9 doesn't expose much information about what it receives from its pins, EVR a bit more if you continuously query its mixer COM pointers, but both are pretty bad at it. I would need to read from the filter graph builder to get proper information like in the filters menu. There are no interfaces linking the renderer to it unfortunately, so that makes it quite a bit harder.

Here are two example builds that can switch between windowed mode and exclusive mode on the fly. Not for general usage. I wonder how I should fix that window?
x86 SSE2: http://www.mediafire.com/?r36sq36676ti432
x64: http://www.mediafire.com/?zv9zjsnwr4whn8o

Same issues as before (Audio issue @ switching no seamless switching possible) + Black Screen when switching to Exclusive Mode (Audio Plays) (both issues aren't in currently preferred 3752i)

[watchman]

@watchman: I'll take a look at the basic text subtitle renderer later on. Right now I didn't really find the exact code that handles these things. The subtitle renderer code lacks comments, proper file naming and organization unfortunately. I'll have to spend some time to analyze some parts.

Hi. I tried to take a look at the source code and I was able to find it pretty quick and also modify it to my needs since it didn't require any special technical knowledge. So you don't have to bother with it anymore. Anyway, thank you for being willing to help :thanks:

I think it would be good if this little modification can find its way to official repository so everyone can benefit from it. I uploaded new source file so you can quickly see changes using some diff sw: http://www.mediafire.com/?43wvyuuuym85g50 (for quicker orientation I added comment lines above every change I did //watchman modification)

I also did one more little improvement, which I think is also very nice (also contains //watchman flag). Its purpose is to not use bottom positioning value if aspect ratio is bigger then 2.0f. Reason of this is to not have subtitles too low if watching video with aspect ratio like 16:9, but also not have subtitles too high if watching movie with cinematic aspect ratio :D

The thing is that hardcorer number like this is not very universal and there might be someone who wants to use different ratio outline, which will better suit his display needs. But unfortunately I'm not really into this old school C++ GUI stuff so I'm not able to do it by myself.

[nand chan]

JanWillem32, can you give me a more detailed explanation of what the pre-resize and post-resize shaders should input/output? eg. something like:

Pre-resize shaders:
Input primaries:
Input gamma curve:
Input white point:
Input value range:
Output primaries:
Output gamma curve:
Output white point:
Output value range:

Post-resize shaders:
Input primaries:
Input gamma curve:
Input white point:
Input value range:
Output primaries:
Output gamma curve:
Output white point:
Output value range:

[Matching_Mole]

@Matching_Mole: There is an option to override placement for subtitles, but I'm not very sure it will work properly. So far I've even seen that one type of bitmapped subtitle is always stretched to the window size (aspect ratio correction broken).

I use regular MPC-HC version with this option activated since ages and, if it works perfectly with text based subtitles, it do not works with bitmap based subtitles... at least the ones from DVD and Blu-ray (I do not use *.idx and *.sub ones).

[janos666]

@ JanWillem32,

I think there is a problem with the PC->TV shader which you integrated into your MPC-HC builds: click (http://forum.doom9.org/showpost.php?p=1532287&postcount=19)

Your method tries to do something about the different Y and Cb,Cr ranges but it fails. The bright primary colors have huge luminance errors (I think they would be C=240 if there were no rounding/clipping errors but they should be 235).

I am sure it's the PC->TV shader because:
1: I was always suspicious about it,
2: I couldn't find any problems when I don't use it: the upper three color values are always 251,253,255 for all primary colors and 0-0 for the other channels, so they are clipped properly and there is no difference between the individual channels.

[janos666]

And with your latest SSE2 build, I do have the "soup opera effect" (and some disturbing artifacts, something like a smooth "false contouring") with the Basic motion interpolation method, but the Precise methods still refuse to do anything.
My GPU switches to "DXAV clocks" when I start the playback and the GPU utilization is almost zero, even with a running Basic motion interpolation.

What do you think about an interpolation like this?
A-A-AB-B-B-BC-C-C-... where AB is an interpolated frame between the A and B frames.
This way we could spare ourselves from the "soup opera effect" and spare the GPU from some processing (or use that processing power to do more advanced interpolation...) and hopefully minimize the possibility of the noticeable artifacts (less interpolated frames = less place for errors and less probability of the detection of the interpolation errors).

[Hera]

I noticed that, in the main MPC thread, someone called you out on not buffering subtitles - whats up with that?

Also, the very latest build fails D3DFS.

[ADude]

Can Jan - or someone else - summarize that actual visual benefits - from the changes in the code that are described in the first post in the thread ?

Thanks !

[golagoda]

Can Jan - or someone else - summarize that actual visual benefits - from the changes in the code that are described in the first post in the thread ?

Thanks !

I'll put it this way - the things that have been improved, have improved. EVR still takes precise setting up to get right, and these builds can sometimes break features (Keep in mind that this is the latest trunk version, and then on top of that it's edited), but it's still better than the normal MPC-HC.

I personally don't even use EVR most of the time, I just use these for the internal subtitle renderer improvements, SSE2 optimisations and that it's based off the trunk MPC-HC, so it's very up to date and I can't be bothered getting the trunk versions from that xvidvideo.ru site or whatever it is, or getting visual studio to compile it myself

[ADude]

I'll put it this way - the things that have been improved, have improved. EVR still takes precise setting up to get right, and these builds can sometimes break features (Keep in mind that this is the latest trunk version, and then on top of that it's edited), but it's still better than the normal MPC-HC.

I personally don't even use EVR most of the time, I just use these for the internal subtitle renderer improvements, SSE2 optimisations and that it's based off the trunk MPC-HC, so it's very up to date and I can't be bothered getting the trunk versions from that xvidvideo.ru site or whatever it is, or getting visual studio to compile it myself

Other than subtitles, are these improvements anything that would improve the video watching experience, and if so, how ?

(I understand that performance and efficiency are important in the long-run and are laudable goals, but that is not what I am asking about in this question, thanks.)

[CruNcher]

@ Jan
Potplayers Direct3D9 Renderer seems to be very efficient (1080p) it's like 30% GPU for MPC-HCs (EVR-CP) and 8% for Potplayers Direct3D9 renderer with DXVA (Renderless and 1 time Native which increases CPU a little from 3% to 9% for Potplayer but holds GPU @ a whopping 8%)
Hmm it looks promising if they can get Shader support working on it :) (MadVR lowest GPU i could get was 17%).

Also Mirillis Custom Renderer used in Splash Player looks very interesting (from a Performance view) though they even have PS support with the same low GPU (when PS disabled).that Potplayers Direct3D9 Renderer provides

http://img254.imageshack.us/img254/5725/mpchcevrcpvspotd3d9.png

[toniash]

@cruncher
How to use Pixel Shaders with Mirillis Splash Player?

[CruNcher]

toniash Detail Boost http://downloadmirillis.com/gfx/clips/DetailBoostDemo01.swf?scale=noscale&tag1=Mirillis%20DetailBoost if im not wrong it's a PS (im not 100% sure though) :)

[toniash]

tohiash Detail Boost if im not wrong it's a PS (im not 100% sure though) :)

It must be if it increases GPU use, I haven't tried

[CruNcher]

not essentialy it could also be a OpenCL or Direct Compute implementation but most probably it isn't (because of hardware interoperability reasons and GPU reach without needing to fall back to Software) ;)

[Keiyakusha]

toniash Detail Boost http://downloadmirillis.com/gfx/clips/DetailBoostDemo01.swf?scale=noscale&tag1=Mirillis%20DetailBoost if im not wrong it's a PS (im not 100% sure though) :)

It looks more like they mislabeled these 2 photos. Sharper one is an original and other one is last.blur().blur() :D

[JanWillem32]

It's certainly busy here. I'm sorry that I can't really go in-depth right now. I'm very busy, because I have exams coming up (which I'll probably fail, as usual).
A nice bonus of the last few days was the big change in internal codecs. I'll need time to test all of that.
I'll try to go over the responses briefly, starting from #564.

@nand chan: I'd love to take a look at mixer code and then copy it 1:1, as the current mixer handlers are pretty much hollow shells for loading external DLL files. I've searched for this kind of code before, but couldn't find anything to import. I'm not going to read the entire DirectShow standards to completely custom write this kind of code.
Software conversion to RGB32 is available in both VMR-9 and EVR, and both are dead slow at it (no support for formats over 8-bit RGB output, either). The mixer that uses the video card is a lot more flexible.
A2R10G10B10 will probably be accepted, but EVR isn't exactly good at doing RGB to RGB conversion from DirectShow to working surfaces. I've ranked the RGB formats as the very lowest for the mixer, mostly for that reason.

@CruNcher: The test type was only different in handling the switching between windowed mode and exclusive mode on the fly. It wasn't really good at it, but it was possible (for most). I've kept some parts of that code and I'll try to fully implement such a function later on.

@watchman: How nice that you could find the target code. Maybe you have a knack for working with code like that. :) We can definitely integrate new functions into the trunk build, as long as it involves individual patches. I was already planning to submit some of my previous patches once I have some more time again. These can be added as well, but you might be able to persuade another developer to help sooner. To work out descriptive comments, GUI items and such, try the MPC-HC IRC channel and ask, else you can post on trac. Please keep me informed when I get back to developing. I'd love to help out properly when I can.

@nand chan: The pre-resize shaders can be used to convert to a working format, similar to the integrated initial pass section. The pack's set of color controls (also included with the chroma interpolators) are a good example of this.
The post-resize shaders are mostly for effects at window resolution. Preparation for display output is property of the final pass section. It's the only spot where such changes won't interfere with the rest of the filter chain.

@Matching_Mole: So it's the same with all bitmapped subtitles... I'll have a look at all four variants, then.

@janos666: I'll try to make a release build that doesn't have the clipping problem while nearest neighbor filtering is active. (It's already fixed it in an intermediate debug type.) Let's try to find the right function after that.

The basic interpolation method lacks any artifact cleanup, that's the main reason for the false contouring on items two frames earlier or later (can be seen clearly for a moment when pausing). It's pretty normal that it doesn't take much processing. The function is integral with the final pass (it doesn't add another filtering pass) and the code is pretty small and efficient.
I'm still looking at making additional frame interpolation modes and refining the current ones, but I haven't seen any good code resources on this yet, unfortunately.
Interpolation exactly in between two frames still has many artifacts with the methods I've currently implemented. I've been reading a bit about deinterlacing technology to see if there's a trick to it. (Not much progress so far.)
If anyone can find basic math or programming on frame interpolation or deinterlacing techniques, I'll happily take a look at integrating it.

@Hera: The buffer works fine. The execution order for rendering items in the paint was better the way it was before I started to fix Alternative VSync a few builds ago, though.

@ADude: I've mostly been trying to boost efficiency, before even trying to integrate filters/settings/stages that can improve quality. There's still a lot to do, though.

@golagoda: Indeed, a varied tester community is the best to quickly find various problems in the items I edit. Especially with the video renderer and DXVA related items, as various systems react in various ways to code in there.

@ADude: I've added a few extra resizer filters (and I really need to add some more), I've integrated some extra filters in the renderer settings menu and people can always insert a custom pixel shader (or copy one of mine).

@CruNcher: A custom mixer and a basic StretchRect will consume a lot less than a big video processing chain (with EVR and VMR-9 as added weight). I'd love to take a look at how they did it code-wise, maybe I can learn a thing or two from that.

I'll skip the last few posts, and go to bed next... I really wasn't planning on staying up this late today (2 a.m. here).

[Qaq]

Jan, good luck with exams.

[nand chan]

@nand chan: The pre-resize shaders can be used to convert to a working format, similar to the integrated initial pass section. The pack's set of color controls (also included with the chroma interpolators) are a good example of this.
The post-resize shaders are mostly for effects at window resolution. Preparation for display output is property of the final pass section. It's the only spot where such changes won't interfere with the rest of the filter chain.

You seem to have misunderstood my questions. What is the set of standards for primary information / gamma / white point etc. that the texture is expected to have at each position?

For example madVR outputs data with the primaries given by the .3dlut's params, and chromatic adaption to its white point, with the gamma being fixed at 2.3 pure power into its internal .3dlut, and expects fully gamma encoded output values.

What does EVR-CP input/expect?

[JanWillem32]

http://msdn.microsoft.com/en-us/library/bb970322%28v=vs.85%29.aspx
But really, range expansion and a Y'CbCr-to-R'G'B' matrix is the only thing truly applied: http://msdn.microsoft.com/en-us/library/ms698715%28v=vs.85%29.aspx .
For the custom renderer code;
In 8-bit mode, only resizing is applied by default (for compatibility and performance, not for quality). The other modes apply a 2.4 power (with safeguard for negative values) on the video input and subtitle blend step, and invert it again in the final pass.
The color management can automatically detect from the input video if a NTSC, PAL or HD R'G'B'-to-R'G'B' LUT is needed.

@Qaq: Thank you, I'll probably need it.

[JanWillem32]

I've tried to apply a few little changes quickly to patch a few issues. I'll have to fix a few more things when I have more time.
I'll work on switching the exclusive mode on the fly later on. It's disabled for now, but if anyone can help coding it, I would be very grateful.
I fixed the external sub/idx items (wrong handling of time codes, my mistake).
I reverted frame present order to what it was a few versions ago. I changed the order for the latest few versions for a few alternative VSync fixes, but I didn't like how the subtitle renderer reacted (paint times too high). Alternative VSync and flushing functions will need re-evaluation for if these can work with this placement (but so far it seems to work the same as before).
The nearest neighbor resizer had a range clamping issue. Turning it into a pixel shader is somewhat unusual, but it works fine now.

[tetsuo55]

@janwillem32: Recommended reading and likely to speed up commit of your changes to trunk: http://itscommonsensestupid.blogspot.com/2008/11/working-effectively-with-legacy-code.html

[CruNcher]

@jan
i still prefer dfr3752i (i think it's a good idea to use it as reference) result wise it's the most stable with the new (EVR-CP) render idea currently, though i can only speak currently for 1 Hardware OS scenario which would be Win7 with Intel Sandy Bridge dunno how it looks for Nvidia and AMD.
dfr3787i has a long black phase now (audio off,video off) @ switching therefore it recovers instantly after it (jitter) most of the times (not always) though it still likes to crash (closing a file while it's playing always freezes it's last frame in the playback area and sometimes it then crashes when closing).

[XRyche]

The added Switch to Limited Range for HD is spot on for pre 2004-05 BD movies. No more too dark scenes. I know Nvidia has the ability to dynamically change contrast but the constant switching gave me headaches so this works great. Dune(1984) on Blu-Ray is great now. Thank You.

[ForceX]

I can only use EVR-CP in the latest builds, selecting any other renderer does not work and falls back to the default Video Renderer. Win 7 x64

[cca]

I've tried to apply a few little changes quickly to patch a few issues. I'll have to fix a few more things when I have more time.
I'll work on switching the exclusive mode on the fly later on. It's disabled for now, but if anyone can help coding it, I would be very grateful.
I fixed the external sub/idx items (wrong handling of time codes, my mistake).
I reverted frame present order to what it was a few versions ago. I changed the order for the latest few versions for a few alternative VSync fixes, but I didn't like how the subtitle renderer reacted (paint times too high). Alternative VSync and flushing functions will need re-evaluation for if these can work with this placement (but so far it seems to work the same as before).
The nearest neighbor resizer had a range clamping issue. Turning it into a pixel shader is somewhat unusual, but it works fine now.

x86 SSE2: http://www.mediafire.com/?8yahnb8aap19df4
x64: http://www.mediafire.com/?kbwk5snkl07co63

Playback seems improved for me in this, but very buggy for real use, any kind of resizing and it 50% chance of freezing the player.

[JanWillem32]

@CruNcher & cca: I've tried to fix a few things to get it working a bit better. I still need to fix more things, but I think I fixed the worst bug with resizing.

@XRyche: That function works only properly with limited range displays. For full range displays regular color controls are advised, as the converter will compress brightness and saturation, and shift the red/green-green/blue balances.

@ForceX: Thank you for noticing. It was a bug with setting curly braces.

[CruNcher]

Much better jan no switch audio glitch anymore but still it has a rather long blackout (video frame) period compared to dfr3752i :)

[cca]

Much better jan no switch audio glitch anymore but still it has a rather long blackout (video frame) period compared to dfr3752i :)

Same here, and the Vsync although much improved in the latest versions still gives the occasional jerk. But way better than it was a few builds ago.

[JanWillem32]

Does the occasional jerk mean that tearing occurs, or does the scheduler deviate from the target amount of refresh cycles to present a frame for? (For example; a 60 Hz monitor with a 24 fps video playing would need scheduling of 2-3-2-3-2-3-2-3 refresh cycles for frames constantly, else it's a glitch.) In case of the latter, what are the responses of each scheduler? There are different schedulers for most scenarios:
-The exclusive mode has two, one for Windows Vista and newer, and one for older systems.
-The frame interpolator stood at the base for the new scheduling code first used in the exclusive mode for Windows Vista and newer, and later in Windowed modes with Aero enabled. It's just a little more complicated as it makes intra-frames for each screen refresh cycle. It depends heavily on the frame queue, as it can create a batch of up to 8 complete output frames per input frame. (It's a multiple render target system that can write up to 4 frames simultaneously, present those, and do that a second time when required. The basic frame interpolator will try to batch everything in the first pass. The adaptive types use the first pass to interpolate the intra-frames in the interval of [0, .5] , and the second pass to interpolate those in the interval (.5, 1).)
-Windows 7 and newer with Aero enabled in windowed mode uses the new present mode (FlipEx) I added a few versions ago. It uses a mode slightly altered from the one used in exclusive mode. (This present mode currently leaves behind the last frame after closing a video, I'll fix that later.)
-Windows Vista with Aero enabled in windowed mode uses a mode slightly altered from the one used in exclusive mode.
-With Aero and Alternative VSync disabled, tearing is pretty much inevitable. Scheduling for this mode is pretty much useless, so I can't even bother on working on scheduling for this mode.
-With Aero disabled and Alternative VSync enabled, the scheduler from the original VSync code is used. However I've patched this code about a dozen times, I still don't really get it. This mode disables scheduling frames completely, making it drop frames when workloads are high (doesn't even have to be even near 100% load) and with higher video frame rates (it drops frames for me on 50 and 60 Hz sample videos). This mode is pretty basic when used with VMR-9 r., EVR CP uses an extra worker thread.
The settings for flushing and Alternative VSync are only used when in windowed mode with Aero disabled.

I can make a function that writes out a log of scheduler statistics to the desktop, maybe that can be useful for debugging.

The blackout period will need a bit of work to become shorter. I'm already glad that the reset function performs better than before.

[cca]

Since I always use windowed mode with Aero on, and my OS in Windows 7, we are definitely talking about a glitch here. The exclusive mode is inconvenient for me, if it ever becomes dynamically switched like madVR does it, then I will use it. Alt VSync is also on but I suspect is may not work as intended, the graph in the statistics display is not continuously jagged as it should for a 24hz video played in a 60Hz refresh, sometimes it is a straight line, then jagged, then a line again in random patterns.

[G_M_C]

[...]

-With Aero and Alternative VSync disabled, tearing is pretty much inevitable. Scheduling for this mode is pretty much useless, so I can't even bother on working on scheduling for this mode.
-With Aero disabled and Alternative VSync enabled, the scheduler from the original VSync code is used. However I've patched this code about a dozen times, I still don't really get it. This mode disables scheduling frames completely, making it drop frames when workloads are high (doesn't even have to be even near 100% load) and with higher video frame rates (it drops frames for me on 50 and 60 Hz sample videos).
[...]

Does this in fact mean you advise leaving Aero on, and alternative Vsync off ? Or Aero off and 'regular' vsync on ? For full screen on secondary output (i.e. TV) i mean.

G_M_C is confused now. It used to be best practive to switch off Aero if memory serves right.

[JanWillem32]

@cca: That pattern is normal for that scheduler. Sometimes the present calls are delayed a bit, causing the jitter graph to lift a bit above the central line, and sometimes the present calls simply fit into the frame queue, making pretty much flat lines. It's caused by delays created by the subtitle renderer and mixer (and the processing line before the mixer). Disabling the subtitle renderer and different sizes for the mixer buffers can make a level in the jitter graph last longer.
The exclusive mode could use a better GUI, and unfortunately, I don't have much experience with that. Switching from exclusive mode to windowed mode proved to be a bit difficult for me. I still don't know how to get the child window to return properly on top of its parent. Switching to exclusive mode from windowed mode is pretty easy.

@G_M_C: It depends, Aero can still corrupt the output in 10-bit exclusive mode (rainbow colors on some systems, but it's rare) and uses some resident memory in both 8- and 10-bit exclusive mode.
For the windowed modes, I've invested quite a bit of work to not have to rely on the Alternative VSync code, so that a frame queue can work. In general, Aero uses a bit more memory and processing (it can't compete with the exclusive mode), and usually can't handle a full frame queue to present frames at every screen refresh interval, but that's nothing compared to the cost of flushing the adapter's command queue and forcing a present afterwards (what the Alternative VSync does).

[cca]

From my testing, Alt. Vsync On or Off, I get the same glitches. Subtitles off is something I cannot live with, most of the content I watch are anime, in Japanese audio, so I need the subs! The trunk MPC has no such issues with the subtitles, I wonder why these exist here.

But anyway, from the testing I did I get the glitches regardless if subs are on or off, so I guess this is not really the issue. The frames are just not presented when they're supposed to, scheduler issue, some other issue, I don't know, but there is a defect somewhere.

[Hera]

Video still effectively stops when a new line of subtitles is loaded and then resumes.
The animation of a loaded line of subtitles doesn't do this...

I think this also happens when accessing statistics (CTRL-J) the first time, subsequently toggling statistics does not stutter.

[JanWillem32]

@cca: I'll take a look at writing something that can log the scheduler statistics. I'm glad it isn't the the subtitle renderer that's causing issues this time, as it's troublesome enough as it is already. I'll have to come up with something that can trace timing issues with all parts in the video timing chain.There are plenty of factors that come into play here. It could very well be something in the mixer that's causing this issue. About that, do both VMR-9 r. and EVR CP have the same timing issue?

@Hera: I've modified the renderer to not initialize the stats screen rendering parts by default, unless invoked for the first time.
The subtitle renderer is still very heavy, but I've already made schematics for improving some things. The first part will be creating a hard separation between the DirectX 9 and VSfilter parts. It's inexcusable that both MPC-HC and VSfilter have to integrate the full package of both parts. Just another case of poor design.

[Hera]

Maybe you keep initializing something redundantly for the each line of subtitles now?

The performance of the stat screen is impressive though - after initialization, toggling between its differ modes doesn't do anything to the jitter.

[JanWillem32]

I've just taken a look at the changes made for the subtitle renderer in general, and there were indeed some changes to the code in recent revisions. I did notice something for optimizing the subtitle texture management in the video renderer, so I quickly added that for a next release. I've already changed the order for constructing the subtitles and presenting frames back to what it was a few versions ago. I wonder if it's something else I've changed or that an revision in the trunk build messed up things in your case. I couldn't find traces of worse performance with my latest build with the typical samples I have. I'm getting perfectly normal readings from the stats screen for the subtitle renderer's queue, too. Could you explain the details of your problem a bit further or provide a basis for comparison?

The stats screen doesn't use much GPU power to render. It does add a lot to the command queue, though. My paint times are about 6 times higher with the full stats screen enabled. You're probably noticing the effect of the cache options I set up for the stats screen font. The original version was a lot more conservative with using video memory.

[XRyche]

I don't know if it's just me or if it's the last 2 builds but I can't use the Haali or the madVR renderers without MPC-HC crashing. I was able to use any renderer I had installed previous to the last 2 builds. Any ideas?

[JanWillem32]

I don't test external renderers/filters for intermediate builds. That simply takes too much time. I've probably broken one of the interfaces again. That happens a lot, and is usually quite easy to fix. I doubt I'll have time for something like this this week, and the first priority is the old synchronized initialization bug. (It's when audio renderer forces the graph to play while the video renderer is still initializing. An annoying thing, and even a potential hazard for crashing or freezing the player on initialization.)

[Hera]

Not sure what else is there to explain.

Well lets say someone says "DERP DERP DOOP DOOP" over some time. First I see "DERP DERP" which stays on the screen long enough for me to read it, then it is replaced by "DOOP DOOP" which also stays on for some time. For me "DERP DERP" is the first line followed by the second line "DOOP DOOP".

Lets also assume that someone sings "DERP DERP" so the font animates a bit (the "EEEE" part in "DEEEERP" for both "DERPS"s).

The stuttering (which is reflected by a spike in the graph) happens when "DERP DERP" shows up and when "DOOP DOOP" shows up - at that very moment.

The animation performance is iffy too, but if short enough it doesn't cause stuttering. That Tohou (sp?) sample MKV some pages back used to play just fine with basic kareoke subtitles... now the the graph divides by zero and sutters...

[XRyche]

Thanks for answering my question JanWillem32. At least now I know what it is and know how to temporarily fix it for the time being. I'm still using MPC-HC experimental renderer all the time but, I like to keep my options open.

[Hera]

Not sure which thread to report,

AMD Laptop,
I noticed that the default MPC video codec causes some videos to be unplayable (graph skyrockets, EVR cuts out sound and skips, graph get back to normal... repeat forever).
Microsoft codec works just fine and doesn't cause that issue.
Not a subtitle issue.

[JanWillem32]

@Hera: Thanks for mentioning that Tohou video, it's a very good example of the problem. I'll take a look at selectively reverting items introduced after dfr3751, as that version doesn't seem to have this issue.

Apart from the support device for DXVA, there's only very little influence of the renderer on the decoder. I think this issue is more something to report on trac, where developers with knowledge of the codecs can take a look at it. Please explain in detail, with for example MediaInfo logs and a small video sample.
Now that I think of it, some decoders could force a weave deinterlacer, or bob on interlaced video. These two methods are much lighter on resources than adaptive deinterlacing. That could explain bad performance for a renderer with interlaced video.

@XRyche: I'll try to make time to fix things next week.

[CruNcher]

Jep on EVR CP for example Cyberlinks Decoder uses their own Software Deinterlacing (they also have their own chroma upsampling though that gets only used in Software mode not DXVA) as it has no access to the Hardware Deinterlacer :)
Though for Intel Hardware EVR-CP seems to be a bad thing i tested so many scenarios yet and especialy IVTC and Deinterlacing on EVR is much much better the adaptivenes of Intels Hardware implementation (Driver, bitstream containter flag independence) can fix many issues (Realtime) that would go undetected in EVR-CP (or fallback to Software) though (i still believe their must be a way to force it also on EVR-CP as it is doable via the EVR Controll Panel (Microsoft) manualy).

[JanWillem32]

Deinterlacing is a difficult thing. Apart from being an obnoxious inheritance from legacy analog TV formats, digital interlacing is bad for encoding efficiency. Deinterlacing itself is usually also badly implemented in both hardware and software.
The optimal spot for a deinterlacer in the filter chain is right after chroma up-sampling, colorspace conversion, optional custom pixel shaders, and right before resizing. While using a decent colorspace and quantization for both input and output. So far I've seen most deinterlacers output garbage, with the typical form of 8-bit 4:2:0 Y'CbCr (YV12, I420/IYUV, NV12) for both in- and output. Without even mentioning the intermediate processing quantization and filter program code of those, most deinterlacers are fundamentally flawed.
I'll ignore the bob method, as that's not a real deinterlacer. The most basic deinterlacer is the weave type.
The weave deinterlacer simply interleaves individual scan lines from two fields to one frame (the field rate is double the frame rate). Because of that, it won't work on 4:2:0 sources, as those simply don't have individual scan lines for chroma. Up-sampling partially in this case is often used (to 4:2:2), and is a very bad practice. When chroma geometry is transformed in a filter, the output should always be 4:4:4 and stay that way throughout the entire rendering chain. Using one filter to up-sample chroma vertically (to 4:2:2) and another in a later stage is bound to lower color quality. (Who would want to use two different filters to up-sample chroma vertically and horizontally anyway?) It's even worse if the output is down-sampled again to 4:2:0 (which often happens).
A weave deinterlacer doesn't change actual color information, as it only re-orders the scan lines. However, the chroma up-sampling required before deinterlacing does alter it. A basic bilinear filter adds exactly 2 bits to quantization (it's a pixel1*.25+pixel2*.75 blend), in both vertical (to 4:2:2) and horizontal (to 4:4:4) passes. More complex forms of scaling use fractional values that often can't be described in exact bits like that.
Deinterlacers that do more than just weaving (I'll just skip the "blend deinterlacer" for now) are usually called adaptive. These forms interpolate frames from fields (the field rate is equal to the frame rate). That kind of interpolation depends on methods based on linear scaling of the internal values in the data pool. In the cases of data pools containing typical Y'CbCr and R'G'B' surfaces, only Cb and Cr (chroma channels) are somewhat linear, the rest really isn't. I won't go in detail on this point right now, but when interpolating using colors, both Y'CbCr and R'G'B' greatly lack linearity and colorimetric range. (Linear RGB is only a little bit better, though.)
Adaptive deinterlacers require a well-processed input to allow proper interpolation. As such, the quality of the in- and output surface format should be pretty good as well.

For the VMR-9 and EVR mixers, I'm not happy with the current position and implementation of the currently available deinterlacers. The output quality of the surfaces used in the mixer can luckily be controlled quite well, but it's not an ideal situation.
The mixer doesn't allow manipulation of the raw fields by the renderer. It always forces progressive RGB as output. On top of that, the deinterlacing code is vendor-specific (inside the graphics driver). Once possible, custom internal deinterlacers should do a better job than that.

As a side-note, it's too bad that many video streams are badly marked in terms of interlacing flags. Cinematic video on TV usually needs a weave deinterlacer, but is usually marked as TV content (50 or 60/1.001 Hz field rates, interlaced from 50 or 60/1.001 Hz frame rates). See for example a few pages back in this thread, the "Evil Trees" sample.

[G_M_C]

Just saw this in the madVR thread, might be useful for you too:

Just a heads-up for anybody who cares.

The latest version of xy-VSFilter (http://code.google.com/p/xy-vsfilter/) (a VSFilter 2.39.x fork for performance) now supports both 4:2:0 10-bit (P010) and 4:2:0 16-bit (P016) input/output.

[ForceX]

That doesn't even seem to support animated subtitles, and that's the kind of subtitles which would actually require performance enhancement, so that's kinda counterproductive. I could just disable animation on my regular VSFilter if I needed that.

[JanWillem32]

Nice to see progress on that part. If it works out well, we might be able to merge some parts of the code.
Anyway, I've fixed conversion to NV12 from P010 for the internal codecs.
The performance of the subtitle renderer is still bad with complex subtitles. (The scheduler doesn't compensate enough for the huge delays that can occur because of the subtitle renderer.)
I've improved the efficiency of the timer code for x64 (the original code was really bad). I don't know if I can improve it a lot for x86.
I've removed "Reinitialize when changing display", as I've improved detection for multihead adapters. (Resets will still be forced when changing from one physical adapter to another.)
I'll try to implement some real features, fix some things and update the main revision next time, when I have more time.

[Keiyakusha]

That doesn't even seem to support animated subtitles, and that's the kind of subtitles which would actually require performance enhancement, so that's kinda counterproductive. I could just disable animation on my regular VSFilter if I needed that.

How about checking yourself before saying that? Animated subtitles is the purpose xy-vsfilter exists for.

[ForceX]

How about checking yourself before saying that? Animated subtitles is the purpose xy-vsfilter exists for.
I did. Neither the subs from Bad Apple video nor Tori no Uta was animating with the filter.

[Keiyakusha]

I did. Neither the subs from Bad Apple video nor Tori no Uta was animating with the filter.
Then something went wrong for you... Maybe you should investigate then and report some bug

[ForceX]

I'm gonna need confirmation from someone that those two files actually work as intended for them. Maybe those specific types of animation are not supported. Don't know else it could be, the http://code.google.com/p/threaded-vsfilter/ project which also works with caching works fine for the files.

[Keiyakusha]

ForceX
Can you upload subtitles from these files somewhere? Including fonts if there any. I do have these videos but not sure if subtitles are the same.

EDIT: btw do you know that you can't replace old vsfilter with xy one? you need to remove old ones and cleanly register xy for it to work properly.

[XRyche]

Just a heads up. ASS subtitles stay on screen until another line of subtitles with tester dfr3787rri, regardless of timing.

[G_M_C]

Nice to see progress on that part. If it works out well, we might be able to merge some parts of the code.
Anyway, I've fixed conversion to NV12 from P010 for the internal codecs.
The performance of the subtitle renderer is still bad with complex subtitles. (The scheduler doesn't compensate enough for the huge delays that can occur because of the subtitle renderer.)
I've improved the efficiency of the timer code for x64 (the original code was really bad). I don't know if I can improve it a lot for x86.
I've removed "Reinitialize when changing display", as I've improved detection for multihead adapters. (Resets will still be forced when changing from one physical adapter to another.)
I'll try to implement some real features, fix some things and update the main revision next time, when I have more time.

x86 SSE: http://www.mediafire.com/?7b8v024m4fu0av9
x64: http://www.mediafire.com/?m79alqofg5k6kp5

JanWillem, do you have an estimation on when you will reach the point of releasing 'a (relatively) stable' ?

[golagoda]

JanWillem, do you have an estimation on when you will reach the point of releasing 'a (relatively) stable' ?

Considering these builds are based off of MPC-HC trunk builds it would be kind of silly calling them stable no matter what is done to them and it would probably confuse a lot of people, saying which builds work the best so far would probably work better :p

[cyberbeing]

That doesn't even seem to support animated subtitles, and that's the kind of subtitles which would actually require performance enhancement, so that's kinda counterproductive.

Should be fixed in the next version (Edit: Fixed in xy_vsfilter_test_20111101), since faster rendering of heavy subtitles animation/karaoke/typesetting are the main reasons for using xy-VSFilter. If you ever find any more bugs, report them on GoogleCode so they can get fixed quickly. The goal is to have zero regressions from VSFilter 2.39.x functionality, but occasionally things sneak in only to get fixed shortly after. That said, all the builds with _test or _mru appended too them can be considered Beta builds potentially with experimental changes.

[Hera]

Nice to see progress on that part. If it works out well, we might be able to merge some parts of the code.
Anyway, I've fixed conversion to NV12 from P010 for the internal codecs.
The performance of the subtitle renderer is still bad with complex subtitles. (The scheduler doesn't compensate enough for the huge delays that can occur because of the subtitle renderer.)
I've improved the efficiency of the timer code for x64 (the original code was really bad). I don't know if I can improve it a lot for x86.
I've removed "Reinitialize when changing display", as I've improved detection for multihead adapters. (Resets will still be forced when changing from one physical adapter to another.)
I'll try to implement some real features, fix some things and update the main revision next time, when I have more time.

x86 SSE: http://www.mediafire.com/?7b8v024m4fu0av9
x64: http://www.mediafire.com/?m79alqofg5k6kp5
Aaaaand you broke subtitles on x64 for me. Same goes for the information at the top which appears when seeking / modifying volume.

Sometimes both are corrupted - broken down into segments and reassembled wrongly. Sometimes the screen goes black.

[JanWillem32]

@XRyche: I've noticed. The subtitle texture allocator is a bit sensitive. It's been like that since I split it into a part for external renderers and the internal one. This really isn't the first time that that bug appeared. Oh well, I've fixed some things today in this regard. The complex subtitles in the "Touhou - Bad Apple!!" video seems to render quite properly again for me with the alpha version I made today.

@G_M_C: I'll integrate the latest revision from the trunk version once I've sorted out some code that's incompatible with some of the latest changes. I'll see if I can make time to do the full sweep of alpha testing things after that, and release a non-intermediate. Integration of smaller patches to the trunk is possible, but the bigger parts of the video and subtitle renderer are mostly (or completely) re-written code and a lot more difficult to finalize.

@Hera: x64 specific? That's new to me.The status messages and the the bottom bar in the exclusive mode are rendered by the OSD renderer. (It actually has pretty much the same fundamental issues as the subtitle renderer, so I might change it to something more like the font renderer for the stats screen.) A black screen now and then is usually caused by a corrupt texture produced in the subtitle renderer. I've tried to improve this part of the code today, so I hope I've fixed most of these types of issues.

[Hera]

Not sure if 64bit specific, maybe will test later.

[janos666]

My problems with mpc-hc SSE2 tester dfr3787rri


- Black screen if I try to play 1080p24 Blu-Ray VC-1 movies in full screen 1920x1080p resolution (refresh doesn't matter).
There is picture in windowed mode but it disappears if I go to full screen windowed mode. (It reappears if I move the cursor down to make the GUI show up on the screen and disappears again if I move it back up...)
D3DFS starts with black screen and it seems frozen (there is no GUI if I move the cursor down on the screen + see later...).


- Crash if I try to pause/resume or seek Blu-Ray AVC movies (producible both with internal splitters + internal DXVA decoder and LAV splitter + FFDShow software decoder).


- 23.967fps playback is smooth (as much as it can be) with 60Hz display refresh in D3DFS mode and Alternative V-sync turned OFF. But V-sync is completely broken with 23.976Hz display refresh. (Very strange because it sounds easier to sync 23.976fps to 23.976Hz than 23.976fps to 60.000Hz...)
Alternative V-sync only makes everything wrong (23.976 display refresh is still unusable but 60.000Hz refresh is broken too) but this is not a new thing.


Edit:
I went back to 3740.
No more 23.976Hz V-sync problem with most of the video formats, but VC-1 videos (in m2ts) aren't smooth (and I get black screen with DXVA decoders).
And I am still unable to seek AVC videos (in m2ts), it must be a general problem.

[RGold]

I see same thing when using optimal render settings - 32 bit floating point. Reset to default works ok for now.

My set up:
ATI5450, LAV audio& video - All internal codecs are disabled. Also using 24Hz auto change frame rate.

[JohnLai]

Oh my, Catalyst 11.10 WHQL totally breaks mpc-hc DXVA into black screen.

Anyway, bug report with dfr3787rri = when fast forward and fast backward non stop, then let the video plays normally, somehow, the video will 'run' slower than audio.

[JanWillem32]

I've managed to get some things a lot more stable this time. I didn't have time to test everything, including external filters, but it's a good start.

-added a modified version of watchman's code to the subtitle parser, thanks again :)
-changed the method for calculating scheduler frame rate compensation, based on jitter comparison;
updated presenter modes: constant frame interpolator, Windows 7 and onwards in windowed mode with Aero enabled, Windows Vista and onwards in exclusive mode
-revised EVR CP initialization, no longer the big "hiccup" at the start, but it's still slower than VMR-9 r.
-revised subtitle allocator;
it now supports quick mode changes for for example resizing a window
resource management has been changed for better efficiency and a lot less crashes when reinitializing or closing
-optimized the renderer's internal pixel shader compiler handler, it's a lot faster now

[janos666]

I've managed to get some things a lot more stable this time. I didn't have time to test everything, including external filters, but it's a good start.

It is indeed a lot more stable. I can seek the video as often as I want and I can quit without appcrash.

V-sync with 23.976Hz refresh is also fine now (D3DFS).


But I still can't play AVC1 videos with this version (which is weird since the encoding format shouldn't matter when I use external software decoders :confused:).
Same as I reported before: windowed mode works but D3DFS crashes and full screen windowed mode gives me a black screen unless I keep the seek-bar on top.

[ChronoReverse]

I'm gonna need confirmation from someone that those two files actually work as intended for them. Maybe those specific types of animation are not supported. Don't know else it could be, the http://code.google.com/p/threaded-vsfilter/ project which also works with caching works fine for the files.

In 32 bit mode, the newest one (http://code.google.com/p/xy-vsfilter/) as of this posting time does animation for me. Without killing my CPU too.

[Hera]

Very quick notebook tests w. D3DFS on two files: Seems to work just fine.

EDIT: Also still crashes with ALT-F4

[golagoda]

Is it just me or in the r3801 build do you have to resize the MPC-HC window for the video to show? It can be the smallest change, but it needs to be changed to see the actual video, don't know if it's meant to be like that but that's happening to me at least. If you don't it just stays as a black screen, not even the OSD will show if you press ctrl+j

Also wasn't able to use this build with madVR either :( last one I could use is 3753 (Tried all the tester/intermediate builds you posted but didn't put into the original post), but I managed to make EVR look decent so I just use that now anyway, once again thanks for these builds.

EDIT: Turns out last working build for me for non-EVR renderers was actually dfr3755i not 3753

[Hera]

netbook performance kinda regressed though, now it stops for up to half a second and then resumes.

Stops happen before the subtitles appear now and during the subtitles - yes before subtitles are loaded there is stopping.
Tohou video with basic kareoke now stutters but renderer doesn't drop frames left and right to keep up with kareoke (aside from minor stopping all the time) and kareoke effect for a certain line goes through like 70% then is gone - it doesn't finish - so it is like renderer now instead of dropping frames drops the subtitles.
Allow Animation When Buffering seems broken - it does nothing.

The stats screen in windowed mode is broken too - the stats are tiny and unreadable, but the graph is fine if not too big.
In windowed mode subtitles also suffer this fate - they are too tiny - unreadable.
This can be fixed by resizing.
This doesn't appear in D3DFS.

Disabling subtitles does not effect the occasional stopping -the stopping or renderer maybe renderer going back and forth between frames is repeated at equal intervals - red like down, green line up type of an effect.
It is at the same parts too, first being when the apple is bitten the first time - stop, mountain on graph, resume.

Play Button does not work anymore. If I paused in Windowed mode, then I have to resume video by seeking... actually it just started playing again.. so there is some unbearable delay between there.
This also exists in D3DFS - Space, PAUSE, video starts playing.


Playing Planet_Earth_From Pole_to_Pole_1080p_sample.mkv I got delays of... well.. a second. Video stopped for a second. Graph and all stats also stop. Resume and the graph has divided by 0...

Also I got D3DFS seekbar in normal EVR...

Trying to use Haali crashes MPC.

[JanWillem32]

@janos666 & golagoda: It seems that it was caused by the resizer section. The skip conditions were wrong for handling equal video and screen sizes.

@Hera: I'll try a few other computers than mine for debugging the Alt+F4 problem. It's been there for a while, but I can't replicate it on my PC.
"Animation When Buffering" seems to work properly for me. It's not intended to do anything when a buffer of 0 is set, by the way.
The bug with the wrong sizes sounds like the one a few hundred revisions ago, where window sizes were initialized wrong. (Mostly when the window was resized immediately after opening. The menu bars often cause this.)
Delays of over a second are somewhat extreme. It's no doubt caused by a scheduler part. A large peak and valley in the jitter graph usually means that the mixer is flushed and all pending samples are immediately dropped frames. The scheduler will do that once the mixer buffers are exhausted, EVR won't respond anymore and the video is many frame times late. A minor version of that action is used when seeking.
The vanilla EVR type does indeed get the wrong OSD type. I'll take a look at fixing the main window organization later on.

I'll debug external filters later on when I have more time.
For now, I've tried to fix a timing issue that could cause dropped frames, and the resizer section.

[Hera]

I am a few NV driver versions behind (due to their bad reputation) - although I doubt that matters?

[CruNcher]

Wow i didn't yet tested the r but already 3801 is amazing 0 jitter when changing on the fly, i mean except the change time itself but immediately after it it stays stable (no matter changing from windowed to fullscreen and back forth) very nice (no issues while switching as well not 1 brake in sound and video) very good work Jan, though still closing it holds the last frame captured :)

[G_M_C]

JanWillem, do you have an estimation on when you will reach the point of releasing 'a (relatively) stable' ?


[...]
@G_M_C: I'll integrate the latest revision from the trunk version once I've sorted out some code that's incompatible with some of the latest changes. I'll see if I can make time to do the full sweep of alpha testing things after that, and release a non-intermediate. Integration of smaller patches to the trunk is possible, but the bigger parts of the video and subtitle renderer are mostly (or completely) re-written code and a lot more difficult to finalize.
[...]

Seems like you've granted my wish for 'a (relatively) stable' after all :p

Thx Jan !

[CruNcher]

yup 3081r doesn't lose that stability very nice now more stuff can be tested (3081r as the current would be also my fav build now after dfr3752i) :)

Though this is something strange im not sure how that could be explainable, but i get a black screen with dfr3752i now where 3081r works perfectly fine very strange as dfr3752i worked before and driver didn't change, or was it just executing 3081r killed dfr3752i video output (i have to restart though and clean system state to be sure it's actually 3801r execution killing 3725i video output for every further run) (but im running Firefox in the background as well with some flash player instance, though not rendering actively and should be suspended)

[Mercury_22]

@JanWillem I think you should put a big warning somewhere asking people to RESET their settings with every new build and to never use your builds at the same time with the trunk builds unless they use an ini file for the settings cause this may cause a lot of false bug reports for your builds and for the trunk

Just my 2c :)

[JanWillem32]

@Hera: I personally don't know. At my parents' house there's a HTPC with an older nVidia IGP, but I haven't been tracking driver issues for revisions lately. Maybe someone else knows?

@CruNcher: The revision was only minor. The main method remained unchanged for the scheduler. The still picture on exiting is indeed a bit nasty, and I really don't know why it happens. The log from the DirectX debug runtime doesn't indicate any resources leaking, so I wonder what part is keeping the surface. I can force the window to clear to black on closing, but that's not a very elegant solution (the logo screen should be used). I don't know what part could break older revisions. I most certainly didn't change any registry/.INI settings other than the limited range output setting the last few revisions.

@G_M_C: Attaining relative stability with a new renderer core is always a bit hard when working with the legacy DirectX 9 forms. (I started with only DirectX 10.0 programming two years ago, DirectX 9 still annoys me with not requiring a decent minimum feature set for video cards.) The demands for keeping compatibility are very high, the code for various operating systems and video cards is very diverse. Two weeks ago, I was happy to find out that at least one of the compatibility modules seems to work: http://sourceforge.net/apps/trac/mpc-hc/ticket/1808 . Note that I couldn't test it by myself, so I was lucky, I guess. I don't have that type of hardware. It just shows that in a few ways my version of the renderer is starting to get more stable than the trunk version.

@Mercury_22: Indeed, I've changed so many settings. I'll try to update the OP today to include a notice.

Two minor notes;
The revision for the resizers gave one minor issue, so I added an error message for that: "linear gamma, both custom pixel shader and resizer passes are disabled, for frame interpolation in combination with EVR to work, at least one is required". As it's a rare condition, and VMR-9 r. doesn't have this issue, I won't fix this.
Little CMS was updated recently. I've seen some support modules for handling types of V4 profiles, along with other changed code. I would appreciate feedback on changes, as I might need to change settings again. (Think of the color clipping to green from a while ago, that required some work to fix.) 3081 is broken in this regard, 3081r had a small fix that I forgot to point out.

[janos666]

Yes, black screen and other reported problems are fixed in dfr3801r. It's usable now.
But I still have sync problems with a VC-1 AP@L3 Blu-Ray video. The GUI reports improper and fluctuating average frame rates (no matter if FTC is ON or OFF) in both windowed and D3DFS mode.

[JanWillem32]

What type of video is it exactly? Maybe I can find a similar sample to test. The two VC-1 sample videos I just tried work fine.
I'm glad that the black screen issue seems to be fixed. It's a bit hard to write code for the compensations involved with skipping the resizing section completely.

[ForceX]

The color clipping seems still to be happening if you enable Black Point Compensation. It goes away if you enable White Point Adapt state to Full. I don't remember this particular behavior in previous builds. Also, I thought BPC was only supposed to work for absolute colorimetric mode.

Also, really great work with these builds. Last few builds started struggling greatly even on 720p content with Light Random dithering. It's much better now.

[CruNcher]

Jan Willem32 its not a super big issue either but it seems on load of the video playback the video surface @ first gets full zomed in the same issue i remember some very very long time ago though it didn't fixed itself (res change) back then in this newer builds though it happens again but it fixes itself after i just guess its 1 second :) though the time is enough to make it obvious (like the new resolution change on switch itself is pretty obvious in the end might distract even, no one is really used to this i guess not all will find it whatever benefits it brings nice @ all compared to the static res change in trunk)
But this is entirely a perception kind of thing and different playback scenarios would also make it invalid of course (it highly depends,on the general usage).

[RGold]

3801r looks stable if I use default render. For optimum render setting I get black screen with sound on. When I move the mouse down to the seek bar the image comes back and will disappear as soon as the seek bar hide itself. Using external LAV filters.

[JanWillem32]

@ForceX: I just tested, with neither my profile nor the one janos666 posted a few months back I've seen the clipping issue. What settings are you using? Can you upload your profile? Maybe the color management is having trouble with a different kind of profile this time.
As far as I remember, White Point Adapt State is for absolute colorimetric mode only. Black point compensation is forced enabled for perceptual mode and forced disabled for absolute colorimetric mode. The option once only worked for saturation and relative colorimetric modes. That could have changed over time, though.

@CruNcher: I haven't seen that yet. Can you elaborate a bit? Does it happen in exclusive mode? (As exclusive mode is less susceptible to problems involving window size issues.)
The checklist for resetting the renderer is passed every .75 seconds, including a window size check for windowed mode (it would be useless for exclusive mode, of course). An immediate reset after initialization is possible. (Just enable the "View", "Statistics" bar. It invades the video area directly after opening. I have no idea how to fix that thing, same as the bar for the fullscreen windowed mode.)
Can you describe "zoomed in"? The default window resolution is a square of only 1×1 pixel. If the entire window area is painted in one color, it could be that the window size initialization is skipped.
Maybe I can whip up a tracing debug build to see if a session log reveals problems when initializing the player on your system. It could be something trivial to fix, for all we know. (As usual, I can't replicate the problem on either of my computers.)

@RGold: Which of the two seek bars do you mean? (Exclusive mode or fullscreen windowed mode?) Is the video you were testing exactly the same resolution as your monitor? What video card do you use? In the video settings tab of the video card's control panel there are options for various filters. Many of those are well known to cause a black screen when the renderer uses better surfaces than 8-bit RGB. Can you try again with all of those disabled?
(I really could use the help of a DirectShow specialist to help get rid of the current mixers. Even if the renderer detects that a video card is capable of processing a certain surface format, there's no guarantee that the mixer won't output plain black surfaces with it.)

[ForceX]

It seems to have been an incompatibility issue of the lut3d files. I deleted my existing ones and the issues are fixed. I guess the reason why it seemingly worked when I turned on Full White Point Adapt State is because I didn't have an existing lut3d file for that. -_-

[janos666]

Here is a small sample: click (http://www.mediafire.com/?4dn1l97jan6x1cb) (I chose this moment because this scene was uploaded countless times everywhere anyway :D).

[CruNcher]

@ Jan
Sure give me a special debug build and ill record it :) here is first a visualization of this http://www.mediafire.com/?zbplbg7tp8csnv3 (i love to play with this as you see hehe, finally i can visualize my on screen experience and bug reports ultra fast (no transcoding))

Here is a complete switch test http://www.mediafire.com/?ifkvvtet0ylg409 (including above issue on the OSD @ init)

[RGold]

Jan,
I took Mercury_22 advise and saved all setting into INI file since I also have the truncated version. Now 32-bit RGB works fine. However I have problems with interlaced AVC material where NV12 output is doing well and RGB just stutters with any both LAV and internal filters. I'm using ATI 5450 video card and Windows 7. Here is the file: http://www.mediafire.com/?oz9w2cl7xesi1i1

[Hera]

same issues (subs ragequittig and video pausing (maybe the same bug) and resuming for no apparently good reason) - there is no indication as to why - CPU usage is relatively low and even when video stops playing, the CPU usage does not spike or anything. Mixed Surfaces Amount is 4, 1 is Free... when it stops that may or may not jump to 3 being free. These pauses are very long.

When these second pauses happen - effectively green/GPU spikes hardcore (peak might not be viewable), red like shows spiked teeth.
This is codec independent, your previous releases did not have this.

In between these pauses, the graph shows perfect flawless playback.

It also may be the case that subtitles do not cause the stuttering / pausing effect... which is irrelevant when the video pauses in well adjusted intervals to troll me.

Resuming video is very slow - it essentially responds to me pressing the play button five second later or so which is unacceptable.

Now it starts for a second with debug info/graph all screwed blurry, then it fixes it and so in Windowed mode after initialization it fixes it
So there is an instance when the debug information is wrong for some reason.

Haali Renderer Still Crashes! :(

Jitter when not freezing: 0, avg sync offset 0, std dev offset 0 (its approaches zero, rarely gets there because of the freezes...)

Jitters goes up to ~7, avg sync offset goes to into ~-1000 territory, std dev offset goes to 1000

NO FRAMES ARE DROPPED WHEN PAUSES HAPPEN

These pauses happen every few seconds - memory leaks?

Subtitles do not have much influence on the offset / jitter... although further testing needs to be done.

Overall I have played 6min of a 1080p MKV with 95 dropped frames and 1/4 - 1 second pauses every ~five seconds.

D3DFS does not help.

I have max paint time of 521 ms which is the only thing that seems off. Normal paint time is 20ms.

Plz fix :)

[JanWillem32]

@janos666: I'll take a look at it again with some various splitters and decoders. For now, the opening of the file is a little bit rough, and smooths out within two seconds for me. VC-1 in an MPEG transport stream is known for its time stamp problems, and I really don't know where to start with fixing that from a renderer perspective. The frame time compensation mode is unchanged from the trunk build, so it should still work.
Does the same thing happen in both windowed modes with and without frame time correction?

@CruNcher: You've made quite informative videos indeed. What the renderer is doing is completely correct. It allocates surfaces at the size of the original window that it initializes with. The player resizes the window after the renderer completed initialization, so after .75 second, the renderer resets to correct for that.
I'm sorry, but I don't have a clue how to work with window handles (as can be seen with my previous experiment with switching exclusive mode on the fly). It should be possible to make the window resize before the renderer initializes, but I doubt I'll be the one to implement that in the near future.

@RGold: I'm not suprised things stutter with 32-bit RGB. Both EVR and VMR really don't like converted input.
Take a look at the native format with MediaInfo, to se what format the video file is natively.
If the native format of the file is 4:2:0 Y'CbCr interlaced, NV12 should be used.
If the native format of the file is 4:2:0 Y'CbCr progressive, NV12 can be used on most video cards, Nvidia cards also support I420/IYUV and YV12 for this.
If the native format of the file is 4:2:2 Y'CbCr, YUY2 is only commonly used.
RGB32 is useful for the Windows still image filter, for example when loading a .BMP file.
The 10-bit formats are yet another issue, I'll put that aside for now.

same issues (subs ragequittig and video pausing (maybe the same bug) and resuming for no apparently good reason) - there is no indication as to why - CPU usage is relatively low and even when video stops playing, the CPU usage does not spike or anything. Mixed Surfaces Amount is 4, 1 is Free... when it stops that may or may not jump to 3 being free. These pauses are very long.

When these second pauses happen - effectively green/GPU spikes hardcore (peak might not be viewable), red like shows spiked teeth.
This is codec independent, your previous releases did not have this.The last few revisions seem to have broken a lot in your case. :( What does the stats screen typically show for the subtitle allocator statistics in these cases you described?
Non-threaded rendering is when "Sub pictures to buffer" is 0. Threaded usage is with a buffer of at least 1. Can you try with a buffer set to 0, and with larger buffer sizes?In between these pauses, the graph shows perfect flawless playback.

It also may be the case that subtitles do not cause the stuttering / pausing effect... which is irrelevant when the video pauses in well adjusted intervals to troll me.

Resuming video is very slow - it essentially responds to me pressing the play button five second later or so which is unacceptable.)I really don't know what would be causing the issue with the slow response to a resume play command. The mixer doesn't parse commands directly, so it takes time to receive a command, but five seconds is really extreme.Now it starts for a second with debug info/graph all screwed blurry, then it fixes it and so in Windowed mode after initialization it fixes it
So there is an instance when the debug information is wrong for some reason.I don't know how to analyze/visualize this directly. Can you try making a screenshot?Haali Renderer Still Crashes! :(I'll fix external filter handlers when I have more time.Jitter when not freezing: 0, avg sync offset 0, std dev offset 0 (its approaches zero, rarely gets there because of the freezes...)

Jitters goes up to ~7, avg sync offset goes to into ~-1000 territory, std dev offset goes to 1000

NO FRAMES ARE DROPPED WHEN PAUSES HAPPENIf no frames are dropped when pauses happen, it means that the mixer handler doesn't detect itself as being late, and just resumes playing the next frame. That generally means that the main paint loop of the renderer isn't taking too long to complete. (Paint times reported in the stats screen will be lower than one frame time.)These pauses happen every few seconds - memory leaks?Memory leaks by either the video renderer or the subtitle renderer are easy to detect by the debugger for both system and GPU memory. During development, these kinds of errors can occur, and are dealt with afterwards. An excessively large buffer pool is more likely. That can be tested by just starting to play a video and looking at the player's memory usage. So far, I've seen nothing of this kind of problem.Subtitles do not have much influence on the offset / jitter... although further testing needs to be done.

Overall I have played 6min of a 1080p MKV with 95 dropped frames and 1/4 - 1 second pauses every ~five seconds.For disabling subtitles, you did completely disable the renderer by disabling the option "Auto-load subitles" in the "Options", "Playback" tab (requires restart)? The subtitle renderer is instructed in a pretty dumb way... It always renders a selected subtitle track, even if it's not visible.D3DFS does not help.

I have max paint time of 521 ms which is the only thing that seems off. Normal paint time is 20ms.In my case, it's 868 ms. That's not strange at all with all the filters I'm loading at the start.Plz fix :)I'll try, as usual. I only wish I had a 'misbehaving' PC like yours to run the debugger on. I'll try to arrange a debug build to work with a DirectX debug runtime and a system tracer, after I've done my round of basic code inspection and fixes.

[renq]

revision 3801 x86 AVX crashes instantly when opening any video.
Win 8 Dev prev, latest madVR & LAVFilters

EDIT1: Using default codecs/filters, EVR CP w/ BiLinear crashes also.
EDIT2: Previous build (3753, x86, avx) works fine even with the settings noted above.
EDIT3: X64 AVX 3801 seems to work fine

[Hera]

Ah, I didn't know that subtitles are renderer even if not shown. I just disabled subtitles via Right Click -> Subtitles.
Will test when time permitting.

[JarrettH]

Is any of this in MPC for real yet? :cool:

[RGold]

Take a look at the native format with MediaInfo, to se what format the video file is natively.
If the native format of the file is 4:2:0 Y'CbCr interlaced, NV12 should be used.
If the native format of the file is 4:2:0 Y'CbCr progressive, NV12 can be used on most video cards, Nvidia cards also support I420/IYUV and YV12 for this.
If the native format of the file is 4:2:2 Y'CbCr, YUY2 is only commonly used.
RGB32 is useful for the Windows still image filter, for example when loading a .BMP file.
The 10-bit formats are yet another issue, I'll put that aside for now.

How can I configure your build to use NV12 for interlaced?

[XRyche]

Is any of this in MPC for real yet? :cool:

Do you mean in the official builds? Actually some of it is implemented (real-if I understood correctly. If not oops :D )but a lot of it isn't as well. That's why this is "experimental". In all honesty, for this being essentially a beta build, the features that do work, work exceptionally well.

[JanWillem32]

Can anyone confirm the case renq is reporting? X86 AVX broken and x64 AVX working is possible, but it at least used to work in the past. I'm not sure if the factor of Windows 8 beta is important here. It could be, since that even for Windows 7 AVX support is relatively new.

@RGold: The internal decoders, ffdshow tryouts and LAV Filters will use NV12 or YV12 by default on pretty much all consumer-grade video content, both for interlaced and progressive.

I've indeed been patching some bits and bytes a while ago. After I dumped the renderer core code and re-wrote the entire paint loop, that was not an option anymore. When the renderer goes into the trunk, it will have to replace the old one. For the work on the subtitle renderer, I might be able to patch it in some smaller parts. As my build currently breaks VSfilter on some interfaces (again and again), that's not going to happen anytime soon.

@XRyche: Well, "exceptionally well" is a bit of an overstatement... Some parts really need some extra care. The constant frame interpolator for instance needs a bit more "soap opera effect' code (I wonder where to find some).

[cca]

Latest build is improved again, but the jerky motion perists in my case, having a lot of glitches.

[chainring]

revision 3801 x86 AVX crashes instantly when opening any video.
Win 8 Dev prev, latest madVR & LAVFilters

EDIT1: Using default codecs/filters, EVR CP w/ BiLinear crashes also.
EDIT2: Previous build (3753, x86, avx) works fine even with the settings noted above.
EDIT3: X64 AVX 3801 seems to work fine
Same exact results for me, except I'm on Win7 x64.

[burfadel]

Mediafire folder doesn't seem to work... (keeps coming up no files then redirects me to my own Mediafire folder).

[Hera]

File without subtitles plays just fine (MP4)
Same goes for disabling subtitles!

So all those issues are subtitle code related.

Also, as for the corruption at the beginning which now fixes itself. You know when you open a file it tells you the file name in the top left corner? That thing is stretched, out of proportion and then it fixes itself.

Also WMP still outperforms MPC:HC (lower CPU) on MP4 files... by a lot (in netbook terms).
WMP can get as low as 5% playing an HD file and generally stays below 20% Atom. For MPC:HC is is like 15 low 40 high approx.
This is not the case when WMP fades in and out its GUI - CPU spikes to 50% - but is irrelevant for anything but GUI discussion.
I mention this from time to time. Easy to test - netbook with h264 DXVA support, W7, WMP, and an MP4 pirated from YouTube.

[JanWillem32]

@cca: I've seen some scheduling issues as well. Creating a scheduling method attached to both VMR-9 and EVR mixer handlers isn't working out so well. (I'll ignore the two other mixers for convenience.)
EVR drops entire sets of frames, VMR-9 calls the paint command too late most of the time. Both are pretty oblivious to monitor refresh rate or any other kind of scheduling associated with that.
Can you describe the improvement in your case for the exclusive mode, the windowed mode with Aero and the windowed mode without Aero (enable Alternative VSync for that one)?

@chainring: Thank you for reporting. We'll see if things work out for the next version.

@burfadel: I'll take a look later, but for now the link indicated by MediaFire to share the folder is still the same. I might need to change some settings.

@Hera: Well, that's a relief. Editing only the subtitle allocator should not be too hard. Did you already try different sizes for the buffer setting (while keeping animation enabled, of course)?

[Hera]

Will test, just a min.

EDIT1: I noticed that CTRL-C in Windowed Mode resizes player back to mini size but leaved the picture of whatever I was watching just before CTRL-C. I mean, instead of MPCHC logo I get 1080p Fullmetal Alchemist Brotherhood image resized to tiny with Graph seeable in the bottom right corner. When in Windowed mode, but maximized (Fullscreen without D3DFS) - The player does not resize after CTRL-C but still leaves the image on screen of whatever I was watching. See like a bug.

EDIT2: Another odd thing - first line of subtitles was blurry and really low res in Windowed mode - second OK.

EDIT3: The above happens due to resizing I believe.

It seems that pictures to buffer is set to 0 by default (I reset the setting!) which is causing the issue I am experiencing. Setting buffer > 0 fixes the stalling I think.

EDIT4: Now I cannot reproduce the bad stuttering... uh, buuuut.
Sometimes when resizing (windowed -> fullscreen non D3D) the subtitles and stat screen do not resize, sometimes they do.
Setting more than 0 buffers DOES keep things much better.

EDIT5:
0 Picture To Buffer + UNchecked Allow Animation When Buffering -aside from slight stuttering- is the same as having Checked Allow Animation When Buffering. Oh...

EDIT6: Having 0 buffer or buffer like of 40 causes pauses / stutter. Having other buffers and kareoke might cause frame dropping, but the sound does not cut out.

EDIT7:

Make sure you are using D3D fullscreen, Press CTRL-Q, leave the file open dialog alone, double click (open) MKV file from Explorer (assuming MKV are opened by default by MPC:HC) - CTRL-C and ALT_F4 do not register that nicely.

[janos666]

3801 shows improper colors with this (http://www.mediafire.com/?zo3vzr60ia06s3t) profile but I think it's a problem with the Little-CMS GIT version.

[JanWillem32]

@Hera: A numbered list to work on? Let's see...
1: Already reported by CruNcher. If the player resizes the renderer's target window during the closing sequence of the renderer, a copy of the last picture is left behind.
Solution: The player should not resize the active window before the renderer is completely unloaded.

2&3: Similar issue as above. If the active window is resized directly after renderer initialization, the renderer resets itself to correct for that in .75 seconds.
Solution: The player should resize the active window before the renderer is loaded.

3: I've never understood why the non-threaded version was made standard. It forces the thread of the video renderer to draw a subtitle, which isn't exactly a great idea. On the other hand, the threaded version does waste cycles on checking for free buffers and constantly allocates and deallocates its memory resources.
I'll see what I can do.

4: If the stats screen doesn't resize, the video isn't resized properly either. I'll see if can replicate this problem. Maybe it's because the fullscreen windowed mode is a bit broken?

5: The non-threaded version always animates.

6: A buffer of 40 on a 1920×1080 screen will take 316.40625 MB of video memory (7.91015625 MB for each frame). If such an amount of memory isn't available, the driver will stall the updating of textures until sufficient space is available.

7: A known item, and certainly not new. The popup dialog windows for "Open File" and such have a higher priority in taking focus. That's okay for multi-monitor playback, but it's not ideal when the the exclusive mode obscures that dialog window.

@janos666: I assume you tested 3801r, the standard 3801 messed up a memory resource for the LUT creation.
It's really dark and sepia-like (low saturation, hue shifted far away from blue). The older version is dark, but doesn't have such a big impact on saturation and tint. Do you see the same thing, or something else?

[cca]

@cca: I've seen some scheduling issues as well. Creating a scheduling method attached to both VMR-9 and EVR mixer handlers isn't working out so well. (I'll ignore the two other mixers for convenience.)
EVR drops entire sets of frames, VMR-9 calls the paint command too late most of the time. Both are pretty oblivious to monitor refresh rate or any other kind of scheduling associated with that.
Can you describe the improvement in your case for the exclusive mode, the windowed mode with Aero and the windowed mode without Aero (enable Alternative VSync for that one)?

@chainring: Thank you for reporting. We'll see if things work out for the next version.

@burfadel: I'll take a look later, but for now the link indicated by MediaFire to share the folder is still the same. I might need to change some settings.

@Hera: Well, that's a relief. Editing only the subtitle allocator should not be too hard. Did you already try different sizes for the buffer setting (while keeping animation enabled, of course)?
I'll try to test later today or tomorrow, I'm a bit swamped with work these days.

[cca]

Some preliminary tests in exclusive full screen produce heavy tearing when Alt Vsync is on, and no tearing but jerky motion (glitches, not dropped frames) when off. In Windowed Aero mode, I always get glitches. Vsync doesn't appear to be doing anything or even detect the actual refresh rate in windowed aero mode, something that the trunk build does even with AERO on.

[janos666]

@janos666: I assume you tested 3801r, the standard 3801 messed up a memory resource for the LUT creation.
It's really dark and sepia-like (low saturation, hue shifted far away from blue). The older version is dark, but doesn't have such a big impact on saturation and tint. Do you see the same thing, or something else?

Yes, 3801r and yes, very brownish white balance with strange huye and saturation.

[RGold]

Some preliminary tests in exclusive full screen produce heavy tearing when Alt Vsync is on, and no tearing but jerky motion (glitches, not dropped frames) when off. In Windowed Aero mode, I always get glitches. Vsync doesn't appear to be doing anything or even detect the actual refresh rate in windowed aero mode, something that the trunk build does even with AERO on.

Yes, tearing is the biggest issue for me. I tried all render settings but none helps. Also sometimes it hangs when starting a video and only way out is to open task manager and kill the application. Want back to the "official" version that seems to work all the time.

[Hera]

You guys use XP or something?

[RGold]

You guys use XP or something?

Windows 7 + ATI 5450

[ForceX]

Yes, 3801r and yes, very brownish white balance with strange huye and saturation.
Did you delete your existing lut3d files? Files from old versions were creating such problems for me.

[G_M_C]

There was a request posted before, that you reset all your settings upon installing Jan's versions, and reconfigure. Also try not to use Jan's version on the same machine as trunk builds.

This is to prevent unreliable or untrue bug-reports, that cannot be reproduced and/or found by the developer(s).

[CruNcher]

Im doing that always automatically when comparing trunk and test :)

[cca]

There was a request posted before, that you reset all your settings upon installing Jan's versions, and reconfigure. Also try not to use Jan's version on the same machine as trunk builds.

This is to prevent unreliable or untrue bug-reports, that cannot be reproduced and/or found by the developer(s).

You understand that you're asking something unreasonable right? Most of us use our home PCs to test, you cannot possibly expect me not to have the trunk build around to plays videos! That build is reliable, at least it's renderer is, asking to have only Jan's builds is asking me to cripple my video playback capability. Sorry, but not going to happen until Jan's builds are on par in reliability with the trunk, in which case will replace the trunk.

As for the settings, I store them in .ini files, no chance that they may interact.

[Hera]

Windows 7 + ATI 5450

Thats... not right.

[CruNcher]

A small Player(Render and PP)/Decoder compare (with a out of DXVA Spec file) :)

EVR Custom Billinear PS 2.0 (MPC-HC test 3801r) + ffdshow quicksync + Sharpen Complex 2:

http://www.mediafire.com/download.php?h9ia0mi6tr637sv

Splash Quicksync Decoder (DXVA?) + Custom Renderer (Direct3D?) + Detail Boost (Shader?):

http://www.mediafire.com/download.php?lr93jn6pnut54bg

PS: A speedup actually indicates a slowdown in Real (when activating Sharpen Complex 2 in MPC-HC , need to find something not so heavy on GPU cycles to compare against splashs detail boost i guess) :(

[RGold]

Thats... not right.

What not right? I'm using Windows 7 X64 with ATI 5450 MXM video card.

[Hera]

Am I the only one who cannot access JanW32's builds on Media Fire right now? I need the latest SSE (non-SSE2) to test...

What not right? I'm using Windows 7 X64 with ATI 5450 MXM video card.

Well you shouldn't be getting tearing IMO. :)

[CruNcher]

uhh madshi implemented DXVA2 based Deinterlacing in his renderer :)
and current test build doesn't seem to support it anymore it crashes with it

[burfadel]

Yep! Me, I mentioned it the other day:

Mediafire folder doesn't seem to work... (keeps coming up no files then redirects me to my own Mediafire folder).

[Hera]

With Six sub pictures to buffer and allow animation while buffer and Haali Splitter and 8-bit surfaces and D3D:FS,
[FTV-subs] Touhou - Bad Apple!! PV [960x720] v2.mkv - started off more at 21 / 30 and moved to 30 / 30.

[CruNcher]

wow that result blows even looking @ the High resource utilization it's stable i would say even more stable then EVR custom or Mirillis Renderer result :)

MPC-HC trunk + Madvr (bicubic) + ffdshow quicksync

http://www.mediafire.com/download.php?7uhdibw4i3r2jce

[RGold]

Am I the only one who cannot access JanW32's builds on Media Fire right now? I need the latest SSE (non-SSE2) to test...



Well you shouldn't be getting tearing IMO. :)

I have no tearing issue with the regular version.

[CruNcher]

just 2 words jan it rocks (this was with 500 ms timer running in the background) :)

http://www.mediafire.com/download.php?ag163hwz6fewzlo

only the innit issue and it would be perfect from a stability stand for NT6 (until i finished my upcoming test marathon) ;)

PS: This is also cool now that any background noise is completely gone it's easy to tell problems apart immediately (for the whole chain) :) http://www.mediafire.com/download.php?d0bg6khk2lk8bjl

Another perfect result :) http://www.mediafire.com/download.php?7gxisjnzedbo0u8

This is also something cool http://www.mediafire.com/download.php?6uhkiqiajnak5c4 (not directly related but also MPC-HC test was used so ;) ) unthinkable todo with XP (NT5) :) 2 different frameworks running side by side with a low timer running :) (and if you take also the fact im recording this all near realtime on a IGP GPU directly (@ relatively low power) into what i upload it becomes even more amazing)

[TheElix]

What? What happened?
PS: This is also cool now that any background noise is completely gone it's easy to tell problems apart immediately (for the whole chain) :) http://www.mediafire.com/download.php?d0bg6khk2lk8bjl
What do you mean background noise is gone?

[burfadel]

How do we access the builds? I'm not the only one that can't access http://www.mediafire.com/?r367kbp7p9but

It just flashes up '0 Items to Display!', then redirects to my Mediafire page (in my case).

[XRyche]

How do we access the builds? I'm not the only one that can't access http://www.mediafire.com/?r367kbp7p9but

It just flashes up '0 Items to Display!', then redirects to my Mediafire page (in my case).

I'm sure JanWillem32 is aware of the issue by now. Just give him time to do something about it.

[CruNcher]

What? What happened?

What do you mean background noise is gone?

The Noise if you have constant vsync changes in the OSD it's still realizable though as a strange spike is visible in both situations but this way it's even easier to spot now (flat line everythings perfect, spike something is wrong somewhere) :)

[burfadel]

I'm sure JanWillem32 is aware of the issue by now. Just give him time to do something about it.

Ah ok! just that when I mentioned it, then mentioned by someone else, and then rementioned by myself, nobody else commented on the issue. At least now I know its a proper issue and not just an issue affecting only a couple of us.

[CruNcher]

So now we know why Mediafire had problems they completely overhauled it got a complete new HTML5 UI ;)

PS: Jan i tested a lot of DXVA implementation with your current EVR Custom and some fail i wonder those that doesn't fail could be called better though ;) ? it seems especially the init issue makes some decoders problems keeping a really big surface without changing it (Mainconcepts DXVA is on that list) :D

[Hera]

The latest SSE (non-SSE2) build crashes when resizing window while playing video.

[JanWillem32]

I'm glad that the folder works again. The links to the files remained the same, so that's a relief.

I've revised the internal numbering for the renderer selection list. This will reset the selection for the renderer to default on the first initialization.

About the settings, not everyone can use the save to .INI function, as it's limited in total size (it hardly supports even a few custom pixel shaders). The Miscellaneous page of the Options menu has a button to export all settings to a .REG file from the registry.

I've completely revised the texture handling for the subtitle renderer. It should have somewhat safer functions now, but some extra revisions will be required later on. It's a bit slower to react to resizing and will consume quite a bit more memory when switching from one buffer to another. Purging resources and making new ones while the video renderer is still running is a delicate procedure.

I've written a scheduler for on EVR CP, and I've misnamed it "Disable Scheduler" (the name of the function that was there before it). It's default enabled for the constant frame interpolator (not system dependent). The selectable version should work for Vista and newer in exclusive mode, for 7 and newer it's also available in windowed mode with Aero enabled. It doesn't have the Frame Time Correction function for VC-1 in MPEG transport streams yet, and I don't know if will work properly with all types of pulldown. It is at least completely compatible with scheduling for a command queue of several entire frames ahead (the other scheduling modes can't really queue more than 1). I probably have to work on getting timing right for the insertion moment of subtitles, but it does a pretty good job at it usually, and maybe I'll add proper support for the non-threaded version of the subtitle renderer later on. There's a new option to adjust the detected monitor refresh rate in the output tab, for if the scheduler skews a bit in timing (can be seen in the jitter graph, the lines should be roughly symmetrical, averaged over a few hundred frames).

I couldn't find out what exactly the problem is with the color management. It's quite clear that the update to the most recent beta caused this, but so far I haven't seen what part of the code is causing this. It might be sufficient to only update the code in the renderer. I will investigate this next week.

I didn't have time to test with external filters. I will do so within the next two weeks.

[golagoda]

I'm glad that the folder works again. The links to the files remained the same, so that's a relief.

I've revised the internal numbering for the renderer selection list. This will reset the selection for the renderer to default on the first initialization.

About the settings, not everyone can use the save to .INI function, as it's limited in total size (it hardly supports even a few custom pixel shaders). The Miscellaneous page of the Options menu has a button to export all settings to a .REG file from the registry.

I've completely revised the texture handling for the subtitle renderer. It should have somewhat safer functions now, but some extra revisions will be required later on. It's a bit slower to react to resizing and will consume quite a bit more memory when switching from one buffer to another. Purging resources and making new ones while the video renderer is still running is a delicate procedure.

I've written a scheduler for on EVR CP, and I've misnamed it "Disable Scheduler" (the name of the function that was there before it). It's default enabled for the constant frame interpolator (not system dependent). The selectable version should work for Vista and newer in exclusive mode, for 7 and newer it's also available in windowed mode with Aero enabled. It doesn't have the Frame Time Correction function for VC-1 in MPEG transport streams yet, and I don't know if will work properly with all types of pulldown. It is at least completely compatible with scheduling for a command queue of several entire frames ahead (the other scheduling modes can't really queue more than 1). I probably have to work on getting timing right for the insertion moment of subtitles, but it does a pretty good job at it usually, and maybe I'll add proper support for the non-threaded version of the subtitle renderer later on. There's a new option to adjust the detected monitor refresh rate in the output tab, for if the scheduler skews a bit in timing (can be seen in the jitter graph, the lines should be roughly symmetrical, averaged over a few hundred frames).

I couldn't find out what exactly the problem is with the color management. It's quite clear that the update to the most recent beta caused this, but so far I haven't seen what part of the code is causing this. It might be sufficient to only update the code in the renderer. I will investigate this next week.

I didn't have time to test with external filters. I will do so within the next two weeks.

As the last SSE version doesn't work very well, x86 SSE: http://www.mediafire.com/?57fm7xqvl9pzbd3
x64: http://www.mediafire.com/?45fm4vvmgbki9ou

Thanks so much, good job and I will try it as always.

[JanWillem32]

Thanks again.:)

I forgot to mention, the two new schedulers tend to require at least 8 mixer buffers to work properly. The jitter graph can even be seen jumping back and forth "in time" when not enough are set. Setting more buffers will also smoothen out the graph, because more samples can be scheduled ahead. Note that setting more buffers will require more memory, but won't necessarily increase the strain on the memory controller. If the video card or IGP is short on total memory, don't use too many buffers, as that will cause swapping textures to the system memory parts. Memory consumption for a single 1920×1080 video frame in the 8- or 10-bit formats takes 7.91015625 MByte, the 16-bit format takes double of that, and the 32-bit format quadruple. There are also some tools available to see the video memory consumption in real time.

[Hera]

As the last SSE version doesn't work very well, x86 SSE: http://www.mediafire.com/?57fm7xqvl9pzbd3


EDIT: Black Screen is caused by Firefox being open along with MPC:HC. What the ****?

Version 3801 was much much better in terms of being usable on Windows XP (See sig).

In that version I had video (3801). In this version I do not get video, just subtitles. There is also a flash of something every time a new line of subtitles appears - to fast for me to notice if that is video. Otherwise the screen is black.

On a youtube 1080p MP4, the screen is grey - black when I get statistics on screeen.

BUT, it doesn't crash when resizing!
EVR & VMR9 renderless also black screen.
Haali makes the player exit/crash.

Something else I noticed,
the ability of the render not to skip frames improved. I still need to test on some more intensive stuff when I have time.

[JanWillem32]

Well, that's quite a chaotic description we have there. Vanilla EVR and VMR-9 w. also give a black screen? I probably can't solve that problem then, as these are completely external renderers. If the mixer parts are failing, it will affect VMR-9 r. and EVR CP, too. You do have normal playback without programs rendering in the background?
The frame dropping code for EVR was a bit rusty, so I've given it some minor updates. The new schedulers tend to never drop frames at all, which can be a bit of a problem if the video frame rate is slightly below, equal or over the monitor refresh rate. I'll have to take a look at creating code to allow dropping frames for such situations, to prevent desynchronization.

[Mierastor]

Would it be possible to add Lanczos to the resizers? It is very popular for image resizing and many people think it gives the best result.

[JanWillem32]

It's been a while since I've added any resizers, so I can indeed try. I'll look for some code or math for it, as long as it's easy to insert. (I'm not going to work out the programming for sampling nodes, like I did for the spline5 and spline6 forms anytime soon.)

[Mierastor]

Ffdshow tryouts has Lanczos as one resize option so maybe there is some useful code there.

[Keiyakusha]

lanczos is a shortcut for bicubic with taps=3 or something like that. don't really remember.
lanczos4 is a bicubic too, but with taps=4

spline on the other hand is somewhat different than lanczos and "many people think it gives the best result"

[Mierastor]

lanczos is a shortcut for bicubic with taps=3 or something like that. don't really remember.
lanczos4 is a bicubic too, but with taps=4
http://en.wikipedia.org/wiki/Lanczos_resampling

[Keiyakusha]

http://en.wikipedia.org/wiki/Lanczos_resampling

Lanczos is a "customized" bicubic, customized by guy with the name Cornelius Lanczos, what you don't understand?

[Mierastor]

Lanczos is a "customized" bicubic, customized by guy with the name Cornelius Lanczos, what you don't understand?
Both are convolution filters. The results can be quite different.

Just Google to find numerous discussions regarding advantages or disadvantages for Lanczos vs. Bicubic.

[Keiyakusha]

Both are convolution filters. The results can be quite different.

Just Google to find numerous discussions regarding advantages or disadvantages for Lanczos vs. Bicubic.

I'm not saying they are the same. Obviously they are not. I'm saying Bicubic can be tweaked to make lanczos out of it. Something like that.

[JanWillem32]

The bicubic filters really don't look a thing like the windowed sinc filters. I know the base filter, but I very much prefer a processed convolution using the weights functions.
base Lanczos sample weight filter:#define PI acos(-1)// this will generate the number PI with full precision, it is useful for example with the sin, cos and tan functions

double LanczosFilter(double x, double radius)
{
if(x == 0) return 1;
if(x < 0) x = -x;// intrinsic sign(...) is faster as it only reads 1 bit, but for a quick sample this is sufficient
if(x >= radius) return 0;// cutoff if beyond 2 for lanczos2, 3 for lanczos3, radius is normally a static const
return sin(x*PI)*sin(x*PI/radius)/(x*x*PI*PI/radius);
}All that's left is to fill in the variables, and write out the convolution function of 4 weights for Lanczos2, 6 for Lanczos3, etc.. A very tedious task.

[Mierastor]

I'm not saying they are the same. Obviously they are not. I'm saying Bicubic can be tweaked to make lanczos out of it. Something like that.
Cannot be done in for example Ffdshow which includes a lot of customization options.

[JanWillem32]

Lanczos2, probably correct in function, but not optimized:// (C) 2011 Jan-Willem Krans (janwillem32 <at> hotmail.com)
// This file is part of Video pixel shader pack.
// This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
// This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
// You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.

// prototype Lanczos2 height resizer
// This shader should be run as a screen space pixel shader if you are up-scaling.
// This shader should not be run as a screen space pixel shader if you are down-scaling.
// This shader requires compiling with ps_2_0, but higher is better, see http://en.wikipedia.org/wiki/Pixel_shader to look up what PS version your video card supports.
// If possible, avoid compiling with the software emulation modes (ps_?_sw). Pixel shaders require a lot of processing power to run in real-time software mode.
// This shader is meant to work with linear RGB input and output. Regular R'G'B' with a video gamma encoding will have to be converted with the linear gamma shaders to work properly.
// Use this shader to scale the height of an image by Lanczos2 interpolation.

// fractions, either decimal or not, are allowed
// set the magnification factor
#define Magnify (4/3.)

sampler s0;
float2 c0;
float2 c1;
#define sp(a, b) float4 a = tex2D(s0, float2(tex.x, coord+b*c1.y));
#define PI acos(-1)// this will generate the number PI with full precision

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float coord = (tex.y/Magnify+.5-.5/Magnify)*c0.y;// assign the output position, normalized to texture height in pixels
float t = frac(coord);// calculate the difference between the output pixel and the original surrounding two pixels
coord = (coord-t+.5)*c1.y;// adjust sampling matrix to put the ouput pixel in the interval [Q1, Q2)

sp(Q1, 0)// nearest original pixel to the top
if (t) {
sp(Q0, -1) sp(Q2, 1) sp(Q3, 2)// original pixels
float Lanczos2wQ0 = sin((1.+t)*PI)*sin((1.+t)*PI/2.)/(pow(1.+t, 2)*PI*PI/2.);
float Lanczos2wQ1 = sin(t*PI)*sin(t*PI/2.)/(t*t*PI*PI/2.);
float Lanczos2wQ2 = sin((1.-t)*PI)*sin((1.-t)*PI/2.)/(pow(1.-t, 2)*PI*PI/2.);
float Lanczos2wQ3 = sin((2.-t)*PI)*sin((2.-t)*PI/2.)/(pow(2.-t, 2)*PI*PI/2.);
return Lanczos2wQ0*Q0+Lanczos2wQ1*Q1+Lanczos2wQ2*Q2+Lanczos2wQ3*Q3;}// interpolation output

return Q1;// case float t == 0 is required to return sample Q1, because of a possible division by 0
}

// (C) 2011 Jan-Willem Krans (janwillem32 <at> hotmail.com)
// This file is part of Video pixel shader pack.
// This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
// This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
// You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.

// prototype Lanczos2 width resizer
// This shader should be run as a screen space pixel shader if you are up-scaling.
// This shader should not be run as a screen space pixel shader if you are down-scaling.
// This shader requires compiling with ps_2_0, but higher is better, see http://en.wikipedia.org/wiki/Pixel_shader to look up what PS version your video card supports.
// If possible, avoid compiling with the software emulation modes (ps_?_sw). Pixel shaders require a lot of processing power to run in real-time software mode.
// This shader is meant to work with linear RGB input and output. Regular R'G'B' with a video gamma encoding will have to be converted with the linear gamma shaders to work properly.
// Use this shader to scale the width of an image by Lanczos2 interpolation.

// fractions, either decimal or not, are allowed
// set the magnification factor
#define Magnify (4/3.)

sampler s0;
float c0;
float c1;
#define sp(a, b) float4 a = tex2D(s0, float2(coord+b*c1, tex.y));
#define PI acos(-1)// this will generate the number PI with full precision

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float coord = (tex.x/Magnify+.5-.5/Magnify)*c0;// assign the output position, normalized to texture height in pixels
float t = frac(coord);// calculate the difference between the output pixel and the original surrounding two pixels
coord = (coord-t+.5)*c1;// adjust sampling matrix to put the ouput pixel in the interval [Q1, Q2)

sp(Q1, 0)// nearest original pixel to the left
if (t) {
sp(Q0, -1) sp(Q2, 1) sp(Q3, 2)// original pixels
float Lanczos2wQ0 = sin((1.+t)*PI)*sin((1.+t)*PI/2.)/(pow(1.+t, 2)*PI*PI/2.);
float Lanczos2wQ1 = sin(t*PI)*sin(t*PI/2.)/(t*t*PI*PI/2.);
float Lanczos2wQ2 = sin((1.-t)*PI)*sin((1.-t)*PI/2.)/(pow(1.-t, 2)*PI*PI/2.);
float Lanczos2wQ3 = sin((2.-t)*PI)*sin((2.-t)*PI/2.)/(pow(2.-t, 2)*PI*PI/2.);
return Lanczos2wQ0*Q0+Lanczos2wQ1*Q1+Lanczos2wQ2*Q2+Lanczos2wQ3*Q3;}// interpolation output

return Q1;// case float t == 0 is required to return sample Q1, because of a possible division by 0
}It also seems I really need to fix the post resize pixel shader parameters, but that's just a flaw in the renderer code.

[Hera]

When the CPU cannot keep up, unlike Haali Renderer, EVR desyncs to a certain point and then cuts out audio and it is disastrous.
When you say "code to allow dropping frames" - will this mean no audio dropouts when CPU cannot keep up?
Under this situation, if the CPU *always* cannot keep up - can the behavior match/exceed what Haali Renderer does?

Off-topic question,
The "#define PI acos(-1)" is being cached by the compiler?

[JanWillem32]

The new schedulers indeed won't drop frames (these will only try to modulate ready frames if it's really late or early), unless desynchronization by the global timer is detected (which allows huge time differences of the audio and video timers). In that case, timers for both the video and audio renderer are reset. The old scheduler will still often drop ready frames from the mixer, or prevent frames from decoding, with any sort of interruption in my case.

The "#define PI acos(-1)" just converts to a constant floating-point number. You can take a look at what a pixel shader stores in its registers by opening the "Shader editor", make the compiler compile some code, extend the gray bottom box to readable size, and scroll trough to the output assembly. (A somewhat faster alternative for developers is to compile a .TXT file, using the fxc.exe utility in the DirectX SDK.)

// Parameters:
//
// float c0;
// float c1;
// sampler2D s0;
//
//
// Registers:
//
// Name Reg Size
// ------------ ----- ----
// c0 c0 1
// c1 c1 1
// s0 s0 1
//

ps_3_0
def c2, 0.375, 0.3125, 0.5, 2
def c3, 1, 1.57079637, 6.28318548, -3.14159274
def c4, 4.93480206, 1, 2, 0
dcl_texcoord v0.xy // tex<0,1>
dcl_2d s0

#line 27
mad r0.x, v0.x, c2.x, c2.y
mul r0.y, r0.x, c0.x // ::coord<0>
frc r0.y, r0.y // ::t<0>

#line 34
add r0.z, r0.y, c3.x
mad r0.w, r0.z, c2.z, c2.z
frc r0.w, r0.w
mad r0.w, r0.w, c3.z, c3.w
sincos r1.y, r0.w
mul r0.w, r0.z, c3.y
mul r0.z, r0.z, r0.z
mul r0.z, r0.z, c4.x
rcp r0.z, r0.z
sincos r2.y, r0.w
mul r0.w, r1.y, r2.y
mul r0.z, r0.z, r0.w // ::Lanczos2wQ0<0>
mul r1.xy, r0.y, c3_abs.wyzw
sincos r2.y, r1.x
sincos r3.y, r1.y
mul r0.w, r2.y, r3.y
mul r1.x, r0.y, r0.y
mul r1.x, r1.x, c4.x
rcp r1.x, r1.x
mul r0.w, r0.w, r1.x // ::Lanczos2wQ1<0>

#line 29
mad r0.x, r0.x, c0.x, -r0.y
add r0.x, r0.x, c2.z
mul r1.x, r0.x, c1.x // ::coord<0>

#line 33
mov r1.yw, v0.y
texld r2, r1, s0 // ::Q1<0,1,2,3>
mov r3.w, c2.w
mad r3.z, c1.x, r3.w, r1.x

#line 38
mul r4, r0.w, r2

#line 33
mad r1.z, r0.x, c1.x, -c1.x
mad r3.x, r0.x, c1.x, c1.x
texld r1, r1.zwzw, s0 // ::Q0<0,1,2,3>

#line 38
mad r1, r0.z, r1, r4
add r0.xz, -r0.y, c4.yyzw
mul r4.xyz, r0.xxzw, c3_abs.wyyw
sincos r5.y, r4.x
sincos r6.y, r4.y
sincos r7.y, r4.z
mul r0.w, r5.y, r6.y
mul r4.xy, r0.xzzw, r0.xzzw
mad r0.x, r0.z, c2.z, c2.z
frc r0.x, r0.x
mad r0.x, r0.x, c3.z, c3.w
sincos r5.y, r0.x
mul r0.x, r7.y, r5.y
mul r4.xy, r4, c4.x
rcp r0.z, r4.x
rcp r4.x, r4.y
mul r0.x, r0.x, r4.x // ::Lanczos2wQ3<0>
mul r0.z, r0.z, r0.w // ::Lanczos2wQ2<0>

#line 33
mov r3.yw, v0.y
texld r4, r3, s0 // ::Q2<0,1,2,3>
texld r3, r3.zwzw, s0 // ::Q3<0,1,2,3>

#line 38
mad r1, r0.z, r4, r1
mad r1, r0.x, r3, r1 // ::main<0,1,2,3>
cmp oC0, -r0.y, r2, r1 // ::main<0,1,2,3>

// approximately 114 instruction slots used (4 texture, 110 arithmetic)Not too bad, as far as I can see. (Reading assembly isn't easy. Also note the the nasty habit of the compiler to truncate numbers to less decimal places than it usually stores in its binary format.)

[G_M_C]

It's been a while since I've added any resizers, so I can indeed try. I'll look for some code or math for it, as long as it's easy to insert. (I'm not going to work out the programming for sampling nodes, like I did for the spline5 and spline6 forms anytime soon.)

AviSynth contains lots of different resizers. maybe you can find some inspiration in Avisynth's source ?

[golagoda]

+1 for Lanczos, I use that with 4 taps on madVR and it provides comparable results to spline 3/4taps, most people seem to prefer lanczos to spline though, depends on how much you hate ringing for the most part, lanczos gives a bit more.

Take your time and I look forward to it if you add it ;)

[JanWillem32]

Thanks for the tips, maybe I'll find something in the Avisynth code. I'll definitely take some time to add a set of resizers. It's a lot of work to get the shader code running, and even more work to write the menu entries (the main reason I added a whole set of six resizers at once the last time).

I've taken a look at the external filters. For the renderers it was easier to solve than I thought at first. (I was afraid it was one of the changes to the subtitle renderer.)
I've also fixed a minor bit of memory management for the subtitle renderer.

[RGold]

Initial test looks good. No tearing.
Question regarding mixer format: With the official version I get input and output same NV12. This build I get NV12 input and x8R8G8B8. What is the difference between these mixer formats?

[JanWillem32]

I changed the stats screen a bit to show what raw format is transferred from the decoder to the mixer, and what format is transferred from the mixer to the renderer. The stats screen of the renderer in the trunk build isn't very clear on this point, but it really does the same thing.

[G_M_C]

I changed the stats screen a bit to show what raw format is transferred from the decoder to the mixer, and what format is transferred from the mixer to the renderer. The stats screen of the renderer in the trunk build isn't very clear on this point, but it really does the same thing.

I think i've asked before, but i cannot remember / or find back the answer:
Was is possible to find out what format the renderer actually outputs to the display ? (Reason for this: to verify if 10-bit is actually outputted, and no dithering is done in/by the renderer)

[JanWillem32]

The renderer itself can only dither when it's commanded to do so (setting dithering level 0 will definitely disable it). As to the capacity of the driver to dither down a 10-bit frontbuffer (in exclusive mode) to 8-bit, I've never seen it happening. My main working display is analog (analog connections on my HD4890 are fed by a 10-bit DAC) and my secondary device accepts 10-bit input easily trough HDMI. Maybe someone can try it out again with an old 8-bit DVI-D monitor on a video card that's generally capable of 10-bit output, but of course won't be able to with such a monitor. Will the monitor give a black screen, will the driver refuse to enable 10-bit output mode (so it can be seen in the stats screen), fake the 10-bit output by rounding to 8-bit, or fake the 10-bit output by dithering to 8-bit?
The last option is actually unlikely. Dithering is pretty heavy, so it's a task for the shadercore (biggest block of transistors in a GPU). When the data is written to a back buffer (which later on shifts places to become a front buffer), the shadercore generally doesn't read or write to/from it again. Reading from the front buffer is done by the micro-controllers for the hardware output ports. These do have some logic on board to convert the front buffer format in memory to signals to output on TMDS (DVI/HDMI), Mini-packet (DP) or analog (through a DAC). I can't imagine that any of those micro-controllers would have a dithering unit on board.
The other three options can simply be observed.
Note that some digital displays will actually report the type and bit depth of the incoming signal.

[G_M_C]

The renderer itself can only dither when it's commanded to do so (setting dithering level 0 will definitely disable it). As to the capacity of the driver to dither down a 10-bit frontbuffer (in exclusive mode) to 8-bit, I've never seen it happening. My main working display is analog (analog connections on my HD4890 are fed by a 10-bit DAC) and my secondary device accepts 10-bit input easily trough HDMI. Maybe someone can try it out again with an old 8-bit DVI-D monitor on a video card that's generally capable of 10-bit output, but of course won't be able to with such a monitor. Will the monitor give a black screen, will the driver refuse to enable 10-bit output mode (so it can be seen in the stats screen), fake the 10-bit output by rounding to 8-bit, or fake the 10-bit output by dithering to 8-bit?
The last option is actually unlikely. Dithering is pretty heavy, so it's a task for the shadercore (biggest block of transistors in a GPU). When the data is written to a back buffer (which later on shifts places to become a front buffer), the shadercore generally doesn't read or write to/from it again. Reading from the front buffer is done by the micro-controllers for the hardware output ports. These do have some logic on board to convert the front buffer format in memory to signals to output on TMDS (DVI/HDMI), Mini-packet (DP) or analog (through a DAC). I can't imagine that any of those micro-controllers would have a dithering unit on board.
The other three options can simply be observed.
Note that some digital displays will actually report the type and bit depth of the incoming signal.

Thx for the answer. I'll have to read it again to understand it fully, but for now i get the idea that if the stats screen reports the renderer is using 10-bit (i.e. in the stats screen is reported something like A2R10G10B10), i can safely assume the output format is 10-bit as well.

[ForceX]

Apart from the crashes when resizing, dfr3810i was the last good build working for me. Ever since the new scheduler build I just can't get smooth playback of 1080p content with CUVID decoding, whether I tick the Disable Scheduler or not. However, I don't think it's exactly related to the new scheduler, because it also happens with VMR9r which doesn't even have the new scheduler. During playback at 16 bit the framerate would drop erratically, but playback is fine if I switch to a 720p video or 8 bit or use software decoding. At first it seemed the problem was because video memory was getting filled but GPU-Z reports the same usage for 3810i and 3836i. Moreover, the problem doesn't happen when Aero is disabled or I use exclusive mode. GPU usage stays below 70% so it's probably not due to workload.

3833i seemed to have a video memory leak in conjunction with CUVID decoding but it seems to have been fixed in 3836, so that's good.

[janos666]

or fake the 10-bit output by dithering to 8-bit?

A spatial/temporal dithering is applied after the 16-bit 2D calibration LUT. It's easy to test.

I calibrated one of my friend's 8-bit (6bit+dithering) c-PVA display. I measured 10-bit effective precision, and ended up with very nice results (the uncalibrated state was disastrous but ArgyllCMS/dispcal did a very decent work, the white balance and gradation got smoothed out without noticeable banding).

My H5850 have one HDMI output only, but I need two cables between my VGA and my TV (one calibration settings memory per input and different refresh rates require different settings...). 10-bit output (EVR-CP) works through both HDMI and DVI->HDMI connections (I use HDMI->HDMI for 1080p24 playback and DVI->HDMI 1080p60 for PC gaming).


I am still not sure about what happens in the HDMI->HDMI situation (real or fake). My PDP is full of dithering noise already (as well as any 6-10+ bit LCD displays I tested had some amount of internal dithering), so I can't visually evaluate this.

[Hera]

Latest build works great, performance wise, on my netbook.

[JanWillem32]

I don't have too much time before I have to go, but I mostly worked on new SSE code for the subtitle texture preparation functions. I've also fixed a "text falloff" problem with bitmap subtitles (still needs better aspect ratio correction).
I'll try to involve myself with the development of a better subtitle renderer if I can come to terms with the rest of the people involved (I'm asking for a lot, and I won't cooperate if the subtitle renderer isn't fundamentally changed to finally produce quality output). It's at the xy-vsfilter tracker, and I'll try to read that thread later on (lot of text, no time for it now). http://code.google.com/p/xy-vsfilter/issues/detail?id=40

@ForceX: A difficult situation, and pretty hard to analyze as well. It could be the combination with the FlipEx present mode (which is pretty new). Only I don't remember exactly when I implemented the FlipEx mode (I believe I did mention it somewhere in this thread). I'll take a look at creating a debug build later, maybe that will help to test.

@Hera: With all present modes or some in particular? I believe you were having issues with subtitles before, this has been solved?

I've worked out the (efficient) programming for a set of Lanczos filters and Bézier curves. Regarding the Lanczos filters, I know the base properties of a truncated windowed sinc function, and I was not very surprised when I simulated values for input:
For a simulated value of t = .312 , the weights for the function are:
-3-> 0.01353790110500565952473035467006
-2-> -0.01482150141104846335254841219284
-1-> -0.08627089893640504238179223189432
0-> 0.81387680430780980122826820168191
1-> 0.31372932636473093833162302177254
2-> -0.02780500481463081933622775622197
3-> -0.02055291682427676817514069470158
4-> 0.00582486728065545855547543976717

The weight sum for a Lanczos2 {-1, 0, 1, 2} is: 1.0135302269215048778418712353382 .
The weight sum for a Lanczos3 {-2, -1, 0, 1, 2, 3} is: 0.97815580868617964631418212844374 .
The weight sum for a Lanczos4 {-3, -2, -1, 0, 1, 2, 3, 4} is: 0.99751857707184076439438792288097 .

The current set of filters and the Bézier curves always sum up to 1 (those are simply built that way). My question is: does anyone know of a way to compensate the weight factors of truncated sinc functions? Also, up how big should the filter window be? I've seen versions taking 16 pixels in each sampling direction (Lanczos8, 256 pixels weighed per output pixel), that's just a lot for a filter that weights the last set of pixels by less than ±0.001 (it's even less for the less dramatic base windowed functions than Lanczos).
Lanczos4:// (C) 2011 Jan-Willem Krans (janwillem32 <at> hotmail.com)
// This file is part of Video pixel shader pack.
// This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
// This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
// You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.

// prototype Lanczos4 height resizer
// This shader should be run as a screen space pixel shader if you are up-scaling.
// This shader should not be run as a screen space pixel shader if you are down-scaling.
// This shader requires compiling with ps_2_a, but higher is better, see http://en.wikipedia.org/wiki/Pixel_shader to look up what PS version your video card supports.
// This shader is meant to work with linear RGB input and output. Regular R'G'B' with a video gamma encoding will have to be converted with the linear gamma shaders to work properly.
// Use this shader to scale the height of an image by Lanczos4 interpolation.

// fractions, either decimal or not, are allowed
// set the magnification factor
#define Magnify (4/3.)

sampler s0;
float2 c0;
float2 c1;
#define sp(a, b) float4 a = tex2D(s0, float2(tex.x, coord+b*c1.y));
#define PI acos(-1)// this will generate the number PI with full precision

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float coord = (tex.y/Magnify+.5-.5/Magnify)*c0.y;// assign the output position, normalized to texture height in pixels
float t = frac(coord);// calculate the difference between the output pixel and the original surrounding two pixels
coord = (coord-t+.5)*c1.y;// adjust sampling matrix to put the output pixel in the interval [Q1, Q2)

sp(Q3, 0)// nearest original pixel to the top
if (t) {
sp(Q0, -3) sp(Q1, -2) sp(Q2, -1) sp(Q4, 1) sp(Q5, 2) sp(Q6, 3) sp(Q7, 4)// original pixels
float4 wset0 = float4(3, 2, 1, 0)+t;
float4 wset1 = float4(1, 2, 3, 4)-t;
float4 w0 = sin(wset0*PI)*sin(wset0*PI/2.)/(wset0*wset0*PI*PI/2.);
float4 w1 = sin(wset1*PI)*sin(wset1*PI/2.)/(wset1*wset1*PI*PI/2.);
return w0.x*Q0+w0.y*Q1+w0.z*Q2+w0.w*Q3+w1.x*Q4+w1.y*Q5+w1.z*Q6+w1.w*Q7;}// interpolation output

return Q3;// case t == 0 is required to return sample Q3, because of a possible division by 0
}

// (C) 2011 Jan-Willem Krans (janwillem32 <at> hotmail.com)
// This file is part of Video pixel shader pack.
// This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2.
// This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
// You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.

// prototype Lanczos4 width resizer
// This shader should be run as a screen space pixel shader if you are up-scaling.
// This shader should not be run as a screen space pixel shader if you are down-scaling.
// This shader requires compiling with ps_2_a, but higher is better, see http://en.wikipedia.org/wiki/Pixel_shader to look up what PS version your video card supports.
// This shader is meant to work with linear RGB input and output. Regular R'G'B' with a video gamma encoding will have to be converted with the linear gamma shaders to work properly.
// Use this shader to scale the width of an image by Lanczos4 interpolation.

// fractions, either decimal or not, are allowed
// set the magnification factor
#define Magnify (4/3.)

sampler s0;
float c0;
float c1;
#define sp(a, b) float4 a = tex2D(s0, float2(coord+b*c1, tex.y));
#define PI acos(-1)// this will generate the number PI with full precision

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float coord = (tex.x/Magnify+.5-.5/Magnify)*c0;// assign the output position, normalized to texture height in pixels
float t = frac(coord);// calculate the difference between the output pixel and the original surrounding two pixels
coord = (coord-t+.5)*c1;// adjust sampling matrix to put the output pixel in the interval [Q1, Q2)

sp(Q3, 0)// nearest original pixel to the left
if (t) {
sp(Q0, -3) sp(Q1, -2) sp(Q2, -1) sp(Q4, 1) sp(Q5, 2) sp(Q6, 3) sp(Q7, 4)// original pixels
float4 wset0 = float4(3, 2, 1, 0)+t;
float4 wset1 = float4(1, 2, 3, 4)-t;
float4 w0 = sin(wset0*PI)*sin(wset0*PI/2.)/(wset0*wset0*PI*PI/2.);
float4 w1 = sin(wset1*PI)*sin(wset1*PI/2.)/(wset1*wset1*PI*PI/2.);
return w0.x*Q0+w0.y*Q1+w0.z*Q2+w0.w*Q3+w1.x*Q4+w1.y*Q5+w1.z*Q6+w1.w*Q7;}// interpolation output

return Q3;// case t == 0 is required to return sample Q3, because of a possible division by 0
}

[CruNcher]

Crashes immediately after loading the stream :( tried all kind of decoder nothing, 3836i works :(

http://img810.imageshack.us/img810/2533/mpchctestcrash.png

[JanWillem32]

Can you try a two-pass resizer (bicubic and onwards) and a one-pass resizer (first three options)? I think I've set the wrong borders for the resizer passes.

[gilic]

The first 3 options crash with a d3derr_invalidcall the rest seems to work.

[ForceX]

It could be the combination with the FlipEx present mode (which is pretty new). Only I don't remember exactly when I implemented the FlipEx mode (I believe I did mention it somewhere in this thread).

FlipEx was introduced in tester dfr3752ir. dfr3810i was the last good build working for me. The new scheduler was introduced in tester dfr3833i and builds since then are problematic for me.

[Hera]

Yeah performance is great in D3D:FS.
The complex subtitles on that music video work even.

[CruNcher]

The first 3 options crash with a d3derr_invalidcall the rest seems to work.

confirmed

PS: Heaviest issue i had till now http://img194.imageshack.us/img194/2483/afterlavsplitterhangwit.png though it seems to only happen in 1 constelation that involves current lav splitter-> mainconcepts mpeg-2 decoder (sdk9) bad dxva bitstream decoding and using File->Close while playing back after the hang MPC-HC test told me this and doesn't work anymore. Ok after a while it seems Windows recovered itself it did some strange things though for a while when trying to open another file after the hang with a new MPC-HC instance and lav splitter it showed "Opening" for several minutes and nothing happened (entirely different file, as this error message normally indicates a access violation) and when i tried to open Process Explorer it wasn't responding for a long time until 3 Process explorer opened up ;) typical stall situation known from NT5 already it seems (though first time i encountered one on NT6 so far :D ).

[Hera]

For the previous build (avoiding this one), on XP, opening a second file seems to crash the player.

[RGold]

I get black screen when I'm launching MKV files in full screen with build 3845i.

[Hera]

I am having hard time maintaining 24 Hz on AMD laptop which is weird - it drops frames and the GPU line zigzags out of control... Not codec related.

Sometimes it de-syncs and causes audio-delay. Pausing and starting it again fixes this issue.

[JanWillem32]

Firstly, I'm sorry I've been totally absent lately. My studies and such take up all my attention right now. It's a mess.
Anyway, I've added frame dropping code to the new scheduler (not in the constant frame interpolator yet) and added automatic chroma detection for chroma up-sampling functions (can still be disabled to test or for use with custom pixel shaders) to the renderer. I've re-written the code for the basic timer in x64 assembly (x86 is on a todo list). Lastly, I've edited the surface eraser function for the subtitle renderer.
Sorry that I haven't had the time to do more or answer questions right now. I'll try to free up some time in a few days to handle things as usual.

[G_M_C]

Firstly, I'm sorry I've been totally absent lately. My studies and such take up all my attention right now. It's a mess.[...]

Np, studies take priority. You are absolutely right on that.

[XRyche]

I take it that the SSE2 builds are still better (if you can use them.) than the SSE builds, right?

[Hera]

EDIT: Nevermind, this needs more testing.
EDIT2: When it comes to non-DXVA playback, Haali Renderer is still superior. Tested with 8 buffers. Haali Renderer did not de-sync where EVR:CP de-synced.

[jackbluray]

blu-ray subtitles are displayed not correctly. They disappear too fast. With ffdshow it works very well

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

bug tracker
https://sourceforge.net/apps/trac/mpc-hc/ticket/1907

[Hera]

What happened to JanW?

[golagoda]

What happened to JanW?

According to his profile he was last online today, probably just doesn't currently have as much time as he used to for whatever reason.

[JanWillem32]

Happy holidays!
Sorry I haven't been around for a while. Studies and family issues made me choose to restrict my area of activities. (Developing software for the projects I'm involved in is quite time consuming.)
I'm at my parents' house right now to spend the holidays with.
I did compile before I left home. I'll make some time to process the questions I received and add the changelog later.

[gilic]

The new release(x86) crashes instantly for me even without opening a file.

[JanWillem32]

I've confirmed that. The executables I've tested that came out of the compiler worked fine before, so I guess something went wrong during copying or archiving. The x64 version I've just downloaded runs fine. I'll upload a x86 version (or a new set) once I'm home again.

[shadewither]

Quoted from trunk MPC-HC thread:
If I ever get the DirectX 11 renderer in a working state (I cant get a mixer to work, unfortunately), I will most certainly not add any of the original scheduling and VSync code.
Does your mixer break the data flow, or it malfunctions in some graphs?
Maybe you can make a fake mixer+presenter combo and channel data out?

[JanWillem32]

The problem is that I don't have a custom mixer at all. If I did, I would have added a module like the one that handles the external EVR or VMR-9 mixers to the DirectX 9 allocator-presenter already. The mixer is the part that negotiates and accepts a DirectShow or Media Foundation video stream, transforms those to working surfaces in video memory, and in the case of EVR or VMR-9, also performs some basic initial filter passes.
I just never figured out how to accept a pin from the graph builder, and read the raw bytes exported by the video decoder. What I can easily do is initialize surfaces from a local unencoded resource in memory without using EVR or VMR-9.
It's too bad I haven't been able to get one to work, as I really don't like the superimposed filters that VMR-9 and EVR apply.
Those mixers will also only bind to DirectX 9 devices. I'm used to programming with DirectX 10 and 11. The interfaces and methods those have are a lot more modern, efficient and have very decent minimum hardware requirements. DirectX 9 has a huge amount of legacy stuff to deal with. I learned the hard way that when working with DirectX 9, I have to insert legacy support options, legacy support tests and fallback functions in every nook and cranny of the renderer code.

[Hera]

Two common problems with the previous 32/64 version (not dfr3913i),
- Sometimes crashes while seeking
- Sometimes crashed file opening nth file

[shadewither]

Happy holidays!
Sorry I haven't been around for a while. Studies and family issues made me choose to restrict my area of activities. (Developing software for the projects I'm involved in is quite time consuming.)
I'm at my parents' house right now to spend the holidays with.
I did compile before I left home. I'll make some time to process the questions I received and add the changelog later.

x64: http://www.mediafire.com/?8ujd5fbyapnn2tv
A small bug: some necessary shaders seem not enabled

If all below conditions are met:
1. surface is not 8-bit;
2. no pre-/post- shader enabled;
3. at 100% size.
(IOW, change surface format, leave rest settings default)

Symptom:
1. wrong color (as if in linear RGB?);
2. "display stats"/"remaining time" won't display.

System:
Windows 7 x64, Aero disabled
EVR input pin is NV12

[JanWillem32]

EVR indeed doesn't handle changes on-the-fly very well. Changing the base color format while rendering invokes a full device reset and the renderer will try to release all resources to make that happen. Unfortunately, the EVR mixer adds a lot of shadow references to various DirectX 9 rendering objects, and the DXVA helper function adds shadow references to the DirectX 9 Ex device and Direct3D 9 Ex base object. Those are a bit difficult to control. It's even worse when changing from rendering on one video card to another (by dragging the player from one screen to another). That operation is still often fatal.
Note that inheritance of (default) settings from the trunk build can give problems in certain cases

[Hera]

OMG/XVID stuff seems to crash when fullscreen non-D3D and you try to get to the seek bar
The audio keeps playing, player fully crashes though.

[CruNcher]

@JanWillem32
First a happy new year for you and family

and now to something i experienced recently due to Quicksync decoding tests http://forum.doom9.org/showpost.php?p=1549083&postcount=386
MPC-HC experimental version was dfr3882i SSE 32 Bit

PS: Will there be a 32 bit compile again ?

[JanWillem32]

The links are in the OP.

I've split x64, x86 SSE and x86 SSE2 code paths for a lot of functions: renderer class initializer, VSync (slightly), device creator/reset, color management (heavy modifications, but unfortunately it's only on the renderer side) and image saving function (heavy modifications, the previous copy function was unsuitable).
Little CMS has been updated again, so I'd like to evaluate if the color management functions all work properly.
The alternative scheduler was renamed, and now uses a different frame time estimation method. The code is shared with the constant frame interpolator. Refresh rate estimation for this scheduler is still statically modified by the "Refresh Rate Adjustment" item in the Output tab of the options screen.
For a better view on the scheduler, I've expanded the stats screen jitter graph (and right-aligned it).

Items to do next:
I have the suspicion that presenter modes used with Aero (both schedulers) and the constant frame interpolator are demanding too much exclusive access on system resources and reserve a lot of those as well. For some reason this doesn't seem to really happen at all when the D3D exclusive mode is used. For example, during testing I've seen differences of more than 200 MB in the video memory pool. That pool includes both used and reserved memory, but I can't get a clear view of it in a per-object basis. I can't get a reading on the different responses of the device I create for the renderer and the allocations done by the operating system and drivers. I'll prioritize some effort to solve this issue.
The windowed full screen seek bar is incompatible with the renderer. I don't know yet if it's easier for me to fix that bar or create a new bar and OSD system for the exclusive mode.
I've lined up both Bézier and Lanczos resizers for integration. I'm still wondering about the filter weights issue I posted about earlier: http://forum.doom9.org/showthread.php?p=1540386#post1540386 . Maybe someone knows more about compensation functions for windowed sync interpolation?
I've written a lot of text over time, and a Russian website already hosts a guide on MPC-HC featuring some of that, but any guide in English is either very old or very incomplete. The newer texts written on most topics are are in bits and pieces. (The guide of the stats screen is pretty much done though.) It all needs compiling and checking for grammar, spelling and completeness. I'll happily write some extra bits about some topics, but I'll probably have to ask someone else to put the guide together.

@Hera and CruNcher: I'll take a look at both issues. The windowed full screen bar will be a tough cookie though.

[gilic]

EVR CP is crashing while EVR works. I tried different rezisers, but that didn't make a difference (x86 SSE2).

edit: i think i pinpointed the cause: when I use lav splitter .mkv files will crash the player, with the internal splitter everything seems to work

[Hera]

Subtitles are hidden when using Haali Renderer Windowed.

[XRyche]

EVR CP is crashing while EVR works. I tried different rezisers, but that didn't make a difference (x86 SSE2).

edit: i think i pinpointed the cause: when I use lav splitter .mkv files will crash the player, with the internal splitter everything seems to work

Crashes with Haali media splitter as well.

[CruNcher]

@Jan

When EVR Custom Deinterlaces what does it use i see GPU shader activity is it using a normal blend or does it use what the Driver sets by default (so in this case the same Intel Pixel Adaptive Deinterlacer as on EVR ?, though if that's the case i should also see the same GPU Utilization with EVR ?)

EVR CP is crashing while EVR works. I tried different rezisers, but that didn't make a difference (x86 SSE2).

edit: i think i pinpointed the cause: when I use lav splitter .mkv files will crash the player, with the internal splitter everything seems to work

yep crashes also here all 32bit versions so far SSE,SSE2,AVX.
seems to be a 32 bit version issue the 64 bit versions work

though the stability of the 64 bit version seems also not to be 100% it crashes allways @ resizing from fullscreen back to windowed
and normal EVR doesn't seem to work in the 64 bit versions no Video output only Audio.
Though it cleans now the surface on close correctly :D

dfr3882i last 32bit version that works (extremely stable)

I've lined up both Bézier and Lanczos resizers for integration.
Cool stuff, though in Intels SB case i wonder if that would be needed especialy the GPU pressure would be fairly heavy and if its implemented in Hardware pretty useless putting the pressure on the Shaders it seems :)

http://forum.doom9.org/showpost.php?p=1552011&postcount=572
http://forum.doom9.org/showpost.php?p=1552089&postcount=577

[JanWillem32]

Sorry that I don't have much time now to handle questions. I did try to fix the x86 versions (it was a pretty nasty bug), and adjust three schedulers a bit.

[gilic]

Everything works nicely with the x86 SSE2 version :]

Alternate scheduler also works, my paint times are approx. 5 times higher than with the default scheduler. the jitter graph has some recurring spikes and the audio/video lines are more apart than with the normal scheduler. I keep the default setting of '1' in the options.

edit: Well I remembered an issue I've been having for a while now. When 'allow animation when buffering' is checked and the buffer is not zero I get flickering/frozen subs. This only happens when there are more lines on screen e.g. anime karaoke.

[CruNcher]

Don't be so sure it still crashes here though it seems to happen based on resolution with every resize Shader in EVR custom i still try to figure out what exactly triggers it as most streams work though its not triggered based on the Decoder thats for sure happens either with Software Decoding or DXVA and the same stream works with EVR Custom in dfr3882i.

ok i think i nailed it :)

dfr3984i:

208x160 crash
240x180 crash
320x128 crash
320x240 crash
480x272 crash
576x432 crash
640x480 OK
720x576 OK
1280x720 OK
1920x1080 OK

dfr3882i:

208x160 OK
240x180 OK
320x128 OK
320x240 OK
480x272 OK
576x432 OK
640x480 OK
720x576 OK
1280x720 OK
1920x1080 OK

[Hera]

Crashes with tiny res XVID/AVI x86_32 SSE2 Windowed - but plays it when using D3DFS

[golagoda]

Sorry that I don't have much time now to handle questions. I did try to fix the x86 versions (it was a pretty nasty bug), and adjust three schedulers a bit.

x64: http://www.mediafire.com/?mz64klh7ggjl34v
x86 SSE: http://www.mediafire.com/?0n3kuehn7xvqot0
x86 SSE2: http://www.mediafire.com/?6wvug90x2rub308
This is the first version in a while that has worked with external renderers, so good job with that, I used to always look forward to your releases because I use madVR sometimes but they stopped working for a while.

The only problem I've found so far is that MPC-HC will crash if you go from full-screen back to normal when the EVR custom renderer is used (open file, press F, leave it for a little bit then press F again and it will crash). I'm using the x86 SSE2 build with default settings (right click -> Renderer Settings -> Reset -> Reset to default) although I have no idea if that makes a difference at all, I reset it to that to see if any of my custom settings made it crash and it kept happening with the default. I also tried changing the resizer to nearest neighbour and bilinear to see if that would make a difference and that didn't do anything either - it still crashes.

Still great job nonetheless, this is coming along nicely.


Problem signature:
Problem Event Name: APPCRASH
Application Name: mpc-hc.exe
Application Version: 1.5.3.3984
Application Timestamp: 4f19ee19
Fault Module Name: nvd3dum.dll
Fault Module Version: 8.17.12.9053
Fault Module Timestamp: 4eece3fd
Exception Code: c0000005
Exception Offset: 007ee094
OS Version: 6.1.7600.2.0.0.768.3
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

I have no idea what's causing it, but I tried different video decoders and the same thing kept happening, although I tested 'EVR' as the renderer and it no longer crashed... weird.

[Hera]

In previous builds, I had major stuttering / frame-dropping with Radeon/AMD notebook - this new version seems to work just fine.

EDIT: Still crashes sometimes when opening file after having opened a different file already

Is it me or does it now continue playing audio when video cannot catch up?

[gilic]

dfr3984i:

208x160 crash
240x180 crash
320x128 crash
320x240 crash
480x272 crash
576x432 crash
640x480 OK
720x576 OK
1280x720 OK
1920x1080 OK


Can't confirm this with my PC. I have some old divx, wmv7 and wmv9 videos with resolutions below 640x480 and they do work as intended.

[CruNcher]

which build and settings exactly EVR isn't affected only EVR Custom

i see already 1 user at least that confirms it more or less :)

[gilic]

@Cruncher

MPC-HC dfr3984i x86 SSE2 (32bit); LAV Filters 0.44; EVR-CP, Catmull-Rom spline6, 4 buffers, 32bit FP surfaces, ati chroma fix Catmull-Rom spline5
everthing possible handled by LAV Filters

win7 64bit, ati 6870, Fujitsu P27T-6 @ 2560x1440 @ 60Hz

[CruNcher]

did you mean catmull-rom 4 or 6 ?,could you also try if it crashs for you forcing 8 bit output :) ?

[gilic]

spline6 as resizer and spline5 for chroma upsampling fix. I tested with 8bit surfaces and the same videos as yesterday and everything worked.

[XRyche]

I can confirm the crashing when going from full screen to windowed as well.

[menlvd]

confirm crashing when going from full screen

[JanWillem32]

Firstly, sorry that I probably haven't solved the crashing on switching from full screen this time. (As usual, I can't replicate the problem at all. I'll see if I can make time to run the debugger on another PC.)
Secondly, sorry that I don't make time to properly respond to requests, questions and various other related things. I'm already feeling a bit guilty about spending this afternoon on programming instead of writing another huge blob of text for my studies...

I'll try to take some time tomorrow to investigate a few things, and respond accordingly. For example, the Quicksync features CruNcher mentioned, I should probably get to know more about those. I know too little about several functions like these, maybe I'll find something worthy to implement separately in the renderer code.

Anyway, I did have some success on some parts, but it will need to be tested, as usual.
-I added a graph that logs paint time.
The colors are now:
gray: time ruler
red: jitter
blue: paint time
green (EVR only): logged incremental frame times
The green line is the most inaccurate. Frame times are usually corrected with the lock function of the renderer to get some stability. VMR-9 doesn't allow control over frame times at all, that's why this graph is absent for VMR-9 r..
The red and blue lines complement each other. It's possible to have a hiccup in one, but not in the other. Both the alternative scheduler and the constant frame interpolator on Vista or newer allow buffering up to 6 frames in the command queue and up to 3 ready buffers to present (requires either Aero or the exclusive mode to be enabled). The "vanilla" mode with Aero enabled can store one frame in the command queue or in the buffer. On systems older than Vista, only the exclusive mode can store 3 ready buffers to present, but probably doesn't keep much in the command queue at all.
The windowed mode without Aero enabled requires the alternative VSync function. This presenter mode flushes all buffers before presenting each frame, so none can be used.

-I've changed the sampler for the frame timers on Vista and newer. These are a bit more precise (so no more flat jitter graphs). Note that the precision is a bit lower with this one for the jitter and frame time log in windowed mode (paint time remains the same). In the exclusive mode, every frame is logged, but in the windowed mode, a lot of present logs are skipped or frames are late because of the delay by the desktop composition. As long as the blue paint time graph remains stable or is completely compensated immediately after each time it has a spike, there's not a real problem with presenting frames.

-I've added compensation functions to better handle difficult frame rate to display refresh ratios for the alternative scheduler.

-I've integrated Lanczos2, 3 and 4. I'm worried about the rounding issues, like I've expressed earlier. In a few tests the moire patterns were very visible, along with the typical ringing. I'd definitely like to add a compensation function for the windowed (sinc) functions to counter such an effect.

-The main reason I'm posting this:
I've improved the texture handler for the subtitle renderer. It seems to work for external renderers as well, but it might need further editing (I've only done a debug run).
I've lowered memory and bus load used for clearing and transferring subtitle texture data. Further improvements will require multi-texturing, which is out of reach for now. Improving its ghastly rendering quality, speed and responsiveness will take time and effort.

A side-project, Copytest...
I wanted to see how much there was to gain with specialized memory copy and fill method over the basic functions. In the mean time I've already implemented the basic SSE copy and fill methods in a few parts of the code (which is working very well). Others might be interested in this, so I'll share it here for now.
The package is only 134 kilobytes in size. It contains source code and executables for both x86 and x64. SSE level requirements for the processor is indicated for each type of test. All tests allocate 512 megabytes (two chunks of 256 megabytes) to test. Basic safety features to abort memory allocation in case of failure are present. Note that warming up the main memory and caches by running one of the tests a few times is usually required to get a representable score. The comments that I left in the code are from after a few rounds of tests. Other PCs may show different test results than the few I gathered.

[CruNcher]

Firstly, sorry that I probably haven't solved the crashing on switching from full screen this time. (As usual, I can't replicate the problem at all. I'll see if I can make time to run the debugger on another PC.)

Hope you find out what change causes the low resolution crashes (starting with dfr3984i cant test dfr3975 as this crashes with every resolution) ? (Intel SB GT1 2559) its also still the case with dfr4005i


Intel(R) HD Graphics 2000




Report Date: 1/26/2012
Report Time[hr:mm:ss]: 1:13:27
Driver Version: 8.15.10.2559
Operating System: Windows 7 Service Pack 1(6.1.7601)
Default Language: German (Germany)
DirectX* Version: 10.1
Physical Memory: 8039 MB
Minimum Graphics Memory: 128 MB
Maximum Graphics Memory: 1760 MB
Graphics Memory in Use: 176 MB
Processor: Intel64 Family 6 Model 42 Stepping 7
Processor Speed: 3110 MHz
Vendor ID: 8086
Device ID: 0102
Device Revision: 09




* Processor Graphics Information *


Processor Graphics in Use: Intel(R) HD Graphics 2000
Video BIOS: 2080.0


Here is the Windows Error Report when trying to render such low resolution streams above dfr3882i

Problemsignatur
Problemereignisame: APPCRASH
Anwendungsname: mpc-hc.exe
Anwendungsversion: 1.5.3.4005
Anwendungszeitstempel: 4f206339
Fehlermodulname: igdumd32.dll
Fehlermodulversion: 8.15.10.2559
Fehlermodulzeitstempel: 4ea1aae9
Ausnahmecode: c0000005
Ausnahmeoffset: 00001828
Betriebsystemversion: 6.1.7601.2.1.0.256.1
Gebietsschema-ID: 1031
Zusatzinformation 1: 0a9e
Zusatzinformation 2: 0a9e372d3b4ad19135b953a78882e789
Zusatzinformation 3: 0a9e
Zusatzinformation 4: 0a9e372d3b4ad19135b953a78882e789

Dateien zur Beschreibung des Problems
WERInternalMetadata.xml
AppCompat.txt
memory.hdmp
minidump.mdmp





Though i have to say its working pretty good except for those 2 crash issues mentioned i tested 3 different sources in windowed mode on Aero and especially 1 of them caused problems the 25 fps Pal in a circle motion camera pan it stuttered with dfr3882i (BBC topgear)
this is not the case anymore all 3 different sources play smooth in windowed now :) 25p Pal 23.976 Film (telecined) and 29.970i Ntsc

Add another crash condition to the list drag and dropping another source into the window while something is still playing also causes it to crash now :(

tough this also looks more specific as it doesn't crash the other way

1440x1080 25fps (CoreAVC DXVA Native) running
->1920x1080 29.97fps (Lav Video Mpeg-2 DXVA 2 Copy Back) = crash

1920x1080 29.97fps (Lav Video Mpeg-2 DXVA 2 Copy Back)
->1440x1080 25fps (CoreAVC DXVA2 Native) running = works

also works both ways in dfr3882i without crashing (reproducible same as the small resolution and fullscreen to window crashs)

So 3 reproducible crashing conditions by me on Intel GT1 2559

1. Fullscreen to Window switching (appeared with dfr3975 64bit 32bit crashed immediately on any file load) https://forum.doom9.org/showpost.php?p=1552771&postcount=756 (confirmed by at least 1 other person)
2. Small Resolutions https://forum.doom9.org/showpost.php?p=1552986&postcount=759 (confirmed by at least 1 other person) (appeared with dfr3975 64 bit 32bit crashed immediately on any file load)
3. Specific (drag and drop size switching) (above) (confirmed only by me for now) (appeared with dfr3975 64bit 32bit crashed immediately on any file load)

all of these 3 crash conditions doesn't happen with dfr3882i (32bit) on Intel GT1 2559 Win7 64 Bit

[JanWillem32]

Maybe a debug trace tells more about these crashes.

I've disabled the frame statistics for this one, hoping that it's the cause of this issue. Note that it can't properly schedule at all because of this.
If anyone thinks this is a DirectX related issue, they can try the debug runtime. The SDK is available at: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=6812 (571.7 MB).
The utility to enable debug is: Program Files (x86) or Program Files \Microsoft DirectX SDK (June 2010)\Utilities\bin\x64\dxcpl.exe or ~x86\dxcpl.exe . Under Direct3D 9, select the debug runtime and "Maximum Validation" (don't forget to reset these after testing).
For viewing the regular debug messages, and optionally the messages generated by debug runtimes, DebugView can be used: http://technet.microsoft.com/en-us/sysinternals/bb896647 (286 KB).
With some luck, a file-line error pops up, so that I can take a look at a specific part of the code.

[CruNcher]

the crash for the resolution issue

[8096] DXVA Decoder : H.264 bitstream decoder, ClearVideo(tm)
[8096] Reset Device: Window size changed with a D3DEx device

Found struct for app : Canopus LossLess CODEC with install dir : \Device\HarddiskVolume2\Windows\System32\

Process Created PID:2748,Name:svchost.exe Parent PID:664

Process CommandLine :C:\Windows\system32\services.exe

Found struct for app : Lagarith Lossless Codec (1.3.25) with install dir : \Device\HarddiskVolume2\Windows

Process Created PID:5408,Name:WerFault.exe Parent PID:2748

Process CommandLine :C:\Windows\System32\svchost.exe -k WerSvcGroup

Process Removed PID:5408,Name:WerFault.exe, Parent ID:2748

Process Removed PID:3652,Name:mpc-hc.exe, Parent ID:5852


happens after the Windows size change :(


This is successfully opening (1920x1080) (fullscreen to window test)

[4048] DXVA Decoder : MPEG-2 variable-length decoder
[4048] --> CMainFrame::OnGraphNotify on thread: 7772; event: 0x0000000d (EC_CLOCK_CHANGED)
[4048] Reset Device: Window size changed with a D3DEx device
[4048] ResetDevice
[4048] --> CMainFrame::OnGraphNotify on thread: 7772; event: 0x0000000e (EC_PAUSED)
[4048] CreateDevice: 0x00000000


changing from WIndow to Full Window back and for (double clicking,no problem)

[4048] Reset Device: Window size changed with a D3DEx device
[4048] ResetDevice
[4048] CreateDevice: 0x00000000
[4048] Reset Device: Window size changed with a D3DEx device
[4048] ResetDevice
[4048] CreateDevice: 0x00000000
[4048] Reset Device: Window size changed with a D3DEx device
[4048] ResetDevice
[4048] CreateDevice: 0x00000000
[4048] Reset Device: Window size changed with a D3DEx device
[4048] ResetDevice
[4048] CreateDevice: 0x00000000

changing from Window to Fullscreen to Window (crash)

[4048] Reset Device: Window size changed with a D3DEx device
[4048] ResetDevice
[4048] CreateDevice: 0x00000000

Process Removed PID:7060,Name:TrustedInstaller.exe, Parent ID:664

Found struct for app : Canopus LossLess CODEC with install dir : \Device\HarddiskVolume2\Windows\System32\

Process Created PID:8080,Name:svchost.exe Parent PID:664

Process CommandLine :C:\Windows\system32\services.exe

Found struct for app : Lagarith Lossless Codec (1.3.25) with install dir : \Device\HarddiskVolume2\Windows

Process Created PID:6048,Name:WerFault.exe Parent PID:8080

Process CommandLine :C:\Windows\System32\svchost.exe -k WerSvcGroup



last debug the drag and drop specific size crash

Works:

[7344] DXVA Decoder : MPEG-2 variable-length decoder
[7344] --> CMainFrame::OnGraphNotify on thread: 6996; event: 0x0000000d (EC_CLOCK_CHANGED)
[7344] Reset Device: Window size changed with a D3DEx device
[7344] ResetDevice
[7344] --> CMainFrame::OnGraphNotify on thread: 6996; event: 0x0000000e (EC_PAUSED)
[7344] CreateDevice: 0x00000000


[7344] CAudioSwitcherFilter::DeliverEndFlush
[7344] --> CGraphThread::OnOpen on thread: 6760
[7344] --> CMainFrame::OpenMediaPrivate - pFileData->fns[0]:
[7344] G:\download\topgear_s16_e1.ts
[7344] --> CFGManagerPlayer::CFGManagerPlayer on thread: 6760
[7344] --> CFGManager::RenderFile on thread: 6760



Crashes:

[7344] DXVA Decoder : H.264 bitstream decoder, ClearVideo(tm)
[7344] CAudioSwitcherFilter::DeliverNewSegment
[7344] --> CMainFrame::OnGraphNotify on thread: 6996; event: 0x0000000d (EC_CLOCK_CHANGED)
[7344] --> CMainFrame::OnGraphNotify on thread: 6996; event: 0x0000000e (EC_PAUSED)
[7344] Reset Device: Window size changed with a D3DEx device
[7344] ResetDevice
[7344] CreateDevice: 0x00000000



[7344] CAudioSwitcherFilter::DeliverEndFlush
[7344] --> CGraphThread::OnOpen on thread: 6760
[7344] --> CMainFrame::OpenMediaPrivate - pFileData->fns[0]:
[7344] D:\test\telecine-mpeg2-hard-test.ts
[7344] --> CFGManagerPlayer::CFGManagerPlayer on thread: 6760
[7344] --> CFGManager::RenderFile on thread: 6760


[7344] CAudioSwitcherFilter::DeliverNewSegment
[7344] DXVA Decoder : MPEG-2 variable-length decoder

Found struct for app : Canopus LossLess CODEC with install dir : \Device\HarddiskVolume2\Windows\System32\

Process Created PID:3528,Name:taskhost.exe Parent PID:664

Process CommandLine :C:\Windows\system32\services.exe

Found struct for app : Canopus LossLess CODEC with install dir : \Device\HarddiskVolume2\Windows\System32\

Process Created PID:1816,Name:svchost.exe Parent PID:664

Process CommandLine :C:\Windows\system32\services.exe

Found struct for app : Lagarith Lossless Codec (1.3.25) with install dir : \Device\HarddiskVolume2\Windows

Process Created PID:5408,Name:WerFault.exe Parent PID:1816

Process CommandLine :C:\Windows\System32\svchost.exe -k WerSvcGroup


hmmm could it be really canopus or lagarith (both vfw) ? but why isn't this triggered with dfr3882i and what is calling this Found struct message ? nothing is impossible will deinstall both and see if it fixes this if it doesn't going to continue with DirectX Debug. Though that always this found struct message appears referring to canopus and lagarith if its crashing might be a coincidence also in the error reporting ?.

[JanWillem32]

It's something after the resizing step apparently, as the device itself reports a successful reset every time. It's just strange that it doesn't crash when doing a regular window resize action.
Don't worry about the codecs reported when the application crashes. That's just the garbage collection method Windows uses to release handles that were previously held by the graph thread. The graph builder will often maintain up to 50 handles if it has to sort many filters.
This is also the reason why the first initialization is so slow on Vista and newer. The graph builder loads all filters it can, sorts them, tries them and then selects the few it really needs with every playback instance. After the first initialization, Windows will be "smart" enough to keep the previously referred filters in memory, until it has to actually free up some memory for applications. This service is called Superfetch [svchost.exe -k LocalSystemNetworkRestricted], and can be controlled by executing the services.msc configuration tab.

[CruNcher]

Ahhh so superfetch is responsible for keeping dshow filters loaded also :)

anyways

Small Resolution Crash (still happening)

[7516] DXVA Decoder : H.264 bitstream decoder, ClearVideo(tm)
[7516] CAudioSwitcherFilter::DeliverNewSegment

Found struct for app : Lagarith Lossless Codec (1.3.25) with install dir : \Device\HarddiskVolume2\Windows

Process Created PID:8032,Name:WerFault.exe Parent PID:3924

Process CommandLine :C:\Windows\System32\svchost.exe -k WerSvcGroup

Process Removed PID:8032,Name:WerFault.exe, Parent ID:3924

Process Removed PID:7516,Name:mpc-hc.exe, Parent ID:5852

Window Fullscreen Window (still crashes)

[5144] CAudioSwitcherFilter::DeliverNewSegment
[5144] --> CMainFrame::OnGraphNotify on thread: 4516; event: 0x0000000d (EC_CLOCK_CHANGED)
[5144] DXVA Decoder : MPEG-2 variable-length decoder
[5144] Reset Device: Window size changed with a D3DEx device
[5144] ResetDevice
[5144] --> CMainFrame::OnGraphNotify on thread: 4516; event: 0x0000000e (EC_PAUSED)
[5144] CreateDevice: 0x00000000
[5144] Reset Device: Window size changed with a D3DEx device
[5144] ResetDevice
[5144] CreateDevice: 0x00000000

Found struct for app : Canopus LossLess CODEC with install dir : \Device\HarddiskVolume2\Windows\System32\

Process Created PID:7384,Name:svchost.exe Parent PID:664

Process CommandLine :C:\Windows\system32\services.exe

Found struct for app : Lagarith Lossless Codec (1.3.25) with install dir : \Device\HarddiskVolume2\Windows

Process Created PID:4244,Name:WerFault.exe Parent PID:7384

Process CommandLine :C:\Windows\System32\svchost.exe -k WerSvcGroup

Process Removed PID:4244,Name:WerFault.exe, Parent ID:7384

Process Removed PID:5144,Name:mpc-hc.exe, Parent ID:5852

Drag and Drop Size Specific (also still crashes)

[8080] --> CGraphThread::OnOpen on thread: 3804
[8080] --> CMainFrame::OpenMediaPrivate - pFileData->fns[0]:
[8080] G:\download\topgear_s16_e1.ts
[8080] --> CFGManagerPlayer::CFGManagerPlayer on thread: 3804
[8080] --> CFGManager::RenderFile on thread: 3804

[8080] DXVA Decoder : H.264 bitstream decoder, ClearVideo(tm)
[8080] CAudioSwitcherFilter::DeliverNewSegment
[8080] --> CMainFrame::OnGraphNotify on thread: 7232; event: 0x0000000d (EC_CLOCK_CHANGED)
[8080] --> CMainFrame::OnGraphNotify on thread: 7232; event: 0x0000000e (EC_PAUSED)
[8080] Reset Device: Window size changed with a D3DEx device
[8080] ResetDevice
[8080] CreateDevice: 0x00000000
[8080] CAudioSwitcherFilter::DeliverEndFlush

[8080] --> CGraphThread::OnOpen on thread: 3804
[8080] --> CMainFrame::OpenMediaPrivate - pFileData->fns[0]:
[8080] D:\test\telecine-mpeg2-hard-test.ts
[8080] --> CFGManagerPlayer::CFGManagerPlayer on thread: 3804
[8080] --> CFGManager::RenderFile on thread: 3804

[8080] CAudioSwitcherFilter::DeliverNewSegment
[8080] DXVA Decoder : MPEG-2 variable-length decoder

Found struct for app : Canopus LossLess CODEC with install dir : \Device\HarddiskVolume2\Windows\System32\

Process Created PID:4648,Name:svchost.exe Parent PID:664

Process CommandLine :C:\Windows\system32\services.exe

Found struct for app : Lagarith Lossless Codec (1.3.25) with install dir : \Device\HarddiskVolume2\Windows

Process Created PID:6556,Name:WerFault.exe Parent PID:4648

Process CommandLine :C:\Windows\System32\svchost.exe -k WerSvcGroup

Process Removed PID:4648,Name:svchost.exe, Parent ID:664

:(

[gilic]

Thanks for your new version JanWillem32.

I did some quick tests with the Touhou bad apple video with complex subs. Average frame rate seems a little bit higher than with your previous version. I noticed that with alternative scheduler and the stats screen the 'jitter' line of text is flickering (appearing/disappearing).

[JanWillem32]

@CruNcher: Yet another attempt at catching the bug: this time a build without the fast reset function; -.
(Other may of course try, too.)

@gilic: I'm glad that the code changes for the subtitle renderer seem to work.
The blinking text and jitter graph indicate that the alternative scheduler is dropping a frame. That functionality isn't implemented in a very pretty way indeed. It's also a bit limited, as it can't drop more than one frame in a row. After every dropped frame, it needs to present a few regular frames again. I doubt it can drop more than maybe a fifth of all frames in total.
I know that the windowed modes sometimes have a tendency to get stuck on going on and off dropping frames without going back to regular scheduling. It's something I have to work on.

[XRyche]

I have a weird issue after trying alternative scheduler in the latest SSE2 build. Everything seemed above-board before I tried the alternative scheduler but once i tried it and turned it off MPC-HC would crash after 1 to 2 minutes of play. I tried switching to madVR and VMR-9 renderless and playback was uninterrupted.

[Hera]

1.5.3.4005 SSE2
I don't think the renderer is working right anymore,
For example - Avr: ~25 Ref: ~29.97

The only stable line (now there are three) is the blue one. Red and Green seem to be in constant dense zig-zagging.
Sometimes both flatline for a tiny bit and then go back to /\/\/\/\/\/\/\/\/\/\/\

Funnies behavior ever,
Opened the [FTV-subs] Touhou - Bad Apple!! PV [960x720] v2.mkv
Which seemed to be working OK, the graph was a mess though.
Then the green line just vanished (division by 0 type vanished) and the video started playing at about 2x speed.
Sound cut out when the video started fast-forwarding.

Yep, something regressed bad enough to de-sync completely and then play too slow or too fast and it skips now.

Still crashes on exit. I think one way to get it to speed forward soundless at the speed of light is to display the statistics.

TLDR:
1.5.3.3984 SSE2 = sex
1.5.3.4005 SSE2 = with a porcupine

[CruNcher]

@CruNcher: Yet another attempt at catching the bug: this time a build without the fast reset function; mpc-hc SSE debug dfr4008i: http://www.mediafire.com/?121kzqrnk1r1a3r .
(Other may of course try, too.)

@gilic: I'm glad that the code changes for the subtitle renderer seem to work.
The blinking text and jitter graph indicate that the alternative scheduler is dropping a frame. That functionality isn't implemented in a very pretty way indeed. It's also a bit limited, as it can't drop more than one frame in a row. After every dropped frame, it needs to present a few regular frames again. I doubt it can drop more than maybe a fifth of all frames in total.
I know that the windowed modes sometimes have a tendency to get stuck on going on and off dropping frames without going back to regular scheduling. It's something I have to work on.

No go it just causes Echoes (visually) @ switching but doesn't fix any of the crashing conditions :( i would be much more relieved if someone on a Intel SB platform could confirm these 3 crashes with the 2559 driver :(
I guess we now came to a point where different ways of hardware workarounds are needed or either 1 way that works everywhere without nurturing the initial improvements can be found (which trunk provides in stability) :)
But therefore this is experimental, and who says that Intels Driver isn't doing something wrong or wasn't designed todo it the way you want todo it ;)
I just can say 100% for sure that dfr3882i was the last really stable version on this configuration and after it hell broke lose (in crash terms) ;)
And it still works that way so i guess i can be pretty sure that overall its not my systems fault in general (unless some change really causes some crazy unexpected 3rd party behavior that im not yet able to realize). Though it's always the best to have a confirmation for this to be sure and also to know in which direction to search for the problem exactly from here. So first confirmation from somewhere and then Pinpointing which change caused this behavior and then find out why it's causing the problems, so the way any Bugreporting system track or bugzilla works :)

[XRyche]

I have a weird issue after trying alternative scheduler in the latest SSE2 build. Everything seemed above-board before I tried the alternative scheduler but once i tried it and turned it off MPC-HC would crash after 1 to 2 minutes of play. I tried switching to madVR and VMR-9 renderless and playback was uninterrupted.

It appears to be corrected. I replaced SSE2 tester dfr4005i build with SSE2 tester dfr3801r build then I replaced that with the original SSE2 tester dfr4005i build. That seemed to correct the issue. Needless to say i won't be messing with the alternative scheduler until a new build.

[XRyche]

One other thing is that with 4:3 DVDs I get a series of thin vertical black lines on the left side of the screen with any degree of the new Lanczos resizer. It only happens with 4:3 DVDs (it doesn't happen with 16:9 DVDs) doesn't happen with another 4:3 format.

[vBm]

I've tried your latest SSE2 build (r4005) playing regular xvid file and going from windowed to fullscreen and then again back to windowed mode mpc-hc has crashed. Here's the minidump (http://vbm.omertabeyond.com/stuff/dmp/mpc-hc.exe.1.5.3.4005.dmp) if you need it.

[CruNcher]

@vmb

whats your config ?

i see no intel driver :)

[JanWillem32]

Thank you all for testing, I wouldn't have found the main crashing issue without the feedback here.

@XRyche: The Lanczos resizers are known to have heavy ringing and rounding issues. Do the lines come from borders in video itself or from the renderer background color? (The background color button is in the View, Options, Miscellaneous tab.)

I've fixed the windowed fullscreen bug, it was caused by the OSD renderer. After reviewing the code, I really wonder why it ever seemed to work at all. I've corrected the basics in the very old code, but it could still use some work to make it more efficient and look a lot better.
I don't know if I solved the problem with crashing on small videos, or other sorts of crashes.
I've edited the alternative scheduler and constant frame rate interpolator. I'm still struggling with the driver to get accurate statistics in non-fullscreen windowed mode with Aero enabled. It's not a big problem for the constant frame rate interpolator, as it really doesn't need much adjustments in timing. However, without it, the driver often doesn't update present statistics often, which is very annoying.
I've refreshed all base subtitle interface functions. It's still less than perfect, but at least I've marked the functions that I couldn't correct yet. If anything fails because of my editing, please report it.

edit: Sorry, the subtitle renderer broke because I did something dumb... I'll release a revision later.

[JanWillem32]

The text subtitle value look-up mechanism was easily fixed. I didn't change much else.

[JohnLai]

4017ri report :
External subtitle such as srt requires user to manually reload the subtitle in order for it to be shown at screen.
Tried to assign key to 'reload' function using 'R' key at mpc and play video in D3D mode, however, the assigned 'R' key only works with caplock turned on.

[XRyche]

Thank you all for testing, I wouldn't have found the main crashing issue without the feedback here.

@XRyche: The Lanczos resizers are known to have heavy ringing and rounding issues. Do the lines come from borders in video itself or from the renderer background color? (The background color button is in the View, Options, Miscellaneous tab.)

I'm pretty sure it isn't from the background colour. The lines extend from the border on the right side of the video itself.

I switched to your latest build (mpc-hc tester dfr4017ri)
and now DVDs only show black in anything but 8 bit surfaces.

[CruNcher]

@Jan
gonna test it Asap you might be also interested in this though i didn't base it yet on MPC-HC experimental https://forum.doom9.org/showpost.php?p=1554676&postcount=619 (also beginning with bicubic it becomes problematic keeping comparable results on GT1 as to much frames where lost, but i find it excelent to test efficiency, frames aren't lost realtime but in the Recording (copy back) overhead though) :)

Also gonna add Mirilis Renderer and sharpening shader :)

Though Jan is it really not possible to use EVR-Custom without the Scaling Shader part so all features of EVR but leaving the scaling to the driver ? (could save some GPU load on SB, adding something like "Use Hardware Resizer")

PS: All 3 crashing conditions are History great work Jan :)

[CruNcher]

You might be also interested in this :)

https://forum.doom9.org/showpost.php?p=1555374&postcount=664

[JanWillem32]

@JohnLai: I just tried external .SRT files in ANSI and UTF-16 formats, both seem to work fine. (I did reset all settings to default prior to testing.)
Keybindings can behave weird because other programs may be tracking them. It's also possible that another keybinding is interfering. MPC-HC does allow duplicates. For some reason there are also different keybindings for fullscreen and windowed modes.
I've had my share of issues with keybindings as well. I have a remote control for my PC. To make it easier to use it, I've had to clear all default keybindings and customize the ones I use. I found out that as long as I don't make combinations with modifiers, such as Shift, Ctrl or Alt, everything just works fine.

@XRyche: I think you're seeing the typical ringing and periodical artifacts. I've seen them as well on the test videos, but that's just how windowed sinc functions seem work without some sort of compensation. It would be a nice idea for a guide to feature pictures that point out the strong and weak points of each resizer, along with additional text.
For the second part, I guess you mean the DVD menus? The VOB videos I just tested seem to work properly. It's been a while since I messed with the DVD navigator. It used to crash or fail on initiating the stream.
If the DVD navigator filter reports a "Still" in the properties tab, the video renderer never receives a command to draw any frames. Frames are only updated when menus change, or when forced by pausing and unpausing.
Even the paused mode for regular video updates the frame twice per second. I should try to insert a similar function for during DVD stills, too.
Another issue is the output of the DVD navigator, it's X8R8G8B8. The EVR mixer is known to fail at RGB to RGB color conversion.

@CruNcher: Those functions are indeed interesting. I'd love to look at integrating them, once a custom mixer is working and I can load specific filters in the mixer stages from external DLL files, such as EVR.dll. For as long as I'm tied to the EVR, VMR-9, Quicktime and RealMedia mixers to handle video input pins, I'm unfortunately severely restricted. I've had a similar issue with trying to import the Sync clock from EVR Sync as an optional module.
I'm still interested in adding extra modules that affect mixer stages, but it will have to wait. Code that only affects later stages than the mixer can be implemented easily, tough.
I'll make comment in the "Intel SandyBridge" thread later on, after I've gathered some samples. The issue is the typical .5 pixel offset problem in DirectX 9: http://msdn.microsoft.com/en-us/library/windows/desktop/bb219690%28v=vs.85%29.aspx .

[XRyche]

@XRyche: I think you're seeing the typical ringing and periodical artifacts. I've seen them as well on the test videos, but that's just how windowed sinc functions seem work without some sort of compensation. It would be a nice idea for a guide to feature pictures that point out the strong and weak points of each resizer, along with additional text.
For the second part, I guess you mean the DVD menus? The VOB videos I just tested seem to work properly. It's been a while since I messed with the DVD navigator. It used to crash or fail on initiating the stream.
If the DVD navigator filter reports a "Still" in the properties tab, the video renderer never receives a command to draw any frames. Frames are only updated when menus change, or when forced by pausing and unpausing.
Even the paused mode for regular video updates the frame twice per second. I should try to insert a similar function for during DVD stills, too.
Another issue is the output of the DVD navigator, it's X8R8G8B8. The EVR mixer is known to fail at RGB to RGB color conversion.



I'm probably not explaining myself correctly (I'm not a videophile so I lack a lot of basic knowledge in this department), sorry. Here's a screenshot http://i.imgur.com/WkGrX.png this is full-motion btw and is still present during movie playback.. You can barely see it (along just the right-hand side, looks like one side of a broken picture frame when upscaled) , but it's there and gets worse when the render upscales when going fullscreen.

The second part isn't just DVD menus (I'm assuming you're referring to black screen during playback). It happens during movie playback as well. The blank screen did not happen in your previous releases regardless of the surface bit depth.

I know these are beta builds so if it seems like I'm complaining, I'm really not. I'm just trying to give a little feedback (awkward as it may be :) ).

[Hera]

This happened, I was able to watch the episode though,

Description:
A problem caused this program to stop interacting with Windows.

Problem signature:
Problem Event Name: AppHangB1
Application Name: mpc-hc.exe
Application Version: 1.6.1.4017
Application Timestamp: 4f27e185
Hang Signature: ec4d
Hang Type: 2048
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1033
Additional Hang Signature 1: ec4d947a8c9206898e20f07202d08b55
Additional Hang Signature 2: 7a57
Additional Hang Signature 3: 7a571f4c851b6bd785201d39f3c02156
Additional Hang Signature 4: ec4d
Additional Hang Signature 5: ec4d947a8c9206898e20f07202d08b55
Additional Hang Signature 6: 7a57
Additional Hang Signature 7: 7a571f4c851b6bd785201d39f3c02156

Read our privacy statement online:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409

If the online privacy statement is not available, please read our privacy statement offline:
C:\Windows\system32\en-US\erofflps.txt

[JohnLai]

Perhaps I am not describing the subtitle issue correctly.
First, I have a file using mkv as container. There is embedded soft subtitle inside the container.
Second, now I dont want to use that embedded sutitle and I put another subtitle (external).
Third, I play the file (which has embedded soft subtitle) plus external subtitle.
Fourth, non of the subtitle will show unless i manually reload.

[JanWillem32]

@XRyche: I've inverted the picture and changed the gamma to one quarter...
Other than the common encoding noise and chromatic errors of the encoding process, I don't see anything out of the ordinary in this picture. Could you point it out?
For the second part you mean that even playing back a .VOB file directly results in a constant black screen? I can't replicate that. Do you have a sample file that has this issue?
Last part: actually, these are deviated nightly builds. Beta builds are versioned and semi-synchronous with the trunk build. The renderer in these builds doesn't exist in this form for the trunk build. (I discarded the main part of the old renderer core.) Don't worry about complaining, I'd rather deal with issues now, than after integration with the main code.

@Hera: You mean it delayed a while before opening, or hung on the end of a video? I'll take a look at the codes you posted later. A basic search on them didn't reveal anything at the moment. I've not even had warnings on the end or closing the player in quite a while. I thought I handled most of them already. If it's on opening (for a few seconds), that's caused by the graph builder (something I never edited before). It sometimes seems to have a hard time loading and sorting filters. Another cause can be creating a LUT for the color management. That takes a while and can block the player's ability to respond to user input while calculating.

@JohnLai: I've just tested it with nearly default settings, and everything seems to work properly for both states of the "Prefer external subtitles over embedded subtitles" option. I've also tested an external splitter to be sure. What is your playback setup? Maybe I can replicate the problem with the same settings.

[Hera]

Hung 5 minutes in, D3DFS w. Graph Initialized (to the Task Manager!). Second time I opened I didn't initialize statistics...

[XRyche]

@XRyche: I've inverted the picture and changed the gamma to one quarter: http://imageshack.us/photo/my-images/534/wkgrxedit.png/ .
Other than the common encoding noise and chromatic errors of the encoding process, I don't see anything out of the ordinary in this picture. Could you point it out?
For the second part you mean that even playing back a .VOB file directly results in a constant black screen? I can't replicate that. Do you have a sample file that has this issue?
Last part: actually, these are deviated nightly builds. Beta builds are versioned and semi-synchronous with the trunk build. The renderer in these builds doesn't exist in this form for the trunk build. (I discarded the main part of the old renderer core.) Don't worry about complaining, I'd rather deal with issues now, than after integration with the main code.



I've found the reason for the blank screen while playing DVDs. If I'm not using hardware acceleration on both PowerDVD and MS MPEG2 decoders (probably happening with other decoders as well. These are the only 2 I use.) I get the blank screen. When I turn on hardware acceleration DVDs play as expected. The problem with this is that subtitles on DVDs don't display with hardware acceleration.

EDIT: It appears that switching to ffdshow's MPEG2 decoder has solved this particular problem. I have no clue why PowerDVD and MS MPEG2 decoders have that issue for me.

As far as the black lines on the right of the screen, they seem to only appear after upscaling and it looks like screenshots only get taken at original resolutions and not resized resolutions (I could be wrong but that's what it looks like).

EDIT: It seems that using the post resize pixel shaders (sharpen complex 2) combined with the Lanczos resizers cause the pronounced black lines on the right side of the video after resizing. When I turn off the pixel shaders it's almost nonexistent unless your specifically looking for it and are right in front of your PC.

[JanWillem32]

@Hera: So you tried to enable the stats screen and then the player was stuck for 5 minutes, but continued normally after that? Did you ever had issues previously with the stats screen? Can you replicate the issue again? Does the system log mention anything for the kernel or driver section at that time? (A driver crash and restart could cause a delay like this.) I'm sorry I'm asking a lot. I just never heard of an application recovering after being non-responsive for such a long time.

@XRyche: I'll try to use the decoders you mentioned to try to replicate the issue, but I can't guarantee that I will be able to replicate it. It's a rather specific issue, it seems. It's extremely uncommon that external software video decoder filters are affected by anything inside the player, especially with DXVA versions still working fine.
Good to know that the issue with the black lines was caused by post-resize pixel shaders. The methods in the original set of pixel shaders are mostly far from ideal, anyway.
If you want to take screenshots of the renderer's output, you can use the Print Screen button on your keyboard while playing. The resulting picture can be pasted into an image editor, such as the standard Paint. Note: D3D exclusive mode doesn't expose renderer output to the Windows desktop (one of the main reasons why it's efficient), so Print Screen won't work as expected in that mode.

[Hera]

I must apologize, but I mean that it got stuck after ~5 minutes of video and I had to invoke the Task Manager to *kill* it.
Second time I watched the entire episode without problems, but I did not evoke the stat screen.

Will test more probably today

[gilic]

There seems to be an issue with windowed mode and videos at their original resolution: the stats screen isn't shown, subtitles disappear and the video noticeably brightens up.
Resizing the window frame by one pixel fixes all the issues.

As always using the latest SSE2 version.

[JanWillem32]

@Hera: Very well, I understand it now. Did you see anything in the logs for the system and hardware, besides the error in the application logs you posted? It could be a driver error.

@gilic: Thank you, that was a good find. I've corrected the bug by changing one character in the code.

I've done some minor optimizations, mostly to enhance thread safety. Mostly the subtitle renderer is affected. The external renderers will be influenced by these changes this time as well.
The links are on the first page. I also included a link to the source code this time.

[gilic]

Thanks for the fix, but there is still one more issue I forgot to mention. When mpc-hc is in windowed mode and you move a firefox window in front the audio stops and the video speeds up by a lot. Could be a conflict with the d2d rendering in firefox.

[menlvd]

Thanks for the fix, but there is still one more issue I forgot to mention. When mpc-hc is in windowed mode and you move a firefox window in front the audio stops and the video speeds up by a lot. Could be a conflict with the d2d rendering in firefox.

same issue!

UPD!
try on HD 720 and 1080 ok! sometimes fail
SD 24fps/23,976 - fail
SD 25fps - ok

[Hera]

Audio cuts out and video start playing ~2x
The only way to stop the video from playing is to CTRL-C
Got that through seeking

[CruNcher]

Subtitles with EVR (default) and DXVA dukey did it :)

https://forum.doom9.org/showpost.php?p=1557391&postcount=16

[RGold]

I always see tearing right after the MKV video is dropping frames. Does not happen with the regular builds. Tried the alternative vsync on/off, didn't help.

[Hera]

MPC:HC is at fault - driver doesn't crash when MPC stops playback and need to killed.

[CruNcher]

@ Jan

this speedup issue also happens with Aero peak but only if the Peaked Window is above the Video surface and the mini preview isn't playing in the same group as the peaked Window (little complex) :)

Isn't the windows and all processes when peaked put into sleep state and after peaking returns from it so the acceleration happens @ the resume of the sleep state (maybe the timers aren't correctly frozen for the peak, and it tries to accelerate the time to get where it should be resyncing, instead from just waking up and resuming, and if the mini preview stays alive i guess it doesn't get frozen in anway and so happily continues without speeding up when the peak state is over) ?

PS: The default EVR renderer is still broken for Intel SB and Drivers (Black Screen) only in MPC-HC tester Trunk is fine

[JanWillem32]

The previous build had two major errors, so I've removed them from my folder. I also removed older builds.
-mixer formats were giving errors in EVR (VMR-9 was unaffected)
-sorting for SSA subtitles was flawed

The links are on the first page.

From a quick test, I can't replicate the speedup issue. I've tried both x86 and x64 nightly Firefox builds 13.0a1 (2012-02-16) in combination with some of my regular test videos.
As this is probably a scheduler and driver combination issue, I'd like to know which scheduler(s) are affected.
Scheduler options: (Not all combinations are valid. For example, alternative Vsync is always disabled in modes with Aero or the exclusive mode.)
adaptive deinterlacing / weave deinterlacing / interlaced bob rendering / progressive video,
Windows XP / Vista / Seven,
EVR / VMR-9,
constant frame interpolator on / off,
alternative Vsync on / off,
bordered windowed mode with Aero / bordered windowed mode without Aero / full screen windowed mode with Aero / full screen windowed mode without Aero / full screen exclusive mode

@Hera: What scheduler mode did you use?

@RGold: What scheduler mode did you use? Dropping frames is a very invasive action. It's hard to debug and implement. (The constant frame interpolator can't drop frames at all, for example.) I can try to change a few settings to improve the basic schedulers, but I can't guarantee extensive frame dropping support for the more advanced schedulers.

@CruNcher: About a year ago, I suggested to give the OSD renderer an input pin for the standard subtitle renderer, but no developers wanted to work on it. (Both the basic EVR and VMR-9 already accept the input by the OSD renderer.)
For the issue with the black screen with basic EVR, can you temporarily reset your settings, test, disable the OSD, and test again? The only thing I've changed is the OSD renderer, the rest of that renderer is external.
For the renderer, I've not implemented a type of sleep state at all. I can add a processing option for the overlapped and minimized window status messages, but what action would really be appropriate in such a case? I can pause the player, but other than that, dropping the video render filter chain (graph builder parts, splitter parts, video decoder, video renderer) would take ages to restart.

I did find a crashing bug when starting an interlaced DVD .VOB video while the player is minimized. I'll try to debug it later.

[gilic]

Thanks for the fix, but there is still one more issue I forgot to mention. When mpc-hc is in windowed mode and you move a firefox window in front the audio stops and the video speeds up by a lot. Could be a conflict with the d2d rendering in firefox.

I've got an update to that issue, seems this has nothing to do with firefox. It's enough to bring an explorer window to the front. Everything seems a bit random, but i found out that alternative scheduler doesn't have the problem (at least with the file were I had one).


-> adaptive deinterlacing / weave deinterlacing / interlaced bob rendering / progressive video (don't know, where can I check?)
-> win7 64bit
-> EVR-CP
-> frame interpolator always off
-> alternative Vsync always off
-> bordered windowed mode with Aero

[RGold]

@RGold: What scheduler mode did you use? Dropping frames is a very invasive action. It's hard to debug and implement. (The constant frame interpolator can't drop frames at all, for example.) I can try to change a few settings to improve the basic schedulers, but I can't guarantee extensive frame dropping support for the more advanced schedulers.


Sorry for my ignorance - where can I see the scheduler mode that is being used? Is crtl+J going to display it?

[XRyche]

Is the internal subtitle renderer still wonky?

[menlvd]

try alternative scheduler and it's works better for me, video a little bit stuttering and after few sec plays fine
evr-cp
2008 r2
mpc-hc x64
alternative vsync off
frame interpolator off
bordered windowed mode with Aero
only appears when switching to Firefox

[CruNcher]

The previous build had two major errors, so I've removed them from my folder. I also removed older builds.
-mixer formats were giving errors in EVR (VMR-9 was unaffected)
-sorting for SSA subtitles was flawed

The links are on the first page.

From a quick test, I can't replicate the speedup issue. I've tried both x86 and x64 nightly Firefox builds 13.0a1 (2012-02-16) in combination with some of my regular test videos.
As this is probably a scheduler and driver combination issue, I'd like to know which scheduler(s) are affected.
Scheduler options: (Not all combinations are valid. For example, alternative Vsync is always disabled in modes with Aero or the exclusive mode.)
adaptive deinterlacing / weave deinterlacing / interlaced bob rendering / progressive video,
Windows XP / Vista / Seven,
EVR / VMR-9,
constant frame interpolator on / off,
alternative Vsync on / off,
bordered windowed mode with Aero / bordered windowed mode without Aero / full screen windowed mode with Aero / full screen windowed mode without Aero / full screen exclusive mode

@Hera: What scheduler mode did you use?

@RGold: What scheduler mode did you use? Dropping frames is a very invasive action. It's hard to debug and implement. (The constant frame interpolator can't drop frames at all, for example.) I can try to change a few settings to improve the basic schedulers, but I can't guarantee extensive frame dropping support for the more advanced schedulers.

@CruNcher: About a year ago, I suggested to give the OSD renderer an input pin for the standard subtitle renderer, but no developers wanted to work on it. (Both the basic EVR and VMR-9 already accept the input by the OSD renderer.)
For the issue with the black screen with basic EVR, can you temporarily reset your settings, test, disable the OSD, and test again? The only thing I've changed is the OSD renderer, the rest of that renderer is external.
For the renderer, I've not implemented a type of sleep state at all. I can add a processing option for the overlapped and minimized window status messages, but what action would really be appropriate in such a case? I can pause the player, but other than that, dropping the video render filter chain (graph builder parts, splitter parts, video decoder, video renderer) would take ages to restart.

I did find a crashing bug when starting an interlaced DVD .VOB video while the player is minimized. I'll try to debug it later.

Don't need to test it anymore with the Leaked Intel (Ivy Bridge) Driver it works now (confirmed with older MPC HC tester builds and EVR Basic, where before it was black screen with Driver 2622 ( last internal driver update October last year ) it works now with the 2626 Driver (updated components last time in Januar this year, though not a official driver yet) :D

It's really nice to see their Drivers constantly improving it's really visible each update somewhere :)

Though still only 8 bit Integer Surfaces work with MPC-HC tester and EVR Custom

And yep as many said before using the alternative sheduler seems to fix every of those suddenly speedup issues (when something hits the video surface) also with aero peak (the one i mentioned above, video surface losing focus)

Though i had that speedup issue just 1 sec ago but it's hard to pinpoint could have been indeed firefox rendering above it though i have firefox direct2d disabled so the only thing that would be accellerated in those regards would be their layers which are D3D9 :)

So the Alternative Sheduler might not fix it entirely but it lowers the Probability of it happening a lot (especially the Aero Peak issue seems completely fixed by it, might be a good indication to pinpoint the overall problem), ill keep an eye on this maybe i can pinpoint some other specific speedup case :)

So it might not be the sleep state of the window but more a issue with the Renderer losing it's focus (Windowed) on Aero in some specific cases though only :D

[jakmal]

I am curious about how chroma upsampling is done with this renderer.

I believe EVR-CP uses the GPU to upsample chroma and the result is dependent on the GPU driver. Is the behaviour of this renderer any different?

[CruNcher]

@ A least on Intel it uses nothing on EVR-CP you need to actually activate the Chroma upsample shader (which consumes GPU same as the luma scaling itself) on EVR Basic Intels Driver does it perfect, see also my Intel Hardware PP vs EVR-CP and shader PP it shows some stages and differences also a pretty good Efficiency compare of the different stages :)

http://forum.doom9.org/showpost.php?p=1554676&postcount=619

http://forum.doom9.org/showpost.php?p=1555516&postcount=675

Though that it doesn't kill any visible data @ upscaling might be wrong if you look carefully it just seems to shift it different ;) though not sure if this is still the case with the new driver or if this might be also only a issue with MPCs EVR i didn't compared other EVRs yet without any changes like Microsofts Default EVR basic used in WMP,WMC or Graphedit Directly.

So in the end i would say frame data gets lost no difference if you use MPCs EVR-CP or EVR basic with the Hardware Scaler, though why this is the case is what i wonder about, and i still have to try different things which might be the reason for this (MPCs Video Frame options come to my mind)

[JanWillem32]

I don't have much time right now, but I'll write my usual amount of text later today. :)
I've re-written parts of the subtitle renderer to handle aspect ratio correction better and perform better texture management.
Because all subtitle types and video renderers required code changes for this, extensive testing is required.
The new check box is in the main "Subtitles" tab now, as I've changed it into a function that is mostly handled by the video renderer now, instead of a subtitle style option. The changes I've made should fix all aspect ratio issues known with the SSA styles (mostly rotation and curve drawings).
Because this function behaves differently, some people might not like it. As usual, I'm willing to discuss options.
The combo box for subtitle texture resolution became useless after I implemented dynamic allocation for the textures, so I removed it.

[burfadel]

I have a problem with dfr4046i, dfr4075 SSE2 works fine. The issue is the screen size with 4:3 material. The video plays too big, as if its greatly zoomed in (stuff off the edge of the screen). Videos that are 16:9 seem to be fine.

I have tried changing the aspect ratio, video frame settings, pan and scan settings etc, nothing gets it back to being correct. The only way to get it back to proper size is to use the manual zoom-in/zoom-out feature with the keypad.

[dukey]

JanWillem32,
are you interested in a subtitle solution that renders to a separate pin ? That's currently what I am working on. Or trying to at least. I already made a proof of concept filter
http://forum.doom9.org/showthread.php?p=1557391#post1557391

Currently trying to rewrite VSFilter to only pass through the video, then spit out subpics on pin number 2.

[JanWillem32]

Interlaced video: A video file can be checked for its video content with either external or internal MediaInfo. (The internal one is located under "File", "Properties".)
Interlaced video consists of two fields (top and bottom) that combine into frames using one of the two deinterlacing methods. The fields are half-height. For example, a true 1080i video field is 1920×540 in size. (Most "1080i" videos are encoded with merely 1440×540 fields, though. After deinterlacing, the video is resized horizontally to match the 16:9 aspect ratio.)

adaptive deinterlacing: This type of deinterlacing extrapolates frames from each field, so the frame rate is equal to the field rate.
This type of interlaced video is the most prone to have visible artifacts after deinterlacing.
Only TV recordings use this type. It's basically the encoded form of progressive video, where half of the scan lines are discarded, so it's a bit of a compromise.
Typical frame rates are 60, 60/1.001, 50, 48 and 48/1.001 Hz. Lower field rates are of course possible, but the scan line artifacts are very visible with lower field rates.

weave deinterlacing: This type of deinterlacing combines two fields in a frame, so the frame rate is half the field rate.
This type of interlacing only has issues with chroma scaling, and issues with having to encode video in two fragments in the (lossy) video compression scheme. It doesn't have to extrapolate other picture data, unlike adaptive deinterlacing.
Both quality and encoding efficiency are less than with the equivalent form of progressive video. This type of interlacing is commonly used to broadcast cinematic video on TV stations that don't permit any progressive video.
Typical frame rates are 60, 60/1.001, 50, 48, 48/1.001, 30, 30/1.001, 25, 24 and 24/1.001 Hz.

interlaced bob rendering: stretches fields out vertically to create a frame, so the frame rate is equal to the field rate.
This is a common fallback method for when adaptive deinterlacing is unavailable. This isn't a deinterlacing method at all, and it's very ugly.

progressive video: No fields are encoded in the source video for this, only complete frames.
Typical frame rates are again 60, 60/1.001, 50, 48, 48/1.001, 30, 30/1.001, 25, 24 and 24/1.001 Hz. Recording equipment can also store progressive video at a lot of other rates, but those are rarely supported by consumer-grade video carriers (broadcasts, discs and such).

Note that the type of interlacing and pulldown information generally isn't stored in the video stream header or file container header. It's read from the stream segments during playback.


@gilic: I'm still trying to replicate the issue. So far, I can only see frames dropping and slow video when frames overlap the video window.

@RGold: There are a lot of scheduler modes. Some options are indeed listed in the stats screen. The mode in use is determined by the list of options I posted yesterday.

@XRyche: Yes, and it always has been that way. It's slow, inefficient, and because it totally lacks any sensible image rendering methods, the image ouput quality is abysmal as well.
The requirement that I should keep VSfilter working using the shared code, makes working on the subtitle renderer parts a horrible chore.

@menlvd: The alternative scheduler sometimes needs a few seconds to lock to a frame rate. This can be seen in the top right of the stats screen. Some videos have such an unstable or uncommon frame rate that the scheduler reverts to per-frame scheduling, instead of using the frame rate lock. This is also the case with variable frame rate videos.

@CruNcher: Good to hear that a new driver is working properly. I'll keep it in mind for when people ask for information.

@jakmal: Chroma up-sampling is generally done by the EVR or VMR-9 mixer.
The mixers are pretty much a black box situation, viewed from the renderer's side. The graphics driver is free to push filters in the rendering chain, the only thing required is that it outputs on the RGB surfaces allocated by the renderer with the correctly negotiated video size.
Most of the filters on top of basic color conversion do more harm than good, though. I don't like it that in many graphics drivers "enhancement" filters for the EVR mixer are enabled by default.
Chroma up-sampling is one of the more basic filters. So far, I've yet to see anything else than nearest neighbor or bilinear filtering by the mixer's chroma up-sampler. The nearest neighbor filter is a "bonus" feature of the AMD driver if you allocate anything but X8R8G8B8 textures. It's easy to apply custom scaling by the renderer if an image has already been scaled by a factor two using nearest neighbor filtering. That's pretty much the "fix" I've implemented as a renderer option.
Note that "using the GPU" doesn't tell everything. The main workhorse of the GPU is its shadercore, but besides that, there are a number of options for integrating ASIC components on the GPU, such as the DXVA decoder circuit. Some filters set by the graphics driver are exclusive to a specific ASIC component (and with it, come the limitations of such a specific circuit). If for example a pixel format isn't supported by an ASIC, the video driver can crash (always very nice), give a black screen output (very common), do the filtering on the shadercore instead (impossible for DXVA), use the ASIC anyway (will give corrupt pixel output), skip the filter (I think this is exactly happening with the AMD driver), or yet even other options I can't think of at the moment...
About that chroma up-sampling custom pixel shader supplied with the player; it's pretty bad, just like most of the others. I still have to round up a nice selection of my own pixel shader set to integrate and delete all of the original ones.
I would love to implement a custom mixer to handle filters like chroma up-sampling by the renderer itself, but I haven't yet figured out how to negotiate a DirectShow/MediaFoundation video pin (this is currently handled completely by EVR and VMR-9).

@burfadel: What kind of video, in which renderer, in what mode, on which system did you experience this problem?

@dukey: My original thoughts were to append the usual subtitle allocator presenter host to the OSD renderer, which is already on a pin for vanilla EVR and VMR-9 in MPC-HC. I can probably help you with the internal parts of the subtitle renderer, but I'm not familiar with handling video pins.

[burfadel]

Problem on win 7 x64, HD6950, EVR-CP renderer, disabled internal video decoders (just for h264 and xvid/divx) and using ffdshow (for filter effects). Issue only affects 4:3 content, and only with dfr4076i, dfr4075 and the normal mpc-hc is fine.

[RGold]

@RGold: There are a lot of scheduler modes. Some options are indeed listed in the stats screen. The mode in use is determined by the list of options I posted yesterday.


I have attached the setting ini file.

[JanWillem32]

I've tested the code, and I've indeed made a typo in the part that calculates the top-to-bottom aspect ratio factor. This is an error in the standard video renderer handler, so all video renderers are affected. I'll re-compile when I have the time. Manually setting a scaling factor is a proper workaround for this issue.

[Hera]

Video stops playing (720p MP4 4:3, ripped from YouTube) when the following actions happen
Minimized
Video hidden by other Windows


MKVs keep on playing without sound (I use Matroska splitter btw)

[CruNcher]

@ Jan
does MPC-HC use the http://en.wikipedia.org/wiki/Multimedia_Class_Scheduler_Service ? that Microsoft introduced with Vista

http://technet.microsoft.com/en-us/magazine/2007.02.vistakernel.aspx

http://blogs.technet.com/b/markrussinovich/archive/2007/08/27/1833290.aspx

Only administrative accounts, like the Local System account in which MMCSS executes, have the Increase Priority privilege that's required to set real-time thread priorities.

Also the Display Stats for EVR-CP couldn't be the same done also for EVR-Basic as the OSD works it shouldn't be any problem to get the same Graph and Information to be displayed same as for subtittles and all without losing DXVA and any Driver ASIC functions (scaling) also :)

[XRyche]

@XRyche: Yes, and it always has been that way. It's slow, inefficient, and because it totally lacks any sensible image rendering methods, the image ouput quality is abysmal as well.
The requirement that I should keep VSfilter working using the shared code, makes working on the subtitle renderer parts a horrible chore.



Ah sorry, I'm not being very clear again. For the past 5-7 builds MPC-HC Experimental has been crashing due to the internal subtitle renderer. I'm pretty sure it's the internal renderer because when I use xyfilter it doesn't crash at all when displaying subtitles (A.S.S.).

[gilic]

I've re-written parts of the subtitle renderer to handle aspect ratio correction better and perform better texture management.
Because all subtitle types and video renderers required code changes for this, extensive testing is required.
The new check box is in the main "Subtitles" tab now, as I've changed it into a function that is mostly handled by the video renderer now, instead of a subtitle style option. The changes I've made should fix all aspect ratio issues known with the SSA styles (mostly rotation and curve drawings).


I've been testing again with the bad apple video.
Performance is the the same for me as with your previous builds. There is a bug/glitch which I noticed, under r.click->video frame when "touch window from inside" (was my default setting I used till now) is selected, the video is cut/moved out off screen above and below. Subtitles in this space are still rendered and performance is worse than usual. With "stretch to window" everything is fine. What's the best setting to use for normal video viewing (full screen)?

Unfortunately I couldn't really test your new rotation & curve drawing code, because I couldn't find a scene with the anime I have.

Also thank you again for your detailed description of the video modes. The windowed mode speedup/stopping issue still persists, but it's only a minor issue for me. I just reported it. You needn't spend to much time on it.
mediainfo of the culprit:
General
Complete name : F:\DAoC\The Clansman[Adorn].avi
Format : AVI
Format/Info : Audio Video Interleave
File size : 154 MiB
Duration : 20mn 40s
Overall bit rate mode : Variable
Overall bit rate : 1 040 Kbps

Video
ID : 0
Format : MPEG-4 Visual
Format settings, BVOP : 1
Format settings, QPel : No
Format settings, GMC : No warppoints
Format settings, Matrix : Default (H.263)
Muxing mode : Packed bitstream
Codec ID : DX50
Codec ID/Hint : DivX 5
Duration : 20mn 40s
Bit rate : 902 Kbps
Width : 512 pixels
Height : 384 pixels
Display aspect ratio : 4:3
Frame rate : 24.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.191
Stream size : 133 MiB (87%)
Title : Video
Writing library : DivX 5.2.1 Alpha (UTC 2004-09-08)

Audio
ID : 1
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Mode : Joint stereo
Codec ID : 55
Codec ID/Hint : MP3
Duration : 20mn 40s
Bit rate mode : Variable
Bit rate : 128 Kbps
Channel(s) : 2 channels
Sampling rate : 44.1 KHz
Compression mode : Lossy
Stream size : 18.6 MiB (12%)
Alignment : Aligned on interleaves
Interleave, duration : 26 ms (0.63 video frame)
Interleave, preload duration : 117 ms
Title : Audio
Writing library : LAME3.92

[JanWillem32]

@Hera: That's one I can easily try in my next debugging session.

@CruNcher: pfAvSetMmThreadCharacteristics is indeed used (for Vista and newer), I kept the lines from the trunk build.
EVR-CP:
http://sourceforge.net/apps/trac/mpc-hc/browser/trunk/src/filters/renderer/VideoRenderers/DX9AllocatorPresenter.cpp
CDX9AllocatorPresenter::VSyncThread (commented out)
http://sourceforge.net/apps/trac/mpc-hc/browser/trunk/src/filters/renderer/VideoRenderers/EVRAllocatorPresenter.cpp
CEVRAllocatorPresenter::RenderThread
CEVRAllocatorPresenter::GetMixerThread (commented out)
Also see CEVRAllocatorPresenter::StartWorkerThreads for the base thread priorities.
EVR Sync:
http://sourceforge.net/apps/trac/mpc-hc/browser/trunk/src/filters/renderer/VideoRenderers/SyncRenderer.cpp
CSyncAP::RenderThread

Note that only the color management parts can really block. Both threads already yield at least once for each frame to prevent blocking. The base priorities (critical and high) are fine. I can disable the MMCSS functions in the renderer, but I think it's working fine as it is.

The vanilla EVR renderer handler is very simple. It doesn't gather stats at all. The external EVR doesn't expose much either. Most of the stats displayed by EVR-CP and VMR-9 r. are purely from the renderer itself.
If someone wishes to write an OSD renderer with stats, I'll happily assist. For the renderers I'm working on, I'm planning to write a seperate OSD renderer that doesn't send screen-sized bitmaps (one of the design flaws that the subtitle renderer also used to have).

@XRyche: Is it with all ASS/SSA subtitles? Else, do you have a sample subtitle file? Did you already try resetting your settings? What mixer input format is reported by the renderer with xy-VSfilter enabled and without?

@gilic: See my previous post about the aspect ratio problem.
I didn't change the rotation & curve drawing code. That part of the code was incapable of adapting aspect ratios. I solved that problem externally.
I'll try to find a sample like the type you posted. I've not been able to replicate the issue yet.

[Hera]

I use the default scheduler BTW

[JanWillem32]

I fixed the aspect ratio math and a minor flaw in the timer math for one of EVR CP's stats for for larger elapsed time values.

[gilic]

Confirmed fixed, thanks.

[Hera]

Actually, video doesn't stop - it speeds up.
Uhm, green line dissapears whenever MPC is not visible it seems and never gets back (if I get back to the video quickly, it goes back, otherwise after a second or two - well it bugs out)
... and you cannot pause the video it seems (stop button works though).
This sees to happen with everything - AVI files included (240p AVI, but not 100% reproducible)
And no sound.
If I use the thumbnail (W7) - it doesn't happen - I guess something happens when the video is not in any form visible to the user that the scheduler doesn't know how to handle.

WMP doesn't actually play the video when it is not visible - I noticed that it quickly recovers when I get back to it...

Alternative scheduler seems really really bad (stutters, can't keep up, de-syncs), but doesn't have this problem.

[JanWillem32]

@RGold: The text file you appended was finally approved. The settings inside described this mode:
adaptive deinterlacing / weave deinterlacing / interlaced bob rendering / progressive video (can vary),
Windows 7,
EVR,
constant frame interpolator off,
alternative Vsync on,
bordered windowed mode without Aero / full screen windowed mode without Aero

The VSync mode written by my predecessors was hard to integrate into the new renderer core. I thought I got it right a few versions ago. I didn't know that the prior kept VSync when dropping frames, nor that mine didn't. I'll take a look at it, maybe I can change it. Thank you for reporting, I would not have found such an exceptional case on my own.

@Hera: I still can't reproduce the issue, but I'll keep trying, including with other computers than mine. The alternative scheduler currently can't handle bordered windowed presenting, dropping more than 1 in 5 unscheduled frames (maybe even less), and it has slowdown issues with overlapping menus (such as the right-click menu). It can easily drop scheduled frames, by the way. For example; playing a 50 fps video on a 25 Hz monitor should cause the scheduler to evenly discard half of all frames.

[JohnLai]

The latest build has issue with blu ray subtitle = Idx + Sub external blu ray subtitles.

http://i.imgur.com/gS9Ll.jpg

[JanWillem32]

Oh, dear... The subtitle renderer must really be broken this time to output grammar like that...
I'll try to look up a Idx + Sub combination. It's probably only a minor issue if the previous builds worked fine.

[JanWillem32]

I'm sorry, but I've tried five samples of Idx + Sub, internal and external with a few types of containers and I can't reproduce the problem at all. Do you get this issue with all Idx + Sub combinations, or only with this one? If it's only this one, can you upload a sample?

[JanWillem32]

I've made a few fixes and performance improvements.
There's a new graph in the stats screen.
-Cyan (previously blue): frame paint time
-Magenta in EVR CP: frame time read from the video stream (magnified by 10)
-Magenta in VMR-9 r.: frame time difference delegated by the external VMR-9 thread (magnified by 10)
The magenta graph is useful for diagnosing source files with bad time stamps. (The frame rate lock function usually repairs that.)

The links are on the first page.

[pururin]

May I ask what is the difference between AVX, SSE2, SSE versions?

Does it effect performance in any parts or function?

:thanks:

[madshi]

JanWillem32,
are you interested in a subtitle solution that renders to a separate pin ? That's currently what I am working on. Or trying to at least. I already made a proof of concept filter
http://forum.doom9.org/showthread.php?p=1557391#post1557391

Currently trying to rewrite VSFilter to only pass through the video, then spit out subpics on pin number 2.
JFYI, we've created a new custom interface for subtitle renderers here:

http://code.google.com/p/xy-vsfilter/issues/detail?id=40
http://madshi.net/SubRenderIntf.h

This interface will be supported by future versions of madVR, LAV Video Decoder and xy-vsfilter.

[ryrynz]

May I ask what is the difference between AVX, SSE2, SSE versions?
Does it effect performance in any parts or function?


They're different instruction sets, SSE2 should be faster than SSE, AVX should be faster than SSE2. Whether that is the case or not I guess only JanWillem could answer.

[JanWillem32]

@pururin: AVX, SSE2 and SSE are some of the many processor extensions on top of the base x86 platform from 1978. Compiler settings determine what instructions the compiler may use. Attempting to use instructions not supported by the processor will generally crash the program.
There are only very few old x86 processors still in the wild that don't support SSE extensions. SSE2 support has been available since the Intel Pentium 4 and AMD Athlon 64 processors (SSE2 support is also a minimum requirement for the x64 instruction set). AVX is still very new and only supported on the most recent generation of CPUs: http://en.wikipedia.org/wiki/Advanced_Vector_Extensions .
Within the code, there are many specific segments for SSE and SSE2 paths. Some types are hard-coded (only one of the two paths will be in the instruction code of the executable), and some types are switched by detecting the processor instruction support bits (multiple code paths will be inside the instruction code of the executable).
An example is the main bitmap renderer in the subtitle renderer. It has a selectable SSE- and SSE2-level rendering path for SSE builds. For SSE2 builds and above, the SSE-level code path is discarded and the processor bits are not detected. Those always use the SSE2 path.
Another example is the copy function for the screenshot function that I've recently added. The old one was really slow. I decided to replace it by 4 switchable code paths for the copy function. Two are on the SSE4.1 level, the other two use SSE-level functions. (The data alignment issue further decides which of the two paths are selected next. All programmers should be familiar with that type of issue.)

@madshi: It's been a while. Eh... I totally forgot about that project. I've been busy with all sorts of things. I guess it would have been nice if I dropped in another message some time ago. I've written quite a few functions that could be used internally. I'll take a look at things later.
In the past, I've asked the MPC-HC development team if I could make the renderers into external DLL files, and put the custom pixel shaders into external TXT files. The ideas were rejected. I'm not even going to ask if I can make the subtitle renderer external this time. So in short: I can replace the internal subtitle renderer, but adding support for something external isn't very useful for me. Still, I don't mind working on the project(s). As I mentioned earlier, I've already written some useful code (mostly SSE stuff), and I don't mind sharing.

[nevcairiel]

They're different instruction sets, SSE2 should be faster than SSE, AVX should be faster than SSE2. Whether that is the case or not I guess only JanWillem could answer.

Its doubtful that there is any measurable difference.
If there is, it should be optimized with ASM code instead of being at the mercy of the compiler, anyway.

You should never need different versions for different CPUs (on the same platform, anyway), its just asking for trouble and a nightmare for users.

[burfadel]

EVR-CP doesn't work in r4101. Works fine in r4087. I tried resetting the render settings etc and no go. In D3D mode, its just a black screen. In basic mode it doesn't even come up with the picture window, it just plays the sound. The other renderers work fine, including normal EVR. This is with the SSE2 version. I also tried the SSE version, and the picture windows did show with the first frame or two, but then crashed.

[ryrynz]

The ideas were rejected.

JanWillem, can you not just create your own fork? It's not the MPC team is really moving things along much. I think having a true dedicated developer with you being unrestricted in your development and working alongside Madshi, Nevcairiel, X_xy_y2 and Haruhiko to create a suite that "just works" sounds like a good idea to me.

[madshi]

@madshi: It's been a while. Eh... I totally forgot about that project. I've been busy with all sorts of things. I guess it would have been nice if I dropped in another message some time ago. I've written quite a few functions that could be used internally. I'll take a look at things later.
In the past, I've asked the MPC-HC development team if I could make the renderers into external DLL files, and put the custom pixel shaders into external TXT files. The ideas were rejected. I'm not even going to ask if I can make the subtitle renderer external this time. So in short: I can replace the internal subtitle renderer, but adding support for something external isn't very useful for me. Still, I don't mind working on the project(s). As I mentioned earlier, I've already written some useful code (mostly SSE stuff), and I don't mind sharing.
Sounds good to me, thanks. I think the interface we created might become more attractive once xy-filter and madVR are both supporting it. Also nevcairiel was considering creating a libass based subtitle renderer supporting that interface, too, and even making use of it in LAV Video Decoder. After all that (which may take a while to turn into reality) maybe you'll get more interest in adding support for the interface to your renderers, too... :D

I'm really sad about the MPC-HC decision makers being so stuck on having an integrated one-file-only stance, plus insisting on having all those source & decoder filters integrated, too. I'd love a small lightweight MPC-HC without all that integrated stuff, with all useful bits and pieces being optional external ax/dll files. But well, what can we do...

[aufkrawall]

I'm really sad about the MPC-HC decision makers being so stuck on having an integrated one-file-only stance, plus insisting on having all those source & decoder filters integrated, too.

Totally agreed.
I don't know why they spend so much time on the decoders and splitters when more and more people instead use LAV.

[CruNcher]

@Jan
is it possible to implement :) http://www.iryoku.com/smaa/

though i guess http://mrhaandi.blogspot.com/p/injectsmaa.html could already work externally

[ryrynz]

I'd love a small lightweight MPC-HC without all that integrated stuff, with all useful bits and pieces being optional external ax/dll files. But well, what can we do...

This is exactly what I'd like to see also, something that's made to go hand in hand with the other up and coming projects. MPC just has no direction right now, Jan, I'd like to see you take it on and work collaboratively with Madshi and co.

[clsid]

@madshi: It's been a while. Eh... I totally forgot about that project. I've been busy with all sorts of things. I guess it would have been nice if I dropped in another message some time ago. I've written quite a few functions that could be used internally. I'll take a look at things later.
In the past, I've asked the MPC-HC development team if I could make the renderers into external DLL files, and put the custom pixel shaders into external TXT files. The ideas were rejected. I'm not even going to ask if I can make the subtitle renderer external this time. So in short: I can replace the internal subtitle renderer, but adding support for something external isn't very useful for me. Still, I don't mind working on the project(s). As I mentioned earlier, I've already written some useful code (mostly SSE stuff), and I don't mind sharing.You should ask again. Maybe a voting should take place. You will have my vote for making things external.

[burfadel]

EVR-CP doesn't work in r4101. Works fine in r4087. I tried resetting the render settings etc and no go. In D3D mode, its just a black screen. In basic mode it doesn't even come up with the picture window, it just plays the sound. The other renderers work fine, including normal EVR. This is with the SSE2 version. I also tried the SSE version, and the picture windows did show with the first frame or two, but then crashed.

Anyone had the same issue with this, or is it just me?!

[JanWillem32]

Its doubtful that there is any measurable difference.
If there is, it should be optimized with ASM code instead of being at the mercy of the compiler, anyway.

You should never need different versions for different CPUs (on the same platform, anyway), its just asking for trouble and a nightmare for users.The AVX versions are just experimental. I tried building them mostly to see what assembly the compiler generates with this setting. I don't think AVX builds will become common for a while.
SSE2 requirement is a bigger issue. I write for an SSE2 level by default, and having to add the SSE level alternative code is annoying. I had to add dozens of switches for this issue in the code. All of those had to be tested. (I at least read the assembly generated by the compiler for the three build types.) Also, for now, I can't even think of adding in an SSE2 level library, such as this one: http://msdn.microsoft.com/en-us/library/windows/desktop/ee418732%28v=vs.85%29.aspx . (There's a good reason why the non-SSE2 version isn't recommended, and there's no real alternative.)
I would very much prefer making SSE2 support a hardware requirement for the program. Note that the DirectX 11 renderer I've tried to import is, eh... a lot more demanding than only requiring SSE2, too. (It was designed for modern systems, for pretty specific tasks. I'll try to lower the CPU+GPU minimum requirements when I have enough time to work on it.)
In terms of statistics: http://imageshack.us/photo/my-images/513/statsda.png/ . SSE versions are usually downloaded by the users that download all versions early on, but afterwards, the SSE2 and base x64 versions dominate. (Too bad that I didn't save the older statistics. I've had several numbers in the hundreds of previous versions.)

About the issue internal/external filters, I can't deal with that stuff while I'm trying to present a candidate for code integration into the trunk build. After integration, I'll happily discuss anything related.

@burfadel: This is so far the only issue reported (aside from the issue with EVR Sync). This is somewhat surprising, as there were no major code changes in the main renderer in between these two builds. (I mostly modified the subtitle renderer host.) Could it be related to this fix afterwards: http://sourceforge.net/apps/trac/mpc-hc/changeset/4102 ? (Depends on the files you tested, of course.) Otherwise, does resetting all settings by the button in the miscellaneous tab help?

@CruNcher: I can indeed integrate such a module. Note that its function is to anti-alias along vertices. The renderer uses vertices to draw the video rectangle. In short, I can use it to anti-alias the borders of the video rectangle. Currently, anti-aliasing is explicitly disabled for the renderer, as it would be a waste for 2D rendering. (Though it would probably look nicer when I want to animate video-textured, falling teapots with this renderer again.)

Sorry that I don't really have time for typing more text right now, sunday and monday are always very busy days for me.

[tetsuo55]

I'm not against external files either.
It would be nice to still be able to compile as a single file, but imho its just blocking progress.

that said people need to provide actual patches.

[burfadel]

Still no go with r4101 with it reset etc. Its only an issue with EVR-CP and Direct3D fullscreen enabled. I tried a build of the standard r4104 found here http://henry.fushizen.eu/builds/MPC-HC/#!/view=details/lang=en/sort=na and no issues, so I don't know... but if nobody else is having the issue with the r4101 mod with EVR-CP and Direct3D, it must be just me :)

[GREG1292]

Avx 4075 works good for me and many thanks. I would like to see more use of the GPU as it looks like eye candy to me
with EVR CP and 32 float and SVP 3.06. Had to upgrade my video card from a AMD 6570 93% gpu and stuttering to a
GTX-480 and 33% GPU and smooth playback.

[burfadel]

Have you tried r4101?

The HD6570 is a low end budget graphics card, and the GTX 480 a high end card (it was the top model in that range), but that you really shouldn't be wanting high GPU use just for video playback :)

[golagoda]

Still no go with r4101 with it reset etc. Its only an issue with EVR-CP and Direct3D fullscreen enabled. I tried a build of the standard r4104 found here http://henry.fushizen.eu/builds/MPC-HC/#!/view=details/lang=en/sort=na and no issues, so I don't know... but if nobody else is having the issue with the r4101 mod with EVR-CP and Direct3D, it must be just me :)
Anyone had the same issue with this, or is it just me?!

I'm having a (possibly) related issue which is extremely hard to explain.

I personally don't use D3DFS like you've said you do but I do use EVR-CP and with the latest build sometimes the video will just freeze/not show but the sound will continue playing, the video starts out playing perfectly fine but then it occurs randomly. Seeking to random spots in a video sometimes seems to fix it but it's weird.

For the record this is with the x64 version.

[burfadel]

I'm using the x86 version, but yes its a similar thing :) the sound plays but no video. What I said earlier in the first post about the issue: 'I also tried the SSE version, and the picture windows did show with the first frame or two, but then crashed. ', which does suggest that the issue may show differently with different builds (as in SSE, SSE2, x64, AVX for those that can try it etc).

Going by that, I dare say your issue and mine are resultant of the same cause.

[Hera]

So, got the normal 64-bit latest binary from you,

Launched some MKV, realized that DTV-DVD codec was incompatible
Also unchecked disable Desktop Composition
Blocked DTV-DVD codec and told MPC:HC to open the file again

Got the following error,
Error creating EVR Custom Renderer
Access is Denied.
CreateDeviceEx failed initialization
DX9AllocatorPresenter failed
Access is denied.

This made the file play without video

Sry, don't have time to help much atm (or volition for that matter)

Also the speeding up / audio cutting out problem is still there.

[pururin]

@ryrynz, nevcairiel and especially JanWillem32
Thanks a lot for the explanation :)
So far I've heard about those extensions but I don't really know how it works. I guess I can see the big picture now(at least a bit).

nev has a point though, which I wonder the same a little, about the measurable difference(s).
Can I benchmark it in someway? Like testing the subtitle rendering performance in heavy karaoke subtitle clips between those versions?

Btw I heard that internal subtitle renderer has some disadvantages to the external one like xy-vsfilter, especially about typesetting.
Here's a sample clip that shows how ISR resize incorrectly: http://www.mediafire.com/?301dtzr51lflvj2

[ryrynz]

It would not be worthwhile benchmarking them the difference is likely to be so small between SSE2 and AVX versions as to be unnoticeable as Nevcairiel stated, only use the SSE version if you must.

[GREG1292]

Have you tried r4101?

The HD6570 is a low end budget graphics card, and the GTX 480 a high end card (it was the top model in that range), but that you really shouldn't be wanting high GPU use just for video playback :)
Have tried r4101 and went back to AVX 4075 but like in games why not take advantage of all the
shaders and so fourth? With the better card madVr is at 43% gpu and a better picture. Though with a low end card EVR CP
looked better as I could not run madVr. So something is going on with more access to the GPU?

[Hera]

Anyone get 1x1 video size on W8?
All codecs / splitters.

1.6.1.4075 works but the newer one DOES NOT.

[CruNcher]

@ Jan
Do you have a idea why this simple chain http://img62.imageshack.us/img62/4116/failsmpchc.png doesn't work with MPC-HC ?

[kostik]

Hey,
Something strange happens with your builds on my laptop.
First time I opened a movie I had black screen only sound. Tried lav filters, ffdshow, MPC codecs and various settings in renderer settings.
Then I installed windows 8 , tried one of your builds and everything worked well except the MPC message to install new directx redist.
Played some movies and they worked flawlessly and smooth accept the strange ringing (I assume it happened because I didn't install directx update).
After installing directx update (June 2010) I had that black screen again and only sound. madVR played good though.
I searched for the DLLs that were installed by Directx and removed them. Then updated directx to March or February 2010 and everything worked but was very slow on my crazy strong laptop. Tried other drivers and still its not smooth with Pixel Shader 6 .
I just wanted to know why and if someone had the same problem with Directx ?

currently I am going back to Windows 7 and try to play again without Directx update and afterwards with .
My laptop specs:
I7 2920XM
Quadro 4000M
16GB 1600MHz
2XSSD drives
Should be good enough.
Thanks

[Hera]

W8 - D3DFS
Clicks don't go to the video.
I was clicking on taskbar shortcuts (eclipse, word, IE10, etc..) instead of interacting with the running video.

[G_M_C]

W8 - D3DFS
Clicks don't go to the video.
I was clicking on taskbar shortcuts (eclipse, word, IE10, etc..) instead of interacting with the running video.

Is 'normal' MPC-HT W8 compatible, or madVR for instance, or is it just the tester builds ?

[Hera]

Is 'normal' MPC-HT W8 compatible, or madVR for instance, or is it just the tester builds ?

see thread title

[JanWillem32]

I've just uploaded a new revision. Sorry for my absence lately. I'll try to write responses, a changelog and maybe some more later this afternoon.

[kostik]

JanWillem32
Thanks for the new version.
I wanted to ask you what is the best combination of shaders I can use to get the best quality video (I watch 1080p X264 movies).
Thanks.

[burfadel]

I've just uploaded a new revision. Sorry for my absence lately. I'll try to write responses, a changelog and maybe some more later this afternoon.

Thanks, this version works again! (r4101 didn't). I have found it very important to have the alternative scheduler turned on, as its much more stable.

[CruNcher]

@ Jan
im not sure what happened and im not sure if its a MPC-HC change yet or a tester change but i was testing some Realtime Manipulation stuff in MPC-HC (latency) and with 4075 and the integrated Mpeg-2 Decoder everything was fine when using ffdshow in between but since 4101 tester this got corrupted i get the video flipped and latency is horrible before i got like 70 ms now 180 ms :( when using PP, though im not sure where the change was that causes this could be also the Internal Mpeg-2 Decoder before i got YV12 output from the Mpeg-2 Decoder now its RGB32 and flipped when reaching ffdshow for further processing, the same with tester dfr4148 :(

with the external filter version 4146 as well as the internal in MPC-HC tester 4075 i get YV12->NV12 and the low latency with the internal filter in MPC-HC tester 4101,4148 no matter what selected i get a RGB32->NV12 very high latency and a flipped output


PS: It seems to be a bug in current MPC-HC tester builds something gets wrong @ the colorspace negotiation with the internal Mpeg-2 Decoder (EVR basic) so it falsely sets RGB32 instead of YV12

[burfadel]

Thanks, this version works again! (r4101 didn't). I have found it very important to have the alternative scheduler turned on, as its much more stable.

Actually when the video file loads and initiates, sometimes mpc-hc r4148 freezes. Once terminated in task manager, you can restart it again and it may work...! this is for both initial load and changing between files. It only happens occasionally though.

Any ideas of if/when the stable new features will be added to the main mpc-hc branch?

[RGold]

4148 looks promising. Ran some H.264 MKV's and saw no tearing, smooth playback.

[JanWillem32]

The previous build failed a bit on a few points, so I quickly repaired some parts. I'm going to have dinner in a few minutes, but I promise I'll post later today.

[CruNcher]

Current Mpc-HC tester 4150 behavior (EVR basic,Intel Scaling) = http://img171.imageshack.us/img171/5488/mpchctesterevrbasic.png
Current MPC-HC trunk 4148 and old tester 4075 behavior (EVR basic,Intel Scaling) = http://img40.imageshack.us/img40/8521/mpchc4148andtester4075.png

[JanWillem32]

Thanks, as usual. Too bad it took most of my free time for this evening to fix it...

[dukey]

@ Jan
im not sure what happened and im not sure if its a MPC-HC change yet or a tester change but i was testing some Realtime Manipulation stuff in MPC-HC (latency) and with 4075 and the integrated Mpeg-2 Decoder everything was fine when using ffdshow in between but since 4101 tester this got corrupted i get the video flipped and latency is horrible before i got like 70 ms now 180 ms :( when using PP, though im not sure where the change was that causes this could be also the Internal Mpeg-2 Decoder before i got YV12 output from the Mpeg-2 Decoder now its RGB32 and flipped when reaching ffdshow for further processing, the same with tester dfr4148 :(

with the external filter version 4146 as well as the internal in MPC-HC tester 4075 i get YV12->NV12 and the low latency with the internal filter in MPC-HC tester 4101,4148 no matter what selected i get a RGB32->NV12 very high latency and a flipped output


PS: It seems to be a bug in current MPC-HC tester builds something gets wrong @ the colorspace negotiation with the internal Mpeg-2 Decoder (EVR basic) so it falsely sets RGB32 instead of YV12

sounds like a dynamic format change fail
The renderer sounds like its asking for a negative height, which means the picture is upside down. Check there, that's probably the issue.

[CruNcher]

Thanks, as usual. Too bad it took most of my free time for this evening to fix it...

Yup fixed and sorry ;) :)

sounds like a dynamic format change fail
The renderer sounds like its asking for a negative height, which means the picture is upside down. Check there, that's probably the issue.

Thx dukey but Jan fixed it

[JanWillem32]

@ Jan
Do you have a idea why this simple chain http://img62.imageshack.us/img62/4116/failsmpchc.png doesn't work with MPC-HC ?The EVR mixer is picky. It won't just accept any input. The format header sent during connection negotiation must be completely filled in (VMR-9 does accept incomplete headers). Also, the input formats it will accept are limited. Check the video processor section of DXVA checker to see which formats EVR will accept, and with what kind of deinterlacer.

@ryrynz, nevcairiel and especially JanWillem32
Thanks a lot for the explanation :)
So far I've heard about those extensions but I don't really know how it works. I guess I can see the big picture now(at least a bit).

nev has a point though, which I wonder the same a little, about the measurable difference(s).
Can I benchmark it in someway? Like testing the subtitle rendering performance in heavy karaoke subtitle clips between those versions?I haven't been able to fully analyze the core drawing techniques of the subtitle renderer yet. I don't have to guess what I'll find in there though...
I'm mostly annoyed by having to write perfectly nice SSE2 type code first, and then add in a non-SSE2 context version next. SSE2 processors have been common for a decade now. Older systems can use legacy builds. I don't mind writing different x86 and x64 code paths in some spots (even if it involves writing entire assembly functions), but providing more legacy support than that is really unwelcome. Checking the assembly for x64 and SSE2 x86 involves only a minor task. The non-SSE2 level assembly is very different, so I need more time to check it separately. I also can't import SSE2 code without writing a non-SSE2 equivalent. I really don't have time to do that.
In terms of performance, the smaller bits and pieces that are switched won't be much of a problem in terms of performance. Not being able to import functionality is a different matter (same thing with wasting my time on legacy support). The largest performance gap is for the color management section, but that's mostly what the compiler itself optimized. My own input in that is smaller. (My part still initializes more than 384 MB of memory to prepare a large LUT, so not optimizing that and parts after that would be silly.)

Btw I heard that internal subtitle renderer has some disadvantages to the external one like xy-vsfilter, especially about typesetting.
Here's a sample clip that shows how ISR resize incorrectly: http://www.mediafire.com/?301dtzr51lflvj2I've fixed that, along with some other minor flaws in the subtitle renderer. Like the last time, it wasn't really hard to fix at all. The code for the subtitle renderer just 'feels' like it's in a very early stage of development every time I work with it. It's full of rookie programmer flaws, doesn't have properly sorted classes, bad object aliasing, band object naming and lacks even sensible optimizations everywhere. That's all very odd, considering it's size. To compare, the main video renderer was in a bad shape because of rendering method flaws mostly. It didn't have such badly written classes and general coding.

Any ideas of if/when the stable new features will be added to the main mpc-hc branch?I've been working on getting stability for all components I changed. Naturally, VMR-9 r. and EVR CP are the main priority, the subtitle renderer changes are pretty stable already (though there's a lot left to optimize). The most recent stability change is that VSfilter will work again with the code I've changed. It was an absolute menace to fix. The next logical thing to fix would be EVR Sync. Do we have any specialist available for writing renderer code? Hmm, I think I know the answer to that.
The merges to the trunk will be negotiated with the MPC-HC staff. I'm well aware that my changes are high-risk, may require immediate maintenance on various components (probably mostly by me) and when bug reports come in on Trac, I'll have to make time to address them.
That last issue is a problem, as I'm sometimes not available for maybe even two weeks. We could use an administrator. Also, someone to (re-)write parts of the guide on MPC-HC would be welcome. Currently, the Russian guide is more complete than the English one. I've written several parts already (mostly for the Russian guide), but it requires assembling and editing. For general tasks, refer to the OP of "Media Player Classic Home Cinema (MPC-HC) - DXVA!" thread. (I could even use a newbie programmer to simply check typecasting and such.)

sounds like a dynamic format change fail
The renderer sounds like its asking for a negative height, which means the picture is upside down. Check there, that's probably the issue.It was the copy function constructor for the video frames that broke.
An annoying thing that it has to exist anyway. After doing the frame copy, the renderer just copies the same stuff to video memory again. It would be better to connect the raw decoder output to the mixer, but the vanilla mixers in EVR and VMR-9 probably won't like that.

Most notable changes in functionality for the current build (ignoring my failed sets for now) would be the new timer for the alternative scheduler, optimizations for renderer functions (mostly optimizing strings) and the fixes for the /frx and /fry ASS/SSA subtitle tags on resized video.

I'm currently investigating what causes the desynchronization bug that can occur when seeking. I've seen what happens in a debug tracing session, but I don't have a fix ready yet.
I'll take a look at the issues with W8 later on, maybe it needs some special window handle settings, like Vista.

[Hera]

Latest version still completely bugs out when minimized / hidden.
Does work on W8 though.

[clsid]

I'm mostly annoyed by having to write perfectly nice SSE2 type code first, and then add in a non-SSE2 context version next. SSE2 processors have been common for a decade now. Older systems can use legacy builds. I don't mind writing different x86 and x64 code paths in some spots (even if it involves writing entire assembly functions), but providing more legacy support than that is really unwelcome. Checking the assembly for x64 and SSE2 x86 involves only a minor task. The non-SSE2 level assembly is very different, so I need more time to check it separately. I also can't import SSE2 code without writing a non-SSE2 equivalent. I really don't have time to do that.
You don't need different code paths. Just use function pointers. Have a look at dsputil.c in the FFmpeg code of MPC.

[JanWillem32]

@Hera: I'll try to fix it. It's just that when minimized, the function that should report the window size simply outputs 0×0, instead of the restored state.
Good news that W8 seems to work.

@clsid: I'm already using a few function pointers, where appropriate. Though that does still mean that I have to write the different functions to point to. Some items do need to be switched in the compiler context, mostly because of some x86-x64 architectural differences. I also explicitly exclude non-SSE2 code paths if SSE2 paths are available for SSE2 builds.

A somewhat new feature this time, I added live D3D FS switching (again). It required a lot of code changes to maintain compatibility with MadVR, not crash, not fail on some subtitle and OSD interfaces, and most of all, maintain a properly working window that can process keyboard and mouse input. I've added code to support multi-monitor setups when switching (I've even inserted semantics to detect some rare cases). As usual, everything needs to be tested.

[burfadel]

Just a question... whats with the title 'mpc-hc tester dfr4076i'? don't youe mean 4162i?

Thanks for builds btw! oh, earlier I mentioned about your MPC-HC not starting the video's properly, it seemed to be related to me using ffdshow decoder instead (as I use some of the filters), and having 'queue output samples' enabled. Not sure why it worked with the normal MPC-HC and not with yours though, but I do realise its a at times, 'sketchy' feature.

[Hera]

@Hera: I'll try to fix it. It's just that when minimized, the function that should report the window size simply outputs 0×0, instead of the restored state.
Good news that W8 seems to work.


0x0 happens when the player is in the background as well?
I got fast forwarding (that ignores pause button) and crackling/odd/but not fast forwarded sound when just snapping another window next to MPC.

W8 may need more testing.

[fagoatse]

0x0 happens when the player is in the background as well?
I got fast forwarding (that ignores pause button) and crackling/odd/but not fast forwarded sound when just snapping another window next to MPC.

W8 may need more testing.

Hmm, in my case the pause button behaves in exactly the same way. In other words, it doesn't seem to work at all. It's similar to fast forwarding(sort of rendering every X frame) and playing garbled sound in slow tempo. However, this happens in win7 x64 here. I'm using rev4151 SSE2 x86 + lav filters, haali and madflac in EVR-CP renderer. Tested h264 files in both software(10bit) and hardware(8bit, dxva2 native) mode.
Specs:
AMD E-350 1.6 GHz dualcore APU equipped with HD6310 GPU.
3GB ram
Win 7 x64, latest directx and GPU drivers.

I've just switched from the latest PotPlayer beta release because it's internal subtitle renderer cannot keep up and causes frame drops while playing hi10p files with .ass subs(especially more complex, such as karaoke) in software mode.
ISR in potplayer adds 20-30% CPU overhead while rendering even simple subs and that's unacceptable in my case. So I decided to give your mpchc's fork a try, and while I haven't tested everything throughly yet, I'm very satisfied. All these optimizations have really paid off, it's particularly visible on such low-end CPUs as mine. Most frame drops I had in potplayer are now alleviated.

I'll provide more feedback and bug reports later.

EDIT: I've forgotten to bring up another issue:
When the CPU hits 100% usage mark the video stalls, although sound is still playing and timeline moves forward. I guess pausing/resuming playback would fix it but since the pause doesnt work at all I have to stop the playback and skip that part. In potplayer it'd just drop frames massively and continue playing in slow-mo. I'm using the same filters and settings I use there so it appears to be a mpchc issue.
Now that I think of it, do filters/splitters/whatever need to be reconfigured/re-registered or something when switching players?

EDIT2: I can record it and upload @ youtube if you cannot reproduce it or I'm just failing at describing the issue.

EDIT3: My list of external filters:
Haali Media Splitter
madFLAC Source
LAV Splitter Source
madFLAC Decoder
LAV Audio Decoder
LAV Video Decoder
in this order, all set to prefer.


Hopefully im being helpful.

[JanWillem32]

JanWillem32
Thanks for the new version.
I wanted to ask you what is the best combination of shaders I can use to get the best quality video (I watch 1080p X264 movies).
Thanks.Sorry for replying this late. Your post got buried in the thread. The first set of filters that are easy to configure are in the video section of the configuration panel for your video card (note: mostly EVR-only). Next are the quality options for the video renderer. If you can spare some GPU power when rendering with 16-bit or 32-bit surfaces, you can probably try some of the "sharpen complex, deband and ... denoise" type shaders (of either the RGB or the Y'CbCr type). Some prefer the more basic sharpening types, though.
Most of the other functions have been integrated in the renderer already (except for the 'joke' shaders). Maybe I should integrate these shaders some time...

@burfadel: I probably messed up the title using the auto-form feature.
The functions backing "queue output samples" in the renderer have not been changed by me. I'll see if I can edit a few things where necessary. Thanks for finding this bug. It's not an item I usually test.

@Hera: I can't replicate the issue, but I do know that the renderer can drop a lot of frames when overlapped. For example: the standard right click menu causes the frame rate to drop to about 19 fps in even my case.

@fagoatse: Nice to see in your first post to this forum in here. I can't replicate the issue, but I never hit 100% CPU usage. That could be the reason. What scheduler are you using? (checklist: http://forum.doom9.org/showthread.php?p=1558955#post1558955)
For using external filters, disable the internal ones first. These are preferred when enabled. The filters that are in use can be seen in the "Play", "Filters" menu during playback.

Verified issues when switching D3D FS in 10-bit display mode: again the bugs with black screen after leaving fullscreen, and rainbow colors sometimes in fullscreen mode. I'll try a few things to solve these two issues.

[fagoatse]

Sorry for replying this late. Your post got buried in the thread. The first set of filters that are easy to configure are in the video section of the configuration panel for your video card (note: mostly EVR-only). Next are the quality options for the video renderer. If you can spare some GPU power when rendering with 16-bit or 32-bit surfaces, you can probably try some of the "sharpen complex, deband and ... denoise" type shaders (of either the RGB or the Y'CbCr type). Some prefer the more basic sharpening types, though.
Most of the other functions have been integrated in the renderer already (except for the 'joke' shaders). Maybe I should integrate these shaders some time...

@burfadel: I probably messed up the title using the auto-form feature.
The functions backing "queue output samples" in the renderer have not been changed by me. I'll see if I can edit a few things where necessary. Thanks for finding this bug. It's not an item I usually test.

@Hera: I can't replicate the issue, but I do know that the renderer can drop a lot of frames when overlapped. For example: the standard right click menu causes the frame rate to drop to about 19 fps in even my case.

@fagoatse: Nice to see in your first post to this forum in here. I can't replicate the issue, but I never hit 100% CPU usage. That could be the reason. What scheduler are you using? (checklist: http://forum.doom9.org/showthread.php?p=1558955#post1558955)
For using external filters, disable the internal ones first. These are preferred when enabled. The filters that are in use can be seen in the "Play", "Filters" menu during playback.

Verified issues when switching D3D FS in 10-bit display mode: again the bugs with black screen after leaving fullscreen, and rainbow colors sometimes in fullscreen mode. I'll try a few things to solve these two issues.


Yes, I've disabled all internal filters, double checked my external ones and everything seems to be fine. MPC-HC's settings are at their defaults values(I increased sub pictures to buffer from 4 to 5 though). The pause bug seems to be happen randomly whereas the 100% usage one happens all the time. I'm uploading vids now. Will be ready in a few mins(I apologize for poor quality but iphone's are terrible and so is lighting in my room)

EDIT:
VIDEO1(100% usage issue): http://www.youtube.com/watch?v=tqfLh6ZcRbE + supplementary vid http://www.youtube.com/watch?v=ZUxRpvfqvn4
VIDEO2(Pause bug as described earlier, @Hera, can you confirm that the same happens to you?) http://www.youtube.com/watch?v=y8HqbjoRGgQ
VIDEO3(A bit different bug, mpchc says that the vid is being played but nothing happens, kinda the opposite to the one above where it says Paused but its being "played" + some strange fast forwarding issues when pausing/resuming) http://www.youtube.com/watch?v=OTCZa9ApnYg (sorry for doing it needlessly long, im jumping on the timeline a lot in order to invoke bugs)

[kostik]

JanWillem32
When I use Sharpen deband PS I get some warnings and these shaders stress my GPU too much . With regular EVR-CP I don't have any errors when compilling the shader and it sresses my GPU less. Also Y'CbCr pixel shaders dont work for me I get strange colors .
Is there anything that can be done?

D3DXCompileShader succeeded
C:\Users\KostaR\Desktop\memory(147,13): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them
C:\Users\KostaR\Desktop\memory(148,13): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them

Thanks.

[Hera]

I think fagoatse is describing my problem.
Oh and this version black screens sometimes when opening / seeking.

[JanWillem32]

@fagoatse: I'll take a look at your videos, try to debug and ask another programmer some questions about scheduling later. Thanks a lot for your effort.

@kostik: The warnings are pretty mild. Which shader is it? Maybe I can mask the warnings. The trunk build never outputs warnings for successfully compiled shaders. I changed that behavior.
The "sharpen complex, deband and ... denoise" type shaders range from pretty light (r=1) to heavy (r=6) types. The default enabled filters of the trunk build and mine are different for when the 10- to 32-bit surfaces options are enabled. The difference in load compared to the baseline, caused by adding an extra pixel shader, should be about the same for both builds.

For the Y'CbCr mode pixel shaders with 16- or 32-bit working surfaces, use "Disable RGB Gamma Linearization" and replace it with a pre-resizer chain of:
-RGB to Y'CbCr for SD&HD video input for floating point surfaces
additionally, these two for chroma up-sampling on ATi video cards:
-2. special 4÷2÷0 to 4÷2÷2 intermediate ... chroma up-sampling
-3. special 4÷2÷2 ... chroma up-sampling
-..., sharpen complex, deband, ... denoise and color controls for SD&HD video input

For when using the 10-bit video surfaces option instead of either floating point surfaces options, switch "RGB to Y'CbCr for SD&HD video input for floating point surfaces" for the integer type, and set "#define IntegerSurfaces 0" to 1 inside "..., sharpen complex, deband, ... denoise and color controls for SD&HD video input".

[Hera]

You can always just look through the comments and ask yourself what you changed at that time.

Jan 21 # 762
"Is it me or does it now continue playing audio when video cannot catch up?"

Jan 27 # 779
"Then the green line just vanished (division by 0 type vanished) and the video started playing at about 2x speed."

Feb 9 #804
"Audio cuts out and video start playing ~2x
The only way to stop the video from playing is to CTRL-C
Got that through seeking"


Now,
- Seeking is almost completely broken - stops video or black-screens video (Audio will continue at normal speed)..
- Video will fast forward if MPC is not up front (Audio will continue at normal speed).

EDIT: I will post some screenshots...

EDIT, Stuck On Seek but Sound Playing (STR - Seek):
http://dl.dropbox.com/u/20408032/stuck%20on%20seek.png

Paused but still playing (sound goes away when pause button is pressed),
http://dl.dropbox.com/u/20408032/paused%20(but%20still%20playing)%20-%20no%20sound.png

Sound OK, Video doing stupid (too fast, skipping, ???):
http://dl.dropbox.com/u/20408032/fast%20forwarding%20-%20sound%20playing%20ok.png

[CruNcher]

@ Jan

I think i found some strange bug :)

https://forum.doom9.org/showpost.php?p=1566483&postcount=19119

so if anyone might got this black screen issue before just try to block ffdshow it might fix it

[JanWillem32]

@Hera: I tried to add in some extra checks on the internal timers this time. I don't know if it will help, but it's worth a shot. I haven't gotten around to edit the window size detection parts yet.

@CruNcher: I haven't found anything on this and the "queue output samples" bug yet in my latest quick debug session.

[RGold]

Thanks for new release. What the difference between i and none i versions? the current 4170 and has no i latter at the and.

Is the seek freeze fixed in 4170?

[JanWillem32]

I've renamed the three files to 4170i. The 'i' types are intermediate builds for which I didn't do a regular debug check for. It takes a lot of time to go through the usual set of scenarios.
I haven't been able to replicate the issues reported, so I can only try changing a few things and hope that people report that it's fixed.

[Hera]

From a minute of testing,
I managed to get video stuck from seeking.

[RGold]

While seeking forward the video freezes and the audio keeps going.

[gilic]

Hello JanWillem32 I'd like to report that at least for me the playback issue when mpc-hc is in the background is fixed with your latest version. Big thanks :]

There seems to be a bug since maybe 4 or 5 versions back relating to subtitles. I noticed with different anime i have that they each crashes repeatedly at the same position (different positions between files). Checking the subtitle with aegisub revealed this happens with negative position values
see here (http://imgur.com/GFm9e)
After deleting these lines and everything play fine.

[CruNcher]

@Hera: I tried to add in some extra checks on the internal timers this time. I don't know if it will help, but it's worth a shot. I haven't gotten around to edit the window size detection parts yet.

@CruNcher: I haven't found anything on this and the "queue output samples" bug yet in my latest quick debug session.

x64: http://www.mediafire.com/download.php?2jbjjsqojnh1t57
x86 SSE2: http://www.mediafire.com/download.php?ep4fajmutpe9w3v
x86 SSE: http://www.mediafire.com/download.php?v269cobbaxkm32q

I guess i solved this mysterious black screen :) https://forum.doom9.org/showpost.php?p=1566633&postcount=14905

[JanWillem32]

@Hera & RGold: I'll just try again...

@gilic: Glad that one thing seems to be fixed.
I've played the sample you indicated, and couldn't get it to crash at all. I'll upload a debug build. If you would like to try it, with some luck it can point at a specific item in the code that's bugged.

@CruNcher: Very well, thanks for linking back.

[fagoatse]

@Hera & RGold: I'll just try again...

@gilic: Glad that one thing seems to be fixed.
I've played the sample you indicated, and couldn't get it to crash at all. I'll upload a debug build. If you would like to try it, with some luck it can point at a specific item in the code that's bugged.
mpc-hc SSE2 debug tester dfr4171: http://www.mediafire.com/download.php?p6f68ujgc63jxfj

@CruNcher: Very well, thanks for linking back.

will this debug build pick up my settings or i'll have to re-do everything? Will give it a try tommorow. Thanks.

[gilic]

How can i get useful crash information for you with the debug build? It's still crashing and I didn't notice anything different. Content of a windows .wer file.

Version=1
EventType=APPCRASH
EventTime=129770239115655945
ReportType=2
Consent=1
ReportIdentifier=8a8db7a9-754b-11e1-b2af-4061862e2998
IntegratorReportIdentifier=8a8db7a8-754b-11e1-b2af-4061862e2998
WOW64=1
Response.type=4
Sig[0].Name=Anwendungsname
Sig[0].Value=mpc-hc.exe
Sig[1].Name=Anwendungsversion
Sig[1].Value=1.6.1.4171
Sig[2].Name=Anwendungszeitstempel
Sig[2].Value=4f6d0c87
Sig[3].Name=Fehlermodulname
Sig[3].Value=mpc-hc.exe
Sig[4].Name=Fehlermodulversion
Sig[4].Value=1.6.1.4171
Sig[5].Name=Fehlermodulzeitstempel
Sig[5].Value=4f6d0c87
Sig[6].Name=Ausnahmecode
Sig[6].Value=c0000005
Sig[7].Name=Ausnahmeoffset
Sig[7].Value=01837e9e
DynamicSig[1].Name=Betriebsystemversion
DynamicSig[1].Value=6.1.7601.2.1.0.256.1
DynamicSig[2].Name=Gebietsschema-ID
DynamicSig[2].Value=1031
DynamicSig[22].Name=Zusatzinformation 1
DynamicSig[22].Value=0a9e
DynamicSig[23].Name=Zusatzinformation 2
DynamicSig[23].Value=0a9e372d3b4ad19135b953a78882e789
DynamicSig[24].Name=Zusatzinformation 3
DynamicSig[24].Value=0a9e
DynamicSig[25].Name=Zusatzinformation 4
DynamicSig[25].Value=0a9e372d3b4ad19135b953a78882e789
UI[2]=C:\Multimedia\MPC HC debug\mpc-hc.exe
UI[3]=Media Player Classic - Home Cinema funktioniert nicht mehr
UI[4]=Windows kann online nach einer Lösung für das Problem suchen.
UI[5]=Online nach einer Lösung suchen und das Programm schließen
UI[6]=Später online nach einer Lösung suchen und das Programm schließen
UI[7]=Programm schließen
LoadedModule[0]=C:\Multimedia\MPC HC debug\mpc-hc.exe
LoadedModule[1]=C:\Windows\SysWOW64\ntdll.dll
LoadedModule[2]=C:\Windows\syswow64\kernel32.dll
LoadedModule[3]=C:\Windows\syswow64\KERNELBASE.dll
LoadedModule[4]=C:\Windows\system32\UxTheme.dll
LoadedModule[5]=C:\Windows\syswow64\msvcrt.dll
LoadedModule[6]=C:\Windows\syswow64\USER32.dll
LoadedModule[7]=C:\Windows\syswow64\GDI32.dll
LoadedModule[8]=C:\Windows\syswow64\LPK.dll
LoadedModule[9]=C:\Windows\syswow64\USP10.dll
LoadedModule[10]=C:\Windows\syswow64\ADVAPI32.dll
LoadedModule[11]=C:\Windows\SysWOW64\sechost.dll
LoadedModule[12]=C:\Windows\syswow64\RPCRT4.dll
LoadedModule[13]=C:\Windows\syswow64\SspiCli.dll
LoadedModule[14]=C:\Windows\syswow64\CRYPTBASE.dll
LoadedModule[15]=C:\Windows\system32\DSOUND.dll
LoadedModule[16]=C:\Windows\syswow64\ole32.dll
LoadedModule[17]=C:\Windows\system32\WINMM.dll
LoadedModule[18]=C:\Windows\system32\POWRPROF.dll
LoadedModule[19]=C:\Windows\syswow64\SETUPAPI.dll
LoadedModule[20]=C:\Windows\syswow64\CFGMGR32.dll
LoadedModule[21]=C:\Windows\syswow64\OLEAUT32.dll
LoadedModule[22]=C:\Windows\syswow64\DEVOBJ.dll
LoadedModule[23]=C:\Windows\system32\VERSION.dll
LoadedModule[24]=C:\Windows\syswow64\COMDLG32.dll
LoadedModule[25]=C:\Windows\syswow64\SHLWAPI.dll
LoadedModule[26]=C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\COMCTL32.dll
LoadedModule[27]=C:\Windows\syswow64\SHELL32.dll
LoadedModule[28]=C:\Windows\system32\WINSPOOL.DRV
LoadedModule[29]=C:\Windows\system32\oledlg.dll
LoadedModule[30]=C:\Windows\syswow64\WS2_32.dll
LoadedModule[31]=C:\Windows\syswow64\NSI.dll
LoadedModule[32]=C:\Windows\system32\OLEACC.dll
LoadedModule[33]=C:\Windows\syswow64\WININET.dll
LoadedModule[34]=C:\Windows\syswow64\Normaliz.dll
LoadedModule[35]=C:\Windows\syswow64\iertutil.dll
LoadedModule[36]=C:\Windows\syswow64\urlmon.dll
LoadedModule[37]=C:\Windows\system32\AVIFIL32.dll
LoadedModule[38]=C:\Windows\system32\MSACM32.dll
LoadedModule[39]=C:\Windows\system32\MSVFW32.dll
LoadedModule[40]=C:\Windows\system32\IMM32.DLL
LoadedModule[41]=C:\Windows\syswow64\MSCTF.dll
LoadedModule[42]=C:\Windows\system32\dwmapi.dll
LoadedModule[43]=C:\Windows\syswow64\PSAPI.DLL
LoadedModule[44]=C:\Windows\syswow64\CLBCatQ.DLL
LoadedModule[45]=C:\Windows\SysWOW64\devenum.dll
LoadedModule[46]=C:\Windows\system32\ntmarta.dll
LoadedModule[47]=C:\Windows\syswow64\WLDAP32.dll
LoadedModule[48]=C:\Windows\syswow64\WINTRUST.dll
LoadedModule[49]=C:\Windows\syswow64\CRYPT32.dll
LoadedModule[50]=C:\Windows\syswow64\MSASN1.dll
LoadedModule[51]=C:\Windows\system32\msdmo.dll
LoadedModule[52]=C:\Windows\system32\imaadp32.acm
LoadedModule[53]=C:\Windows\system32\msg711.acm
LoadedModule[54]=C:\Windows\system32\msgsm32.acm
LoadedModule[55]=C:\Windows\system32\msadp32.acm
LoadedModule[56]=C:\Windows\SysWOW64\l3codeca.acm
LoadedModule[57]=C:\Windows\system32\CRYPTSP.dll
LoadedModule[58]=C:\Windows\system32\rsaenh.dll
LoadedModule[59]=C:\Windows\system32\RpcRtRemote.dll
LoadedModule[60]=C:\Windows\system32\WINSTA.dll
LoadedModule[61]=C:\Windows\SysWOW64\quartz.dll
LoadedModule[62]=C:\Windows\system32\MMDevAPI.DLL
LoadedModule[63]=C:\Windows\system32\PROPSYS.dll
LoadedModule[64]=C:\Windows\system32\wdmaud.drv
LoadedModule[65]=C:\Windows\system32\ksuser.dll
LoadedModule[66]=C:\Windows\system32\AVRT.dll
LoadedModule[67]=C:\Windows\system32\AUDIOSES.DLL
LoadedModule[68]=C:\Windows\system32\msacm32.drv
LoadedModule[69]=C:\Windows\system32\midimap.dll
LoadedModule[70]=C:\Multimedia\LAV Filters\x86\LAVSplitter.ax
LoadedModule[71]=C:\Multimedia\LAV Filters\x86\avformat-lav-54.dll
LoadedModule[72]=C:\Multimedia\LAV Filters\x86\avcodec-lav-54.dll
LoadedModule[73]=C:\Multimedia\LAV Filters\x86\avutil-lav-51.dll
LoadedModule[74]=C:\Multimedia\LAV Filters\x86\libbluray.dll
LoadedModule[75]=C:\Windows\system32\d3d9.dll
LoadedModule[76]=C:\Windows\system32\d3d8thk.dll
LoadedModule[77]=C:\Windows\system32\atiu9pag.dll
LoadedModule[78]=C:\Windows\system32\dxva2.dll
LoadedModule[79]=C:\Windows\system32\evr.dll
LoadedModule[80]=C:\Windows\system32\MFPlat.DLL
LoadedModule[81]=C:\Windows\system32\ncrypt.dll
LoadedModule[82]=C:\Windows\system32\bcrypt.dll
LoadedModule[83]=C:\Windows\SysWOW64\bcryptprimitives.dll
LoadedModule[84]=C:\Windows\system32\DShowRdpFilter.dll
LoadedModule[85]=C:\Windows\system32\WTSAPI32.dll
LoadedModule[86]=C:\Windows\system32\slc.dll
LoadedModule[87]=C:\Multimedia\LAV Filters\x86\LAVVideo.ax
LoadedModule[88]=C:\Multimedia\LAV Filters\x86\swscale-lav-2.dll
LoadedModule[89]=C:\Multimedia\LAV Filters\x86\avfilter-lav-2.dll
LoadedModule[90]=C:\Windows\system32\d3dx9_43.dll
LoadedModule[91]=C:\Windows\system32\D3DCompiler_43.dll
LoadedModule[92]=C:\Windows\system32\aticfx32.dll
LoadedModule[93]=C:\Windows\system32\atiumdag.dll
LoadedModule[94]=C:\Windows\system32\atiumdva.dll
LoadedModule[95]=C:\Multimedia\LAV Filters\x86\LAVAudio.ax
FriendlyEventName=Nicht mehr funktionsfähig
ConsentKey=APPCRASH
AppName=Media Player Classic - Home Cinema
AppPath=C:\Multimedia\MPC HC debug\mpc-hc.exe


@fagoatse you can copy your .ini file (options->player->other for setting)

[Hera]

@Hera & RGold: I'll just try again...


The latest version is better, it is just 'not there' yet.
I am not able to get it to speed up it seems.

[gilic]

I want to update my bug report. If "subpictures to buffer" is 0 mpc-hc crashes, if it's 1 or 2 the moving text on top for that specific file isn't shown/flickering and if its 3 or up everything seems fine "allow animation" is disabled. I've always struggled to find the right combination of settings for subtitles. Everything I tried so far had issues with different files.

[JanWillem32]

For basic debugging: http://forum.doom9.org/showthread.php?p=1553934#post1553934 . Note that the DirectX debug runtimes are only used to debug the client-side of the graphics interfaces, these don't debug the program itself. To complete the text I linked; I use a very different debugger. The debugger in the compiler suite can hook the program being run and re-trace every instruction in the debug build. That's a bit 'deeper' than just executing it. This type of debugging is near-ideal, but I doubt many people here will have the compiler suite installed.

@fagoatse: Debug builds are the same as release builds, but really slow and full of extra data for error checking and tracing. There's no difference in the handling of player settings.

@Hera: That's at least something, although I don't know what part of the code fixes it (else I would add a comment to it to point out the issue). I'll try the debugger on my other machine tomorrow, maybe I'll find out some more.

@gilic: What I mostly was looking for, is a debug trace text segment, just before crashing.
If "subpictures to buffer" is 0 a different queue handler is used. I'll test that one tomorrow. I never knew it could be sensitive to this kind of thing. (The queue system doesn't create subtitles, it only stores finished subtitles for the video renderer to use.) Don't worry too much about setting the "subpictures to buffer" higher. I've re-written some of the memory functions for it. It's pretty fine now to use 12 (and maybe some more) for even the more extreme karaoke (as long as your video card has enough memory). The reference "Touhou - Bad Apple!!" sample seems to render better with more buffers than what the trunk build prefers.

[gilic]

Are there any negative side effects with a high subpicture buffer? Also would ollydebug be of any use for your purpose?

[Hera]

Sound sometimes stutters when MPC crashes (new IMO) / get stuck when seeking, offset also seems to be in 2x,xxx mark.
Seeking has less problems with smaller resolution files.

Uhm, using Haali Splitter, same behavior as seeking can be reproduced when Haali switches from one file (that is like Opening Song) to the main file (the episode itself). This doesn't happen with LAV Splitter because it still doesn't support having Opening / Ending in separate files.

Also switching to D3D FS seemed to attempt to switch instantly... and I had to kill it because it failed.

[JanWillem32]

@gilic: More subpictures means more video memory consumed. I've made the texture management render-size dependent. For a subtitle with data in every corner of the screen the memory consumption will be quite large.
Example, "Touhou - Bad Apple!!" sample on a 1080p screen: Aspect ratio correction will limit the base render area to 1440×1080. Because this sample renders in pretty much every corner, no further area reduction is used. (I should edit this to handle each piece of text separately, right now it can only blend one composed picture per video frame.) The pixel format is A8R8G8B8 (the color and alpha quality is actually even less than that). That means that there's about 1440×1080×32 bits (5.9326171875 megabyte) in each subtitle texture. That's quite a lot, but doesn't have to be a big problem if there's plenty of video memory left to buffer a bit. Normal subtitles use a smaller drawing area, and will therefore consume less memory.
If you know how to work with OllyDbg, go ahead and try. I haven't worked with it yet.

@Hera: Okay, I'll try to debug tomorrow with the Haali splitter active. I've also seen some problems with switching D3D mode on and off.

[Hera]

I think it just got stuck the same way as the seeking / haali-file-switching problem. I think... I am not a good tester :P

Also, on Windows 8, I do not get the seek bar in D3D FS mode when moving the mouse cursor down the screen. I can make it appear, by... well... selecting the video by clicking on the video a few times (clicking causes pauses)?
Mouse clicks seem to go through the video before getting the seek bar responding to the mouse - who to blame - bleep if I know

EDIT:
Another behavior I noticed - video stops playing, not during anything weird, just during normal playback.

EDIT:
Another behavior I noticed, after un-pausing, video plays, audio is no where to be found. Pausing and Un-pausing causes audio / video de-sync...

EDIT:
When going transitioning to OP/ED - sometimes the video goes back a 1/4 to 1/8 of a second. Then fast forwards to where it is supposed to be, and at that point gets stuck.

[JanWillem32]

I've re-written some memory management parts (which were hard to reconfigure, as the program shouldn't invoke the admin prompt of UAC). The biggest benefit was for memory allocation speed for the color management. (Which overall didn't really become much faster, but any optimization for it is a given.)
Various little bugs were squashed, but no real new features were added.
The biggest fix was for the internal MPEG2 decoder and its (badly implemented) subtitle part. I've added semi-native NV12 support for both (next to its native I420/IYUV fomat). MPEG2 videos and DVD menus should no longer be given as converted YUY2 or RGB32 to the mixer. This should solve all issues with wrong chroma coloring on DVD menus and the issue of reverting to the MS DVD video decoder. I don't have data on how my changes will affect the DXVA implementation for MPEG2, but it should be fine. I've also discarded the option for allowing planar formats. The NV12 output can handle interlaced video, but won't perform software deinterlacing (I'm really not going to add that feature). Enable "Set interlaced flag in output media type" for proper handling of interlaced NV12 output by the video renderer. If NV12 deinterlacing fails with any of the decent video renderers, please report it. For the x64 version, SSE2 math was updated (I couldn't get it into the x86 SSE2 build yet). If the x64 version specifically has visual artifact, memory or other problems, please report it. I've changed quite a lot of code to make this decoder work properly (for me, at least), some of the edited code may be less than perfect.
As a side-effect from fixing the bugs with switching D3D fullscreen mode, the worker thread feature for the filter graph has been disabled for the internal renderers. I'll analyze if it's worth it to fix (this feature was already disabled for when a video is started in D3D mode in the first place).
I've not found any bugs with the renderer's timing system yet. I'll have to do further analysis on that.

[CruNcher]

@Jan
This might be of help @ optimizing things http://software.intel.com/en-us/articles/vcsource-tools-intel-gpa/ i find it really usefull :) some functions are comparable to Nvidias tools though it's more Generic and seems to be usable on non Intel GFX Hardware too :) it can show a lot of DirectX information as well including the Shader Execution status and stall situations :)
You can analyze Realtime via a HUD (though they keep sensors restricted into Groups to keep the overhead down) or via recording and analyzing after (lower overhead)
It doesn't seem to work though with testers Fullscreen http://img835.imageshack.us/img835/5888/cpugpupoweranalyzedxva.png
but analyzing it with the Intel GPA System Analyzer in the background works also Realtime and that is really fast with minimal overhead updating @ record speed http://img69.imageshack.us/img69/5806/intelgpasystemanalyzer.png and more configurable also in sensor count on screen @ once see this Video Demo http://software.intel.com/en-us/videos/channel/visual-computing/intel-gpa-2012-demo-at-gdc-2012/1532811356001 :)
Btw don't be surprised by the Playback Speed in the Screenshots (no MPC-HC Performance issue) the Video is VFR and the FPS is the actual 3D Engine Render speed @ recording time ;)

Really nice http://img252.imageshack.us/img252/879/latencynice.png you can see in realtime here what caused the Power to go up in the Frame it is the Rendering of the Meteor drive by and it's Shader Effects :)

[fagoatse]

Thanks Jan, will give it a try today or tomorrow.
I can confirm that 4170i has improved things a bit, although the issues described by Hera are still present.

btw, I think you should stop offering SSE builds, every CPU out there supports SSE2 and above so it's no big deal. Legacy CPUs that can only handle SSE are too slow for playback these days anyway.


@Hera
Which of your setups are you testing on?
We're having similar issues, so I presume it's the ATI one with LAV filters and haali in x86 using SSE2 builds and EVR-CP+DXVA. Perhaps there's some connection between these components. Although it doesnt happen in potplayer so i guess it's either the renderer or pausing/seeking/playing functionality being broken to some extent?

[Hera]

@Hera
Which of your setups are you testing on?
We're having similar issues, so I presume it's the ATI one with LAV filters and haali in x86 using SSE2 builds and EVR-CP+DXVA. Perhaps there's some connection between these components. Although it doesnt happen in potplayer so i guess it's either the renderer or pausing/seeking/playing functionality being broken to some extent?
Post #909 (the one before this one) was tested on my NVIDIA ION netbook (AMD 4250M rig also exhibits same symptoms, but I don't video much). I finished Clannad ~After Story~ (1080p BDRip w. Animated Subtitles) in two days on it. I get similar problems on both computers. On both computers I am using LAV for Video (Native DXVA enabled) and Audio. I have tried LAV splitter, but it doesn't support external OP/ED and thus I reverted back to Haali Splitter. I have not tried whether or not Haali Renderer works (w. LAV CUDA ofc).

I have yet to try 4210i - but judging from the description, I am not optimistic.

I have not tried the post-breakage MPC tester builds on the Athlon XP rig yet.

[fagoatse]

Post #909 (the one before this one) was tested on my NVIDIA ION netbook (AMD 4250M rig also exhibits same symptoms, but I don't video much). I finished Clannad ~After Story~ (1080p BDRip w. Animated Subtitles) in two days on it. I get similar problems on both computers. On both computers I am using LAV for Video (Native DXVA enabled) and Audio. I have tried LAV splitter, but it doesn't support external OP/ED and thus I reverted back to Haali Splitter. I have not tried whether or not Haali Renderer works (w. LAV CUDA ofc).

I have yet to try 4210i - but judging from the description, I am not optimistic.

I have not tried the post-breakage MPC tester builds on the Athlon XP rig yet.

I tried 4210i and while performance is really impressive I can confirm two bugs you'd reported earlier, namely:

Another behavior I noticed - video stops playing, not during anything weird, just during normal playback.

Another behavior I noticed, after un-pausing, video plays, audio is no where to be found. Pausing and Un-pausing causes audio / video de-sync...

And of course the issue I mentioned about a week ago regarding video stall caused by heavy karaoke subs with animations(tested using Doki's release of toradora BD in 10bit). I'm pretty sure it's ISR's fault. In potplayer or regular mpchc when the CPU hits the wall and the video decoder cannot keep up it starts dropping frames, but in this case it just freezes, though audio is still being decoded. Well, basically any video decoding and rendering is dead and cpu sits at ~0%(just audio being processed but thats not very taxing). It seems to only happen on low-end CPUs(1.6 GHz dual core in this case). I've also noticed that after updating to 4120i and LAV filters to 0.50 the hang happens a few seconds later than it always used to(it's 100% reproducible at exactly the same moment).

[Hera]

And of course the issue I mentioned about a week ago regarding video stall caused by heavy karaoke subs with animations(tested using Doki's release of toradora BD in 10bit). I'm pretty sure it's ISR's fault. In potplayer or regular mpchc when the CPU hits the wall and the video decoder cannot keep up it starts dropping frames, but in this case it just freezes, though audio is still being decoded. Well, basically any video decoding and rendering is dead and cpu sits at ~0%(just audio being processed but thats not very taxing). It seems to only happen on low-end CPUs(1.6 GHz dual core in this case). I've also noticed that after updating to 4120i and LAV filters to 0.50 the hang happens a few seconds later than it always used to(it's 100% reproducible at exactly the same moment).
I noticed video just getting stuck not during heavy subtitles - just normal speech subtitles (DXVA).

But, yet seeking getting stuck IS related to CPU power IMO: smaller video sizes do get stuck LESS when seeking. Some thread probably times out because it is not getting enough CPU time.

[fagoatse]

I noticed video just getting stuck not during heavy subtitles - just normal speech subtitles (DXVA).

But, yet seeking getting stuck IS related to CPU power IMO: smaller video sizes do get stuck LESS when seeking. Some thread probably times out because it is not getting enough CPU time.

Yeah, although im not getting any hangs while playing 8bit stuff in dxva2 native. TBH HD6310 is okay with anything I throw at it, thanks to UVD3 I guess.
I've had quite a few random freezes in HW mode as well, but the hangs I've described above occur every time in SW mode when playing demanding 10bit content. It's probably as you're saying, not enough cpu time and inability to recover from it as it should - frame dropping. I can bear with occasional frame drops but not with being forced to restart playback.

[CruNcher]

I experience a reproducible crash it's not their with dfr4170i i'll look more into it later, it happens with specific files on EVR could be maybe the Resolution crash Problem regressed back in ?

[RGold]

Using latest build, player will freeze as follows:

1. Playback will end and and the player will exit full screen.
2. Drag and drop another video file into the player window.
3. Player will freeze with white window.

[JanWillem32]

@CruNcher: That's indeed a very nice HUD (and a few other tools), thanks for the links.
What exactly do you mean by "Resolution crash Problem"?

@fagoatse: Unfortunately, the trunk x86 build is set at an SSE level, so I can't drop testing and legacy support for those parts.

For the little discussion in between: it's indeed the subtitle renderer. When seeking, the subtitle renderer's queue is emptied. After that, the subtitle rendering thread starts to render new frames. In doing so, it blocks other parts of the player until the subtitle picture queue is full again. I've been re-writing the queue handler, with some success. It's just very hard to get it "just right" that it will work nicely for even low-power systems, while still being capable of rendering a subtitle frame for every video frame on faster systems. (I can post a build here, but I'm not 100% sure it's stable enough for general usage. It performs pretty well, though.)

@RGold: Is it with specific settings, or the defaults? I can't seem to replicate the issue. Do automatic transitions of the playlist work properly? Does the same thing happen in bordered windowed and fullscreen exclusive modes?

[Hera]

I also noticed the video get stuck after a resume from sleep.

[heavy voice]
JanWillem32 is credit to team!
[/heavy voice]

[RGold]

@RGold: Is it with specific settings, or the defaults? I can't seem to replicate the issue. Do automatic transitions of the playlist work properly? Does the same thing happen in bordered windowed and fullscreen exclusive modes?

1. For 24Hz video material, using autocahnge fullscreen monitor mode for 23.981 @ 1600X1200.
2. Default render settings with Aero is disabled.
3. It's only happening in bordered windowed mode.
4. Does not happen with the trunk version.

[burfadel]

Current build of this is 200 builds behind the mainstream MPC-HC...

Not that the current version doesn't work great, just keen for an update!

[JanWillem32]

I actually had a lot of unexpected problems due to the recent updates. Anyway, I've added the experimental resizer derived from EVR for EVR CP, It's mostly incompatible with any other destination surface format other than 8-bit RGB, I didn't have time to fully equip the renderer with functions that allow parameter changes for switching from and to this resizer, it often distorts if the window or video rectangle changes in size and may fail connecting if down-sizing of the video is requested. The resizer is set temporarily in the "nearest neighbor" slot. This feature will have to be improved and evaluated if it is to be integrated.
The subtitle renderer queue function has been edited, I'd like some reports about how much it has improved on low-end systems. I've also disabled the queue thread for when no subtitle source is active.
I might need to edit the frame time schedulers a bit again, the rules for timing when seeking and such are a bit strict right now.

[burfadel]

Thanks for the update! :) however it doesn't work...

On the same settings as the 4210 build, it simply displayed a couple of frames then froze, the sound kept playing but the whole player froze up (requiring task manager to kill it). I reset the renderer settings back to default (so no D3D etc), and this time this error came up:
compiling initial pass pixel shader 2 failed
(I don't have any pixel shaders selected nor have it enabled).

This is the same with the SSE, SSE2, and x64 builds.

[CruNcher]

I actually had a lot of unexpected problems due to the recent updates. Anyway, I've added the experimental resizer derived from EVR for EVR CP, It's mostly incompatible with any other destination surface format other than 8-bit RGB, I didn't have time to fully equip the renderer with functions that allow parameter changes for switching from and to this resizer, it often distorts if the window or video rectangle changes in size and may fail connecting if down-sizing of the video is requested. The resizer is set temporarily in the "nearest neighbor" slot. This feature will have to be improved and evaluated if it is to be integrated.
The subtitle renderer queue function has been edited, I'd like some reports about how much it has improved on low-end systems. I've also disabled the queue thread for when no subtitle source is active.
I might need to edit the frame time schedulers a bit again, the rules for timing when seeking and such are a bit strict right now.

x86 SSE: http://www.mediafire.com/download.php?2foy7ed1a25ob2f
x86 SSE2: http://www.mediafire.com/download.php?v210al0560a5tbd
x64: http://www.mediafire.com/download.php?mu9jo5jcn7ddw3o

Great news Jan, i tried it out it doesn't seem to work though input was 720x576 NV12 tried also RGB32,YUY2,YV12 no difference (DXVA,Software decoding) 8 Bit integer as Rendering.

Evr Custom nearest neighbor

http://desmond.imageshack.us/Himg827/scaled.php?server=827&filename=mpchctestevrcustomnativ.png&res=landing


Evr Custom Bicubic 1.00 PS 2

http://img16.imageshack.us/img16/9692/mpchctestevrcustombicub.png

Default EVR (Intel Hardware Scaling)

http://img856.imageshack.us/img856/9329/mpchctestdefaultevr.png

[burfadel]

hmmm, no matter what I try, I can't get the new one to play...

[Hera]

Seems to work (bilinear). But hey, seems to work based on 1 minute of testing.
If I have the time, I will add more detail.

[CruNcher]

burfadel i had mix ups in the past when trying different MPC-HC versions and Tester in terms of Pixelshaders it seems it can screw up the settings somehow (i guess registry conflicts) so be sure to check the shader tab is disabled and look if your shader list is correct also the Evr Custom Shader box likes to mix up with perlin smooth step in tester when used MPC-HC trunk before ;).

[Hera]

How much ram is normal for MPC to be using BTW?

[CruNcher]

after 1 execution it should be as low as possible which currently for tester and trunk is somewhere around 8 MB you can lower that disabling the GUI same as CPU usage though dunno where that CPU usage drain is coming from when the GUI is active.
Though everything after that can vary per system due to the way also directshow precaches stuff and holds it loaded and how much and why (auto connection triggering).

[Hera]

after 1 execution it should be as low as possible which currently for tester and trunk is somewhere around 8 MB you can lower that disabling the GUI same as CPU usage though dunno where that CPU usage drain is coming from when the GUI is active.
Though everything after that can vary per system due to the way also directshow precaches stuff and holds it loaded and how much and why (auto connection triggering).

I meant when playing video... :P

[CruNcher]

Yep as i said that can vary per system and configuration used filters ect

[Gelatinous]

I'm having issues with the latest build (SSE2 version) as well:

1) madVR does not load at all if it is selected as the video renderer. The only way to get it to load is to set it as preferred in the external filters AND change the renderer to a non-madVR option.

2) The internal subtitle renderer only shows up on EVR.

Previous build (r4210) works fine

Thanks for giving a new build though; I much prefer your subtitle renderer to VSfilter.

[burfadel]

burfadel i had mix ups in the past when trying different MPC-HC versions and Tester in terms of Pixelshaders it seems it can screw up the settings somehow (i guess registry conflicts) so be sure to check the shader tab is disabled and look if your shader list is correct also the Evr Custom Shader box likes to mix up with perlin smooth step in tester when used MPC-HC trunk before ;).

Yes, pixel shader tab disabeld and no shaders selected (I even tried enabling it in 4210 and selecting shaders and then trying 4406. I tried internal an external decoder filters, different video renderers etc. Nothing worked!

[CruNcher]

urgh did you update your Drivers Recently ?

[burfadel]

Not for a couple of weeks. Either way, 4210 works, 4406 doesn't... if it is a driver etc issue doesn't explain why one works and the other doesn't!

[CruNcher]

it seems to be a shader compile issue so it's pretty possible i guess the driver is responsible failing here with some of the shader based setups, does overlay mixer work also look in Renderer Settings if you have anything enabled that makes use of shader.

[HoP]

when a file playing and i drag&drop another file into the mpc ,i get this error (but not crash.i click 'OK' two times and file play)

http://upit.cc/i/9db2fbea.png

[burfadel]

I also tried build 4406, 4410 and 4420 from http://henry.fushizen.eu/builds/MPC-HC/

Every one worked as they should. Its only this MPC-HC 4406 that doesn't work, 4210 does.

[burfadel]

New version works perfectly :) no issues like with 4406.

Thanks! :)

Just a side note (and I noticed it is 4210 as well), how does the alternative scheduler work out its timing? If I change the HPET timer resolution to 0.5MS (instead of default 15.6MS), the sound and video seems to have sync issues. Obviously I could simply not do this, but it may mean others with different timer resolutions set (such as 1.0 MS or other resolutions) may have issues with the alternative scheduler. To change I use the program Timerresolution. I use it, like others, for improvements in gameplay (albeit small as they are).

[Hera]

Three things that should not happen,
1. Audio cuts out when video cannot keep up. A much better behavior is to let video stutter and audio play smoothly.
2. Audio starts before video as of last two builds (it syncs a fraction of a second later).
3. Seek bar in fullscreen non-exclusive mode resizes video. This is completely worthless and annoying.

[Nya_Su]

Hello,

I don't have OSD (like when changing volume) when the video renderer is madVR, is that normal ?

Thanks.

[JanWillem32]

@CruNcher: The EVR-inherited resizer will need some work before I'll standardize it. I've edited it a bit to handle window sizes better, but it's hard to get the positioning just right.

@Gelatinous: I've edited the code responsible for external filters this time. I didn't have the time to give it a full check, though.

@HoP: I'm very familiar with that one. When the renderer's initialization fails (usually because other components are still quitting), the graph builder will just try again. Note that it may revert silently to VMR-7 w. after a renderer failure.

@burfadel: I've made every DirectX 9Ex device request its frame time data from IDirect3DSwapChain9Ex::GetPresentStatistics. The organization for the statistics and coordinating frame time syncs is handled on the system side.
Coordination for the internal graph timers partially depends on whether HPET timers are available, but older multimedia timers are always used in some parts.
The HPET timer can't be altered. (Except in some systems where it's linked to the CPU clock frequency, and has problems with the power management.) The multimedia timers can be changed in resolution. To set them to the maximum allowed precision, we first call timeGetDevCaps() to see what values are allowed. It may very well be that the 0.5 ms setting is illegal on your system. The renderer thread will always set the highest precision allowed for the multimedia timers on initialization. This is a system global setting. The highest precision setting set by any program is always used, until the thread releases it.

@Hera: 1. Is it when the CPU or when the GPU hits 100% usage?
I've tried to simulate the issue by clocking my GPU very low, and I only got both audio and video cutting out when the graph desynchronization limit hits (it's half a second).
The schedulers can drop frames to prevent this. The original schedulers can drop at least 1 in 4 frames, the alternative scheduler can drop about 1 in 8 frames. Both can schedule frames to drop in advance, for example when playing back a 25 fps video on a 24 Hz screen. The constant frame interpolator scheduler can't really drop frames at all.
When the hardware can't keep up, even with the schedulers dropping frames, desynchronization is inevitable. Editing the frame dropping code for the schedulers isn't easy. Dropping multiple frames in quick succession distorts the global view on frame time statistics (as no statistics are generated on dropped frames). It's hard to correct that to a situation where the renderer can use its usual presenting scheme again after dropping frames.
2. I've noticed that, too. I wonder what's causing it. I didn't change the schedulers at all for the previous two builds.
3. I agree. It should be re-programmed to not resize the video window. I've tried to edit it earlier, but it didn't help.

@Nya_Su: I messed up the handlers for the external filters a bit last time. I think the OSD should be fine now.

Other changes:
-the alternative scheduler can now work in bordered windowed mode (the green jitter graph will still look different than in fullscreen, though)
-I've set the default queue size for the subtitle renderer to 6 (for those with more GPU memory, higher values are pretty okay as well)

[Nya_Su]

@Nya_Su: I messed up the handlers for the external filters a bit last time. I think the OSD should be fine now.


Indeed, now it works. Thanks a lot!

[Hera]

The sound cutting out was when the CPU was saturated (I use basic settings, so GPU should not have a lot to do). I will try this again, might have been a fluke. :) Sound must not cut out, video on the other hand can stutter. I don't know what Haali does differently, but it doesn't cut out audio (atl. in not horribly-bad cases). I think I managed to make it play a 1080p file with it just rendering 19 out of 24 frames a second. If you could manage to incorporate Haali Render's tricks, that would make it the ultimate thing in performance (You are very close!).

Also I installed and reset MPC on XP (SSE) rig, player exited (crashed) when telling it to open the next file (DVD). That is, after opening a file, opening another one seemed to cause a crash. (Common)

Possible due to CPU saturation (netbook), opened a video and it played without sound until seeking. (Once)

[Gelatinous]

@CruNcher: The EVR-inherited resizer will need some work before I'll standardize it. I've edited it a bit to handle window sizes better, but it's hard to get the positioning just right.

@Gelatinous: I've edited the code responsible for external filters this time. I didn't have the time to give it a full check, though.

@HoP: I'm very familiar with that one. When the renderer's initialization fails (usually because other components are still quitting), the graph builder will just try again. Note that it may revert silently to VMR-7 w. after a renderer failure.

@burfadel: I've made every DirectX 9Ex device request its frame time data from IDirect3DSwapChain9Ex::GetPresentStatistics. The organization for the statistics and coordinating frame time syncs is handled on the system side.
Coordination for the internal graph timers partially depends on whether HPET timers are available, but older multimedia timers are always used in some parts.
The HPET timer can't be altered. (Except in some systems where it's linked to the CPU clock frequency, and has problems with the power management.) The multimedia timers can be changed in resolution. To set them to the maximum allowed precision, we first call timeGetDevCaps() to see what values are allowed. It may very well be that the 0.5 ms setting is illegal on your system. The renderer thread will always set the highest precision allowed for the multimedia timers on initialization. This is a system global setting. The highest precision setting set by any program is always used, until the thread releases it.

@Hera: 1. Is it when the CPU or when the GPU hits 100% usage?
I've tried to simulate the issue by clocking my GPU very low, and I only got both audio and video cutting out when the graph desynchronization limit hits (it's half a second).
The schedulers can drop frames to prevent this. The original schedulers can drop at least 1 in 4 frames, the alternative scheduler can drop about 1 in 8 frames. Both can schedule frames to drop in advance, for example when playing back a 25 fps video on a 24 Hz screen. The constant frame interpolator scheduler can't really drop frames at all.
When the hardware can't keep up, even with the schedulers dropping frames, desynchronization is inevitable. Editing the frame dropping code for the schedulers isn't easy. Dropping multiple frames in quick succession distorts the global view on frame time statistics (as no statistics are generated on dropped frames). It's hard to correct that to a situation where the renderer can use its usual presenting scheme again after dropping frames.
2. I've noticed that, too. I wonder what's causing it. I didn't change the schedulers at all for the previous two builds.
3. I agree. It should be re-programmed to not resize the video window. I've tried to edit it earlier, but it didn't help.

@Nya_Su: I messed up the handlers for the external filters a bit last time. I think the OSD should be fine now.

Other changes:
-the alternative scheduler can now work in bordered windowed mode (the green jitter graph will still look different than in fullscreen, though)
-I've set the default queue size for the subtitle renderer to 6 (for those with more GPU memory, higher values are pretty okay as well)

x64: http://www.mediafire.com/download.php?ocqi4swgblga41n
x86 SSE2: http://www.mediafire.com/download.php?2wc9c682wu3wpyp
x86 SSE: http://www.mediafire.com/download.php?05j9yr8ao5xlvmo

This build and the last build work perfect for me, thanks. I was having a similar issue with the madVR OSD and its fixed now as well.

[Hera]

Testing the x86_64 build, I think you borked the fix you did about minimzation. Audio stops and video does funny things when player is in background again.

Also access is denied error when switching files DX9AllocatorPresenter

[JanWillem32]

The sound cutting out was when the CPU was saturated (I use basic settings, so GPU should not have a lot to do). I will try this again, might have been a fluke. :) Sound must not cut out, video on the other hand can stutter. I don't know what Haali does differently, but it doesn't cut out audio (atl. in not horribly-bad cases). I think I managed to make it play a 1080p file with it just rendering 19 out of 24 frames a second. If you could manage to incorporate Haali Render's tricks, that would make it the ultimate thing in performance (You are very close!).Okay, I'll try. One item has been updated, at least.Also I installed and reset MPC on XP (SSE) rig, player exited (crashed) when telling it to open the next file (DVD). That is, after opening a file, opening another one seemed to cause a crash. (Common)If that was with the standard DVD navigator, I'm not surprised. I've had many issues from both in- and outside the renderers. e.g.: http://sourceforge.net/apps/trac/mpc-hc/ticket/1724 . If it's with the regular playlist as well, let's take a look at debugging the problem.Possible due to CPU saturation (netbook), opened a video and it played without sound until seeking. (Once)I've had that quite a few times as well (debug builds more often). It happens with the reference builds as well. (The global timer has multi-threading issues, I believe.)

I've added a window handler for the FlipEx presenting mode (Win 7&8, windowed modes with Aero enabled). It should clear the stuck images after closing a video and allow easier re-initialization, such as with the drag and drop of a video on the player.
I'm having severe issues with the handling functions that mess with the initialization of the video renderer. As a precaution, the 'hot' initialization function is disabled for now. When starting playback, the video will desynchronize (and usually drop a lot of frames) because of this. In case of severe desynchronization after opening a file, rewind a few seconds. I'll see what I can do to address this nasty reoccurring issue.
I've made the alternative scheduler better at dropping frames. It's unlikely that I'll be able to improve it any more on the scheduling side. The other option would be the mixer side, but the mixer calls the graph and resets the global timer. This halts normal playback of audio and video to resynchronize in full, so I can't really work with that. An approach like with the Haali renderer (custom mixer and presenter) would be better at controlling an issue like this. I can't control a whole lot from the renderer side, dropping a frame of the external VMR-9 or EVR mixers, or of the external decoder is pretty difficult with the current renderers.

[Hera]

Crashing while switching files is not related to .VOB - any format makes the player silently exit on my XP system after switching files 1 to 3 times.

[Nya_Su]

@JanWillem32: This build gives me quite a few dropped frames -don't know why-, so I went back to the previous one (which doesn't have this problem).

[Hera]

From some basic tests, it doesn't feel like I am getting smooth video anymore. IMO, just stick to fixing bugs so you could get your work added to trunk. :)

Again XP, D3D Err Device Lost when trying to play video in D3D fullscreen, D3D9 allocator failed. Result is no subs in fullscreen,

[JanWillem32]

The "video without subs" situation is caused by the "feature" that when any video renderer fails, the player may silently revert to VMR-7. I have no idea who thought that was a good idea. Not honoring settings set by the end user (such as the video renderer option) is such a bad practice. I'd prefer showing the error in a messagebox and closing the graph instead.

-I fixed a crash condition of the subtitle renderer
-I did extensive legacy mode debugging (that really needed a lot of work)
-I optimized the device creation and reset sequences
-I optimized and corrected the window geometry code (used by all video renderers)
-I fixed the timing issues for (re-)initialization
-I've done a lot and now I'm really in need of my beauty sleep :D

[Hera]

Fullscreen non-D3D, showing the seekbar sometimes makes the video black out instead of getting squished.

[Gelatinous]

The build just posted seems to crash no matter what file i open with it; both SSE and SSE2 versions.

I should also note that in previous builds (4492 and 4462 tested) the subtitles seem to have an issue when switching screens; they will disappear entirely until the video is restarted when dragged or swapped (win+shift+left) to another screen. On Build 4462, this does not happen when "sub pictures to buffer" is set to 5.

[Nya_Su]

Same as Gelatinous, it crashes with any file... (SSE2).

[JanWillem32]

Does resetting settings help? Are the crashes with any renderer?
Let's try to debug the problem. (As usual, I can't replicate the crashes.)
I don't have much time right now, but I'll happily take a look at bug reports later. I can easily revert a few of the latest changes (if it's caused by something I changed, at least).
Quick debug description: http://forum.doom9.org/showthread.php?p=1553934#post1553934

[Gelatinous]

Resetting settings does allow it to play, but as soon as i switch to madVR (all other renderers seem fine) MPC crashes on launch.

Restoring my previous settings and switching to other renderers works as well.

[Hera]

Still crashes when switching files. Otherwise seems OK. Although I can't get Haali Renderer to work, it keeps using the fallback renderer if I enable Haali...

[Gelatinous]

Still crashes when switching files. Otherwise seems OK. Although I can't get Haali Renderer to work, it keeps using the fallback renderer if I enable Haali...

I'm having this issue too. I have traced it back to your 4406 build dated 16th april.

On Build 4406, selecting Haali reverts to the default renderer (as does madVR). You fixed the madVR side of the issue in build 4437, but when haali is selected (at least in my case) it switches the renderer to madVR as well. The filters menu will show it as Haali Video Renderer, but when clicked it brings up the madVR settings window. When madVR.ax is unregistered, haali reverts to the default video renderer.

I just tried the latest build from xhmikosr and haali seems to work fine there.

http://i.imgur.com/YjbgW.jpg <-filters menu
http://i.imgur.com/Icy1M.jpg <-When haali's option is clicked

[Hera]

Still crashes when switching files. Otherwise seems OK. Although I can't get Haali Renderer to work, it keeps using the fallback renderer if I enable Haali...

Although, on W7, there is no crashing due to switching files.

[JanWillem32]

I've tried to fix the sockets for the external renderers, I'll take a new look at the crashing issue when switching files the next time.

[Hera]

Well I still cannot get Haali Render to work, default filters and Haali Media Splitter. I am not sure what is wrong, sometimes it is the video codec not supporting video format Haali Renderer uses, but I cannot get Haali to work with internal video codec and LAV video codec. Ofc an alternative decision would be to abandon its support completely considering that no one is developing it anymore. I am not going to test MadVR considering it is a massive GPU and CPU hog.

On the other hand, thank you very much for removing that annoying resize. :)

EDIT: Whacha know ... it started playing all fast while in the background without audio again.

[RGold]

Well I still cannot get Haali Render to work,...[/I]

Why are you using Haali Render? It's out dated...

[Hera]

Why are you using Haali Render? It's out dated...

Because it allows me to play video files that EVR:CP break under due to complete CPU saturation?

[Mangix]

have you tried madVR with the resizers set to bilinear?

[Hera]

Same issues on 64-bit system,

- Haali does not work
- MPC does not properly handle being the background

[Gelatinous]

I'm still having the issue with Haali as well; madVR still shows up in its place.

[Nya_Su]

Well, this build seems to work. Some of my externals filters disappeared, but I can't be sure of the cause as I updated some of them in the same time - even if it's the first time I notice such a behavior.

Got one question: you say it's the "mpc-hc tester dfr4537i", but in the "about" form, it says 1.6.2.4536... is that normal ? (I took mpc-hc SSE2 tester dfr4537i.7z)

[JanWillem32]

@Nya_Su: I don't have a clue why the list of external filters might have changed. I haven't edited any code related to that part.
The version script sometimes fails a bit at setting the build number during compiling (mostly when I've just updated the working set of files). I've also had several builds that had build number 0.

Most important changes:
-I've tried to fix the Haali Renderer socket again.
-I've fixed one of the root causes of accelerated playback of video when the player is minimized when using one of the two original schedulers of EVR CP.
-I've fixed a few issues of the internal MPEG1/2 decoder (one of which I caused).

[Hera]

What about merging with main? You seem to have achieve good stability here.

[JanWillem32]

I still have to fix EVR Sync (a lot of work), check if I can make the EVR resizer work properly and check if I haven't broken VSfilter again. If the stability is proper on Windows XP and onward, we can start integrating parts.

[Hera]

Oh, I thought sync was going to be removed.

[Nya_Su]

It looks like this build (mpc-hc tester dfr4588i x86 SSE2) is working fine :-)

[tetsuo55]

Oh, I thought sync was going to be removed.Removed is probably the wrong word for it, merged into EVR-CP is a better way to describe it.

[Hera]

Anyone not getting subs with Haali renderer?

Also, sometimes the video starts paused.

[stranger_in_the_night]

Also, sometimes the video starts paused.
I've noticed this as well - if you have the "play next file in folder" option on, about half the time the player will skip through 3-4 files before playing.

[Nya_Su]

It looks like I may have found a bug in this build (dfr4588i x86 SSE2):

When you play a file, press CTRL+G to open the jump menu. Then if you press SHIFT+END, it doesn't select the entire time like it used to...

Can anyone confirm this is a bug, as it worked fine in the previous build (4537)?

EDIT:

Anyone not getting subs with Haali renderer?


I tried my test files with Haali renderer and I always had subs.

[burfadel]

I've noticed this as well - if you have the "play next file in folder" option on, about half the time the player will skip through 3-4 files before playing.

I have found this too!

[JanWillem32]

I've fixed a bug with the subtitle queue that causes problems with proper animation of styled text subtitles and flickering of bitmap-based subtitles. I'll make new builds when more testing has been done.

@Hera: The EVR Sync schedulers are planned for integration into EVR CP, but with the main rendering path in its current state, that's not something I can do.

@Stephen R. Savage: Good to know that the compatibility parts are working well on an older IGP. It's difficult to design a rendering path that doesn't use methods such hardware can't use, both for performance and compatibility reasons.
1. The alternative scheduler allows a 6-frame command and 3-frame backbuffer queue. It allows the present loop to not insert delays (what the older schedulers do), but schedule by setting a frame's present duration in advance. The DirectX API functions will put the present thread temporarily to sleep when the queue is full. A paragraph on scheduling I wrote earlier:
An example is 25 fps video on a 50 Hz screen. In this case, if the scheduling works out perfectly, each frame is presented for 2 screen refresh intervals, and the clock can be stable at 100%.
It becomes more difficult when a 25 fps video is displayed on a 60 Hz screen. In that case, the scheduler has to plan every frame to display 2.4 screen refresh intervals. That means it has to vary between displaying frames for 3 and 2 screen refresh intervals, for 40% and 60% of the time respectively. When a frame is displayed for 3 screen refresh intervals the clock will be under 100%, because the flame is displayed for too long. The inverse is of course valid for the frames that are displayed for 2 screen refresh intervals. The average of the clock speed over some time should be 100%.
A good scheduler adapts the present count cycle for matching video fps to display refresh rate perfectly, while keeping track of non-scheduled dropped frames and glitches.
The constant frame interpolator can also use the frame queue when used in combination with EVR CP. Its scheduler is similar to the alternative scheduler.
I can experiment with deeper command and backbuffer queues. It would allow more time to resist glitches, but a deeper queue means that it will take longer to close or reset the renderer and extra backbuffers will consume memory.
2. I merged VSync and Accurate VSync under Alternative VSync. It's only used under the GDI desktop. When D3D fullscreen exclusive mode or Desktop Composition is enabled, this function is automatically disabled.
I should probably rename Alternative Vsync to something to indicate it's only for the GDI desktop.
3. The quality options are enabled with the quality mode: enable 10-, 16- or 32-bit surfaces for that.

@Hera: I'll do a round of checking external parts and filters soon. It's been a while since I've done that (for dfr4151).

I also have the problem with video starting paused, playlists and menus not working properly. I've recently only edited the MPEG2 and video renderer parts, so it's probably not any of my code that causes it. I'll see how this resolves later on. Please compare found bugs to the trunk build and report the bugs to whom created them.
I'll fix some issues for the subtitle renderer and post a build once I've had enough time to test stuff.

[fagoatse]

Yo~!
I've been stuck with 4210i(?) build for a while and I'm willing to give a newer one a try. I've got quite a lot of 'samples' that will throughly test the ISR : P.
Also, if I recall correctly you were interested in seeing results of newer builds on low-end machines. So here am I again. Any ETA on the newer builds? Perhaps an "i" release or gearing towards a "stable" one?

[JanWillem32]

@fagoatse: I'll try to smooth out the issues of subtitle renderer queue soon and post a few builds. I'll happily await the results after that.

@Stephen R. Savage: I'll try:
Old
1. measure current time 1
2. render a frame
3. measure current time 2
4. put the rendering thread to sleep for one frame time (give or take a bit, depending on scheduling) -current time 2 +current time 1 to compensate for the time spent in the rendering loop
5. present the frame
6. goto 1

New
1. measure current time 1 (only for the stats screen, other parts ignore this value)
2. render a frame
3. present the frame to the queue, along with the scheduler's calculated amount of screen refreshes that the frame should be displayed for
4. read last presented frame time stamp 2 from the DirectX present queue (it's used to sychronize to the main clock, that also keeps track of audio)
5. goto 1
The alternative scheduler doesn't put the rendering thread to sleep, but leaves that to the DirectX functions, so it only sleeps when the queue is full. While there are frames in the queue, unscheduled frame drops and glitches don't happen until the frames in the queue are used up.

[JanWillem32]

It has been added only recently. On top of that, I still have to write a fallback mechanism to the basic scheduler in EVR CP, for when someone disables Desktop Composition in windowed modes.
I think it might also be worth it to add an option for the user to set the queue depth for the alternative scheduler and the constant frame interpolator. The current setting is pretty much the minimum, so that it doesn't consume much memory.

[madshi]

1. The alternative scheduler allows a 6-frame command and 3-frame backbuffer queue. It allows the present loop to not insert delays (what the older schedulers do), but schedule by setting a frame's present duration in advance. The DirectX API functions will put the present thread temporarily to sleep when the queue is full.
You probably already now this, but just to be safe, let me mention that in windowed mode, every Present() call blocks until both rendering is completed and the next VSync comes (unless you told D3D not to wait for VSync). Practically that means that it's pretty hard to get the backbuffer queue to fill in windowed mode. In fullscreen exclusive mode, Present() doesn't block, if there's a free backbuffer left, so you can already start rendering the next frame even before the next VSync comes. With Aero activated, things are different again, then even in windowed mode Present() may not block, eventually. I don't really know why Microsoft made Present() block in windowed mode (without Aero). I believe they could have implemented that in a better way. <sigh>

[JanWillem32]

From what I've seen, the desktop mode without Aero enabled needs artificial flushing of the command queue and an adjustable VSync timer, else the presented picture tears. The VSync function implemented by my predecessor added this functionality, I only simplified it (and broke its functionality a dozen times while working on the renderer).
Under systems before Vista in fullscreen exclusive mode, it's also pretty hard to schedule frames with the queue, as there's no command to mark frames to display for two or more screen refreshes. (Although it's fine for the constant frame interpolator, as it tries to fill every screen refresh with a separate frame.)
Under systems since Vista in fullscreen exclusive mode, I don't use Present(), but PresentEx(), which does allow marking frames to display for two or more screen refreshes (using the alternative scheduler).
The same thing goes for systems since Seven in windowed mode with Aero enabled, under the FlipEx present mode.
For Vista and Server 2008 with Aero enabled, I still have to implement similar functionality, using the DWM functions.

In a nutshell, it's hard to create and maintain schedulers for all systems and modes. Each generation adds new modes to the existing ones, without porting them back to older systems. Add the set of EVR CP, VMR-9 r., RealMedia handler, QuickTime handler and EVR Sync to manage with pretty much the same renderer, and the list of things to maintain gets rather big. On the system side, some the DirectX parts could have gotten a better implementation indeed.

[ForceX]

RealMedia handler, QuickTime handler
Why do we still need these, exactly? I thought there were DiretShow filters which can handle these formats. Are they for streaming?

[JanWillem32]

I actually don't know. I can't test them. Because I hardly changed the code in these two handlers, I just assume I didn't break them. If there are proper DirectShow decoders for these formats, it's better to use EVR CP instead. The two handlers can't use most of the renderer features. A proper DirectShow decoder will also allow streaming by the way.

[stranger_in_the_night]

so it's probably not any of my code that causes it.

I've tested against trunk build 4585 (x86) on Windows 7, and can't get it to fault with opening/playing files in the ways previously described.


A few other problems I've noticed with the recent build(s):

There seems to be a memory leak in GPU memory usage. If you open a file then close it, the GPU memory used should be 0. It is with EVR and madvr renderers for example, but with EVR custom it seems to be holding open 80-90% of the memory instead.

The program also seems to use a lot more private memory in the same conditions (open a file, then close it) compared to trunk.

With the alternate scheduler, there seems to be some sort of slight sync issue that doesn't show up on the statistics. If I turn the alternate scheduler on, then off, the playing file seems to skip a couple of frames to catch up.

The alternate scheduler also seems to have a problem with the Microsoft DTV-DVD video decoder and calculating the correct frame rate. For instance with interlaced content deinterlaced as 60p, the average reported frame rate hovers in a wide range around 30hz, and doesn't lock.

I've also seen it a couple of times where the frame rate is reported as 0hz; when it does the alternative scheduler doesn't work properly at all.

[Hera]

Here are some screens on your MPC build in action. Kinda random really.

1080p & 720p (No Subs) (https://skydrive.live.com/redir.aspx?cid=0361988083ce2fa3&resid=361988083CE2FA3!1389&parid=361988083CE2FA3!1398&authkey=!AHgXC3BZZtLiWnU)
1080p Memory Usage High? (https://skydrive.live.com/redir.aspx?cid=0361988083ce2fa3&resid=361988083CE2FA3!1390&parid=361988083CE2FA3!1398&authkey=!AHtI1Ok9hyhdnY8)
2x 1080p MP4 (hardsubbed) (https://skydrive.live.com/redir.aspx?cid=0361988083ce2fa3&resid=361988083CE2FA3!1391&parid=361988083CE2FA3!1398&authkey=!AJiOffhKZzI5M6Q)
Statistics Saturating the CPU? (https://skydrive.live.com/redir.aspx?cid=0361988083ce2fa3&resid=361988083CE2FA3!1392&parid=361988083CE2FA3!1398&authkey=!ANLIx62W29oq4ss)
1080p MKV - low CPU (https://skydrive.live.com/redir.aspx?cid=0361988083ce2fa3&resid=361988083CE2FA3!1397&parid=361988083CE2FA3!1398&authkey=!AIPEo468HqiG1Hk)
2x 1080p MKV - GPU Saturation? (https://skydrive.live.com/redir.aspx?cid=0361988083ce2fa3&resid=361988083CE2FA3!1394&parid=361988083CE2FA3!1398&authkey=!AJeUYS5dzOlakd8)
Video with Statistics Enabled (https://skydrive.live.com/redir.aspx?cid=0361988083ce2fa3&resid=361988083CE2FA3!1395&parid=361988083CE2FA3!1398&authkey=!ALIlhCXfUtsijwg)
Same video - Less Statistics (https://skydrive.live.com/redir.aspx?cid=0361988083ce2fa3&resid=361988083CE2FA3!1396&parid=361988083CE2FA3!1398&authkey=!AJSFp31QrrWSwCg)
random (https://skydrive.live.com/redir.aspx?cid=0361988083ce2fa3&resid=361988083CE2FA3!1393&parid=361988083CE2FA3!1398&authkey=!AGES26vf4yD1tyQ)

[JanWillem32]

I've been a bit busy with trying to get code I wrote into the trunk. I've also spent some time on getting all schedulers to stabilize more easily.
The issue with interlaced files with the schedulers is a complicated one. Neither EVR nor VMR-9 output clean frame/field display durations when deinterlacing. The effect is worse when pulldown is applied. The frame frame/field display durations are displayed as the magenta graph in the stats screen. Note that schedulers average these statistics over hundreds of frames before usage. The raw time stamps for even nice progressive videos in modern video containers are usually much too inaccurate to use directly.
The issue with starting in paused mode is still strange. I'll have to trace where it comes from. (None of the renderers will order pause, play or stop themselves.)
I've re-designed the memory management of the renderer's initialization and closing functions. Maybe it will help with lessening the memory strain and decommit resources more easily.
I've edited the subtitle renderer's functions to do faster committing and de-committing of whole subtitles in the queue.
The subtitle renderer's (re-)initialization is a little bit too slow, I'll try to fix that the next time.
I've taken some extra time for a full test round of externals, so I could do a non-intermediate set of builds this time. The links are on the first page.

[Nya_Su]

Made a few tests with the 4739 build, and it looks very nice!

I have the impression that it works better with madvr/reclock, that it's faster to start...

Thanks a lot!

EDIT : I mean it works better than before with madvr/reclock, not better than the other renderers (as I don't use them).

[G_M_C]

[...]
The issue with starting in paused mode is still strange. I'll have to trace where it comes from. (None of the renderers will order pause, play or stop themselves.)[...]


I've not followed this thread recently, but this sentence caught my eye. I've switched to using madVR exclusively, and haven't used your builds recently. But i too have noticed that when i switch over to full-screen on my secondary, the movie pauses. Is this the same you guys are talking about ?

I haven't thought about this, cause i dont find it annoying. And this pause-after full-screen has been there since i started using madVR as renderer/decoder. And because i thought nothing about this, i haven't found the urge to look for updates (to either MPC-HT of madVR), following the idea 'if it aint broke ...'

The reason i want to mention that i noticed this is that, because i haven't updated for a while, the pause-problem was already there in my build; 1.5.3.3704 (madVR 0.79). Maybe it helps tracking the origin of this 'back through time'.

If my problem is something else ... please ignore the above :p

[Hera]

Switching to D3D FS works when playing video, but keyboard listener didn't work - I ALT-F4-ed Opera instead of MPC:HC...
If starting playback in D3D FS, ALL OK

[JanWillem32]

@G_M_C: It seems to happen randomly. Both EVR CP and VMR-9 r. are affected, but I don't know why.

I've changed the functionality of the device selection in the "Output" tab and inside the renderer.
I've tried to fix the function that switches D3D exclusive mode. It should be better at getting focus now.

[HoP]

crash,if use AviSynth in ffdshow

[JanWillem32]

Did that work before? Does the most recent trunk build have the same issue?

[HoP]

Did that work before? Does the most recent trunk build have the same issue?

previous build was like this
i havent this problem with henry build(mpc-hc_x64_r4773) and xhmikosr build(MPC-HC.1.6.2.4764.x64)

http://henry.fushizen.eu/builds/MPC-HC/#!/view=details/lang=en/sort=na


http://xhmikosr.1f0.de/mpc-hc/

[JanWillem32]

Do you remember in which of my builds the AviSynth plugin started to fail?

[HoP]

^
no.sorry

[Virtual_ManPL]

Some bugs I find:

- Nearest neighbor (PS 2.0) resizer don't work,
changing to it from other resizer causes MPC-HC to crash;

- Enable Post-Resize Pixel Shaders don't work,
when it's enabled while playing file, video stops updating,
when it's enabled before playing file, video didn't start;

- pausing is lagged,
when it's used, it pauses but next it 'plays/adds' some frames ahead and then video finally stops;

- going to fullscreen gives some artifacts in between this operation
http://imgur.com/uwP1F



Using MPC-HC 1.6.2.4769 with LAV Filters on Win 7 (all 64bit)

[Hera]

Nearest Neighbor seems to cause video to not exist, player still plays file though.

Pause lagg is probably same in cause as seeking lagg.

Going to D3D FS from windowed during playback is super smooth here. No artifacts.

[dukey]

Why would there even be a nearest neighbour option ?

[Virtual_ManPL]

@ Hera -
When I enable 'D3D Fullscreen Mode' under Renderer Setting=>Presentation,
I don't get any menus,bars,controls,etc... so it's not for me,
because 25-50% of time I use MPC-HC in windowed mode, not in fullscreen

@ dukey -
I agree we should remove it,
but maybe it's left for testing proposes... :p