mplayer - H265 problems anyone?

[Dariusz Piatkowski]

That's right...not H264, but H265...

I published another engine building video on my channel a couple of weeks ago, and it being nearly 20 mins made for a pretty good-sized file, even the YouTube 720 version was about 1.6G.

So I went back to my old trusy video encoder, that being HandBrake, which I'm running on the Ryzen7 Win10 box here and played around with a few different setups. Eventually I compared the H264 to a H265 encoding because the Nvidia video card that's in that box supports H265 hardware encoding...YEAH...big improvement, from about 20 mins on Super1080HQ on CPU-alone, to just about 3 mins on the GPU!

Anyways...was pretty happy...but I always do my final review on my OS/2 box to see how the slower hardware handles it. Now here is where the surprise showed up: mpalyer wasn't able to play the H265 video normal. What I mean by that is that the playback was about 1/2 speed and it was definitely single threaded, my CPU monitor would show a single core at 100%, which would switch to another core, etc, etc.

In comparison a regular H264 1080HQ playback normally uses about 15-20% spread on the 6 cores, and it's definitely multi-threaded.

I'm running MPlayer SVN-r38083-9.1.0, smPlayer is just fine and VLC seems to be OK, but for some reason I discovered that none of the 1080 vides are producing video outputs in VLC, but that's a separate issue.

Sooo...I'm curious: has anyone else seen this?

I logged an issue report for this, see => https://github.com/komh/mplayer-os2/issues/11

Thanks everyone!

[Heikki Kekki]

That's right...not H264, but H265...

Anyways...was pretty happy...but I always do my final review on my OS/2 box to see how the slower hardware handles it. Now here is where the surprise showed up: mpalyer wasn't able to play the H265 video normal. What I mean by that is that the playback was about 1/2 speed and it was definitely single threaded, my CPU monitor would show a single core at 100%, which would switch to another core, etc, etc.

In comparison a regular H264 1080HQ playback normally uses about 15-20% spread on the 6 cores, and it's definitely multi-threaded.

I'm running MPlayer SVN-r38083-9.1.0, smPlayer is just fine and VLC seems to be OK, but for some reason I discovered that none of the 1080 vides are producing video outputs in VLC, but that's a separate issue.

Sooo...I'm curious: has anyone else seen this?

I logged an issue report for this, see => https://github.com/komh/mplayer-os2/issues/11

I can see same behaviour.

Code: [Select]

mplayer.exe https://test-videos.co.uk/vids/bigbuckbunny/mp4/h265/1080/Big_Buck_Bunny_1080_10s_2MB.mp4MPlayer 1.4-9.1.0 (C) 2000-2019 MPlayer Team

[Dave Yeo]

Your MPlayer build is likely too old to have a good H265 decoder. MPlayer uses FFmpeg where H265 was likely added first as basic C code with no threading then updated for speed. Another possibility is that FFmpeg used/uses an external library such as H265. You should test with FFplay, perhaps the version that RPM installs.

[Dariusz Piatkowski]

Hi Dave,

Your MPlayer build is likely too old to have a good H265 decoder...

Actually, the SVN signature is there because that is the latest release Ko provided to an issue I previously reported and which he addressed. I actually re-tested with the official current release as well, and the behaviour is the same.

However Dave, good point re:FFMPEG RPM package...I went to install but ANPM is having a problem with the repos at the moment (here anyways) so I'll re-try later on. Good time to replace the numerous other versions of FFMPEG I have on my system today!!