MPC-HC v2.2.1

[vehf263]

Hi,
Please return keyboard shortcuts. Or please explain what was the special need to change them despite their many years of the same existence.
Thank you.

[shae]

What do you mean? As far as I can tell the keyboard shortcuts are there, same as ever.

[Budtz]

I if use 32bit version of mpchc on 64bit win OS - do I use 32bit or 64bit version of mediainfo.dll?

Any1 know?

[LigH]

A 32 bit EXE can only load 32 bit DLL's.

[el Filou]

I opened a WebM/Opus video, and in the same folder was a .opus file with its audio track that I had extracted, with the same file name.
This caused MPC-HC to load the external audio file, as the setting "Auto-load audio files" was enabled, but it then tried to play both the WebM embedded audio track and the external audio track at the same time (I noticed it because the WASAPI exclusive audio renderer gave an error). In the filter list are two instances of the splitter, audio decoder, and audio renderer, but there is no way to select only one of the audio sources at a time. Is this a bug, or intended behaviour?
In other words, is the feature "Auto-load audio files" meant only to play video files with no embedded audio?
I verified that this happens both with internal LAV Splitter and external one, and with other types of files too (I checked with a TS/AC3)

[clsid]

That would be a user error
it happens because you have disabled the internal stream switcher.

[el Filou]

Indeed!
My bad.

[clsid]

1.8.7 is available now

[Klementh]

Thank you!

SHA-256 hashes:

MPC-HC.1.8.7.x64.exe: 03C3D6D6DEEC183AC619AD047EE0265D852356C1532684F7AADCD8CEF5834730

MPC-HC.1.8.7.x64.zip: 193D14FD8FB8C151402E2D820BACFADC19FED44E45DD60BF79E238DCB8749A3E

MPC-HC.1.8.7.x86.exe: D0EEB300B8AFAE92A0A99E5810172CC1211921014E58A98F92D7F008E0A6E524

MPC-HC.1.8.7.x86.zip: F5AC249896B4254A0D9CFA3F66DB57B0DEDA2B462787C8B5BD08532FDB4E5B93

Hashtab.

[bitterman]

Thanks.

[sam0t]

Thx clsid for your work. *Thumb up*

[Nintendo Maniac 64]

Good to see that video width for youtube-dl is now discretely taken into account behind-the-scenes so that setting "YDLMaxHeight" to '1080p' will not serve you 2560x1080 on 4k videos with ultrawide aspect ratios and will instead serve 1920x810.


Anyway, I've been testing the new "YDLVideoFormat" setting and my results are the following:

• 0 - same behavior as v1.8.6
• 1 - AVC @ 30 fps
• 2 - AVC @ 60 fps
• 3 - VP9 @ 30 fps
• 4 - VP9 @ 60 fps
• 5 - VP9.2 + HDR @ 30 fps
• 6 - VP9.2 + HDR @ 60 fps
• 7 - AV1 @ ??? fps
• 8 - AV1 @ ??? fps

I do have concerns however about the selection behavior of 30 fps vs 60 fps. As one would expect, if you set it to 60 fps and that format isn't available, it'll fall back to 30 fps and setting it to 30 fps even when 60 fps is available will result in you always getting 30 fps - nothing wrong with either behavior in my eye.

The problem is when you set it to an according 30 fps format, such as "7" and it's not available while the accompanying 60 fps format is, it'll then choose said 60 fps format. This is most apparent on this video where the AV1 and VP9.2+HDR formats are only available in 60 fps, and setting them to their according 30 fps formats instead results in the equivalent 60 fps format being played for a given resolution.

And because I am unable to find a video with AV1 encodes in both 60 fps and 30 fps (only one or the other), this behavior means I am also unable to determine which "YDLVideoFormat" AV1 setting is for 30 fps or 60 fps.


In general, this is not exactly ideal behavior due to bandwidth (more likely for VP9.2) and/or processing requirements (more likely for AV1), and I would think that it would make more sense if it instead fell back to the highest quality codec where 30 fps is available at a given resolution (it's worth mentioning however that, since YouTube's AV1 encodes don't seem to support HDR at this time, it'd probably be wise to make sure AV1 doesn't doesn't fall back to the HDR VP9.2 encodes).



EDIT: I just realized, with that same HDR Costa Rica video, regardless of whether "YDLMaxHeight" is set to '720', '1080', or the default '1440', it'll always choose the HDR VP9.2 encodes when "YDLVideoFormat" is set to the default of '0' even though no computer electronic device in my house is even HDR capable.

Is this in fact the correct behavior?

Now I realize MPC-HC doesn't have built-in HDR functionality nor is it planned, but hypothetically if it did then wouldn't it either 1. be able to display HDR video on SDR displays and OSes that lack HDR support without issue anyway or 2. be able to include or exclude YouTube's HDR encodes depending on whether your display and/or OS is HDR-enabled or not?

(for reference this isn't even an issue for me since I change the default "YDLVideoFormat" setting to something else anyway)




EDIT 2: Just noticed a super minor GUI, uh...well it's not a bug but it's a default setting that is less than ideal.

So in "Advanced" on the "Options" window, the default size of the "Value" header is small enough that changing the value for "YDLMaxHeight" to any other 4-digit number will cause the text to turn into two digits followed by "..." because the bold text takes up more room horizontally.

Obviously the user can just expand how much horizontal room the "Value" header takes up, but it still seems like something that's kind of silly for a default setting when all it needs is like just a couple more pixels.

[clsid]

Uhmm, the available values for that option are shown in its tooltip when you hover above it.

Auto value will pick a stream based on resolution and bitrate. It can't read your mind about whether you want HDR or not. Others probably do want HDR when playing such a video. Also, you don't need HDR equipment, as madVR can convert it to SDR.

I could make it prefer regular VP9 in case madVR isn't used. But not high on my todo list right now.

The GUI issue doesn't happen here.

[Nintendo Maniac 64]

Originally Posted by clsid

Uhmm, the available values for that option are shown in its tooltip when you hover above it.

Well then, I'm a derp.

(my concerns regarding the 30fps vs 60fps choosing behavior is still present however)

[clsid]

Do you have an example link where VP9 is only available as 60fps, and H.264 is available as 30fps?

[Nintendo Maniac 64]

Originally Posted by clsid

Do you have an example link where VP9 is only available as 60fps, and H.264 is available as 30fps?

For VP9 non-HDR specifically and not VP9.2 nor AV1? No - AFAICT that discrepancy in available encodes does not occur with VP9 non-HDR and AVC.


If you're OK with a video where that discrepancy occurs only for VP9.2 and AV1, then that costa rica video I linked to previously is like that:

https://www.youtube.com/watch?v=LXb3EKWsInQ&t

That is, for AVC and VP9 the 30fps and 60fps formats are available, but for VP9.2 and AV1 only the 60fps formats and none of the 30fps formats are available.

One interesting thing though is that the AV1 encodes still follow the normal behavior in that, below 720p, it becomes 30fps only. However, the VP9.2 encodes actually remain only 60fps all the way down to 240p and 144p.

[dim]

Any idea why black bars are not detected by madvr ? Works ok in other players. Tried starting with a clean .ini but it persists.

[sneaker_ger]

Do you use native DXVA2 or native D3D11? Black bar detection isn't supported by madvr, then.

[dim]

@sneaker_ger
thank you so much, I wouldn't have guessed.

[Nintendo Maniac 64]

Originally Posted by sneaker_ger

Do you use native DXVA2 or native D3D11? Black bar detection isn't supported by madvr, then.

Do you know if black bar detection is supported with LAV's CUVID and QuickSync decoders?