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

[kirakami]

when will next mpc-hc stable release?

[Keiyakusha]

when will next mpc-hc stable release?
This is depends on what do you mean by "stable" and why you need it at all. MPC-HC's stable releases are no different from svn builds, some of the old ones was even more buggy due to bugs fixed after release.

[kasper93]

When I load unstyled (microdvd) subtitles then it should inherit default style and everything seams to work good, but I wonder why subtitles goes smaller and little lower when I set view->subtitles->default style? It supposed to be same style so why it is different?
I know that my English is not as good as it should be so to help you understand:
default style off (http://dl.dropbox.com/u/16282309/MPC-HC/defstyle.off_.png)
default style on (http://dl.dropbox.com/u/16282309/MPC-HC/defstyle.on_.png)

Second bug also related to "default style". It overwrite style of styled subtitle nicely but border is thicker than that with unstyled subtitles.

[boyumeow]

@kasper93,
Couldn't be sure I'm answering correctly for U, but "default style on" would use what MPC-HC has set, while "default style off" would use what format/code the subtitles is written as.

Same as U, my English is not as good as to help U understand :p. And I don't feel ashamed by it, cause I use it to interact with people who could not understand my language and I don't speak their language. Thanks.

[DzigiBau]

Small question.

Since I fight intensively with eventual tearing or judder with panning scenes when watching ripped materials, I found out that movies play very fine in RGB32 mode, which is obviously not an DXVA mode.

When I switch decoder to DXVA, FFDshow or MPC internal decoder, output goes to NV12 where all problems appear again.

The questions here is how to improve playback in NV12 mode, which has problems with panning scenes when it plays little bit slower. With panning scenes I mean situation when camera moves from left to right, playback starts to be slower then normal.

I use ATI 5770 card on quadro processor system.

[namaiki]

If you are on Windows Vista or newer do you have Aero enabled? Try enable it though that will and won't help if you have multiple monitors.

Since I fight intensively with eventual tearing or judder with panning scenes when watching ripped materials, I found out that movies play very fine in RGB32 mode, which is obviously not an DXVA mode.

[hoborg]

Hi.
I am not sure what can be wrong with this sample (http://hobring.esero.net/saf/samples/dxva_green_screen_sample.zip), but if i use DXVA decoder, it will produce green screen. SW decoder working good (some pixelation on begin).
If i use PDVD 11 decoder in DXVA mode, it will play it just fine - no pixelation.

[jackbluray]

blu-ray subtitles are displayed not correctly. They disappear too fast. With ffdshow it works very well

file here
http://www.megaupload.com/?d=24ZO2T1Y

bug tracker
https://sourceforge.net/apps/trac/mpc-hc/ticket/1907

[DzigiBau]

If you are on Windows Vista or newer do you have Aero enabled? Try enable it though that will and won't help if you have multiple monitors.

Forgot to tell. I use Windows 7, with Aero on, all the time.

I thing the problem is with something wrong in NV12 output, needed for DXVA or better said, it could be improved to some point like it playback near to RGB32 which is excellent but without DXVA.

Another one. When I use FFDShow, it crashes randomly, with and without DXVA, when MPC-HC says something like »Faid to load (something)« on the place where it is written »Playing« but it disappears to quickly to see what is exactly written there. When it happens MPC-HC minimizes itself, meaning that I need to double click it again to get into Full Screen mode again. Could someone tell me what is wrong or how to solve this one.

[ADude]

This is depends on what do you mean by "stable" and why you need it at all. MPC-HC's stable releases are no different from svn builds, some of the old ones was even more buggy due to bugs fixed after release.

What about the most recent stable one 1.5.2.3456 ?

Does anyone remember any nasty bugs fixed right after that release ? :D

[Keiyakusha]

What are you trying to say? There was plenty of fixes. That's why I asked what one understands by "stable". This term can't be applied to such opensource project to begin with. But from my point of view "stable" is a something feature-complete and bug-free. By feature-complete I mean that all features that already there are doing the best of what they actually can. At this point comes release, and new features are added to the trunk (or was already added in branch). Again from my personal point of view stable mpc-hc is possible after: works on EVR is completed/tested/integrated, decoders/splitters replaced, translation engine (or how i should call it?) rewritten, subtitle rendering engine updated, obsolete stuff removed (like any renderers except EVR-CP and madvr.), maybe something else that I forgot.

[ADude]

The way a stable release is supposed to work is that at a certain point, you stop adding new features and then fix any existing bugs until there are no more. Since MPC-HC does not have accountants who are demanding that it be released before it is ready ;), then there should be no problem in waiting until that is accomplished.

In contrast, what you have proposed is just more and more features. Stable is about fixing bugs...

[Keiyakusha]

Features that I mentioned are not really new. Work on them was already started, more or less. But sadly there isn't much progress. Without completing these you won't see real bug/usability fixes except the ones like "this entry in that menu was moved 2px up so you can better see the entry below" (I just made up this example).

[XinHong]

Hi,
I can't choose the nvidia card for MPC-HC, the option is greyed. If i am looking inside the H264/DXVA filter properties it's Intel HD Graphics instead of nVidia.

System : Dell XPS 15z with optimus, 285.62 drivers

http://nsa22.casimages.com/img/2011/12/25/111225114727895855.png

[vivan]

Rename mpc-hc.exe to something else and add it manualy...

[XinHong]

Rename mpc-hc.exe to something else and add it manualy...

It's working, thanks

[JanWillem32]

@DzigiBau: That initial (short) error could mean that the selected video renderer failed and the filter graph reverts to another renderer in the list. If this is the case, the "Play", "Filters" menu will list a different video renderer than the one selected in the "View", "Options", "Playback", "Output" tab. (It could also be the audio renderer or another filter, but that's a bit rare.)
Tearing and judder have been quite an issue for years now. The situation is different across operating systems, settings and even individual computers. I've been trying to integrate a new EVR CP+VMR-9 r. renderer core into the player (and change some extra things here and there to make it work). While some fixes and features worked the moment I wrote them, tearing and judder have remained difficult to deal with. I've worked on quite a few renderers and worked on other software too, but to put it mildly: the VSync code has the worst methods and code I've ever dealt with and has been frustrating me since the moment I started working on it. The only reason I never completely scrapped it, was because I have no alternative function for usage in the windowed mode without Aero.
Luckily, for the windowed mode with Aero and the exclusive mode, I've had some success with some new functions. It did take some effort to get the original parts of the VSync code as an optional module of the renderer, instead of its heavily integrated former state (breaking its functionality a lot of times in the process).
If I ever get the DirectX 11 renderer in a working state (I cant get a mixer to work, unfortunately), I will most certainly not add any of the original scheduling and VSync code.
To get to the point of why RGB-like input could be processed faster than other Y'CbCr types with an AMD/ATi card (probably the main part of your problem):
- The conversion logic in the mixer from Y'CbCr to RGB takes processing. This one is actually negligible, as it's a mere bilinear or nearest neighbor 2× scaling on the chroma channels and a basic matrix multiplication on to get RGB out of Y'CbCr. Doing that efficiently on even a lowly DirectX 9.0 level GPU is easy. Doing that just as efficiently on a CPU is possible, but I guess most programs are not ready yet to set a CPU with SSE4 extensions (2007 level) as a requirement...
- None of the EVR mixer filters work on RGB-like input. The AMD/ATi driver enables all video "enhancement" filters with every install. These filters are very expensive when processing video. Disable all of them (except deinterlacing and pulldown, as those won't activate when not needed) and select your own set of filters, after you've seen the "neutral" state of the video renderer in action. Note that the player's "own" color controls are a duplicate of those in the video card's control panel. (Those also doesn't work on RGB-like input.)
- DXVA specific: the driver sets a medium GPU clock speed specifically when DXVA is used, as opposed to 3D clock speeds when software decoding is used. In my case (HD4890) it's 500 MHz in DXVA mode and 850 in 3D mode by default, but I override those with ATi Tray Tools program profiles I made to suit either a '720p' or '1080p' mode.
Reasons to not use RGB input:
- The transport of 'RGB24' or 'RGB32' textures take 24 and 32 bits per pixel respectively. That's a lot more than NV12 at 12 bits per pixel. (The impact of this is a lot less than what it used to be, thanks to better handling of large chunks of data over PCIe buses as opposed to AGP/PCI and older.)
- Converting Y'CbCr to RGB is lossy. The mixer can do a much better quality conversion than is available in 'RGB24' or 'RGB32' when the renderer is set up to use 10-, 16- or 32-bit surfaces.
- EVR-specific: the EVR mixer can sometimes make a mistake when it's given converted RGB input. It will output a black screen or rainbow colors in that case.
I only advise to use RGB input for the mixer if it's not converted, such as with a BMP file through the Windows still image filter. In the case of video, just use the appropriate 4:2:2 or 4:2:0 Y'CbCr format the mixer can natively work with (NV12 for 4:2:0 input video and YUY2 for 4:2:2 input video).
I do still intend to make a new mixer module besides the modules that load the external EVR and VMR-9 mixers, to extend support of surface types and have control over the rendering stages in the mixer. Unfortunately, I haven't figured out how to make one, and there are no developers to help with this.

Next up was the discussion about stable releases...
MPC-HC has a lot of code, from a lot of features and sources. A lot of it isn't ideally written to say the least. There's a lack of comments, debug-mode tests for things that could go wrong (even silently) and structuring in the code. This makes it hard to work with some parts. When I started working on the internal renderers, I soon realized that everything required refactoring of the code to make it proper and maintainable. I've done that, and now I can't even patch in features I've written into the original renderer code at all (the entire files are different).
Other developers will probably recognize such an issue.
Of course, new code isn't always perfect immediately and will need maintenance later on. But most patches for bugs I've seen are for old code. The notion of adding features to a program leads to potential bugs might be true, but from a developer point of view, having to deal with the bugs in (newer) code with plenty of comments, tests and decent structuring is a whole lot less of a hassle than performing maintenance on old code.
In my opinion, every fix and every new feature that may or may not directly enhance user experience, but does have proper code is an improvement. As the stable release builds and even versioned beta ones are usually a few revisions behind nightly test versions (even on the day of release), those are considered more stable, and more suitable for the "standard" user. Yet, when bugs/questions arise, it's common to just redirect to a (newly made) nightly build and let people try again. For this and many other ongoing projects, a stable or beta is a build with a bit of an extra hassle to get ready.
Feedback on changes in nightly builds is more interesting to me (even for the parts I didn't write myself).

[DzigiBau]

@JanWillem32

Thank you for your excellent explanation.
If you find a time, would you clarify for me two quick things.

1. You suggest using Y'CbCr format for watching movies. No problem. What would you suggest to put in the ATI Catalyst options, My Digital Flat Panels, Pixel format:

- Y'CbCr 4:2:2
- Y'CbCr 4:4:4
- RGB 4:4:4 (limited RGB)
- RGB 4:4:4 (Full RGB)

2. I have ATI Tray Tool, also. What would you suggest to put in Overclock profiles for 720p and 1080p. Default values for my ATI 5770 card is 400MHz Core and 900Mhz for memory.

[JanWillem32]

Sure, not a problem.
1. That's the HDMI or DP output mode of the video card to the display.
Internally EVR CP and VMR-9 r. render in full-range RGB. If your display can be configured to properly accept full-range RGB, it's pretty straightforward.
Note that some devices default to some odd legacy-mixed-with-archaic limited range mode and can't recognize full range RGB automatically. Consult the OSD menu section of the manual of the device how to configure the input format in RGB mode of the HDMI or DP inputs.

I've never seen any proper documentation of what kind of signal should be output in limited RGB mode. The only proper references I ever found were voltages for transporting limited range/studio RGB signals to analog CRT TV's trough BNC connected systems.

The two Y'CbCr modes are produced by the display driver ordering the video card to do a color conversion on everything the renderer outputs. Many consumer TV's can't properly deal with RGB input (in various gradations, with various issues), that's what the two Y'CbCr output modes are for.
The two Y'CbCr modes are the same in the luma (grayscale Y') channel, the 4:2:2 type has half-width, full-height color resolution in the chroma (Cb and Cr) channels compared to full-width, full-height with the 4:4:4 types.
(For completeness: 4:2:0 has half-width, half-height chroma resolution, and is the most common sub-sampling type with consumer-grade video sources. Chroma is typically resized to full video size by the video renderer.) A small note: the 10-bit display output option can't work on HDMI v1.0 to v1.2 connections, for HDMI v1.3 only RGB and Y'CbCr 4:4:4 formats support it, and not all HDMI v1.4 support it for the Y'CbCr 4:2:2 mode.

What I mostly meant by my previous post was:
For the chain to the renderer from the decoder, the format should be NV12 for most videos in your case (it's a native representation of how unconverted color data comes out a common 4:2:0 video image). A DVB stream is sometimes 4:2:2 natively, YUY2 is used by default to transport that (it's pretty rare, though). A Windows .BMP file loaded with the still image filter will output RGB24 or RGB32 to the renderer (this is usually without any decoding at all).

2. ATi tray tool has a performance graph function to see GPU utilization in real time or with log files. In my case, I need less than the idle 240 MHz to render 1080p with the renderer in its most neutral state. Because I like to add filters and enable a few options, I overclock it to above stock 3D clocks on the heaviest videos (deinterlacing is expensive, for example). It's not very hard to profile, and doesn't need much precision. Do keep a bit of extra overhead for heavy scenes (to avoid lagging frames).

[markanini]

I've got a DTV Tuner scan problem. The scan misses some channels that the included Presto PVR software finds. The channels in question have excellent reception in Presto. I get some error messages when the scan is searching the frequency, not sure if that's related to my issue of if it's due to the firmware upgrade "channels" that share the frequency.

[sialivi]

I believe I read the LAV Audio is required for video files with PCM audio tracks. Is this something that's planned to be supported internally? If not, what's preventing this?

[clsid]

@Aleksoid1978
I noticed you updated Libav with some modifications for H.264 MBAFF. Did you notice any problems with ffdshow as well, or was it just with the MPC internal decoder? The MBAFF samples I have here seem to play ok with ffdshow.

[Aleksoid1978]

@Aleksoid1978
I noticed you updated Libav with some modifications for H.264 MBAFF. Did you notice any problems with ffdshow as well, or was it just with the MPC internal decoder? The MBAFF samples I have here seem to play ok with ffdshow.

It's problem in libav part and ffdshow also have this problem.
sample - http://aleksoid.tosei.ru/Test/Sample/Blind_Fury.m2ts

Try in software mode - we have low fps.

[shadewither]

I'd like to know how MPC-HC's color management work under windows ICM 2.0?
(Actually I have no idea how windows ICM 2.0 works)

0. Not related to MPC-HC, for a plain D3D device:
0-1. Does windows assume it's linear and apply (only) device-profile? Or it's possible to set profile (or customize transform) on D3D device?
0-2. Is there any difference between windowed/windows Aero/exclusive? Is there any difference between vista and 7?

1. Let renderer = EVR CP in MPC-HC:
1-1. Is there difference between EVR CP and plain D3D surface?
1-2. Does MPC-HC CM work by pre-compensating ("user settings" - "windows icm settings")? (If so, is "windows icm settings": device-profile, system default profile, or sRGB?)

[ageback]

rev.3923
x64 build failed.

1>ZenLib.lib(Ztring.obj) : error LNK2005: ldexpf has been defined in libmingwex.a(lib64_libmingwex_a-ldexpf.o)

[Aleksoid1978]

rev.3923
x64 build failed.

Yes - i know, fix later.

[JanWillem32]

@shadewither:
0: Windows ICM Will set gamma tables to the device once a color profile is installed for the device that includes gamma tables. Many profiles don't contain such data, those only have color transformation data. The gamma table remains linear for those. (My own working colo profles lack gamma tables as well.)
Depending on the device context you use, SetDeviceGammaRamp or SetGammaRamp can be used to manually apply a gamma table as well (not implemented in MPC-HC):
http://msdn.microsoft.com/en-us/library/ms536529
http://msdn.microsoft.com/en-us/library/windows/desktop/bb174434%28v=vs.85%29.aspx
Next, there's the color transformation data in the profile. It's at every individual program's discretion to request this data and use it to set up transformations. This part is implemented in EVR CP and VMR-9 r..
From Windows XP SP2 and up these functions are implemented. The status for Aero on or off and exclusive mode do not influence these.
Note that DirectX 9.0 compliant devices do not have to support gamma tables internally. I don't know if those actually exist, though. I do know that many multihead video cards can only support one gamma table, even if multiple display devices are attached. So, beware of that issue and test for correct functionality when using multihead. Using multiple color profiles without gamma tables will of course still work properly for such a case.

1-1: The EVR mixer in EVR CP uses a regular DirectX 9 device to render, so D3D render target surfaces are indeed used internally. The custom presenter part is in essence the base DirectX 9 device creator, and also handles the raw output from the mixer. It's pretty much the same case for VMR-9 r. on the VMR-9 mixer.

1-2: The renderer loads the color profile associated with the device. When none are found, the version in the trunk build will silently revert to a sRGB profile. In the version I edited, a fatal error is reported in such a case. For generating a 3D (RGB to RGB transformation) lookup table, the little CMS engine is used. This table is used to transform the output colors from the last few rendering passes to display-specific colors, just before the optional, and final dithering filter pass. (If gamma tables are loaded on the device, all colors are implicitly transformed a second time by the video adapter just before display output.)

[shadewither]

Thanks for the explanation.
One more question:
@shadewither:
(If gamma tables are loaded on the device, all colors are implicitly transformed a second time by the video adapter just before display output.)
Is this implemented in windows, or delegated to display driver?

[JanWillem32]

It's an optional part of the hardware natively in the video output port controller. Some profiling softwares create profiles with embedded gamma tables, others don't. The gamma tables are supposed to be continuously active on the output controller, as the color transformation data is supposed to transform the data "on top of" the gamma tables. The color transformation data has no embedded data to be able to transform without the gamma transformation after its own filer pass with such profiles.
The Windows color system will activate a gamma table once a profile is loaded during boot time of the system (or when it is set by an event).
The advantages of profiles with embedded gamma tables are:
-The gamma transformation itself doesn't really take much hardware resources.
-Programs without internal color correction will have basic gamma correction.
The main disadvantage of doing a double color conversion is clear:
-The gamma transformation is of lower quality than what larger lookup tables can provide. This is especially the case with the implementation in MPC-HC, where the dithering pass is applied after the color lookup. Applying a second color conversion will degrade the dithering quality (just like any other digital filter that acts on the color data after dithering, even those implemented inside the display device itself).
-Using the gamma tables doesn't lower the processing cost of doing a high-quality color conversion in applications that can load color profiles at all.

[Aleksoid1978]

rev.3923
x64 build failed.

Fix at rev.3930

[shadewither]

It's an optional part of the hardware natively in the video output port controller.
...
The Windows color system will activate a gamma table once a profile is loaded during boot time of the system (or when it is set by an event).
...
I see. Thanks for the detailed information (again).

So the only feasible approach for CM is still to rely on monitor built-in LUT and multi-profile support. Or not to bother with CM.

Windows ICM architecture still sucks badly. No one will ever need it.

[Mercury_22]

@Alexins Please help me :
your x64 "trunk" build and my x64 builds ("trunk" & BE mod) do NOT work correct with "CLOSE" (window close) command from a remote control
BUT your x64 BE MOD and any x86 versions mine or yours "trunk" & BE mod are working correct !

What did you change in the x64 BE mod that makes "CLOSE" (window close) command work correctly ? :helpful:

If anyone else knows the answer please let me know :thanks:

[alexins]

Mercury_22, tomorrow I can help you to solve this problem.

[Mercury_22]

Mercury_22, tomorrow I can help you to solve this problem.

Ok I'll wait :thanks:
Also maybe you can add this fix to the trunk please ! cause this is a BUG in the x64 trunk / official version and not a "feature" of the BE MOD since the x86 it's working correct but the x64 doesn't

[JanWillem32]

I see. Thanks for the detailed information (again).

So the only feasible approach for CM is still to rely on monitor built-in LUT and multi-profile support. Or not to bother with CM.

Windows ICM architecture still sucks badly. No one will ever need it.I wouldn't put it that way. The functions provided by Windows ICM work properly. Every application has different needs in graphics:
-A high quality color management mode, with a large lookup table that the application creates from the data in the ICM files. For this mode MPC-HC can create lookup tables from 2 MB (a 64³ volume texture) up to 128 MB (a 256³ volume texture) in video memory. The lookup takes processing and video memory. Most low-end video cards and IGPs can't handle even a simple lookup in real time. The "256³" option in MPC-HC is too heavy for even my video card to render in idle mode in real time.
For this mode, the presence of gamma tables in a ICM profile are more of a curse than a blessing. If I could program MPC-HC to only use its own lookup table, and unload the gamma tables while playing, I would have done that already. (Unloading the gamma table is easy, there's just no module that I know of in little CMS that combines both the gamma tables and the transformation data to one output, although both come from a single ICM file.)
-A performance mode, with only the optional gamma tables loaded, as this is a lot less demanding in resources than enabling a full color managed mode.

Also note that for Linux and Mac OS X these functions are implemented in exactly the same way. The systems only load gamma tables by default (if present), applications are responsible for more advance color management with the transformation data in the ICM/ICC files.

A monitor built-in LUT would be ideal, but because the renderer's output is rounded to 8-bit (10-bit RGB optional in exclusive mode though compatible analog, HDMI or DP connections), limited gamut, gamma-encoded RGB, it definitely isn't. (It's only because of the rounding step a dithering filter is present in MPC-HC at all.) The internal lookup tables in consumer-grade monitors are also usually very limited in size, compared to software or industry-grade hardware solutions.
For DC compliance in industry-grade hardware, a full signal path of at least 12 bits (for each of the 3 channels) in width is a requirement. The input signal is in a 12- or 14-bit (full gamut) XYZ colorspace. The color transformation to 12-bit (or more) RGB for the directly attached display controller never requires dithering. The rendering process usually takes place in a 16-bit integer fashion, but 32-bit floating-point is becoming more common in integrated systems, as well.
I would definitely like to see systems like that to become better within reach of the consumer and professional. The best I can do for now on the software side of things is creating a graphics rendering suite that never has to compromise by accuracy in gamut, in limiting bitness or provide support for legacy formats/hardware/software. The renderer in MPC-HC isn't quite up to par (yet). Aside from always having to work with abysmal input video quality, the many legacy hardware/software/formats support parts, lack of absolute control over its primary rendering target (the raw display panel input) and having filter+dither a lot for that reason, the EVR and VMR-9 mixers limit my options for better rendering. (I don't really like having to set the low quality, top performance mode as default in the MPC-HC rendering options, either.)

[JarrettH]

MPC hard crashes on DVD menus...the cursor will show the spinning time-out animation, menu music stops and the program will crash shortly after. I don't know if this is an MPC or madvr problem or how I can help solve it. I'm using ffdshow as the mpeg2 decoder, a GT240 with 275.33 drivers and Windows 7 32-bit

This is so frustrating, I can't even tell you the unimaginable amount of times it happen...8 out of 10?

[Hera]

You should be able to close the player when it D3D full-screen with the mouse.

[Px]

Bug in ass subtitle handling, if I set WrapStyle: 3, then lines with \N newline tag splitted incorrectly. Sub code example:

[Script Info]
; Script generated by Aegisub 2.1.8
; http://www.aegisub.org/
Title: Default Aegisub file
ScriptType: v4.00+
WrapStyle: 3
PlayResX: 640
PlayResY: 480
ScaledBorderAndShadow: yes
Video Aspect Ratio: 0
Video Zoom: 6
Video Position: 0

[V4+ Styles]
Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding
Style: Default,Comic Sans MS,30,&H002A3D3E,&H0000FFFF,&H00FFFFFF,&H803C5B5C,-1,0,0,0,100,100,0,0,1,3,2,2,10,10,20,204

[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:01.00,0:00:20.00,Default,,0000,0000,0000,,Значит, "хранить мир в школе" -\Nзадача Совета, да?
Dialogue: 0,0:00:25.00,0:00:45.00,Default,,0000,0000,0000,,{\fs24\c&H8893ec&}"Mai Hime" - дословно с яп. "Танцующая Принцесса".\N"Hi.M.E" - "Высокотехнологичное материализующее устройство"
When WrapStyle set to 0, sub text displayed in two lines, but with 3 they split to three (or more) lines, it looks like in mode 0 line wrapping occurs after dealing with \N tags, and in mode 3 - before, what is incorrect

[nevcairiel]

And i thought the ASS standard was basically defined by how MPC-HC/VSFilter renders it. :D

[Px]

And i thought the ASS standard was basically defined by how MPC-HC/VSFilter renders it. :D
Then it's time to revise the standard! :D
Anyway, Aegisub also affected, I post the message on forum a couple of days ago, but seems they still celebrating New Year :rolleyes:

[Juce]

Is it normal that bottom-field-first interlacing does not work with ATI and DXVA?

Sample: http://www.mediafire.com/file/v6syaag8znfw7wn/420i1920x1080ref04bff_crf25.mkv

Tested with MPC-HC 1.5.3.3936, Windows XP, HD5450.

[alexins]

All, check this build mpc-hc (http://www.xvidvideo.ru/clsid/out/mpc-hc.MPEG2.7z), as he works with mpeg2+dxva?

[Px]

All, check this build mpc-hc (http://www.xvidvideo.ru/clsid/out/mpc-hc.MPEG2.7z), as he works with mpeg2+dxva?
Working on Radeon 6950/Catalyst 11.12

[LigH]

How do I have to set it up correctly to check it?

I enabled the internal MPEG splitter, and the internal MPEG-2 DXVA video decoder, but not the internal generic MPEG-2 video decoder - then it does not use it for SD PAL video, but falls back to ffdshow. If I enable the internal generic MPEG-2 video decoder too, this one is used.

Are you possibly only interested in HD MPEG-2 video?

Windows XP SP3, GeForce 9600 GT, VMR9 Renderless

[Px]

GeForce 9600 GT
Doesn't have bitstream mpeg2 decoder...

[betaking]

Working on GTX 460/290.53.

[wanezhiling]

All, check this build mpc-hc (http://www.xvidvideo.ru/clsid/out/mpc-hc.MPEG2.7z), as he works with mpeg2+dxva?

Use DXVA Checker to ensure your GPU support ModeMPEG2_VLD

I really have a question: DXVA mpeg2 interlaced video couldn't double frame, I don't know why and whether it will return again?

[Mercury_22]

Mercury_22, tomorrow I can help you to solve this problem.
I've also create a ticket (https://sourceforge.net/apps/trac/mpc-hc/ticket/1938) for the "Window Close" bug so when you want you can post the fix either here or there :thanks:

[wanezhiling]

mpc-hc 1.5.3.3939 BE Mod (http://we.pcinlife.com/data/attachment/forum/201201/07/025556lilzydpp5mmj9hp1.jpg)

ArcSoft TMT5 (http://we.pcinlife.com/data/attachment/forum/201201/07/025557mci400619flmsfzu.jpg)

As you see, this chinese subtitle(PGS)"我問良心 為免孤獨誰都和親" appears at 00:00:30 when using mpc-hc, but at 00:00:25 by TMT5. 00:00:25 is right.

In fact the whole subtitles(PGS) cannot catch the video/audio by mpc-hc 1.5.3.3939..


The sample is here (http://www.gokuai.com/f/rd1VTE9qh67977s6),IDM is available.

[ryrynz]

Are there any goals left for 1.5.3? It would be nice to see more than one or two stable releases a year. Last release was on 22-July 2011, for software that has daily updates the full releases are looking pretty stagnant.