MPC-HC tester builds for internal renderer fixes

[menlvd]

Thanks for the fix, but there is still one more issue I forgot to mention. When mpc-hc is in windowed mode and you move a firefox window in front the audio stops and the video speeds up by a lot. Could be a conflict with the d2d rendering in firefox.

same issue!

UPD!
try on HD 720 and 1080 ok! sometimes fail
SD 24fps/23,976 - fail
SD 25fps - ok

[Hera]

Audio cuts out and video start playing ~2x
The only way to stop the video from playing is to CTRL-C
Got that through seeking

[CruNcher]

Subtitles with EVR (default) and DXVA dukey did it :)

https://forum.doom9.org/showpost.php?p=1557391&postcount=16

[RGold]

I always see tearing right after the MKV video is dropping frames. Does not happen with the regular builds. Tried the alternative vsync on/off, didn't help.

[Hera]

MPC:HC is at fault - driver doesn't crash when MPC stops playback and need to killed.

[CruNcher]

@ Jan

this speedup issue also happens with Aero peak but only if the Peaked Window is above the Video surface and the mini preview isn't playing in the same group as the peaked Window (little complex) :)

Isn't the windows and all processes when peaked put into sleep state and after peaking returns from it so the acceleration happens @ the resume of the sleep state (maybe the timers aren't correctly frozen for the peak, and it tries to accelerate the time to get where it should be resyncing, instead from just waking up and resuming, and if the mini preview stays alive i guess it doesn't get frozen in anway and so happily continues without speeding up when the peak state is over) ?

PS: The default EVR renderer is still broken for Intel SB and Drivers (Black Screen) only in MPC-HC tester Trunk is fine

[JanWillem32]

The previous build had two major errors, so I've removed them from my folder. I also removed older builds.
-mixer formats were giving errors in EVR (VMR-9 was unaffected)
-sorting for SSA subtitles was flawed

The links are on the first page.

From a quick test, I can't replicate the speedup issue. I've tried both x86 and x64 nightly Firefox builds 13.0a1 (2012-02-16) in combination with some of my regular test videos.
As this is probably a scheduler and driver combination issue, I'd like to know which scheduler(s) are affected.
Scheduler options: (Not all combinations are valid. For example, alternative Vsync is always disabled in modes with Aero or the exclusive mode.)
adaptive deinterlacing / weave deinterlacing / interlaced bob rendering / progressive video,
Windows XP / Vista / Seven,
EVR / VMR-9,
constant frame interpolator on / off,
alternative Vsync on / off,
bordered windowed mode with Aero / bordered windowed mode without Aero / full screen windowed mode with Aero / full screen windowed mode without Aero / full screen exclusive mode

@Hera: What scheduler mode did you use?

@RGold: What scheduler mode did you use? Dropping frames is a very invasive action. It's hard to debug and implement. (The constant frame interpolator can't drop frames at all, for example.) I can try to change a few settings to improve the basic schedulers, but I can't guarantee extensive frame dropping support for the more advanced schedulers.

@CruNcher: About a year ago, I suggested to give the OSD renderer an input pin for the standard subtitle renderer, but no developers wanted to work on it. (Both the basic EVR and VMR-9 already accept the input by the OSD renderer.)
For the issue with the black screen with basic EVR, can you temporarily reset your settings, test, disable the OSD, and test again? The only thing I've changed is the OSD renderer, the rest of that renderer is external.
For the renderer, I've not implemented a type of sleep state at all. I can add a processing option for the overlapped and minimized window status messages, but what action would really be appropriate in such a case? I can pause the player, but other than that, dropping the video render filter chain (graph builder parts, splitter parts, video decoder, video renderer) would take ages to restart.

I did find a crashing bug when starting an interlaced DVD .VOB video while the player is minimized. I'll try to debug it later.

[gilic]

Thanks for the fix, but there is still one more issue I forgot to mention. When mpc-hc is in windowed mode and you move a firefox window in front the audio stops and the video speeds up by a lot. Could be a conflict with the d2d rendering in firefox.

I've got an update to that issue, seems this has nothing to do with firefox. It's enough to bring an explorer window to the front. Everything seems a bit random, but i found out that alternative scheduler doesn't have the problem (at least with the file were I had one).


-> adaptive deinterlacing / weave deinterlacing / interlaced bob rendering / progressive video (don't know, where can I check?)
-> win7 64bit
-> EVR-CP
-> frame interpolator always off
-> alternative Vsync always off
-> bordered windowed mode with Aero

[RGold]

@RGold: What scheduler mode did you use? Dropping frames is a very invasive action. It's hard to debug and implement. (The constant frame interpolator can't drop frames at all, for example.) I can try to change a few settings to improve the basic schedulers, but I can't guarantee extensive frame dropping support for the more advanced schedulers.


Sorry for my ignorance - where can I see the scheduler mode that is being used? Is crtl+J going to display it?

[XRyche]

Is the internal subtitle renderer still wonky?

[menlvd]

try alternative scheduler and it's works better for me, video a little bit stuttering and after few sec plays fine
evr-cp
2008 r2
mpc-hc x64
alternative vsync off
frame interpolator off
bordered windowed mode with Aero
only appears when switching to Firefox

[CruNcher]

The previous build had two major errors, so I've removed them from my folder. I also removed older builds.
-mixer formats were giving errors in EVR (VMR-9 was unaffected)
-sorting for SSA subtitles was flawed

The links are on the first page.

From a quick test, I can't replicate the speedup issue. I've tried both x86 and x64 nightly Firefox builds 13.0a1 (2012-02-16) in combination with some of my regular test videos.
As this is probably a scheduler and driver combination issue, I'd like to know which scheduler(s) are affected.
Scheduler options: (Not all combinations are valid. For example, alternative Vsync is always disabled in modes with Aero or the exclusive mode.)
adaptive deinterlacing / weave deinterlacing / interlaced bob rendering / progressive video,
Windows XP / Vista / Seven,
EVR / VMR-9,
constant frame interpolator on / off,
alternative Vsync on / off,
bordered windowed mode with Aero / bordered windowed mode without Aero / full screen windowed mode with Aero / full screen windowed mode without Aero / full screen exclusive mode

@Hera: What scheduler mode did you use?

@RGold: What scheduler mode did you use? Dropping frames is a very invasive action. It's hard to debug and implement. (The constant frame interpolator can't drop frames at all, for example.) I can try to change a few settings to improve the basic schedulers, but I can't guarantee extensive frame dropping support for the more advanced schedulers.

@CruNcher: About a year ago, I suggested to give the OSD renderer an input pin for the standard subtitle renderer, but no developers wanted to work on it. (Both the basic EVR and VMR-9 already accept the input by the OSD renderer.)
For the issue with the black screen with basic EVR, can you temporarily reset your settings, test, disable the OSD, and test again? The only thing I've changed is the OSD renderer, the rest of that renderer is external.
For the renderer, I've not implemented a type of sleep state at all. I can add a processing option for the overlapped and minimized window status messages, but what action would really be appropriate in such a case? I can pause the player, but other than that, dropping the video render filter chain (graph builder parts, splitter parts, video decoder, video renderer) would take ages to restart.

I did find a crashing bug when starting an interlaced DVD .VOB video while the player is minimized. I'll try to debug it later.

Don't need to test it anymore with the Leaked Intel (Ivy Bridge) Driver it works now (confirmed with older MPC HC tester builds and EVR Basic, where before it was black screen with Driver 2622 ( last internal driver update October last year ) it works now with the 2626 Driver (updated components last time in Januar this year, though not a official driver yet) :D

It's really nice to see their Drivers constantly improving it's really visible each update somewhere :)

Though still only 8 bit Integer Surfaces work with MPC-HC tester and EVR Custom

And yep as many said before using the alternative sheduler seems to fix every of those suddenly speedup issues (when something hits the video surface) also with aero peak (the one i mentioned above, video surface losing focus)

Though i had that speedup issue just 1 sec ago but it's hard to pinpoint could have been indeed firefox rendering above it though i have firefox direct2d disabled so the only thing that would be accellerated in those regards would be their layers which are D3D9 :)

So the Alternative Sheduler might not fix it entirely but it lowers the Probability of it happening a lot (especially the Aero Peak issue seems completely fixed by it, might be a good indication to pinpoint the overall problem), ill keep an eye on this maybe i can pinpoint some other specific speedup case :)

So it might not be the sleep state of the window but more a issue with the Renderer losing it's focus (Windowed) on Aero in some specific cases though only :D

[jakmal]

I am curious about how chroma upsampling is done with this renderer.

I believe EVR-CP uses the GPU to upsample chroma and the result is dependent on the GPU driver. Is the behaviour of this renderer any different?

[CruNcher]

@ A least on Intel it uses nothing on EVR-CP you need to actually activate the Chroma upsample shader (which consumes GPU same as the luma scaling itself) on EVR Basic Intels Driver does it perfect, see also my Intel Hardware PP vs EVR-CP and shader PP it shows some stages and differences also a pretty good Efficiency compare of the different stages :)

http://forum.doom9.org/showpost.php?p=1554676&postcount=619

http://forum.doom9.org/showpost.php?p=1555516&postcount=675

Though that it doesn't kill any visible data @ upscaling might be wrong if you look carefully it just seems to shift it different ;) though not sure if this is still the case with the new driver or if this might be also only a issue with MPCs EVR i didn't compared other EVRs yet without any changes like Microsofts Default EVR basic used in WMP,WMC or Graphedit Directly.

So in the end i would say frame data gets lost no difference if you use MPCs EVR-CP or EVR basic with the Hardware Scaler, though why this is the case is what i wonder about, and i still have to try different things which might be the reason for this (MPCs Video Frame options come to my mind)

[JanWillem32]

I don't have much time right now, but I'll write my usual amount of text later today. :)
I've re-written parts of the subtitle renderer to handle aspect ratio correction better and perform better texture management.
Because all subtitle types and video renderers required code changes for this, extensive testing is required.
The new check box is in the main "Subtitles" tab now, as I've changed it into a function that is mostly handled by the video renderer now, instead of a subtitle style option. The changes I've made should fix all aspect ratio issues known with the SSA styles (mostly rotation and curve drawings).
Because this function behaves differently, some people might not like it. As usual, I'm willing to discuss options.
The combo box for subtitle texture resolution became useless after I implemented dynamic allocation for the textures, so I removed it.

[burfadel]

I have a problem with dfr4046i, dfr4075 SSE2 works fine. The issue is the screen size with 4:3 material. The video plays too big, as if its greatly zoomed in (stuff off the edge of the screen). Videos that are 16:9 seem to be fine.

I have tried changing the aspect ratio, video frame settings, pan and scan settings etc, nothing gets it back to being correct. The only way to get it back to proper size is to use the manual zoom-in/zoom-out feature with the keypad.

[dukey]

JanWillem32,
are you interested in a subtitle solution that renders to a separate pin ? That's currently what I am working on. Or trying to at least. I already made a proof of concept filter
http://forum.doom9.org/showthread.php?p=1557391#post1557391

Currently trying to rewrite VSFilter to only pass through the video, then spit out subpics on pin number 2.

[JanWillem32]

Interlaced video: A video file can be checked for its video content with either external or internal MediaInfo. (The internal one is located under "File", "Properties".)
Interlaced video consists of two fields (top and bottom) that combine into frames using one of the two deinterlacing methods. The fields are half-height. For example, a true 1080i video field is 1920×540 in size. (Most "1080i" videos are encoded with merely 1440×540 fields, though. After deinterlacing, the video is resized horizontally to match the 16:9 aspect ratio.)

adaptive deinterlacing: This type of deinterlacing extrapolates frames from each field, so the frame rate is equal to the field rate.
This type of interlaced video is the most prone to have visible artifacts after deinterlacing.
Only TV recordings use this type. It's basically the encoded form of progressive video, where half of the scan lines are discarded, so it's a bit of a compromise.
Typical frame rates are 60, 60/1.001, 50, 48 and 48/1.001 Hz. Lower field rates are of course possible, but the scan line artifacts are very visible with lower field rates.

weave deinterlacing: This type of deinterlacing combines two fields in a frame, so the frame rate is half the field rate.
This type of interlacing only has issues with chroma scaling, and issues with having to encode video in two fragments in the (lossy) video compression scheme. It doesn't have to extrapolate other picture data, unlike adaptive deinterlacing.
Both quality and encoding efficiency are less than with the equivalent form of progressive video. This type of interlacing is commonly used to broadcast cinematic video on TV stations that don't permit any progressive video.
Typical frame rates are 60, 60/1.001, 50, 48, 48/1.001, 30, 30/1.001, 25, 24 and 24/1.001 Hz.

interlaced bob rendering: stretches fields out vertically to create a frame, so the frame rate is equal to the field rate.
This is a common fallback method for when adaptive deinterlacing is unavailable. This isn't a deinterlacing method at all, and it's very ugly.

progressive video: No fields are encoded in the source video for this, only complete frames.
Typical frame rates are again 60, 60/1.001, 50, 48, 48/1.001, 30, 30/1.001, 25, 24 and 24/1.001 Hz. Recording equipment can also store progressive video at a lot of other rates, but those are rarely supported by consumer-grade video carriers (broadcasts, discs and such).

Note that the type of interlacing and pulldown information generally isn't stored in the video stream header or file container header. It's read from the stream segments during playback.


@gilic: I'm still trying to replicate the issue. So far, I can only see frames dropping and slow video when frames overlap the video window.

@RGold: There are a lot of scheduler modes. Some options are indeed listed in the stats screen. The mode in use is determined by the list of options I posted yesterday.

@XRyche: Yes, and it always has been that way. It's slow, inefficient, and because it totally lacks any sensible image rendering methods, the image ouput quality is abysmal as well.
The requirement that I should keep VSfilter working using the shared code, makes working on the subtitle renderer parts a horrible chore.

@menlvd: The alternative scheduler sometimes needs a few seconds to lock to a frame rate. This can be seen in the top right of the stats screen. Some videos have such an unstable or uncommon frame rate that the scheduler reverts to per-frame scheduling, instead of using the frame rate lock. This is also the case with variable frame rate videos.

@CruNcher: Good to hear that a new driver is working properly. I'll keep it in mind for when people ask for information.

@jakmal: Chroma up-sampling is generally done by the EVR or VMR-9 mixer.
The mixers are pretty much a black box situation, viewed from the renderer's side. The graphics driver is free to push filters in the rendering chain, the only thing required is that it outputs on the RGB surfaces allocated by the renderer with the correctly negotiated video size.
Most of the filters on top of basic color conversion do more harm than good, though. I don't like it that in many graphics drivers "enhancement" filters for the EVR mixer are enabled by default.
Chroma up-sampling is one of the more basic filters. So far, I've yet to see anything else than nearest neighbor or bilinear filtering by the mixer's chroma up-sampler. The nearest neighbor filter is a "bonus" feature of the AMD driver if you allocate anything but X8R8G8B8 textures. It's easy to apply custom scaling by the renderer if an image has already been scaled by a factor two using nearest neighbor filtering. That's pretty much the "fix" I've implemented as a renderer option.
Note that "using the GPU" doesn't tell everything. The main workhorse of the GPU is its shadercore, but besides that, there are a number of options for integrating ASIC components on the GPU, such as the DXVA decoder circuit. Some filters set by the graphics driver are exclusive to a specific ASIC component (and with it, come the limitations of such a specific circuit). If for example a pixel format isn't supported by an ASIC, the video driver can crash (always very nice), give a black screen output (very common), do the filtering on the shadercore instead (impossible for DXVA), use the ASIC anyway (will give corrupt pixel output), skip the filter (I think this is exactly happening with the AMD driver), or yet even other options I can't think of at the moment...
About that chroma up-sampling custom pixel shader supplied with the player; it's pretty bad, just like most of the others. I still have to round up a nice selection of my own pixel shader set to integrate and delete all of the original ones.
I would love to implement a custom mixer to handle filters like chroma up-sampling by the renderer itself, but I haven't yet figured out how to negotiate a DirectShow/MediaFoundation video pin (this is currently handled completely by EVR and VMR-9).

@burfadel: What kind of video, in which renderer, in what mode, on which system did you experience this problem?

@dukey: My original thoughts were to append the usual subtitle allocator presenter host to the OSD renderer, which is already on a pin for vanilla EVR and VMR-9 in MPC-HC. I can probably help you with the internal parts of the subtitle renderer, but I'm not familiar with handling video pins.

[burfadel]

Problem on win 7 x64, HD6950, EVR-CP renderer, disabled internal video decoders (just for h264 and xvid/divx) and using ffdshow (for filter effects). Issue only affects 4:3 content, and only with dfr4076i, dfr4075 and the normal mpc-hc is fine.

[RGold]

@RGold: There are a lot of scheduler modes. Some options are indeed listed in the stats screen. The mode in use is determined by the list of options I posted yesterday.


I have attached the setting ini file.

[JanWillem32]

I've tested the code, and I've indeed made a typo in the part that calculates the top-to-bottom aspect ratio factor. This is an error in the standard video renderer handler, so all video renderers are affected. I'll re-compile when I have the time. Manually setting a scaling factor is a proper workaround for this issue.

[Hera]

Video stops playing (720p MP4 4:3, ripped from YouTube) when the following actions happen
Minimized
Video hidden by other Windows


MKVs keep on playing without sound (I use Matroska splitter btw)

[CruNcher]

@ Jan
does MPC-HC use the http://en.wikipedia.org/wiki/Multimedia_Class_Scheduler_Service ? that Microsoft introduced with Vista

http://technet.microsoft.com/en-us/magazine/2007.02.vistakernel.aspx

http://blogs.technet.com/b/markrussinovich/archive/2007/08/27/1833290.aspx

Only administrative accounts, like the Local System account in which MMCSS executes, have the Increase Priority privilege that's required to set real-time thread priorities.

Also the Display Stats for EVR-CP couldn't be the same done also for EVR-Basic as the OSD works it shouldn't be any problem to get the same Graph and Information to be displayed same as for subtittles and all without losing DXVA and any Driver ASIC functions (scaling) also :)

[XRyche]

@XRyche: Yes, and it always has been that way. It's slow, inefficient, and because it totally lacks any sensible image rendering methods, the image ouput quality is abysmal as well.
The requirement that I should keep VSfilter working using the shared code, makes working on the subtitle renderer parts a horrible chore.



Ah sorry, I'm not being very clear again. For the past 5-7 builds MPC-HC Experimental has been crashing due to the internal subtitle renderer. I'm pretty sure it's the internal renderer because when I use xyfilter it doesn't crash at all when displaying subtitles (A.S.S.).

[gilic]

I've re-written parts of the subtitle renderer to handle aspect ratio correction better and perform better texture management.
Because all subtitle types and video renderers required code changes for this, extensive testing is required.
The new check box is in the main "Subtitles" tab now, as I've changed it into a function that is mostly handled by the video renderer now, instead of a subtitle style option. The changes I've made should fix all aspect ratio issues known with the SSA styles (mostly rotation and curve drawings).


I've been testing again with the bad apple video.
Performance is the the same for me as with your previous builds. There is a bug/glitch which I noticed, under r.click->video frame when "touch window from inside" (was my default setting I used till now) is selected, the video is cut/moved out off screen above and below. Subtitles in this space are still rendered and performance is worse than usual. With "stretch to window" everything is fine. What's the best setting to use for normal video viewing (full screen)?

Unfortunately I couldn't really test your new rotation & curve drawing code, because I couldn't find a scene with the anime I have.

Also thank you again for your detailed description of the video modes. The windowed mode speedup/stopping issue still persists, but it's only a minor issue for me. I just reported it. You needn't spend to much time on it.
mediainfo of the culprit:
General
Complete name : F:\DAoC\The Clansman[Adorn].avi
Format : AVI
Format/Info : Audio Video Interleave
File size : 154 MiB
Duration : 20mn 40s
Overall bit rate mode : Variable
Overall bit rate : 1 040 Kbps

Video
ID : 0
Format : MPEG-4 Visual
Format settings, BVOP : 1
Format settings, QPel : No
Format settings, GMC : No warppoints
Format settings, Matrix : Default (H.263)
Muxing mode : Packed bitstream
Codec ID : DX50
Codec ID/Hint : DivX 5
Duration : 20mn 40s
Bit rate : 902 Kbps
Width : 512 pixels
Height : 384 pixels
Display aspect ratio : 4:3
Frame rate : 24.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.191
Stream size : 133 MiB (87%)
Title : Video
Writing library : DivX 5.2.1 Alpha (UTC 2004-09-08)

Audio
ID : 1
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Mode : Joint stereo
Codec ID : 55
Codec ID/Hint : MP3
Duration : 20mn 40s
Bit rate mode : Variable
Bit rate : 128 Kbps
Channel(s) : 2 channels
Sampling rate : 44.1 KHz
Compression mode : Lossy
Stream size : 18.6 MiB (12%)
Alignment : Aligned on interleaves
Interleave, duration : 26 ms (0.63 video frame)
Interleave, preload duration : 117 ms
Title : Audio
Writing library : LAME3.92

[JanWillem32]

@Hera: That's one I can easily try in my next debugging session.

@CruNcher: pfAvSetMmThreadCharacteristics is indeed used (for Vista and newer), I kept the lines from the trunk build.
EVR-CP:
http://sourceforge.net/apps/trac/mpc-hc/browser/trunk/src/filters/renderer/VideoRenderers/DX9AllocatorPresenter.cpp
CDX9AllocatorPresenter::VSyncThread (commented out)
http://sourceforge.net/apps/trac/mpc-hc/browser/trunk/src/filters/renderer/VideoRenderers/EVRAllocatorPresenter.cpp
CEVRAllocatorPresenter::RenderThread
CEVRAllocatorPresenter::GetMixerThread (commented out)
Also see CEVRAllocatorPresenter::StartWorkerThreads for the base thread priorities.
EVR Sync:
http://sourceforge.net/apps/trac/mpc-hc/browser/trunk/src/filters/renderer/VideoRenderers/SyncRenderer.cpp
CSyncAP::RenderThread

Note that only the color management parts can really block. Both threads already yield at least once for each frame to prevent blocking. The base priorities (critical and high) are fine. I can disable the MMCSS functions in the renderer, but I think it's working fine as it is.

The vanilla EVR renderer handler is very simple. It doesn't gather stats at all. The external EVR doesn't expose much either. Most of the stats displayed by EVR-CP and VMR-9 r. are purely from the renderer itself.
If someone wishes to write an OSD renderer with stats, I'll happily assist. For the renderers I'm working on, I'm planning to write a seperate OSD renderer that doesn't send screen-sized bitmaps (one of the design flaws that the subtitle renderer also used to have).

@XRyche: Is it with all ASS/SSA subtitles? Else, do you have a sample subtitle file? Did you already try resetting your settings? What mixer input format is reported by the renderer with xy-VSfilter enabled and without?

@gilic: See my previous post about the aspect ratio problem.
I didn't change the rotation & curve drawing code. That part of the code was incapable of adapting aspect ratios. I solved that problem externally.
I'll try to find a sample like the type you posted. I've not been able to replicate the issue yet.

[Hera]

I use the default scheduler BTW

[JanWillem32]

I fixed the aspect ratio math and a minor flaw in the timer math for one of EVR CP's stats for for larger elapsed time values.

[gilic]

Confirmed fixed, thanks.

[Hera]

Actually, video doesn't stop - it speeds up.
Uhm, green line dissapears whenever MPC is not visible it seems and never gets back (if I get back to the video quickly, it goes back, otherwise after a second or two - well it bugs out)
... and you cannot pause the video it seems (stop button works though).
This sees to happen with everything - AVI files included (240p AVI, but not 100% reproducible)
And no sound.
If I use the thumbnail (W7) - it doesn't happen - I guess something happens when the video is not in any form visible to the user that the scheduler doesn't know how to handle.

WMP doesn't actually play the video when it is not visible - I noticed that it quickly recovers when I get back to it...

Alternative scheduler seems really really bad (stutters, can't keep up, de-syncs), but doesn't have this problem.

[JanWillem32]

@RGold: The text file you appended was finally approved. The settings inside described this mode:
adaptive deinterlacing / weave deinterlacing / interlaced bob rendering / progressive video (can vary),
Windows 7,
EVR,
constant frame interpolator off,
alternative Vsync on,
bordered windowed mode without Aero / full screen windowed mode without Aero

The VSync mode written by my predecessors was hard to integrate into the new renderer core. I thought I got it right a few versions ago. I didn't know that the prior kept VSync when dropping frames, nor that mine didn't. I'll take a look at it, maybe I can change it. Thank you for reporting, I would not have found such an exceptional case on my own.

@Hera: I still can't reproduce the issue, but I'll keep trying, including with other computers than mine. The alternative scheduler currently can't handle bordered windowed presenting, dropping more than 1 in 5 unscheduled frames (maybe even less), and it has slowdown issues with overlapping menus (such as the right-click menu). It can easily drop scheduled frames, by the way. For example; playing a 50 fps video on a 25 Hz monitor should cause the scheduler to evenly discard half of all frames.

[JohnLai]

The latest build has issue with blu ray subtitle = Idx + Sub external blu ray subtitles.

http://i.imgur.com/gS9Ll.jpg

[JanWillem32]

Oh, dear... The subtitle renderer must really be broken this time to output grammar like that...
I'll try to look up a Idx + Sub combination. It's probably only a minor issue if the previous builds worked fine.

[JanWillem32]

I'm sorry, but I've tried five samples of Idx + Sub, internal and external with a few types of containers and I can't reproduce the problem at all. Do you get this issue with all Idx + Sub combinations, or only with this one? If it's only this one, can you upload a sample?

[JanWillem32]

I've made a few fixes and performance improvements.
There's a new graph in the stats screen.
-Cyan (previously blue): frame paint time
-Magenta in EVR CP: frame time read from the video stream (magnified by 10)
-Magenta in VMR-9 r.: frame time difference delegated by the external VMR-9 thread (magnified by 10)
The magenta graph is useful for diagnosing source files with bad time stamps. (The frame rate lock function usually repairs that.)

The links are on the first page.

[pururin]

May I ask what is the difference between AVX, SSE2, SSE versions?

Does it effect performance in any parts or function?

:thanks:

[madshi]

JanWillem32,
are you interested in a subtitle solution that renders to a separate pin ? That's currently what I am working on. Or trying to at least. I already made a proof of concept filter
http://forum.doom9.org/showthread.php?p=1557391#post1557391

Currently trying to rewrite VSFilter to only pass through the video, then spit out subpics on pin number 2.
JFYI, we've created a new custom interface for subtitle renderers here:

http://code.google.com/p/xy-vsfilter/issues/detail?id=40
http://madshi.net/SubRenderIntf.h

This interface will be supported by future versions of madVR, LAV Video Decoder and xy-vsfilter.

[ryrynz]

May I ask what is the difference between AVX, SSE2, SSE versions?
Does it effect performance in any parts or function?


They're different instruction sets, SSE2 should be faster than SSE, AVX should be faster than SSE2. Whether that is the case or not I guess only JanWillem could answer.

[JanWillem32]

@pururin: AVX, SSE2 and SSE are some of the many processor extensions on top of the base x86 platform from 1978. Compiler settings determine what instructions the compiler may use. Attempting to use instructions not supported by the processor will generally crash the program.
There are only very few old x86 processors still in the wild that don't support SSE extensions. SSE2 support has been available since the Intel Pentium 4 and AMD Athlon 64 processors (SSE2 support is also a minimum requirement for the x64 instruction set). AVX is still very new and only supported on the most recent generation of CPUs: http://en.wikipedia.org/wiki/Advanced_Vector_Extensions .
Within the code, there are many specific segments for SSE and SSE2 paths. Some types are hard-coded (only one of the two paths will be in the instruction code of the executable), and some types are switched by detecting the processor instruction support bits (multiple code paths will be inside the instruction code of the executable).
An example is the main bitmap renderer in the subtitle renderer. It has a selectable SSE- and SSE2-level rendering path for SSE builds. For SSE2 builds and above, the SSE-level code path is discarded and the processor bits are not detected. Those always use the SSE2 path.
Another example is the copy function for the screenshot function that I've recently added. The old one was really slow. I decided to replace it by 4 switchable code paths for the copy function. Two are on the SSE4.1 level, the other two use SSE-level functions. (The data alignment issue further decides which of the two paths are selected next. All programmers should be familiar with that type of issue.)

@madshi: It's been a while. Eh... I totally forgot about that project. I've been busy with all sorts of things. I guess it would have been nice if I dropped in another message some time ago. I've written quite a few functions that could be used internally. I'll take a look at things later.
In the past, I've asked the MPC-HC development team if I could make the renderers into external DLL files, and put the custom pixel shaders into external TXT files. The ideas were rejected. I'm not even going to ask if I can make the subtitle renderer external this time. So in short: I can replace the internal subtitle renderer, but adding support for something external isn't very useful for me. Still, I don't mind working on the project(s). As I mentioned earlier, I've already written some useful code (mostly SSE stuff), and I don't mind sharing.

[nevcairiel]

They're different instruction sets, SSE2 should be faster than SSE, AVX should be faster than SSE2. Whether that is the case or not I guess only JanWillem could answer.

Its doubtful that there is any measurable difference.
If there is, it should be optimized with ASM code instead of being at the mercy of the compiler, anyway.

You should never need different versions for different CPUs (on the same platform, anyway), its just asking for trouble and a nightmare for users.

[burfadel]

EVR-CP doesn't work in r4101. Works fine in r4087. I tried resetting the render settings etc and no go. In D3D mode, its just a black screen. In basic mode it doesn't even come up with the picture window, it just plays the sound. The other renderers work fine, including normal EVR. This is with the SSE2 version. I also tried the SSE version, and the picture windows did show with the first frame or two, but then crashed.

[ryrynz]

The ideas were rejected.

JanWillem, can you not just create your own fork? It's not the MPC team is really moving things along much. I think having a true dedicated developer with you being unrestricted in your development and working alongside Madshi, Nevcairiel, X_xy_y2 and Haruhiko to create a suite that "just works" sounds like a good idea to me.

[madshi]

@madshi: It's been a while. Eh... I totally forgot about that project. I've been busy with all sorts of things. I guess it would have been nice if I dropped in another message some time ago. I've written quite a few functions that could be used internally. I'll take a look at things later.
In the past, I've asked the MPC-HC development team if I could make the renderers into external DLL files, and put the custom pixel shaders into external TXT files. The ideas were rejected. I'm not even going to ask if I can make the subtitle renderer external this time. So in short: I can replace the internal subtitle renderer, but adding support for something external isn't very useful for me. Still, I don't mind working on the project(s). As I mentioned earlier, I've already written some useful code (mostly SSE stuff), and I don't mind sharing.
Sounds good to me, thanks. I think the interface we created might become more attractive once xy-filter and madVR are both supporting it. Also nevcairiel was considering creating a libass based subtitle renderer supporting that interface, too, and even making use of it in LAV Video Decoder. After all that (which may take a while to turn into reality) maybe you'll get more interest in adding support for the interface to your renderers, too... :D

I'm really sad about the MPC-HC decision makers being so stuck on having an integrated one-file-only stance, plus insisting on having all those source & decoder filters integrated, too. I'd love a small lightweight MPC-HC without all that integrated stuff, with all useful bits and pieces being optional external ax/dll files. But well, what can we do...

[aufkrawall]

I'm really sad about the MPC-HC decision makers being so stuck on having an integrated one-file-only stance, plus insisting on having all those source & decoder filters integrated, too.

Totally agreed.
I don't know why they spend so much time on the decoders and splitters when more and more people instead use LAV.

[CruNcher]

@Jan
is it possible to implement :) http://www.iryoku.com/smaa/

though i guess http://mrhaandi.blogspot.com/p/injectsmaa.html could already work externally

[ryrynz]

I'd love a small lightweight MPC-HC without all that integrated stuff, with all useful bits and pieces being optional external ax/dll files. But well, what can we do...

This is exactly what I'd like to see also, something that's made to go hand in hand with the other up and coming projects. MPC just has no direction right now, Jan, I'd like to see you take it on and work collaboratively with Madshi and co.

[clsid]

@madshi: It's been a while. Eh... I totally forgot about that project. I've been busy with all sorts of things. I guess it would have been nice if I dropped in another message some time ago. I've written quite a few functions that could be used internally. I'll take a look at things later.
In the past, I've asked the MPC-HC development team if I could make the renderers into external DLL files, and put the custom pixel shaders into external TXT files. The ideas were rejected. I'm not even going to ask if I can make the subtitle renderer external this time. So in short: I can replace the internal subtitle renderer, but adding support for something external isn't very useful for me. Still, I don't mind working on the project(s). As I mentioned earlier, I've already written some useful code (mostly SSE stuff), and I don't mind sharing.You should ask again. Maybe a voting should take place. You will have my vote for making things external.

[burfadel]

EVR-CP doesn't work in r4101. Works fine in r4087. I tried resetting the render settings etc and no go. In D3D mode, its just a black screen. In basic mode it doesn't even come up with the picture window, it just plays the sound. The other renderers work fine, including normal EVR. This is with the SSE2 version. I also tried the SSE version, and the picture windows did show with the first frame or two, but then crashed.

Anyone had the same issue with this, or is it just me?!

[JanWillem32]

Its doubtful that there is any measurable difference.
If there is, it should be optimized with ASM code instead of being at the mercy of the compiler, anyway.

You should never need different versions for different CPUs (on the same platform, anyway), its just asking for trouble and a nightmare for users.The AVX versions are just experimental. I tried building them mostly to see what assembly the compiler generates with this setting. I don't think AVX builds will become common for a while.
SSE2 requirement is a bigger issue. I write for an SSE2 level by default, and having to add the SSE level alternative code is annoying. I had to add dozens of switches for this issue in the code. All of those had to be tested. (I at least read the assembly generated by the compiler for the three build types.) Also, for now, I can't even think of adding in an SSE2 level library, such as this one: http://msdn.microsoft.com/en-us/library/windows/desktop/ee418732%28v=vs.85%29.aspx . (There's a good reason why the non-SSE2 version isn't recommended, and there's no real alternative.)
I would very much prefer making SSE2 support a hardware requirement for the program. Note that the DirectX 11 renderer I've tried to import is, eh... a lot more demanding than only requiring SSE2, too. (It was designed for modern systems, for pretty specific tasks. I'll try to lower the CPU+GPU minimum requirements when I have enough time to work on it.)
In terms of statistics: http://imageshack.us/photo/my-images/513/statsda.png/ . SSE versions are usually downloaded by the users that download all versions early on, but afterwards, the SSE2 and base x64 versions dominate. (Too bad that I didn't save the older statistics. I've had several numbers in the hundreds of previous versions.)

About the issue internal/external filters, I can't deal with that stuff while I'm trying to present a candidate for code integration into the trunk build. After integration, I'll happily discuss anything related.

@burfadel: This is so far the only issue reported (aside from the issue with EVR Sync). This is somewhat surprising, as there were no major code changes in the main renderer in between these two builds. (I mostly modified the subtitle renderer host.) Could it be related to this fix afterwards: http://sourceforge.net/apps/trac/mpc-hc/changeset/4102 ? (Depends on the files you tested, of course.) Otherwise, does resetting all settings by the button in the miscellaneous tab help?

@CruNcher: I can indeed integrate such a module. Note that its function is to anti-alias along vertices. The renderer uses vertices to draw the video rectangle. In short, I can use it to anti-alias the borders of the video rectangle. Currently, anti-aliasing is explicitly disabled for the renderer, as it would be a waste for 2D rendering. (Though it would probably look nicer when I want to animate video-textured, falling teapots with this renderer again.)

Sorry that I don't really have time for typing more text right now, sunday and monday are always very busy days for me.

[tetsuo55]

I'm not against external files either.
It would be nice to still be able to compile as a single file, but imho its just blocking progress.

that said people need to provide actual patches.