View Full Version : MPC-HC tester builds for internal renderer fixes
JanWillem32
6th May 2011, 01:21
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
6th May 2011, 02:57
How to use the new scaler? Just select any of the "Bicubic" resizer options under View-> Options-> Output?
burfadel
6th May 2011, 03:33
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
6th May 2011, 08:34
@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.
thanks to JanWillem32,i've downloaded the software you uploaded,once i'm available,i'll do the tests
JanWillem32,Would you like to tell me what Low Quality(64" points),Medium Quality(128" points) and High qulity(256" points) mean?
JanWillem32
6th May 2011, 10:47
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.
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
6th May 2011, 11:28
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.
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
6th May 2011, 14:45
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.
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
7th May 2011, 09:05
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
7th May 2011, 16:56
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.
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
7th May 2011, 21:52
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
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
8th May 2011, 00:11
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
8th May 2011, 03:58
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
9th May 2011, 20:31
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
11th May 2011, 18:52
The selectable dithering levels do wonders om less than stellar sources :)
Tell us more about the scalers, the Perlin one sounds intriguing.
CruNcher
11th May 2011, 23:55
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
12th May 2011, 09:35
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
12th May 2011, 19:23
@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
12th May 2011, 19:34
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
12th May 2011, 20:27
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
14th May 2011, 00:55
[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
14th May 2011, 08:02
: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
14th May 2011, 15:02
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
17th May 2011, 21:49
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
17th May 2011, 22:31
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
17th May 2011, 23:40
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
18th May 2011, 00:29
- 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
18th May 2011, 01:29
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
18th May 2011, 01:46
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
18th May 2011, 03:08
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
18th May 2011, 09:56
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
18th May 2011, 13:05
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
18th May 2011, 15:03
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
18th May 2011, 17:27
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
18th May 2011, 19:39
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
20th May 2011, 10:19
-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
20th May 2011, 13:07
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
21st May 2011, 14:11
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
22nd May 2011, 12:19
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
22nd May 2011, 15:23
@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
22nd May 2011, 21:54
[...]
@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
24th May 2011, 03:41
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
24th May 2011, 09:19
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
27th May 2011, 09:22
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.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.