No HW Acceleration for some 4K videos

Just tested it, works great with all the samples i have with DXVA copy-back. Thanks a lot.

Also, i just noticed "D3D11" in LAVs HW decoder dropdown menu. Is this new? I don't remember seeing it in the past. It gives me slightly better performance with the same samples (according to the stats display) but it does push the intel GPU to 85% and makes my laptop fan start spinning (it's usually passive while idle or even watching videos with DXVA). Also, choosing the nvidia GPU (optimus) doesn't seem to work, hw acceleration doesn't kick in. I'm not really surprised since GPU's with optimus tech from nvidia were always incompatible with some kinds of software (nvidia CUVID for ex also doesn't work for me), even forcing the nvidia gpu on the control panel. Anyway, DXVA already gives me real-time playback so i'll stick to it. I'll try some heavier videos in the morning or even higher resolutions to see the difference.

nikkoaki wrote:Just tested it, works great with all the samples i have with DXVA copy-back. Thanks a lot.

Also, i just noticed "D3D11" in LAVs HW decoder dropdown menu. Is this new? I don't remember seeing it in the past. It gives me slightly better performance with the same samples (according to the stats display) but it does push the intel GPU to 85% and makes my laptop fan start spinning (it's usually passive while idle or even watching videos with DXVA). Also, choosing the nvidia GPU (optimus) doesn't seem to work, hw acceleration doesn't kick in. I'm not really surprised since GPU's with optimus tech from nvidia were always incompatible with some kinds of software (nvidia CUVID for ex also doesn't work for me), even forcing the nvidia gpu on the control panel. Anyway, DXVA already gives me real-time playback so i'll stick to it. I'll try some heavier videos in the morning or even higher resolutions to see the difference.

The 3 main differences with D3D11VA and DXVA is

1) D3D11VA uses Direct3D11 for video functionality instead of Direct3D9
2) Video decoders can selectively switch between native and copy-back for performance reasons.
3) It only works on Windows 8+ for technical reasons(on Windows 7 it will end up in a black screen).

For the rest D3D11VA and DXVA are exactly the same and any GPU supporting Direct3D 11 and DXVA 2.0 will support D3D11VA.

The main reason you're seeing a performance increase is either because LAV chose native instead of copy-back, or because Direct3D11 video functionality is slightly more efficient.

Edit: It only doesn't work on Windows 7 and below, on Windows 8.0 it does work according to this post https://github.com/mpv-player/mpv/issues/3285

Admin wrote:Disable the internal decoder in MPC-HC. It currently only works for external instance of LAV Video.

Disabled the internal filters but it still doesn't work. I installed the beta package of the codec pack(standard).

notcyf wrote:
The 3 main differences with D3D11VA and DXVA is

Yeah, yesterday i did a bit of research and found that information here in this forum. I should have searched first instead of asking. I thought i had a more up to date codec pack.

notcyf wrote:
because LAV chose native instead of copy-back

Says copy back in the stats display. It's a small difference anyway. What kind of sucks for laptop users is that it uses way more GPU power compared do DXVA2 (95% @9W compared to 46% @4W), at least for me.

notcyf wrote:
Disabled the internal filters but it still doesn't work.

Strange, it's working for me. Can you confirm in the stats display that it's not saying "LAV video decoder (internal)"?
EDIT: i forgot, be sure that the external filters have all the correct check-marks enabled too (h264 and 4k)

nikkoaki wrote:

notcyf wrote:
The 3 main differences with D3D11VA and DXVA is

Yeah, yesterday i did a bit of research and found that information here in this forum. I should have searched first instead of asking. I thought i had a more up to date codec pack.

notcyf wrote:
because LAV chose native instead of copy-back

Says copy back in the stats display. It's a small difference anyway. What kind of sucks for laptop users is that it uses way more GPU power compared do DXVA2 (95% @9W compared to 46% @4W), at least for me.

notcyf wrote:
Disabled the internal filters but it still doesn't work.

Strange, it's working for me. Can you confirm in the stats display that it's not saying "LAV video decoder (internal)" in the stats display?
EDIT: i forgot, be sure that the external filters have all the correct check-marks enabled too (h264 and 4k)

Found the issue: The regkey paste Admin provided had some spacing error caused the DWORD to end up being 0x00000000 rather than 0x00000001

Edit: Still not working for some reason, it does not say (internal) since i added LAV Video Decoder to the external filter list and disabled the internal filter.
Edit2: Never mind, i got it working because i fiddled with some settings trying to get it to work, reverted those and it's now working:
https://i.imgur.com/8clESmM.png
You do not have to enable the external filter since MPC-HC will use the merit system of DirectShow to pick the correct decoders if the internal filters are disabled.

The only thing that's still in question is if this is going to work on all videos encoded by Android's MediaCodec's Baseline profile. If it does this is an issue that should be reported to AOSP because it could be a misconfiguration.

D3D11VA only switches to native mode when used together with MadVR. In other cases it runs in copyback mode. If you specifiy which GPU it must use, then it also uses copyback.

D3D11VA should give a tiny bit better performance than DXVA2. The higher CPU usage is strange and might be Intel (or Optimus) specific. Using Nvidia probably requires setting Nvidia as default GPU for the player. You can do that with NVIDIA Profile Inspector tool.

Yes, it would be interesting to test it with videos from a few different phones. If all work then this tweak can maybe be enable by default. Stuff encoded with x64 in baseline profile is also compatible. There are probably not many other common sources of H264 video with baseline profile.

Admin wrote:D3D11VA only switches to native mode when used together with MadVR. In other cases it runs in copyback mode. If you specifiy which GPU it must use, then it also uses copyback.

D3D11VA should give a tiny bit better performance than DXVA2. The higher CPU usage is strange and might be Intel (or Optimus) specific. Using Nvidia probably requires setting Nvidia as default GPU for the player. You can do that with NVIDIA Profile Inspector tool.

Yes, it would be interesting to test it with videos from a few different phones. If all work then this tweak can maybe be enable by default. Stuff encoded with x64 in baseline profile is also compatible. There are probably not many other common sources of H264 video with baseline profile.

Yeah i just meant that the functionality is there, despite only MadVR using the feature.

The only common tool that might use Baseline is FFMPEG, which already sets the proper flags for DXVA compatibility, so it seems that this is solely present in Android phones.

There might be other hardware based encoders too, for example those uses in DVRs and security cameras.

notcyf wrote:
The only thing that's still in question is if this is going to work on all videos encoded by Android's MediaCodec's Baseline profile. If it does this is an issue that should be reported to AOSP because it could be a misconfiguration.

It affects more than android, and it may be specific to the soc manufacturer.. From what i've read, you can ask mediacodec for a specific profile/level and mediacodec will pass that info to the proprietary codecs. It's up to the codecs to produce the right files: READ HERE AND HERE

Here is some action camera samples that suffer from the same problem, the polaroid cube:
https://my.pcloud.com/publink/show?code=kZpyA4ZKXc74Ictjp4gRlu7zU4lb7kRiTz7#page=login

Here are some samples of the phone list i mentioned earlier.. they are all Baseline and now work fine:

https://cdn.gsmarena.com/imgroot/reviews/17/oneplus-5/camera/gsmarena_v001.mp4
https://cdn.gsmarena.com/imgroot/reviews/17/xiaomi-mi-mix-2/camera/gsmarena_v001.mp4
https://cdn.gsmarena.com/imgroot/reviews/17/nokia-8/camera/gsmarena_v001.mp4

admin wrote:
The higher CPU usage is strange and might be Intel (or Optimus) specific. Using Nvidia probably requires setting Nvidia as default GPU for the player. You can do that with NVIDIA Profile Inspector tool..

It's the intel GPU that skyrockets, the cpu stays the same.
Forcing to open a video with the nvidia gpu as default will give me a black screen and hang MPC-HC, doesen't matter what type of hw decoder is selected. It was always like this and googling a bit online reveals i'm not the only one with this problem.. optimus can really suck in some situations.

nikkoaki wrote:

notcyf wrote:
The only thing that's still in question is if this is going to work on all videos encoded by Android's MediaCodec's Baseline profile. If it does this is an issue that should be reported to AOSP because it could be a misconfiguration.

It affects more than android, and it may be specific to the soc manufacturer.. From what i've read, you can ask mediacodec for a specific profile/level and mediacodec will pass that info to the proprietary codecs. It's up to the codecs to produce the right files: READ HERE AND HERE

Here is some action camera samples that suffer from the same problem, the polaroid cube:
https://my.pcloud.com/publink/show?code=kZpyA4ZKXc74Ictjp4gRlu7zU4lb7kRiTz7#page=login

Here are some samples of the phone list i mentioned earlier.. they are all Baseline and now work fine:

https://cdn.gsmarena.com/imgroot/reviews/17/oneplus-5/camera/gsmarena_v001.mp4
https://cdn.gsmarena.com/imgroot/reviews/17/xiaomi-mi-mix-2/camera/gsmarena_v001.mp4
https://cdn.gsmarena.com/imgroot/reviews/17/nokia-8/camera/gsmarena_v001.mp4

admin wrote:
The higher CPU usage is strange and might be Intel (or Optimus) specific. Using Nvidia probably requires setting Nvidia as default GPU for the player. You can do that with NVIDIA Profile Inspector tool..

It's the intel GPU that skyrockets, the cpu stays the same.
Forcing to open a video with the nvidia gpu as default will give me a black screen and hang MPC-HC, doesen't matter what type of hw decoder is selected. It was always like this and googling a bit online reveals i'm not the only one with this problem.. optimus can really suck in some situations.

Yes, but these are just the profile levels. The problem here is that the Baseline profile(no matter the profile level) is not using the Constrained Baseline flag as defined in A2.1.1 in the h.264 spec which states that if a encoder/decoder has both the constraints defined in A2.1(Baseline) and A2.2(Main) it is compatible with A2.1.1. The problem is that Android's MediaCodec is not using this flag *by default*, and that is the problem, because (for example) most hardware manufacturers probably don't even know that their files produced aren't going to work on Windows DXVA thanks to Google's defaults.

Also, all these files you just posted, work absolutely fine on DXVA(i do not see any artifacts or weird issues) with the registry key, even though they are not Constrained Baseline-flagged files as required by the DXVA specification.

I wouldn't be able to play these files without DXVA on my older laptop(4th generation i5), because 4K h.264 really lags on the software decoder for me. This is brilliant.

notcyf wrote:
Yes, but these are just the profile levels.

What i meant is that it may actually be the proprietary encoders that puts (or don't) those flags. I may be wrong, i know nothing about this.. i just get the idea (from reading) that the mediacodec api is just an easy way to talk to these encoder/decoders.

I don't know, you may be right.. in <here> there is nothing about "constrained baseline" so maybe they don't go to the effort to put the flag because they only care that the device can do unconstrained baseline anyway.

BTW, https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/844522-h264-hardware-decoding
It seems to affect VDPAU too (or did)

EDIT:
Also, this is a good read (and seems very recent), it's about chrome but it's video encoding so it's relevant: https://bugs.chromium.org/p/chromium/issues/detail?id=761336

I have talked with Qualcomm about what their HW encoders produces, and it does not produce any bitstream which is outside of CBP tool set. That is why we are negotiating Constrained Baseline for the HW codecs in the Android native library. It's not lying, even though MediaCodec documentation says Baseline.

So it's not a matter of a missing flag but android not supporting it in the first place?

nikkoaki wrote:

notcyf wrote:
Yes, but these are just the profile levels.

What i meant is that it may actually be the proprietary encoders that puts (or don't) those flags. I may be wrong, i know nothing about this.. i just get the idea (from reading) that the mediacodec api is just an easy way to talk to these encoder/decoders.

I don't know, you may be right.. in <here> there is nothing about "constrained baseline" so maybe they don't go to the effort to put the flag because they only care that the device can do unconstrained baseline anyway.

BTW, https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/844522-h264-hardware-decoding
It seems to affect VDPAU too (or did)

EDIT:
Also, this is a good read (and seems very recent), it's about chrome but it's video encoding so it's relevant: https://bugs.chromium.org/p/chromium/issues/detail?id=761336

I have talked with Qualcomm about what their HW encoders produces, and it does not produce any bitstream which is outside of CBP tool set. That is why we are negotiating Constrained Baseline for the HW codecs in the Android native library. It's not lying, even though MediaCodec documentation says Baseline.

So it's not a matter of a missing flag but android not supporting it in the first place?

That quote literally states that the bitstream complies to the Constrained Baseline Profile which means (for us) it should be fine to use DXVA on videos produced by any Qualcomm device.

It also runs fine on my S8+ which is an Exynos 8895

This is also only the case for files produced by Chrome on Android to Windows, which sounds like almost the same problem as that we had here, and it seems like that Google is aware of the issue.

The H264 profile negotiated is meaningless to Android at present. No matter what profile is negotiated, MediaCodec will encode H264 in its own way. So just munge the SDP to get the negotiation done, i.e. force it to be BP or CBP bidirectionally.

For Android users that record videos, it seems like the Baseline profile is hardcoded.

I totally misunderstood it then, thanks.