Media Player Classic - Home Cinema (MPC-HC) - v1.7.13

[ryrynz]

UI could still use a refresh.. Perhaps make it similar to Foobar2000.

[huhn]

it's not possible to use the mouse wheel for volume in windows 10 preview. it only works when the mouse wheel is on top of the volume bar so impossible to use in fullscreen exclusive mode.

it works totally fine in options -> internal filter.

tested build 1.7.6.279(f22cc00).

i double checked the hot keys. everything is default and right.

[kasper93]

They changed mouse behavior. Now it will scroll window that the pointer is hovered on and not active one like with older windows builds. Thanks for report, but I think we should wait some time before fixing Win10 specific bugs. They might as well revert this behavior before release. But I will keep this in mind.

[Gaius]

Will we ever get a quick way to open streaming video URLs?

[vBm]

After 3 months since our last stable build, we are happy to announce v1.7.7.

This release is a bugfix release, with many improvements and a few new features.

Highlights of this release:


Fixed a crash affecting DVD playback with subtitles on 64-bit builds
Worked around a bug in the latest NVIDIA driver (v344.11) which caused a corrupted display of 10-bit videos
Improved HEVC decoding: software decoding should be up to twice faster and hardware accelerated decoding is now available (but still experimental so disabled by default)
Improved subtitle renderer and subtitle queue (more than twice faster on complex subtitle scripts)
Support for audio cover art
New Arabic and Thai translations. Remember that you can help us (https://trac.mpc-hc.org/wiki/Translations) translating MPC-HC to your language.



Don’t forget, that our official builds, both the stable and the beta builds, are digitally signed (http://mpc-hc.org/2013/02/25/binaries-are-signed/). Be aware of scams and only get the files from our site!

You can download the new version here (http://mpc-hc.org/downloads/). For the complete changes see the changelog (http://mpc-hc.org/changelog/).

[Vyral]

Thanks for the new version.

However, I've a 404 error from SourceForge when trying to download the lastest version.

[xiringu]

Hi, this is my first post in this subforum, but I've been using mpc-hc for a long time.

I'd like to ask a few things, so I'll start with these:

.-Why is still Color Controls in Miscellaneous and not somewhere logic like Playback?

.-Also, why when I click on Brightness, Contrast, etc, the step is 40 points? Shouldn't it be something like 10?

Thanks for your great work :)

[xiringu]

Is there any shader to replicate the scanlines found on console emulators?

What I'd like is to add horizontal black lines to some videos that are low-res or too blocky, and I prefer to give them an old school look instead. :)

Unfortunately I have no idea where to start to make my own shaders.

Thanks

[hello_hello]

After 3 months since our last stable build, we are happy to announce v1.7.7.

This release is a bugfix release, with many improvements and a few new features.

First..... thanks for the new version. It's appreciated.

I can't find mention of it in the changelog but it seems the behaviour in relation to left clicking on a video has changed and as a result MPC-HC now has an annoyance similar to MPC-BE.

I don't know the best way to describe the different modes so I'll do it like this. View/Presets/Minimal (no window surrounding the video) and View/Presets/Normal (normal window).

Past versions of MPC-HC have ignored a left click on the video in respect to pausing/resuming play when the player is in "minimal" mode, but allowed you to click on the video to drag it to a different position. When in "normal" mode you could left click on the video to pause/resume but not drag the player. Moving the player's position on the monitor required clicking on the title bar.

The current version of MPC-HC allows you to both left click to pause/resume and also to drag regardless of the mode it's in..... the same behaviour as MPC-BE. As a result though, it now tends to ignore some left clicks to pause the video, just as MPC-BE does. Fortunately, the behaviour is nowhere near as bad as it is for MPC-BE, where sometimes you can click and click for days before playback eventually pauses or resumes, but MPC-HC does ignore some left clicks, which it's never done before.

I think it'd be a good idea to retain the current behaviour in "minimal" mode, where the odd click to pause the video being ignored is probably a reasonable compromise, but when in "normal" mode I'd much prefer the old behaviour. There's really no need to click on the video itself to move the player around when there's a perfectly good title bar for doing just that. And left clicking on the video to pause/resume playback would be 100% reliable again (assuming my assumption about the change of behaviour being the cause of the problem is correct).

I know it's possible to change the left click function to something else but I really don't want to. I've been using MPC-HC the same way for as long as I can remember. Left click to pause/resume playback, middle click to go in an out of fullscreen mode, right click for the menu.....
(I've never quite understood why the default behaviour for fullscreen mode has been a left double click. It makes no sense to me. Are there lots of mice/devices these days without middle click functionality?)

Thanks!

[fvisagie]

I've encountered a situation where the x64 build won't render Avisynth scripts, while the x86 build does. This happens even with the simplest of scripts, e.g.Version()

With the x64 build it makes no difference whether the internal Avisynth splitter filter is enabled or not. The error message "Cannot render the file" is displayed on the status bar, but no pin rendering failure or anything else is reported.

System and version information:
Windows 8.1 64-bit
Avisynth 2.6.0 Alpha 4 32-bit
MPC-HC 1.7.6 64-bit

[hello_hello]

I have a question regarding MPC-HC's window resizing when opening a video with a resolution higher than that of the monitor (I'm still using a CRT as my main PC monitor). The previous behaviour of opening the player to "monitor width", then resizing the window by moving the titlebar and navigation bar as necessary has changed with 1.7.7 (thankfully) and the player now opens the window while adding black bars to the top and bottom of the video as it once did. Well.... it wouldn't bother me if it opened with a window which matched the resized video (no black bars), it was the more recent behaviour of opening the player window then resizing it by moving the titlebar/navigation bar up and down which frustrated me a little. Anyway.......

My CRT is running at 1152x864. I open a 1280x720 video. The current version of MPC-HC resizes it down to monitor width and there's small black bars above and below the video. I drag the player to the TV and it immediately does it's titlebar/navigation bar adjusting and the black bars are gone. The player window isn't 1280x720, it's still resized down, but the titlebar/navigation bar dance has removed the black bars.
But it doesn't always do the same thing. Sometimes after dragging the player to the TV the video/window is resized up to 720p.
When the resolution is even lower.... ie 1280x544.... there's no resizing after dragging the video to the TV. No titlebar/navigation bar dance. It just stays the same as it was on the first monitor.... I think I much prefer that behaviour..... but why doesn't the player always behave the same way in respect to resizing itself and the video?

Thanks.

[Snowknight26]

On a similar note, opening a 1080x1920 (yes, vertical) video on a 2560x1440 display causes black bars to be added either side of the video when they shouldn't be. The video is correctly resized to fit the usable display area (so screen size minus ~30 pixels for the task bar on Windows 7) but the player's width is far wider than the width of the scaled video.

Example:
http://stfcc.org/pics/i/1bcbde42ba51f2e80bfca43a03551b45_th.png (http://stfcc.org/pics/i/1bcbde42ba51f2e80bfca43a03551b45.png)
The red image is 1080x1920 resized, by MPC-HC, to 'Touch Window From Inside.'

[Superb]

I'm having an issue w/ 1.7.7. Freezes after about 30-45 minutes of playback. Might be a memory leak w/ the new subtitles code (it raises up to 500MB).
I'm reverting to 1.7.6 to see if I'm mistaken and it's another issue.

[jkauff]

I'm having an issue w/ 1.7.7. Freezes after about 30-45 minutes of playback. Might be a memory leak w/ the new subtitles code (it raises up to 500MB).
I'm reverting to 1.7.6 to see if I'm mistaken and it's another issue.
I've watched three movies from start to finish so far with 1.7.7 with no problems.

[Superb]

I've watched three movies from start to finish so far with 1.7.7 with no problems.Do you watch them with subtitles? What kind of decoding do you use? I use dxva2native w/ the internal lav filters. I have Intel HD Graphics 4600 w/ the latest driver.

[MysteryX]

The latest version 1.7.7 has a bug where the NowPlaying message is being sent repeatedly non-stop
CMD_NOWPLAYING = &H50000003

I'm hooking up to the MPC-HC process to control it via API and this causes me troubles. It was working fine with v1.7.3

Btw, the main issue with MPC-HC is that it crashes and freezes regularly, especially when using SVP. Are there any plans to resolve that?

[kasper93]

@Snowknight26 @hello_hello Black bars will be fixed in next nightly, test build if you want to see before https://trac.mpc-hc.org/ticket/4937#comment:7

I can't find mention of it in the changelog but it seems the behaviour in relation to left clicking on a video has changed and as a result MPC-HC now has an annoyance similar to MPC-BE.

You can change Play/Pause command to "Left Down" to revert old behavior. See also https://trac.mpc-hc.org/ticket/4956

I'm having an issue w/ 1.7.7. Freezes after about 30-45 minutes of playback. Might be a memory leak w/ the new subtitles code (it raises up to 500MB).
I'm reverting to 1.7.6 to see if I'm mistaken and it's another issue.

You need to provide more information. So we can diagnose the issue. You can create a dump file manually when it freeze:

Reproduce the issue with MPC-HC.
If you're on a 32-bit operating system, open the task manager as usual or if you're on a 64-bit operating system, open the task manager from C:\Windows\SysWOW64\taskmgr.exe.
Locate the mpc-hc.exe (or mpc-hc64.exe) process.
Right click on it and press "Create Dump File" (or something similar).
Compress and upload the created dump file for us (using your favorite file hosting website).


The latest version 1.7.7 has a bug where the NowPlaying message is being sent repeatedly non-stop
CMD_NOWPLAYING = &H50000003

It is a feature to ensure that we have valid metadata during live stream playback. Please open a ticket (http://trac.mpc-hc.org/) - we probably could change it to send data only when metadata change.

Btw, the main issue with MPC-HC is that it crashes and freezes regularly, especially when using SVP. Are there any plans to resolve that?

Sure if you prove that it is MPC-HC issue. We can't check every thirdparty filter and if it freeze/hang only with SVP it is most likely problem in SVP. If not we still need more information how to reproduce the problem, but frankly I would ask SVP developers first.

[foxyshadis]

I've encountered a situation where the x64 build won't render Avisynth scripts, while the x86 build does. This happens even with the simplest of scripts, e.g.Version()

With the x64 build it makes no difference whether the internal Avisynth splitter filter is enabled or not. The error message "Cannot render the file" is displayed on the status bar, but no pin rendering failure or anything else is reported.

System and version information:
Windows 8.1 64-bit
Avisynth 2.6.0 Alpha 4 32-bit
MPC-HC 1.7.6 64-bit

There's your problem; you need the 64-bit installed as well, along with 64-bit versions of any plugins you use.

[MysteryX]

It is a feature to ensure that we have valid metadata during live stream playback. Please open a ticket (http://trac.mpc-hc.org/) - we probably could change it to send data only when metadata change.
I tried opening up a ticket during the day but never received a confirmation email so I can't confirm the account and open a ticket.

Sure if you prove that it is MPC-HC issue. We can't check every thirdparty filter and if it freeze/hang only with SVP it is most likely problem in SVP. If not we still need more information how to reproduce the problem, but frankly I would ask SVP developers first.
MPC-HC often freezes when seeking. The SVP guys said they spent a LOT of time trying to work around the issue and came to the conclusion they couldn't solve that on their side. The work-around they have is to either turn-off SVP for 1 or 2 seconds when seeking, or not reset at all which causes visual glitches for a few seconds. It still crashes and freezes, but not as often.

[hello_hello]

You can change Play/Pause command to "Left Down" to revert old behavior. See also https://trac.mpc-hc.org/ticket/4956

Thanks, I didn't realise that made a difference. Mind you normally I have it set to "left down" but currently it's "left up". I can't remember if I changed it to see if it'd make the problem go away or if I never changed it to "left down" in the first place, but it's "left down" now, so I'll see how it goes.

Cheers.

[hello_hello]

I'm running XP. I just noticed when looking at the list of renderers for version 1.7.7, MPC-HC says VMR7 (Renderless) is unavailable and if I try to select it, tells me the renderer isn't installed. Not that I particularly want to use it, but MPC-HC 1.7.6 sees it as available and seems happy to use it.

Thanks.

[kasper93]

@hello_hello: We changed the key in default settings. We had many requests about it.

VMR-7 (renderless) doesn't work on x64 and if desktop resolution is higher than 2048x2048px. If it works for you in 1.7.6 we will definitely need to make filter less strict. But make sure it is actually VMR-7 (renderless) in filter menu.

[hello_hello]

@Snowknight26 @hello_hello Black bars will be fixed in next nightly, test build if you want to see before https://trac.mpc-hc.org/ticket/4937#comment:7

Thanks. That's much better, at least in respect to the player opening with a window that matches the video resolution. No more titlebar/navigation bar bouncing up and down.

I still can't work out what criteria MPC-HC uses in order to decide whether it's going to resize itself when the player is dragged from one monitor to another. Or in my case, from my CRT monitor to my TV.
For video with a resolution of 1280x720 (just higher than my monitor resolution of 1152x864) opening the video then dragging it to the TV sometimes results in the video being resized back up to 1280x720, while sometimes it doesn't. The same applies to 1080p. Sometimes it almost seems like it's on a timer. The longer the video is allowed to play on the lower resolution monitor, the less likely it is to resize itself when moved to the TV.
For lower resolution video such as 1280x544 it's never resized after being moved to the TV.

Personally, I'd prefer it if MPC-HC opened a video, resized according to the monitor it's being displayed on and left it at that. I'd prefer it didn't automatically resize simply because I've moved the player to a different monitor.

Is that all purely the behaviour of the player or could the video drivers be involved? I'm running XP with an Nvidia card and the drivers are probably a year or so old.

[kasper93]

I tried opening up a ticket during the day but never received a confirmation email so I can't confirm the account and open a ticket.

Strange. But don't worry, I will make a patch tomorrow and discuss with others your issue.

MPC-HC often freezes when seeking. The SVP guys said they spent a LOT of time trying to work around the issue and came to the conclusion they couldn't solve that on their side. The work-around they have is to either turn-off SVP for 1 or 2 seconds when seeking, or not reset at all which causes visual glitches for a few seconds. It still crashes and freezes, but not as often.

The question still stands, is there anything MPC-HC is doing wrong? I'm pretty much sure we doesn't do anything fancy during seeking. If he spend a lot of time fixing the issue I'm pretty sure he looked at MPC-HC code as well. Like I said before I'm not using SVP, but if we get clear information that we do something wrong or even an idea how we can improve compatibility with SVP we will surly consider any changes.

[kasper93]

Thanks. That's much better, at least in respect to the player opening with a window that matches the video resolution. No more titlebar/navigation bar bouncing up and down.

I still can't work out what criteria MPC-HC uses in order to decide whether it's going to resize itself when the player is dragged from one monitor to another. Or in my case, from my CRT monitor to my TV.
For video with a resolution of 1280x720 (just higher than my monitor resolution of 1152x864) opening the video then dragging it to the TV sometimes results in the video being resized back up to 1280x720, while sometimes it doesn't. The same applies to 1080p. Sometimes it almost seems like it's on a timer. The longer the video is allowed to play on the lower resolution monitor, the less likely it is to resize itself when moved to the TV.
For lower resolution video such as 1280x544 it's never resized after being moved to the TV.

Personally, I'd prefer it if MPC-HC opened a video, resized according to the monitor it's being displayed on and left it at that. I'd prefer it didn't automatically resize simply because I've moved the player to a different monitor.

Is that all purely the behaviour of the player or could the video drivers be involved? I'm running XP with an Nvidia card and the drivers are probably a year or so old.

In initial few seconds of playback, we allow video to stabilize. For example anamorphic video files doesn't have proper size instantly when opening file, we need to process few frames first. After this period of time autofit (on video size changes) is locked unless you have "limit video proportions on resize" selected. When you drag video window to another screen apparently renderer is reinitialized and notified that video size has been changed. And when you do that in first 5 sec of playback it will do full window autofit. At least this is my guess to what you are seeing. I think it is not necessarily bad thing, let say you opened a file and instantly drag to another monitor, you want to watch it there and the autofit is adjusted accordingly. I mean when open mpc-hc on 1152x864 monitor, 720p video size will be limited to this resolution and when you drag to another monitor quick enough it will be back to it's full size according to you settings in options.

[hello_hello]

@hello_hello: We changed the key in default settings. We had many requests about it.

I suspect MPC-HC was set to "left down" when I noticed the problem, so I changed it to "left up" to see if it'd make a difference.
Since switching back to "left down" it's definitely ignored a few left clicks to pause/resume playback, but it's very irregular and impossible to repeat. I assume it must relate to the changed "click and drag" behaviour though, because I've never noticed it happen before. Well, if it did it was very, very occasionally. Since version 1.7.7 the frequency has increased enough for me to post here about it. I'll keep using it set to "left down" though and see what happens.

VMR-7 (renderless) doesn't work on x64 and if desktop resolution is higher than 2048x2048px. If it works for you in 1.7.6 we will definitely need to make filter less strict. But make sure it is actually VMR-7 (renderless) in filter menu.

I'm running XP and my desktop resolution is way lower than that, but it appears VMR-7 (renderless) isn't working for version 1.7.6 either. If I select it, only "video renderer" is displayed in the filters list. I tried 1.7.4 and 1.7.1 and they're the same, so I guess it hasn't worked for a while.

Thanks.

[hello_hello]

I think it is not necessarily bad thing, let say you opened a file and instantly drag to another monitor, you want to watch it there and the autofit is adjusted accordingly.

I could argue it's a bad thing if the video is 1080p, because even when the player is dragged to a 1080p display, the title bar and navigation bar take up some of the screen real estate so the video is resized, but not to it's full resolution. So why resize at all? ;)
1.7.7 resizes so the player window fills the display and the video has black bars down the sides. The test build from post #1573 resizes without black bars, but the video resolution still isn't 1080p.
Anyway, that's neither here nor there.....

I mean when open mpc-hc on 1152x864 monitor, 720p video size will be limited to this resolution and when you drag to another monitor quick enough it will be back to it's full size according to you settings in options.

Thanks for the info. It's no big deal. I'd just prefer it didn't resize when I move it to my TV. I'll be a bit more patient before moving it in the future.

Although it still doesn't explain why the resizing doesn't seem consistent. For instance I've tried quite a few videos with resolutions such as 1280x544, which are still resized down slightly for my 1152x864 monitor, but they're never resized up when moved to the TV no matter how quickly I move the player after opening the video. That applies to 1.7.7 and the build you linked to in post #1573. If the video is 1280x720 or 1920x1080 etc, it is resized.

Cheers.

[MysteryX]

The question still stands, is there anything MPC-HC is doing wrong? I'm pretty much sure we doesn't do anything fancy during seeking. If he spend a lot of time fixing the issue I'm pretty sure he looked at MPC-HC code as well. Like I said before I'm not using SVP, but if we get clear information that we do something wrong or even an idea how we can improve compatibility with SVP we will surly consider any changes.

I suggested him to get in touch with you

http://www.svp-team.com/forum/viewtopic.php?id=2217

[Pulstar]

Been away for a long while, is MPC-HC finally doing subtitles optimally, thereby negating the need for external subs filter?

[huhn]

depends. was only a issue for styled ASS file anyway.
I haven't founds a sample where the internal filter is still way slower than xy vobsub.

not sure if they fixed the color space issue.

[fvisagie]

There's your problem; you need the 64-bit installed as well, along with 64-bit versions of any plugins you use.

Thanks, although in a sense that deepens my confusion - I'd understood that 32-bit Avisynth could be used by large-address-aware applications. Is large-address-aware in other words not necessarily the same thing as a 64-bit application?

[LigH]

Absolutely not.

The "conservative" addressing of 32-bit processes has a limit of 2 GB RAM per process due to reserving the most significant bit of addresses in a 32-bit selector as a special flag (only 31 bits used). Large Address Aware processes use the msb as well (all 32 bits used), so it could use up to 4 GB RAM on a 64-bit OS (a 32-bit Windows limits per-process RAM to 2 GB, or 3 GB with a kernel boot switch, to protect the OS kernel and direct memory access to devices in a range between 3 and 4 GB).

64 bit processes use 64 bits instead of 31 or 32 bits for memory addresses. They could use Terabytes of RAM (Microsoft may limit per-process RAM for cheap OS variants, though, I'm not sure about that without looking for specs).

[fvisagie]

Thanks for clearing that up so thoroughly.

[kasper93]

I could argue it's a bad thing if the video is 1080p, because even when the player is dragged to a 1080p display, the title bar and navigation bar take up some of the screen real estate so the video is resized, but not to it's full resolution. So why resize at all? ;)

It depends on your settings, many users use autofit feature, which in this case will adjust size according to monitor resolution.

Although it still doesn't explain why the resizing doesn't seem consistent. For instance I've tried quite a few videos with resolutions such as 1280x544, which are still resized down slightly for my 1152x864 monitor, but they're never resized up when moved to the TV no matter how quickly I move the player after opening the video. That applies to 1.7.7 and the build you linked to in post #1573. If the video is 1280x720 or 1920x1080 etc, it is resized.

I'm not sure, why. Could you see how this one works https://www.dropbox.com/s/km76ugun6f13och/MPC-HC.1.7.7.24.x86.7z

[MysteryX]

The question still stands, is there anything MPC-HC is doing wrong? I'm pretty much sure we doesn't do anything fancy during seeking. If he spend a lot of time fixing the issue I'm pretty sure he looked at MPC-HC code as well. Like I said before I'm not using SVP, but if we get clear information that we do something wrong or even an idea how we can improve compatibility with SVP we will surly consider any changes.

According to MAG79

I think the problem is somewhere near frames buffer. SVPFlow library calculates some frames ahead by avisynth demands. Avisynth store in memory some frames by ffdShow demand. ffdShow store in memory some frames by player (or renderer) demand. Renderer have internal frame buffer to avoid stutter. When seek all these buffers must be cleared and filled again with new frames. I think the clear buffer function of some of these elements from the chain may contain the error.

[hello_hello]

@hello_hello: We changed the key in default settings. We had many requests about it.

I suspect MPC-HC was set to "left down" when I noticed the problem, so I changed it to "left up" to see if it'd make a difference.
Since switching back to "left down" it's definitely ignored a few left clicks to pause/resume playback, but it's very irregular and impossible to repeat. I assume it must relate to the changed "click and drag" behaviour though, because I've never noticed it happen before. Well, if it did it was very, very occasionally. Since version 1.7.7 the frequency has increased enough for me to post here about it. I'll keep using it set to "left down" though and see what happens.

I thought I should report back to say I've been using MPC-HC a bit over the last few days with "left down" set as the method for pausing/resuming playback and it's been behaving itself. No ignored mouse clicks. So I guess the "left up" setting was the cause there.

I'm not sure, why. Could you see how this one works https://www.dropbox.com/s/km76ugun6f13och/MPC-HC.1.7.7.24.x86.7z

Sorry about the slow reply (the real world got in the way), but that's very consistent. I can open a video on my PC monitor and drag it over to the TV and so far it hasn't resulted in MPC-HC resizing the window/video a single time, regardless of the resolution. I copied my previous ini and toolbar.bmp files to the new MPC-HC directory to make sure they didn't change anything and the behaviour remained the same.
Previously I'd open a video, pause it, wait a second, move the player to the TV, and then cross my fingers it wouldn't resize when I resumed playback. Now I can open a video on the PC monitor and drag it over to the TV immediately without pausing playback and the video remains it's original size.

In the past MPC-HC has been a little odd in respect to consistency and resizing. I posted about it here but it didn't seem to attract any interest. https://trac.mpc-hc.org/ticket/4660#comment:1
At the time I had two MKVs which to me seemed identical in respect to resolution and aspect ratio, yet when dragging one to the TV MPC-HC would always resize it, but for the second it never would. The samples have been deleted and I'm not sure I still have them myself, but if I can find them I'll test them later. For the moment though, it all seems fine.

Thanks!

[hello_hello]

While I'm thinking about it.....

One of the reasons I hadn't been crazy about MPC-HC resizing itself when it's moved to the TV is I often use it for previewing or comparing encoded video etc. Is there a reason why Avisynth scripts aren't included in the list of supported media types when using the File/Quick Open menu? If anything it seems odd the player has a source filter for a file type which isn't included in the supported format list. It doesn't matter to me as I put MPC-HC in the Windows SendTo menu, but I'm curious if there's a reason.

On a similar subject.... in the drop down list of supported media types (File/Quick Open menu) there's a media type called "other". I've not been able to work out what media type "other" refers to.

Thanks again.

[hello_hello]

I just noticed......

I'm running XP and when using the Reset button to errr.... reset everything, MPC-HC resets the renderer to VMR7 (renderless), which is the renderer it's also claiming is "unavailable". Version 1.7.7 and the test build linked to in this post (http://forum.doom9.org/showthread.php?p=1696873#post1696873) both do the same.
You can then open MPC-HC's preferences and change any setting you like, as long as it's not a setting in the Playback/Output section, and there's no warning the selected renderer is unavailable. The warning only appears if you've clicked on Playback/Output at some stage.

I assume VMR7 (renderless) being unavailable is a player limitation and not a problem with the Windows installation?? I ask, because versions 1.6.9 and earlier seem to be more than happy to use VMR7 (renderless). It appears in the filters list when it's selected.
A little ironically though, the default renderer for MPC-HC 1.6.9 (XP) isn't VMR7 (renderless) anyway. It's VMR7 (windowed).

Thanks.

[CruNcher]

There is some strange problem with Maxwell on Windows 7 and no Aero with the EVR Custom renderer

in those regards it seems better to use the Standard EVR which also seems to include a Realtime FRC from Nvidia :)

Lets hope this can be made accessible via EVR Custom :)

http://www.ld-host.de/uploads/images/7ca9422bb259b10c32d0c31330558eba.jpg

http://www.ld-host.de/uploads/images/ccd73dab63770a3ec882d9dc66ae417d.jpg

Here is my current problem with EVR Custom it only happens in normal Fullscreen (not exclusive)

Fullscreen

http://www.ld-host.de/uploads/images/8da1fcf28a4bb537ac456cc7577f1cd3.jpg

Maximized

http://www.ld-host.de/uploads/images/9fb3088a97e9fcb75242ccbaf5ad66c6.jpg

These FPS brakedowns only happen @ Fullscreen im currently testing 344.11 WHQL on a GTX 970 with MPC-HC 1.7.7 x64 and (tester dfr7370rrri)

[cyberbeing]

http://www.geforce.com/whats-new/articles/geforce-344-48-whql-driver-released

Green video bug in 344.11 fixed in 344.48.
It appears NVIDIA implemented a partial workaround in EVR only, without actually fixing the underlying issue. :(

The driver still exposes and prefers broken P010 output with 'System Default', 'Old Video Renderer', 'Overlay Mixer', 'VMR7 (Windowed)'. You can trigger the issue in 344.48 by either using these renderers directly, or disabling every output format in LAV except P010 with EVR which triggers a fallback to the 'System Default' renderer.

[Megalith]

I am running the latest nightly and noticed that videos that match my desktop resolution are cut off at the sides unless I maximize MPC or go full screen.

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

What I see when the video file is opened.

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

What happens when I maximize the MPC window.

[kasper93]

Meh, for the case "touch window from outside" and alike it indeed make sense to not correct window aspect ratio for video frame. Will change that

FYI, this video doesn't match your desktop resolution as you stated...

[Megalith]

It should; both are 1920x1080. Here is a screenshot (http://i.imgur.com/091at5W.jpg) for "proof."

[bukem]

Play next in the folder option is gone again either in stable MPC-HC 1.7.7 or later SVN builds. The last build with that option included I could find is MPC-HC 1.7.6 stable. Please advice.

[vBm]

Play next in the folder option is gone again either in stable MPC-HC 1.7.7 or later SVN builds. The last build with that option included I could find is MPC-HC 1.7.6 stable. Please advice.

Options -> Player -> After playback

you have desired options in a dropdown menu.

[esd827]

Additional functions request:
I want to see the wmv videos directly in IE11 by mpc-hc.

win8.1, IE11, mpc-hc v1.7.7, wmp12

A: Set the property wmp12: wmv videos
B: Set to property mpc-hc: wmv Video

Procedure:
IE11 to open the file, open wmv videos

A: In IE11, wmp12 videos will open directly.

B: In the case of mpc-hc videos,
・ Open a wmv movie, or do you want to save: leave query
・ Open
・ Open wmv videos.

This step is cumbersome, I want to open direct as of wmp12.

[bukem]

Options -> Player -> After playback

you have desired options in a dropdown menu.

Thank you! Didn't notice the menu was moved there.

[Cybermutant]

After updating to MPC-HC nightly v1.7.7.73 I noticed that the PageUp key did not work anymore for going back a chapter.

I found that commit c1a0d5c has incremented many command IDs in resource.h to insert ID_AFTERPLAYBACK_PLAYNEXT, and because I had previously modified the configuration for Next and Previous commands, the key assignment of Next has shifted onto that of Previous. When I checked the Options, both commands were set to PageDown.

Users who have modified key assignments for commands in the ID range 919 to 946 will have to re-set these when they update to v1.7.7.73 or newer.

Luckily, MPC-HC doesn't have a "Delete File" or "Format Disk" command in that range :D

[kasper93]

The issue is already fixed and will be in next nightly. You always use nightly builds at your own risk.

[pirlouy]

I have a playlist .m3u like this:
#EXTM3U
#EXTINF:0,2 - France 2 (HD)
rtsp://mafreebox.freebox.fr/fbxtv_pub/stream?namespace=1&service=201&flavour=hd
#EXTINF:0,2 - France 2 (standard)
rtsp://mafreebox.freebox.fr/fbxtv_pub/stream?namespace=1&service=201&flavour=sd

I'd like MPC-HC to display playlist like this:
France 2 (HD)
France 2 (standard)

MPC-BE does it right, but MPC-HC can't and just displays:
stream?namespace=1&service=201&flavour=hd
stream?namespace=1&service=201&flavour=sd