Media Player Classic Home Cinema (MPC-HC) - DXVA!

[nevcairiel]

Aero itself already prevents tearing, you don't need vsync correction anymore.
The graph is however not really accurate with Aero on, because the renderer doesn't really pick up everything Aero does behind its back.

[CruNcher]

Yep i realized that everything is indeed much smoother with Aero and Vsync can cause even problems when moving the MPC-HC window around while playing back certain Framerates, i wonder why Arcsoft disables it though also for Totalmediatheatre and changes to the Basic Interface and by default MPC-HC is also set todo so.
I realized no drawback in Playback till now and also jitter is relatively low the only issue is this sample.ts and problems with EVR Sync and Custom :( the either Flickering (Evr Sync) or Slideshow (Evr Custom) issue, though that doesn't seem to be Aero related @ all :)
I also found another stream that shows this issue also .ts and also 29.970 H.264 (i had no issues with these streams on DXVA1 and Nvidia VMR9 Renderless but with EVR Custom&Sync Microsoft DTV Decoder DXVA2 and HD2000 they seem to go out of control now)

[nevcairiel]

You can configure the newer versions of TMT5 if they should disable Aero or not. I think it was mostly done for performance reasons (on low end cards, rendering Aero and the video might not work 100% smooth)

[koliomalinov]

Hi, were can I download the latest build with BE MOD, accept the xvidvideo.ru, thanks.

[ramicio]

I was thinking to this display (http://i.imgur.com/zfvWB.png) but if it's not enough we will see what we can do.

I have no information area.

[Underground78]

I have no information area.

Have you enabled the menu item "View" > "Information"?

[ramicio]

Yes I have.

[Underground78]

Are you playing a DVD opened as such using "File" > "Open DVD"?

[ramicio]

No, this is with an MKV. All my video is in Matroska.

[Underground78]

No, this is with an MKV. All my video is in Matroska.

Hmm, it might not be reported here then but we might change that. You better open a ticket if you don't want your feature request to be lost in this thread.

[ramicio]

Hmm, it might not be reported here then but we might change that. You better open a ticket if you don't want your feature request to be lost in this thread.

Thank you, I just did that now.

[JanWillem32]

Wow is Aero more efficient then the Internal Vsync ?
the more i use this on the Intel IGP the more im impressed with Film content on 60 Hz :)

With Aero disabled it jitters like crazy with Aero on its a dream :)This VSync behavior is normal.
The windowed mode without desktop composition uses a GDI renderer to draw to the screen. It doesn't really VSync on its own and doesn't queue up frames to draw.
The windowed mode with desktop composition uses a DirectX 9 Ex renderer do draw to the screen. It performs VSync on its own and queues up a minimal amount of frames to perform triple buffering.
Both modes really don't expose any information to programs about when a frame is flipped to the front buffer for display, and the programs that try to display something are not allowed to flip frames to the front buffer.
In the exclusive mode, programs are linked up directly to the device's front and back buffers, and are allowed to flip those themselves. Synchronization data from the video card itself can be used in this case for VSync methods.

In the exclusive mode, there's no compromise when timing frame rates to refresh rates and timing presentations to VSync cycles.
In the windowed mode with desktop composition, the VSync is automatic, but you have to guess how much time it takes and compensate for the delay to get the timing frame rates to refresh rates correct.
In the windowed mode without desktop composition, the VSync is not automatic. You have to interpolate the delay from the GDI renderer, compensate for it with every frame (as it rarely presents successive frames in the same time spans), and try to present a frame in the GDI renderer's VBlank time (when it's not drawing to the next frame yet). After that, try to compensate for the delay to get the timing frame rates to refresh rates correct.
From some experience I can say that timing in the windowed modes is very hard to get right.

More information about the two main VSync functions:
"Alternative VSync" disables the standard DirectX 9 VSync function. It forces frames to immediately present to the display (in exclusive mode) or window (in windowed mode) when a present is called.
"VSync" enables the renderer's internal VSync timer. It creates a delay in the paint loop of the renderer prior to a present call, to try to get it right into the VBlank period.
The renderer itself is capable of queuing up to 4 fully rendered frames in exclusive mode, unless "VSync", "Alternative VSync", "Flush GPU Before VSync" or "Flush GPU After Present" is enabled. Else, the renderer always waits for frames to present, prior to creating new frames. (In my modified builds, I've also enabled the frame queue in windowed mode, with the same restrictions.)

[Betsy25]

Can anyone please test the .wmv clip under "An hour-long session on Fiddler @ MIX2011 can be streamed from here." at https://fiddler2.com/Fiddler/help/video/default.asp

In MPC-HC the video plays choppy/stuttering, while in WMP it plays correct. You can see in the screen-in-screen in the video.



Video: Windows Media Video 9 960x540 29.97fps 926kbps [Raw Video 1]
Audio: Windows Media Audio 44100Hz stereo 64kbps [Raw Audio 0]

MPC-HC default install from K-Lite codec pack 7.7.0

Please?

[CruNcher]

This VSync behavior is normal.
The windowed mode without desktop composition uses a GDI renderer to draw to the screen. It doesn't really VSync on its own and doesn't queue up frames to draw.
The windowed mode with desktop composition uses a DirectX 9 Ex renderer do draw to the screen. It performs VSync on its own and queues up a minimal amount of frames to perform triple buffering.
Both modes really don't expose any information to programs about when a frame is flipped to the front buffer for display, and the programs that try to display something are not allowed to flip frames to the front buffer.
In the exclusive mode, programs are linked up directly to the device's front and back buffers, and are allowed to flip those themselves. Synchronization data from the video card itself can be used in this case for VSync methods.

In the exclusive mode, there's no compromise when timing frame rates to refresh rates and timing presentations to VSync cycles.
In the windowed mode with desktop composition, the VSync is automatic, but you have to guess how much time it takes and compensate for the delay to get the timing frame rates to refresh rates correct.
In the windowed mode without desktop composition, the VSync is not automatic. You have to interpolate the delay from the GDI renderer, compensate for it with every frame (as it rarely presents successive frames in the same time spans), and try to present a frame in the GDI renderer's VBlank time (when it's not drawing to the next frame yet). After that, try to compensate for the delay to get the timing frame rates to refresh rates correct.
From some experience I can say that timing in the windowed modes is very hard to get right.

More information about the two main VSync functions:
"Alternative VSync" disables the standard DirectX 9 VSync function. It forces frames to immediately present to the display (in exclusive mode) or window (in windowed mode) when a present is called.
"VSync" enables the renderer's internal VSync timer. It creates a delay in the paint loop of the renderer prior to a present call, to try to get it right into the VBlank period.
The renderer itself is capable of queuing up to 4 fully rendered frames in exclusive mode, unless "VSync", "Alternative VSync", "Flush GPU Before VSync" or "Flush GPU After Present" is enabled. Else, the renderer always waits for frames to present, prior to creating new frames. (In my modified builds, I've also enabled the frame queue in windowed mode, with the same restrictions.)

Thx for the Explanation Jan i looked @ those 2 .ts samples and it seems it helps to lower the EVR Buffer to 4 a lot on EVR Custom it doesn't become a Slideshow anymore and on EVR Sync it only flickers if the Window is moved with a Buffer of 4 :)
Not smooth in any way but much better then with a Buffer of 5 = Slideshow (Overspeed)

http://img17.imageshack.us/img17/6422/evrbuffer4.th.png (http://img17.imageshack.us/img17/6422/evrbuffer4.png)

Here is a Visualization of the Problem :)

http://mirror05.x264.nl/CruNcher/mpc-hc/

[STaRGaZeR]

To whoever may interest, I've done some minor modifications to the logic that decides between vsync modes 0, 1 and 2 in this build for my personal use. Trunk doesn't quite work for my 120Hz display, but looking at the code weird stuff that I've fixed here should be fixed for other setups too. Of course, bugs may have been introduced, so use it only if you feel like it. Changes apply to EVR CP only.

http://www.mediafire.com/?9vcyc7kmc6rb669

[clsid]

It seems that several people get better results with VSync turned off on Win7, including myself. Since Aero (desktop composition) is enabled by default, perhaps it would be a good idea to disable VSync by default on Windows 7? Any opinions?

[JanWillem32]

I've already set that up. Pretty much all items are unchecked by default in my builds. I've also set up inhibition of starting up the main VSync thread if desktop composition is enabled in windowed mode, or when only the default VSync from the DirectX 9 device is used.

@STaRGaZeR: A patch to import? I can at least try to fix some parts of the half-broken VSync for the windowed modes.

[STaRGaZeR]

@STaRGaZeR: A patch to import? I can at least try to fix some parts of the half-broken VSync for the windowed modes.

Not really, this is just for personal use but works just fine with everything I throw at it, at all refresh rates. I was tired of Reclock, madVR and stuff so I decided to take a look myself and the results are way better than expected. Just sharing so people with issues similar to mine don't get crap like this (http://img851.imageshack.us/img851/5285/85509261.png). The original algorithm just doesn't work for certain cases. For example, in that screenshot mode 1 should have changed to 2 way earlier to avoid that mess.

Aero does solve tearing, but doesn't solve the issue of smoothness at all. Most people are on 60Hz displays, so they don't notice.

[CruNcher]

Btw http://mirror05.x264.nl/CruNcher/mpc-hc/ (please wait for it to be fully loaded i still have to improve the progressive streaming @ the 1:35 (EVR move window demo) it will recover @ 1:50 (End of EVR Custom Window move) and start again @ 2:52 (EVR smooth demo) mark those aren't performance issues @ recording but VBV problems with Quicksync :( it was my first try todo a Live Quicksync Desktop Recording based progressive Streaming Framework not that bad but still buggy itself sorry, the best is to wait for the whole to be finished loading, gonna try to adapt to the bandwith limits)

[JanWillem32]

@STaRGaZeR: I see something else, too. The trunk build can't detect 119, 89, 71, 59, 47, 29 and 23 Hz reports as (n+1)/1.001 Hz. It assumes n Hz, which is almost 1 Hz too low. It's a known problem in the trunk build. Anyway, if you can show any modified code, please share it with us. The timing/VSync functions are known to be buggy, and we happily accept contributions to the code.

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

[clsid]

It would be nice to get some fixes implemented into trunk for these kind of bugs.

I am not a big fan of huge merges from a branch into trunk. This was done in the past with the beliyaal merge, and that was in hindsight not much of a success. Most of todays renderer related bugs are the result of that merge. So hopefully your work can, once ready, be merged in smaller chunks with time in between each merge.

[Superb]

@STaRGaZeR: could you please publish the source for your modified binary? (you know... GPL and stuff...)

[JanWillem32]

@clsid: I've completely deleted and added several files. The main paint loop (that takes a frame from the mixer, processes it and puts it on screen) in the shared renderer has been revised for more than 90% of the code (it takes up about two thirds of all the code in the renderer part). There's no way that can be split up. When I first started that re-write, it wouldn't compile into something sensible for weeks. The parts for the mixer updates, internal codecs, some of the VSync parts (shared by the renderer and mixers), subtitle renderer parts, and a few other small items are patchable.
About beliyaal, a comparison:
I've already been around here for developing for a longer period of time,
I've interacted more with the users of tester builds,
I have a more suitable previous specialization for writing renderer code (2D, 3D, ray-tracing, modeling and texturing with DirectX 10/11),
I'll happily stick around for a while for maintenance (there's plenty to do),
and I'll happily work on the subtitle renderer, a new custom mixer or a DirectX 11 renderer in the future (preferably only one at a time).
Although I'm probably harder to actually work with (not much experience with open source projects like this, personality issues ;)), I intend to go in a different direction than the one beliyaal chose for.

[STaRGaZeR]

@STaRGaZeR: I see something else, too. The trunk build can't detect 119, 89, 71, 59, 47, 29 and 23 Hz reports as (n+1)/1.001 Hz. It assumes n Hz, which is almost 1 Hz too low. It's a known problem in the trunk build. Anyway, if you can show any modified code, please share it with us. The timing/VSync functions are known to be buggy, and we happily accept contributions to the code.

That isn't important for the actual vsync correction, at least in my tests. And what do you mean it can't detect 119Hz or 59Hz? Here it does.

@STaRGaZeR: could you please publish the source for your modified binary? (you know... GPL and stuff...)

Sure. Here's a new build and patch with a little correction.

Build: http://www.mediafire.com/?x03th273rhzfba7
Patch: http://www.mediafire.com/?xdpd85voixkyq2p

If you are thinking of integrating this into something, do not, I repeat, do not do it until it has been properly tested.

Take a look at the FIXME I added, interesting stuff but I couldn't do it with my limited knowledge of the code.

[CruNcher]

Could somebody please test this sample http://www.mediafire.com/?h93rl062889477p with a VP2/4/5 on a Nvidia card using Microsofts DTV-DVD Decoder and MPC-HC with EVR-Custom all sync options off on Aero Win7 :)

Slowly i believe this is a Intel Decoder (Driver) issue with this sample, though that it works in EVR (normal) is strange but it works with EVR Custom & Sync fine withouth DXVA with any Software Decoder :)

and someone else with Sandy Bridge based HD 2000/3000 (latest win64 driver)

Potplayer 64 shows the same behavior

[pirlouy]

It would be nice to get some fixes implemented into trunk for these kind of bugs.

I am not a big fan of huge merges from a branch into trunk

I think the best choicie would be to add another renderer. You rename the "EVR CP" by "EVR beliyaal (beta)". You rename the "EVR Sync" by "EVR by ar-jar (beta)".
And now "EVR by JanWillem32 (beta)".
Like this, no unhappy people, and JanWillem32 can work to improve things thanks to casual users.

[clsid]

@clsid: I've completely deleted and added several files. The main paint loop (that takes a frame from the mixer, processes it and puts it on screen) in the shared renderer has been revised for more than 90% of the code (it takes up about two thirds of all the code in the renderer part). There's no way that can be split up. When I first started that re-write, it wouldn't compile into something sensible for weeks. The parts for the mixer updates, internal codecs, some of the VSync parts (shared by the renderer and mixers), subtitle renderer parts, and a few other small items are patchable.
About beliyaal, a comparison:
I've already been around here for developing for a longer period of time,
I've interacted more with the users of tester builds,
I have a more suitable previous specialization for writing renderer code (2D, 3D, ray-tracing, modeling and texturing with DirectX 10/11),
I'll happily stick around for a while for maintenance (there's plenty to do),
and I'll happily work on the subtitle renderer, a new custom mixer or a DirectX 11 renderer in the future (preferably only one at a time).
Although I'm probably harder to actually work with (not much experience with open source projects like this, personality issues ;)), I intend to go in a different direction than the one beliyaal chose for.It would be great if you could give the VSync stuff some priority, because vsync bugs are for example causing playback problems with certain wmv files.
Any subtitle improvements are welcome too. Certainly when they improve performance.

[ikarad]

and I'll happily work on the subtitle renderer,
I expect that because in mpc-hc sub renderer is very buggued and doesn't worked with some blu-rays.

Where can we post you the problems with sub renderer?

[tetsuo55]

@ikarad open tickets on trac and cc janwillem

[ikarad]

@ikarad open tickets on trac and cc janwillem

on track (http://sourceforge.net/apps/trac/mpc-hc/ticket/48) still open since 2 years and you have said that it will be never corrected (no developpers worked on sub renderer).

I will try on janwillen bugreport.
Can you give the link of track janwillem?

[groen]

Can anyone please test the .wmv clip under "An hour-long session on Fiddler @ MIX2011 can be streamed from here." at https://fiddler2.com/Fiddler/help/video/default.asp

In MPC-HC the video plays choppy/stuttering, while in WMP it plays correct. You can see in the screen-in-screen in the video.



Video: Windows Media Video 9 960x540 29.97fps 926kbps [Raw Video 1]
Audio: Windows Media Audio 44100Hz stereo 64kbps [Raw Audio 0]

MPC-HC default install from K-Lite codec pack 7.7.0

I use mpc-hc (with internal filters disabled) and ffdshow-tryout as codec filters with lav filters for splitter and evr sync renderer with no dxva. But for wmv,wma, ffdshow-tryouts is completely disabled. The samples open ok in windows media player, but when opening it in mpc-hc the video loads but there is no audio. I tried enabling wma in ffdshow-tryouts but it did not work. Are there any internal mpc-hc filters that i could enable for wma ? As all the internal filters and ffdshow is disabled i guess it would be using the same filters that it uses in windows media player.

I have an install of 32bit mpc-hc which uses the internal filters and it works ok. Do you know which internal filter might be making wma work?

[Aleksoid1978]

on track (http://sourceforge.net/apps/trac/mpc-hc/ticket/48) still open since 2 years and you have said that it will be never corrected (no developpers worked on sub renderer).

I will try on janwillen bugreport.
Can you give the link of track janwillem?

Can you upload a 200-500mb sample for test.

[blaster00]

LAV Audio Decoder does not connect to MPC Audio renderer, it uses DirectSound instead.

[ikarad]

Can you upload a 200-500mb sample for test.

Here
http://www.zshare.net/download/943243170ecd3dc9/


added at bug report
https://sourceforge.net/apps/trac/mpc-hc/ticket/48#comment:20

At 13seconds, with ffdshow the subs "the fourth wave of ennemy photon torpedoes is approchaing!" is displayed. With mpc-hc the sub is not dispayed.

[namaiki]

Could somebody please test this sample http://www.mediafire.com/?h93rl062889477p with a VP2/4/5 on a Nvidia card using Microsofts DTV-DVD Decoder and MPC-HC with EVR-Custom all sync options off on Aero Win7 :)

Slowly i believe this is a Intel Decoder (Driver) issue with this sample, though that it works in EVR (normal) is strange but it works with EVR Custom & Sync fine withouth DXVA with any Software Decoder :)

Which bad behaviour is it? Is it the "go" "stop" "go" "stop" with LAV splitter? Still seems to occur with my GeForce 330M and Intel HD grahics.

[oddball]

Will there ever be full support for bluray playback? right now it just plays the movie from the index file. no menu or extras. i'd love to be able to replace tmt.

[ageback]

Simp. Chinese for 3710
http://hotfile.com/dl/129114147/b91f6de/mplayerc.sc.rc.7z.html

[CruNcher]

Which bad behaviour is it? Is it the "go" "stop" "go" "stop" with LAV splitter? Still seems to occur with my GeForce 330M and Intel HD grahics.

Yeah this is crazy i didn't analyzed this yet fully and Jan did go more into it and says the stream is damaged @ those parts but i wonder why it is smooth here then even with the damaged parts though only on EVR (normal) and with Lav Video i doubt that intel interpolates frames here on the Renderer without knowing anything about the Stream @ all :P
This behavior of such damaged streams and scenes really interests me especially with motion blur coming into play and all this interlacing telecine going on and then even wrong flags, im really surprised that it playbacks smooth @ all :) though it does only @ the framerate the wrong flags are suggesting which is 24.30 fps (which would be obviously out of standard for a 32.976 telecine) and most decoder drive out to 38 or 48 and doesn't get the pan smooth which is somehow expected (especially for Hardware decoder) but in this case not efficient.
Though it could also be that my eyes where tricking with me because i watched the scene over and over maybe in the end they adapted so heavily to it that they themselves interpolated the pan :D

PS: Nope not my eyes it really works adaptively on EVR but only if Lav Videos Interlace flag sending is disabled and on EVR (normal) the impact on real Interlaced Streams seems 0 which seems to make this option kinda useless.
Ok the only thing that gets lost this way seems to be Double Framerate deinterlacing but it seems easier to implement a button for this and keep the damaged ones correct in the first place then to insist always on 2x (smooth) Deinterlacing :)
Or do it the other way disable Interlace flag sending on the go and leave the decision to the Renderer if you realize a problem (shortcut) and done (though i would prefer the other way and send the interlace flag only when needed to get for example 25i->50p instead of 25p or 30i->60p instead of 30p)
Though this needs to be implemented in the Player directly and Player and Filter need to communicate for this, also the smartest way would be a fully adaptive way which doesn't need any flags @ all ;)

I guess a Soc based on http://www.hqv.com/index.cfm?page=tech.cadence would have no real problems getting this wrong flaged stream right and @ the same time do full 60p deinterlacing with another stream ;)

[nevcairiel]

If you turn the send interlaced flags option off in LAV Video, it really doesn't stop sending those flags, it just doesn't set it in the media type anymore - but the individual frames are still flagged.
EVR-CP stops deinterlacing completely then, resulting in obvious combing on interlaced streams. I didn't test plain EVR, maybe it still deinterlaces, who knows.

The problem here is that the stream is actually progressive, but somehow coded as interlaced, causing these totally weird issues.

[CruNcher]

If you turn the send interlaced flags option off in LAV Video, it really doesn't stop sending those flags, it just doesn't set it in the media type anymore - but the individual frames are still flagged.
EVR-CP stops deinterlacing completely then, resulting in obvious combing on interlaced streams. I didn't test plain EVR, maybe it still deinterlaces, who knows.

The problem here is that the stream is actually progressive, but somehow coded as interlaced, causing these totally weird issues.

Yes i wonder why, is Renderer based deinterlacing (Hardware Vendor supplied) not supported with a Custom Renderer @ all or is it done on purpose or does Microsoft doesn't allow it or does Intel,Nvidia and AMD need to support it on the Driver side ?
And yes Deinterlacing (EVR normal) works for every interlaced file i push @ it with Lav Video but only the 1x Deinterlacing no Double Framerate that works only if the interlace flag is being enabled.

[nevcairiel]

EVR-CP supports hardware deinterlacing, you just need to keep the flag checked.

[CruNcher]

Yes but why does it work on EVR normal without a flag then ;) ? and the obvious cool thing about it that you can even push it wrong streams it will do them right (not with every Decoder though it seems) which EVR-CP fails because it needs the flag to deinterlace anything @ all and wrong flaged streams then go hi wire ;)

If Intels Hardware should do the work here perfect why not leverage this and build the whole playback behaviour around it (not sure though how Nvidia does in the same scenario) :)

And if they can decide where it works via the Driver we should push them to support also Custom Renderer like EVR-CP :)

[ikarad]

Can you upload a 200-500mb sample for test.

Have you see example and find the problem?


Here
http://www.zshare.net/download/943243170ecd3dc9/


added at bug report
https://sourceforge.net/apps/trac/mpc-hc/ticket/48#comment:20

At 13seconds, with ffdshow the subs "the fourth wave of ennemy photon torpedoes is approchaing!" is displayed. With mpc-hc the sub is not dispayed.

[Aleksoid1978]

Have you see example and find the problem?

Yes - i see. But - if open and play video, a see subtitle at 13 second, as and with ffdshow. Subtitle show on 1 second - with ffdshow too.

[gommorah]

Hey guys,

Have any of you had a chance to check out my ticket (https://sourceforge.net/apps/trac/mpc-hc/ticket/1712) yet? I'd like that patch to make it into mainline VSFilter if at all possible.

[roytam1]

I wonder if this VSFilter patch be applied to the tree?
http://direct264.svn.sourceforge.net/viewvc/direct264/Patches/vsfilter_3697.patch?revision=392&view=markup

VSFilter:
1) Supports NV12 and NV21 color space in DirectVobSub and CSRI interface.
2) New interface csri_add_file.
3) Use BT601/BT709 matrix based on resolution.

[ikarad]

Yes - i see. But - if open and play video, a see subtitle at 13 second, as and with ffdshow. Subtitle show on 1 second - with ffdshow too.

this sub ""the fourth wave of ennemy photon torpedoes is approchaing!""? With mpc-sub it is displayed and disappeared immediately. With ffdshow it displayed normally

I try since two years with all version of mpc-hc and it has never function (I had ask to casimir 666 to add support of bluray sub. He began to work upon but he had arrested before correcting all the bugs. Casimir have seen the problem but he said that he hadn't the time to correct (he started to work upon the support of dxva)). With ffdshow it works since the support of hd subs by albain.

example
with mpc-hc sub renderer at 13seconds
http://nsa28.casimages.com/img/2011/09/10/mini_110910043545939218.jpg (http://www.casimages.com/img.php?i=110910043545939218.jpg)
video here: http://www.zshare.net/video/944028910121c37b/


with fddshow sub renderer at 13 seconds
http://nsa28.casimages.com/img/2011/09/10/mini_110910043803690303.jpg (http://www.casimages.com/img.php?i=110910043803690303.jpg)
video here: http://www.zshare.net/video/94402815ee4780d4/

bugtracker
https://sourceforge.net/apps/trac/mpc-hc/ticket/48#comment:22

If you want, I can upload anew 3gb example in bugtracker because between 7minutes and 9 minutes there are many other examples of this problem.

edit: I succeed to give you 2 min showing many problems with sub renderer with mpc-hc. Video take 500mb and I will give you tomorrow.

[JanWillem32]

A 3 GB sample is probably illegal to share. To be on the safe side, and to have a much smaller sample, can you try to demux the subtitles with eac3to, for instance?
http://forum.doom9.org/showthread.php?t=125966
The command line syntax is: eac3to sample.m2ts 3:track3.sup 4:track4.sup
I assume you want to use the same video as your previous sample? To select only one of the two subtitle tracks, you can also specify only "3:track3.sup" or "4:track4.sup".
We can easily test these subtitles with any kind of dummy video.

[nijiko]

General
ID : 31337 (0x7A69)
Complete name : I:\***.ts
Format : MPEG-TS
File size : 11.4 GiB
Duration : 1h 54mn
Overall bit rate : 14.4 Mbps

Video
ID : 256 (0x100)
Menu ID : 1024 (0x400)
Format : MPEG Video
Format version : Version 2
Format profile : Main@High
Format settings, BVOP : Yes
Format settings, Matrix : Custom
Format settings, GOP : M=3, N=15
Codec ID : 2
Duration : 1h 54mn
Bit rate mode : Variable
Bit rate : 13.5 Mbps
Maximum bit rate : 24.0 Mbps
Width : 1 440 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 29.970 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.290
Stream size : 10.8 GiB (94%)

Audio
ID : 272 (0x110)
Menu ID : 1024 (0x400)
Format : AAC
Format/Info : Advanced Audio Codec
Format version : Version 2
Format profile : LC
Muxing mode : ADTS
Codec ID : 15
Duration : 1h 54mn
Bit rate mode : Constant
Bit rate : 140 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Delay relative to video : -94ms
Stream size : 115 MiB (1%)


MPEG Spliter 1.5.*.* can not play this file well.
AAC is broken for playing.
But MPEG Spliter 1.0.0.5 in Gulik project has no problem.

BTW, all MPC series players, such as potplayer, kmp, also have the same problem.
Non-MPC series, such as VLC, splash, is fine.

Haali MPEG-TS can play well before 1:40:00,
after that will be mute.

After reporting, PotPlayer is work correctly with these clips, but now there is still problem with MPC-HC.

[Aleksoid1978]

After reporting, PotPlayer is work correctly with these clips, but now there is still problem with MPC-HC.

As i say - give a sample to test, no another way to detect problem.