MPC-HC tester builds for internal renderer fixes

[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