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

[JanWillem32]

If you're implying VSFilter is not handling subpixels or it's not doing anti-aliasing, that is incorrect. The following images show, left to right: 1) Not anti-aliased; 2) Anti-aliased, pixel-accuracy; 3) Half-pixel accuracy; 4) Quarter-pixel accuracy; 5) VSFilter (I think this is 1/8-pixel accuracy).My exact words were "really badly at". The pixel rendering kernel in the subtitle renderer merely does an extreme amount of supersampling on already badly truncated vertices. It can't hold a candle in regard to the initial sub-pixel accuracy of vertices, the configurabilty (think of ClearType, anti-aliasing levels and such) and the performance-to-quality ratio, compared to any of the other renderers I've seen.
The images you posted feature basic upright letters and the picture has a large contrast. Those are easy to render, and hides the 6-bit-at-best color rendering quite well. (The colors degrade even more if heavy grading of pre-multiplied alpha comes into play, and after the weird R'G'B'->Y'CbCr limited range conversion is used.)
The subtitle renderers are really not easy to edit. (Not only the vector renderers are odd.The bitmap-type renderers also do weird things.) The bad performance of the vector subtitle renderers is mostly due to sloppy programming and poor design choices. These two reasons are also the main cause of the awful rendering quality, which bothers me the most.
In the case of rendering SSA/ASS subtitles, there's also the factor of the color tags for the awkward R'G'B' format the standard calls for. For some reason a notation that only takes 256 levels of R'G'B' color and alpha was chosen, instead of a regular floating-point notation. This means that only few colors can be rendered at all, which is just a pity.

I've been trying to edit a few of the worst things where I could, but it's very hard. The double dependency of both VSFilter and the DirectX 9 allocator unit on the same subtitle renderers makes it a menace as well. I mostly edited the subtitle queue handler, SSE function implementations and editing the DirectX 9 allocator unit to clear it from bugs (or more commonly adding 'features' of the subtitle renderer) for the texture unit and color correction. It gained in quality and performance and I'm happy that that work paid off. It's just by far not good enough, though.

@MasterNobody: I'll give it a try. Thank you for reporting, though normally this should go on the bug tracker.

[cyberbeing]

Similarly, things should be tested properly before imported from xy-VSFilter
I agree, especially since xy-VSFilter is based on VSFilter 2.39.

For this reason, the tentative plan was to merge anything MPC-HC needed from VSFilter 2.41 into xy-VSFilter rather than the other way around. I still haven't forgotten xhmikosr's request to get the xy-VSFilter dev on IRC to enter discussions with the MPC-HC team. Unfortunately this became delayed longer than expected. For a long time the project was on haitus, and now he's pre-occupied with completing xy-VSFilter's side of the new subtitle interface designed with madshi and nevcairiel as a replacement for the MPC-HC ISR.


My exact words were "really badly at". The pixel rendering kernel in the subtitle renderer merely does an extreme amount of supersampling on already badly truncated vertices. It can't hold a candle in regard to the initial sub-pixel accuracy of vertices, the configurabilty (think of ClearType, anti-aliasing levels and such) and the performance-to-quality ratio, compared to any of the other renderers I've seen.
I completely agree. Some fonts display quite horrible aliasing when rendered by VSFilter, which in many ways mimics the native rendering of its GDI32 backend. The good news is the xy-VSFilter dev has been tentatively planning as a long-term goal to completely rewrite the rendering code and the rest of VSFilter as fully floating-point along with implementation of high quality anti-aliased font rendering.


I read somewhere that xy-VSFilter crashed just because you used a negative value between {\p1}...{\p0}, showing it's not very stable yet, though promising.
Do you remember where you read that, or rather how long ago? I'm not able to reproduce any crashes caused by negative {\p1}...{\p0} values, and I never remember receiving any bug reports about such. I'll need an example script, if there really is such a bug in the current versions.

[Liisachan]

Do you remember where you read that, or rather how long ago? I'm not able to reproduce any crashes caused by negative {\p1}...{\p0} values, and I never remember receiving any bug reports about such. What I read was: "Fixed crash when \clip runs out of video frame"
http://code.google.com/p/xy-vsfilter/wiki/ReleaseNotes?tm=6
It was not {\p1}...{\p0}, but {\clip(...)}. Sorry!

@JanWillem32
@cyberbeing
I'm really happy and excited to know that there are people who are actually trying to improve VSFilter. And yes! I have to agree, in general, with what you guys are saying (though I don't really know the technical details).

Just in case there is some renewed interest: I posted these to MPC-HC bug tracker while ago:
*#2460 ASS Shadow alpha is wrong if subtitles are overlapped in a certain way (http://sourceforge.net/apps/trac/mpc-hc/ticket/2460)
*#2461 \r in ASS can break "Position subtitle relative to the video frame" (http://sourceforge.net/apps/trac/mpc-hc/ticket/2461)

Both are very old problems for me, but a few years ago, it was like, people were like "Reporting a bug of VSFilter? You're wasting your time. No one is working on it." I didn't know the latest buzz at all, and am happy to hear about xy-VSFilter.

[sneaker_ger]

I think #2461 does not apply to stand-alone (xy-)vsfilter anyway, since it only works on the input by the decoder. But that is not the only problem with MPC-HCs renderer and the positioning IIRC. For example positioned subtitles, boxes, etc. would also overlap into the black borders.

[MasterNobody]

@MasterNobody: I'll give it a try. Thank you for reporting, though normally this should go on the bug tracker.
To which one? You still use one at sf.net? Anyway thx.

P.S. btw. Link "Bugs can be reported here" from first post doesn't work.

[JanWillem32]

The support readme: https://github.com/mpc-hc/mpc-hc#readme
The support tracker is still the same as it was indeed. For your sample, it doesn't crash for me. It only rarely throws an exception that the crash reporter catches. The video keeps playing for me. It's a bit hard to debug, but I'll try some more.

@Liisachan:
For #2460; A layer property is probably stored wrong. I don't exactly know where to look for this code. I generally don't touch the code that handles these sorts of things.
For #2461; I re-wrote the DirectX 9 texture unit in the renderer fixes builds. It seems to work for the sample.

By the way, in the picture you posted, the sample for "no anti-aliasing" shows pixel blur (with a strong ClearType tinting of red on the left). If I render fonts without anti-aliasing, absolutely no color blending occurs. Also, the color is different than the other samples. Do you have any further source information about this picture?

[Liisachan]

@JanWillem32
The first picture is drawn as SSA by VirtualDub's old plugin, called Subtitler, with the Advanced Rasterizer disabled. The last picture is drawn normally (as text) by VSFilter. The other pictures are drawn by VSFilter too, but as a path, as {\p1}...{\p0}, {\p2}...{\p0}, and {\p3}...{\p0} respectively. I'm on Win XP, with USP10 1.0626.7600.20602. It's just showing VSFilter is anti-aliasing, and (my guess is) it's internally equivalent to {\p4}...{\p0}. I didn't mean anything else.

EDIT: Wait, captions like "no anti-aliasing" are drawn normally on an image editor. They are not part of demo, but simply captions.

[cyberbeing]

*#2460 ASS Shadow alpha is wrong if subtitles are overlapped in a certain way (http://sourceforge.net/apps/trac/mpc-hc/ticket/2460)

xy-VSFilter doesn't exhibit this issue.

By the looks of it, the bug was inadvertently fixed in xy-VSfilter's October 30th 2011 build, and has never resurfaced since.

[Pulstar]

I still can't figure out the 10bit option under Presentation. Using stats the output is still 8bit, even if it is forced, and no decoder can output 10bit through EVR(CP) at all. Is there a point to enabling it? 10bit sources are seldom seen, and madVR is overkill for my needs.

[JanWillem32]

The 10-bit output is a renderer feature, independent from video source. (The renderer can operate without video input as well, and output in 10-bit.)
Requirements for this feature:
-operating on Windows 7
-AMD Radeon/FireGL X1??? generation video card or newer, using a D-Sub analog (verified), HDMI (verified) or DP (no reports yet) connection, or one of the enabled Nvidia Quadro video cards since 2007 with a DP connection (no reports yet), I don't have information on Intel GPUs and 10-bit output capability yet
-D3D fullscreen exclusive mode enabled
-a display that will accept the 10-bit RGB signal (Note that the options for the Y'CbCr and 'limited range'/'studio range' RGB formats in the video card configuration panels force conversion of the pictures after the renderer, which degrade the image. Only full-range RGB formats are available for the renderer to output. Trying to output natively on a surface in a Y'CbCr format for display output has not been successful yet.)

[gilic]

-AMD Radeon/FireGL X1??? generation video card or newer, using a D-Sub analog (verified), HDMI (verified) or DP (no reports yet) connection

I can confirm that 10bit output over displayport works (for me) under statistics display says A2R10G10B10.

[Pulstar]

Ah yes, it works now, though the D3D option is a bit inconvenient. Cheers!

Edit - Actually it doesn't. Setting output to P010 in ffdshow just crashes the player, and using internal filter the output is NV12.

[ajp_anton]

What can I do to always automatically move a fullscreen video to the very top to give more space for subtitles in the bottom black bar (so they don't overlap with the movie so much)?

[Mikey2]

Can anyone please help with this problem I Have been having for a long time?

Basically, my "mpc-hc.ini" file very often gets corrupt. Whenever I save anything from the "options" menu, MPC freezes for 10-30 seconds. It took me a while to see that in Windows explorer it is rebuilding "mpc-hc.ini". (I can see the file-size go up from 0 to the current size of 254 KB.) If I do anything, stop anything, open another instance of MPC, etc while it is re-building this file, it stops right there, leaving me with an uncomplete ini file.

I'm a software engineer, so I can get pretty technical, but it seems to me that in order to fix other possible defects that MPC is rebuilding the entire ini file needlessly (often nothing changes at all...You can reproduce the problem by selecting "Options" then simply pushing "OK.")

Thanks in advance for any help. (And let me know if I can do anything to help!) This initially was just an annoyance, but it is getting real bad now...

Oh currently I"m on version 1.6.4.5881 (2196459) - however, as I mentioned, I have had this issue for as far as I can remember. (Although I think it is getting worse as new options are added in subsequent versions.) I'm also on Windows 7 x64, but I also noticed this on my 32-bit Windows 8 laptop.

thanks again,
MikeY

[Pulstar]

What can I do to always automatically move a fullscreen video to the very top to give more space for subtitles in the bottom black bar (so they don't overlap with the movie so much)?

Use the numpad keys to shift the picture in any direction you want. You can also untick the "Position subtitles relative to the video frame" option under Default Style.

[Tiduz]

edit: problem solved.

[ajp_anton]

Use the numpad keys to shift the picture in any direction you want. You can also untick the "Position subtitles relative to the video frame" option under Default Style.Well, that's not really automatic, and it will rarely align perfectly with the top, but I guess it's better than nothing (once I remap the keys to my laptop keyboard).

[pulbitz]

It is deblocking problem.
Other decoders are the same condition.
Anyway I turn it off and caputre.

mpc-hc_dxva_decoder_does_not_deblocking.jpg:http://imageupload.org/thumb/thumb_224108.jpg (http://imageupload.org/en/file/224108/mpc-hc-dxva-decoder-does-not-deblocking.jpg.html)
other_decders_are_OK.jpg:http://imageupload.org/thumb/thumb_224109.jpg (http://imageupload.org/en/file/224109/other-decders-are-ok.jpg.html)


Edit:
ffdshow_libav_skip_deblocking_always.jpg:http://imageupload.org/thumb/thumb_224112.jpg (http://www.imageupload.org/en/file/224112/ffdshow-libav-skip-deblocking-always.jpg.html)
I have compared between MPC-HC H.264 DXVA decoder and 'skip deblocking always' in ffdshow libavcodec.
They are same quality.

bump.
Not yet fix. (MPC-HC H.264 DXVA decoder doesn't support deblocking for Intel HD Graphics)

sample.flv
http://www.sendspace.com/file/xdrg1y

[JanWillem32]

Edit - Actually it doesn't. Setting output to P010 in ffdshow just crashes the player, and using internal filter the output is NV12.The EVR and VMR-9 mixers require support from the video card drivers to handle formats. The Y'CbCr formats supported by all reasonably modern video cards are: NV12 (8-bit 4:2:0), YUY2 (8-bit 4:2:2) and UYVY (8-bit 4:2:2). Nvidia also added YV12 and I420/IYUV (both 8-bit 4:2:0) support. It's not likely that newer drivers will support more formats anytime soon. Equipping the renderer with a custom mixer that supports additional formats is possible, but creating a custom mixer would require quite a bit of programming work.

[GrofLuigi]

Can anyone please help with this problem I Have been having for a long time?

Basically, my "mpc-hc.ini" file very often gets corrupt. Whenever I save anything from the "options" menu, MPC freezes for 10-30 seconds. It took me a while to see that in Windows explorer it is rebuilding "mpc-hc.ini". (I can see the file-size go up from 0 to the current size of 254 KB.) If I do anything, stop anything, open another instance of MPC, etc while it is re-building this file, it stops right there, leaving me with an uncomplete ini file.

I'm a software engineer, so I can get pretty technical, but it seems to me that in order to fix other possible defects that MPC is rebuilding the entire ini file needlessly (often nothing changes at all...You can reproduce the problem by selecting "Options" then simply pushing "OK.")

Thanks in advance for any help. (And let me know if I can do anything to help!) This initially was just an annoyance, but it is getting real bad now...

Oh currently I"m on version 1.6.4.5881 (2196459) - however, as I mentioned, I have had this issue for as far as I can remember. (Although I think it is getting worse as new options are added in subsequent versions.) I'm also on Windows 7 x64, but I also noticed this on my 32-bit Windows 8 laptop.

thanks again,
MikeY

I have never seen anything like that (in the sense that MPC-HC is doing it), and I work on multiple computers/OS-s, often comparing the .ini-s and sorting the sections. If I change one option, only that option is written. There are some sections that MPC-HC likes to sort in its own way, and they aren't rewritten when I just visit the Options page(s).

I think in your case it might be caused by virus/antivirus or UAC File System Virtualization (http://windowsteamblog.com/windows/b/developers/archive/2009/08/04/user-account-control-data-redirection.aspx).

GL

[Liisachan]

Whenever I save anything from the "options" menu, MPC freezes for 10-30 seconds. It took me a while to see that in Windows explorer it is rebuilding "mpc-hc.ini". (I can see the file-size go up from 0 to the current size of 254 KB.) This is just a guess, but it may have something to do with this line in mplayerc.cpp.

bool CMPlayerCApp::ChangeSettingsLocation(bool useIni)
{
...
// In case an ini file is present, we remove it so that it will be recreated
_tremove(GetIniPath());
AFAIK, the original intention of the above is, if the current .ini file is in ANSI, it will be deleted once and recreated as a Unicode (UTF-16LE) file so that a "Unicode" path can be stored in .ini (eg file names in Spanish and in Chinese at the same time).

[cremor]

Is the automatic loading of subtitles broken in 1.6.3? I remember that it used to work fine but I can't get it working now. I'm playing an avi file and the subtitles are in a "Subs" subfolder in idx/sub format.

Automatic loading of subtitles is enabled and the subtitle search path is using the default value.

[Mikey2]

Thanks for the responses re: my problem is simply that MPC-HC is rebuilding the ini file each time anything changes..


Re: anti-virus, I tried MSE, NOD32, and none at all. It doesn't seem like it is making anything "dirty" on that end since it is rebuilding the file.

That line of code looks exactly like what I think is happening! But why is it being called ever-time? Could there be something wrong with my ASCII/Unicode defaults? I know that on my system I have had several problems with this, from Notepad++ working differently depending on the type to My SQL Server stored procs for my other development activities always needed to be changed to ANSI.

I'm not home now but I'll play with procmon when I get home.

EDIT: Taking the simplest recreation steps, I did the following:
1) Open MPC-HC.
2) Close MPC-HC.

For this scenario, ProcMon is showing approximately 102,061 event lines that touch the mpc-hc.ini file! (18,268 Opens, 18,268 Closes, 11,741 Reads, 2,472 Writes, 132 Get ACL, 51,180 Other )

EDIT2 (back home now on the problem computer): I notice in Notepad++ that MPC-HC creates the file encoded in "UCS-2 Little Endian." When I try to re-save the file in ANSII or UTF-8, I MPC-HC rebuilds it back to UCS-2 Little Endian. (BTW the "rebuild" takes about 5 seconds, during which time MPC-HC is unresponsive.)

Edit3: Actually can you point me out to that part of the source code? I'd like to see what is calling that function. Inferring from the name of the method, it looks like it may also be called when MPC thinks it's storing the ini file to a different location. Again I'll have to check when I get home, but perhaps my shortcut is pointing to a virtualized path (e.g. libraries) and it is getting confused thinking it is in a different place each time.

Thanks much in advance.
MikeY.

[Mikey2]

Is the automatic loading of subtitles broken in 1.6.3? .

Subtitles still work for me. I usually put it in the same directory, rename the file to the same as the mkv/avi and select "prefer external subtitles..." Also, if you're putting them into a subfder, make sure to include the subs\ relative path in that list. Finally, make sure "auto-load subtitles" is still selected on the playback screen. (I know this is obvious, but sometimes people forget that one.) (I'm sorry, I'm on my phone now so I don't remember the exact names for all this...)

[Liisachan]

Edit3: Actually can you point me out to that part of the source code? I'd like to see what is calling that function. Inferring from the name of the method, it looks like it may also be called when MPC thinks it's storing the ini file to a different location. Again I'll have to check when I get home, but perhaps my shortcut is pointing to a virtualized path (e.g. libraries) and it is getting confused thinking it is in a different place each time.

mplayerc.cpp (https://github.com/mpc-hc/mpc-hc/blob/bcd7563a666aa2b803d1f0d479c50f015a4af63a/src/mpc-hc/mplayerc.cpp) Line 418 CMPlayerCApp::ChangeSettingsLocation

This function is called in Line 1018 if IsIniValid() && !IsIniUTF16LE(). [There might be another place calling it, but I'm not sure.]

- IsIniValid() is FileExists(GetIniPath()). This may fail even when .ini does exists, if GetIniPath() fails, or if it returns an incorrect path for some reason. GetIniPath is:

CString path = GetProgramPath(true);
path = path.Left(path.ReverseFind('.') + 1) + _T("ini");
return path;

This suggests that .ini must share the path with the program .exe. If, for example, a file-link (shortcut) is used for .ini, things may go wrong. Like you said, a virtualized path may be a problem. Also, GetProgramPath itself might fail, if for example the exe is remote.

- IsIniUTF16LE() returns false not only when it succeeds and the file is actually not UTF-16 LE, but also when CFile f fails, and when f.Read() fails. Also, if this is cross-platform, the below code has obviously an endianness problem. Though, I think CFile always reads a WORD as LE, since this is on Windows. A byte order mark (BOM) is 0xFEFF, which is 0xFF 0xFE if encoding is UTF16-LE. [Edit: I was wrong. The below is just fine, as f.Read is byte-by-byte reading.]

WORD bom;
if (f.Read(&bom, sizeof(bom)) == sizeof(bom)) {
isUTF16LE = (bom == 0xFEFF);
}

[Mikey2]

Wow thanks a lot Liisaschan! As I mentioned, I am a software engineer, so I think I will try getting down and dirty in the code. Just to make sure I'm in the right place, is current development being done on this svn repository: http://sourceforge.net/projects/mpc-hc/ and/or this onehttps://github.com/mpc-hc/mpc-hc ?

What version of VC++ are you using to compile? (I currently have Visual Studio 2008 installed, but my MSDN license should still be valid if I need to upgrade.) Is there any specific "gotcha's" involved in getting my environment setup to debug MPC-HC?

This sounds like it could be fun! :)

Oh and as far as changes, I won't checkin anything; I just want to step-into the code and see where it is going wrong... (It is weird, I am staring at Notepad++ which clearly stating the file is encoded UCS-2 Little Endian...)

MikeY

[Liisachan]

@Mikey2
I'm just a hobbyist (a user), not an MPC-HC dev nor a professional programmer. I've never even tried to compile MPC-HC myself. MPC-HC things used to be on sourceforge, but now it's on github.com, starting from 1.6.3. You should check files in /docs, and http://sourceforge.net/apps/trac/mpc-hc/wiki/How_to_compile_the_MPC - it says vs2010 (maybe the free Express version will do).

In ChangeSettingsLocation, UpdateData(true) is always called anyway even when StoreSettingsToIni() fails. This means that if CreateFile(...GENERIC_WRITE...) fails but WriteProfile* doesn't fail, then an ANSI (non-Unicode) ini file is recreated every time you start MPC-HC, because it sees the ini is not in Unicode, and so it tries to recreate it, but the ini doesn't have an BOM if CreateFile fails, when WriteProfile* writes ANSI strings. Perhaps that's not your problem, though, since you say your ini is already in UTF-16. To make sure, you can rename a random sample media file like "中文 & español.avi" and try to bookmark it, while "Store settings to .ini" is enabled. Restart MPC-HC and select it from the bookmarks; it works if .ini is in Unicode, and doesn't work if .ini is in ANSI.

EDIT:

Another thing you can try easily is an old version like
4235 (http://sourceforge.net/projects/mpc-hc/files/MPC%20HomeCinema%20-%20Win32/MPC-HC%20v1.6.1.4235_32%20bits/)
If builds before 4274 don't have your problem, then the 4274 changes (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=revision&revision=4274) may have caused it.

[vBm]

Just to make sure I'm in the right place, is current development being done on this svn repository: http://sourceforge.net/projects/mpc-hc/ and/or this onehttps://github.com/mpc-hc/mpc-hc ?

What version of VC++ are you using to compile? (I currently have Visual Studio 2008 installed, but my MSDN license should still be valid if I need to upgrade.) Is there any specific "gotcha's" involved in getting my environment setup to debug MPC-HC?

we're switched to github for development repository.
VS2010 is needed to compile mpc-hc.

[cremor]

Subtitles still work for me. I usually put it in the same directory, rename the file to the same as the mkv/avi and select "prefer external subtitles..." Also, if you're putting them into a subfder, make sure to include the subs\ relative path in that list. Finally, make sure "auto-load subtitles" is still selected on the playback screen. (I know this is obvious, but sometimes people forget that one.) (I'm sorry, I'm on my phone now so I don't remember the exact names for all this...)

I just found out that it works fine when the subtitles have the exact same name as the movie file. But my subtitles are named "<movie file name>.en.<extension>" and "<movie file name>.de.<extension>". Shouldn't this work too? How are you supposed to automatically load more than one subtitle otherwise?

[Thunderbolt8]

is mpc-hc actually able to open/read BD menus like a normal playback software (e.g. powerdvd) or a standalone player?

[JanWillem32]

@TheCatcher: Today I had the spare time to do some programming, so I integrated the changes you wanted in the renderer. I modified the parameters a bit, so it can be used a bit more universally for other pixel shaders as well. I posted the builds and pixel shaders in the renderer fixes thread on this board.

[mr.duck]

The log has stopped updating? http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc/?view=log

Is there an updated URL?

[JEEB]

The log has stopped updating? http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc/?view=log

Is there an updated URL?
Yes, MPC-HC switched from svn to git: repository log (https://github.com/mpc-hc/mpc-hc/commits/master)

[mr.duck]

Yes, MPC-HC switched from svn to git: repository log (https://github.com/mpc-hc/mpc-hc/commits/master)

I see. Thanks.

Is there any way too see the the build number (such as r5940) from this new list?

[JEEB]

Is there any way too see the the build number (such as r5940) from this new list?
No. Git (like many other newer revision control systems, such as mercurial) basically have abolished the concept of a single-lined, unmodifiable revision histories, and thus every commit just has a hash of its own (usually the seven first symbols of it are long enough to be specific to one, so a shortened version is shown on github f.ex.), and the history is a line that tangles these commits together. So no, there is no automatical revision number in git (hg actually makes it harder for the user to rebase etc. + tries to "look the same" so it just counts the amount of commits and creates a revision number for the user from there when you check its command line log IIRC).

That said, the MPC-HC's master branch is supposed to be without rebasing, so the revision numbers you get when you build are gotten by counting from the last svn commit and adding the amount of commits after it to it (you can't otherwise match up the numbers because svn puts all branches in a single history line, while git only has the history of a certain branch in a branch).

[e-t172]

No. Git (like many other newer revision control systems, such as mercurial) basically have abolished the concept of a single-lined, unmodifiable revision histories, and thus every commit just has a hash of its own (usually the seven first symbols of it are long enough to be specific to one, so a shortened version is shown on github f.ex.), and the history is a line that tangles these commits together. So no, there is no automatical revision number in git (hg actually makes it harder for the user to rebase etc. + tries to "look the same" so it just counts the amount of commits and creates a revision number for the user from there when you check its command line log IIRC).

That said, the MPC-HC's master branch is supposed to be without rebasing, so the revision numbers you get when you build are gotten by counting from the last svn commit and adding the amount of commits after it to it (you can't otherwise match up the numbers because svn puts all branches in a single history line, while git only has the history of a certain branch in a branch).

"git describe" to the rescue!

The command finds the most recent tag that is reachable from a commit. If the tag points to the commit, then only the tag is shown. Otherwise, it suffixes the tag name with the number of additional commits on top of the tagged object and the abbreviated object name of the most recent commit.

So you just need to tag the tree you're building from with the build number, and you're all set.

[Tiduz]

ok, is it just me or is normalize broken for a while? my audio randomly gets softer and then when i disable and reenable it i get louder sound again, am i the only one with this problem?

[patch1]

Is there any way too see the the build number (such as r5940) from this new list?

I agree it is a useful function (http://forum.doom9.org/showthread.php?p=1585559#post1585559) even if it is now difficult to generate.
I now use the date to relate commit history (https://github.com/mpc-hc/mpc-hc/commits/master) to available builds (http://xhmikosr.1f0.de/mpc-hc/)

Not exact, I suspect due to time zone differences and multiple commits in a day but at least it limits the number of hash codes I need to check.

[Reino]

@ patch1:
XhmikosR can probably put the hash in the filename of the nightlies.Since it's unclear what rev. build corresponds with what commit, this suggestion made by Underground78 would help a lot, but as of yet XhmikosR hasn't answered to it.

[Liisachan]

Another VSFilter problem if anyone is interested:
VSFilter: Shadow is not drawn when Border is very thin (#2588) (https://sourceforge.net/apps/trac/mpc-hc/ticket/2588)

When the border width is very small but not zero, MPC-HC "forgets" to draw the shadow, both in hardsubbing and softsubbing. Left to right, border=0.25 / 0.125 / 0.0625 / 0.062499 / 0 (@ 100%; if zoomed, the threshold will change):
http://ffdshow.faireal.net/tmp/missing_shadow_demo.png
This results in several realistic problems, such as unintended shadow blinking when the border width is slowly animated from non-zero to 0, or from 0 to non-zero (Sample clip (https://sourceforge.net/apps/trac/mpc-hc/raw-attachment/ticket/2588/missing_shadow_test.mkv)).

User-side workaround: For example, instead of \bord1\t(0,2000,\bord0), try \bord1\t(0,1750,\bord0.125)\t(1750,2000,\3a&Hff). Instead of \bord0\t(0,2000,\bord1), try \bord0.125\3a&Hff\t(0,250,\3a&H00)\t(250,2000,\bord1).

[v0lt]

What do you think about moving the mixer from MpaDecFilter to AudioSwitcher? And about removing the "custom channel mapping"?

[Mercury_22]

What do you think about moving the mixer from MpaDecFilter to AudioSwitcher? And about removing the "custom channel mapping"?

Do not remove the "custom channel mapping"!!!!!!!!!!!!!!!!!
And yes "moving the mixer from MpaDecFilter to AudioSwitcher" seems a good idea

EDIT : Also it will be nice if you could add independent volume levels for each channel like in FFD

[betaking]

Do not remove the "custom channel mapping"!!!!!!!!!!!!!!!!!
And yes "moving the mixer from MpaDecFilter to AudioSwitcher" seems a good idea

+1!I also agree with you!

[jq963152]

Hello,

with MPC-HC x64 1.6.3.5818, hardware acceleration apparently is not used on videos with resolutions beyond 1920x1080?

Why is that?

And is there any way to use hardware acceleration on videos with resolutions beyond 1920x1080?

Thanks in advance.

[v0lt]

with MPC-HC x64 1.6.3.5818, hardware acceleration apparently is not used on videos with resolutions beyond 1920x1080?
Call type of your video card.

[JanWillem32]

@jq963152: It's at the bottom of the page: https://github.com/mpc-hc/mpc-hc/blob/master/src/filters/transform/MPCVideoDec/FfmpegContext.cpp . There are restrictions to the size. If you see any case that needs to be corrected, please give us some documentation. We can then patch these items.

[jq963152]

Thanks for your replies.

Call type of your video card.

NVIDIA GeForce GT 520 (GF119)

@jq963152: It's at the bottom of the page: https://github.com/mpc-hc/mpc-hc/blob/master/src/filters/transform/MPCVideoDec/FfmpegContext.cpp . There are restrictions to the size. If you see any case that needs to be corrected, please give us some documentation. We can then patch these items.

Well, not sure, not a programmer, but the text from your link apparently states the following (among other things):



https://github.com/mpc-hc/mpc-hc/blob/master/src/filters/transform/MPCVideoDec/FfmpegContext.cpp#L165 (https://github.com/mpc-hc/mpc-hc/blob/master/src/filters/transform/MPCVideoDec/FfmpegContext.cpp#L165)
nVidia cards support level 5.1 since drivers v6.14.11.7800 for XP and drivers v7.15.11.7800 for Vista/7

https://github.com/mpc-hc/mpc-hc/blob/master/src/filters/transform/MPCVideoDec/FfmpegContext.cpp#L188
HD4xxx, HD5xxx, and HD6xxx AMD/ATI cards support level 5.1 since drivers v8.14.1.6105 (Catalyst 10.4)

And at least according to Wikipedia:

http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels

AVC HP@L5.1 apparently would allow for much higher resolutions than 1920x1080, wouldn't it?

Also, in the LAV Filters thread apparently the following was posted:

Only Ivy Bridge does 4K decoding, if you're running it on your 2500k from your signature, no 4K for you.

NVIDIA (via CUVID) only supports it with VP5 (VDPAU Feature Set D). AMD claims to support it with the 7xxx series, but in my tests, it just failed miserably.
Try it with LAV CUDA or LAV CB, as in these modes IIRC, there are no blocks on any resolutions. (res > 1080p HD)
LAV Native DXVA might block some res. higher then 1920x1088 IIRC

And apparently when playing back 3840x2160 video here for example with a GT 520, hardware acceleration apparently is only shown as "active" in the LAV Video Configuration panel when it is set to LAV CUVID or LAV DXVA2 (copy-back).

But when setting it to LAV DXVA2 (native) or when using internal MPC-HC Video Decoder it apparently is falling back to software decoding.

Why are resolutions beyond 1920x1080 blocked with LAV DXVA2 (native) and internal MPC-HC Video Decoder (which is DXVA2 native as well, isn't it?)?

[nevcairiel]

Its blocked with DXVA2 Native in LAV because auto-detection of 4k support is not working properly, and if it enabled it but doesnt support it, you get a black screen, which is no good. :p
Either i'll have to fix the auto-detection (might be tricky) or simply add a checkbox so people can turn on 4k DXVA if they think their Hardware can do it.

In any case, I've been rather busy with a lot of different things over the last few weeks, and not much got done.

[jq963152]

Its blocked with DXVA2 Native in LAV because auto-detection of 4k support is not working properly, and if it enabled it but doesnt support it, you get a black screen, which is no good. :p

But with VP5 you would not get a black screen, or would you ;)?

Either i'll have to fix the auto-detection (might be tricky) or simply add a checkbox so people can turn on 4k DXVA if they think their Hardware can do it.

That would probably be appreciated :D;).

[jq963152]

There are restrictions to the size. If you see any case that needs to be corrected, please give us some documentation. We can then patch these items.

No reply from you :p?