Hardware decoding

[Jimmy-Z]

First of all, thank you for this project and it's a fun ride.

This is more like a discussing thread than a issue report, I'd probably better post on the gentoo forum but that will need me to create an account there, so, if you don't mind.

I'll cut straight to the point though, you seemed to have misinterpreted several things regarding hardware decoding.

SMPlayer does allow you to choose codec, and if you choose h264_mmal and click apply, the setting seems to persist, but that's just regarding the parameter it passes to mpv, not what mpv actually uses, the fact SMPlayer/SMTube is faster than Chrome/Firefox for youtube videos is not because of hardware decoding, it's probably the better rendering path.

To check this, in SMPlayer "Preferences/Advanced/MPlayer/mpv" you can specify a -v parameter then you can check "View/MPlayer/mpv log" to see what's actually going on, or enable the "Run MPlayer/mpv in it's own window" option, then press i on the separate mpv window, the active hwdec option will be visible after the video codec.

To actually use hardware decoding at current state, you need to select "auto-copy" in SMPlayer preferences/Performance/Hardware decoding, h264/avc youtube videos will be using the "mmal-copy" codec now, but the cpu usage will not drop visibly, I suppose the -copy overhead killed the benefit.

Or, simply using mpv -v --hwdec=auto-copy instead, this might solve #162

But, h265/hevc hwdec is not achievable using this, errors like:

[ffmpeg/video] hevc_v4l2m2m: Could not find a valid device
[ffmpeg/video] hevc_v4l2m2m: can't configure decoder
[vd] Could not open codec.
[vd] Falling back to software decoding

this is probably the reason behind #136 --hwdec=v4l2m2m-copy kinda works for h264/avc though, so it's obviously buggy here.

LibreELEC can hardware decode all my test files, even 4K60 hevc ones, too bad I like mpv more than Kodi.

BTW you can check the codec Kodi is using by pressing 'o' in the playing interface.

[sakaki-]

Thanks, that's interesting. Are you able to use the v4l2 or mmal codecs for your test files, if you specify the appropriate codec to ffplay or gst-launch-1.0, as described e.g. here?

[Jimmy-Z]

I didn't test that, but I'd assume there won't be any difference, mpv uses ffmpeg for mmal/v4l2.

And I can't test it now since I only have one micro SD and I'm on Arch now.

You can test with any HEVC file, I suppose the result will be just like that. you can get some hevc test files here: https://kodi.wiki/view/Samples#Codecs.2C_Framerates_and_Subtitles

[acroobat]

You may also want to test 5.4 kernel's video performance.It is future default kernel and it is almost stable for now.

[sakaki-]

The (shortly forthcoming) v1.6.0 image now uses auto-copy by default with SMPlayer. It also uses an rpi-5.4.y kernel and a more extensively patched ffmpeg (now with many of the LibreELEC patches applied - thanks @acroobat for the tip).

Even in the v1.5.4 image though, I have double checked and (as noted e.g. here):

demouser@pi64 ~ $ ffplay -vcodec h264_v4l2m2m -i test.h264

and

demouser@pi64 ~ $ ffplay -vcodec h264_mmal -i test.h264

do both use the RPi's hardware codecs. However, the mpv triggered from SMTube was not, I agree (in the absence of auto-copy), despite the attempt to pass specific codecs down from SMPlayer, so my original text / claim (about SMTube using hardware decoding) was misleading.

Apologies for any confusion >< and thanks @Jimmy-Z for having pointed this out!

best,

sakaki

[Jimmy-Z]

Glad to help :)