Log in

View Full Version : MPC-HC tester builds for internal renderer fixes


Pages : 1 2 3 4 5 6 7 8 [9] 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

Traps
9th September 2011, 00:09
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
9th September 2011, 00:28
@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
9th September 2011, 14:25
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
9th September 2011, 21:30
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
10th September 2011, 01:09
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
10th September 2011, 09:00
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
10th September 2011, 11:15
@jan

http://forum.doom9.org/showthread.php?p=1525288#post1525288 :D

Hera
10th September 2011, 19:35
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
11th September 2011, 21:23
@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
12th September 2011, 03:25
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
12th September 2011, 08:52
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
12th September 2011, 14:11
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
12th September 2011, 15:23
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
12th September 2011, 15:51
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
12th September 2011, 17:55
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
12th September 2011, 20:13
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
15th September 2011, 12:28
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
15th September 2011, 12:54
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
16th September 2011, 01:04
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
16th September 2011, 10:14
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
17th September 2011, 15:23
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
17th September 2011, 16:01
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
17th September 2011, 16:29
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
17th September 2011, 17:01
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
17th September 2011, 17:37
nand chan, yes, 24 in foo is "24 padded to 32" actually.

cca
18th September 2011, 12:59
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
18th September 2011, 13:23
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
18th September 2011, 17:05
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
18th September 2011, 17:36
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
18th September 2011, 18:48
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
18th September 2011, 23:20
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
19th September 2011, 01:22
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
19th September 2011, 07:24
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
19th September 2011, 13:58
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
19th September 2011, 14:12
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
19th September 2011, 15:28
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
19th September 2011, 16:11
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
19th September 2011, 21:44
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
19th September 2011, 23:25
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
20th September 2011, 00:08
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
20th September 2011, 01:42
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
20th September 2011, 14:09
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
20th September 2011, 16:44
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
20th September 2011, 18:00
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
20th September 2011, 19:59
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
20th September 2011, 21:07
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
20th September 2011, 23:29
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
21st September 2011, 11:48
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
21st September 2011, 13:37
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
21st September 2011, 14:04
Anyone has 'no sound' issue when using MPC Audio Renderer with build 3733 64bit?