Raspberry Pi 4: Chronicling the Desktop Experience – Watching Video – Week 10

Last Updated on March 18, 2020

This is a weekly blog about the Raspberry Pi 4 (“RPI4”), the latest product in the popular Raspberry Pi range of computers.

I’ve previously examined how the RPI4 performs streaming video in Week 3 of my blog. This week, I’m looking at video playback from locally stored media.

Does the RPI4 have sufficient grunt to be a capable video device?

OMXplayer

The obvious first port of call is OMXplayer. It’s a command-line player which is hardware accelerated, leveraging the OpenMAX API to use the RPI4’s hardware video decoder in the GPU. The Pi Foundation claims the program plays many popular audio and video file formats, offers low power video playback, together with ultra low consumption of CPU cycles. If you must have a GUI frontend, there’s omxplayerGUI which I talked about in Week 3.

It’s important to recognize OMXplayer only supports some codecs, specifically GPU hardware codecs. This means that you’re restricted to H.264, VP6, VP, and a few other codecs. H.263, H.265, MPEG4, MPEG2, HEVC and lots of other codecs aren’t supported by the software.

Over the years, I’ve amassed a huge collection of video files, mostly taken with a variety of different camcorders. I’ve got a whole raft of video files coded with H.264, but I have others in DV, HDV, MPEG-2, AVCHD format, and more besides. Straight away, a large chunk of my files aren’t compatible with OMXPlayer. So it’s not a universal solution for video playback. But how does it fare on compatible files?

Even with H.264 encoded files, many wouldn’t play with OMXplayer on my system, with the software just exiting offering a feeble “have a nice day ;)”. And I spent a fair chunk of time investigating possible reasons for the issue, ultimately without success.

For files that play on OMXplayer performance is glorious. With various 720p and 1080p H.264 videos, there are no dropped frames, no panning issues, no tearing. Silky smooth in fact. With CPU usage averaging around 3.5% of 1 core, the experience rivals my main desktop machine. The key sticking point is that tons of my video files don’t start on OMXplayer, so what are the options? Anyone suggesting I re-encode all the videos is living in cloud cuckoo land.

VLC

For many years, VLC on the Raspberry Pi was a definite no-no.  It ran slower than a tortoise on a freezing winter day. But the Raspbian repositories recently started offering VLC packages with hardware acceleration. And the latest version too! There’s therefore no need to get under the bonnet and start compiling your own version any more. Raspbian’s VLC supports MMAL hardware acceleration in overlay mode and inside the video window.

Unlike OMXplayer, VLC played every single video put before it including files encoded with HEVC. Well at least everything in my huge video collection. Great stuff. It’s truly a universal video player on the RPI4.

How’s performance? First, with MP4 videos (H.264 video / AAC audio encoded at 1920×1080 resolution). Playing these videos in windowed mode was a mite disappointing. While top reports the video was consuming around 20-30% of 1 core of the CPU, playback has issues with some tearing or jerkiness on panning. Not that bad but noticeable on occasions, and enough to be an unwelcome distraction. I am somewhat of a perfectionist though. Things are a lot better with videos encoded at anything lower than 1080p.

Watching 1080p videos full screen offers dramatic improvements. Instead of 20-30% CPU usage, it drops to 10-15% of 1 of the CPU cores. More importantly, playback is noticeably more fluid, handing difficult panning scenes extremely smoothly. It’s definitely a great experience in full screen modes with no dropped frames, no unwelcome distractions. Files encoded with the HEVC codec don’t seem to benefit from hardware acceleration.

If you like watching video full screen on one monitor while performing other activities on the second monitor (such as surfing the net, reading/writing emails, doing work etc), you certainly won’t be disappointed with performance.

mpv

I’m very fond of mpv, so I tried that next. The version included in the Raspbian repository doesn’t enable hardware acceleration. This makes a huge impact. For example playing 1080p files you’re landed with extremely high CPU usage, averaging over 300% of the processor (i.e. it uses more than 3 of the 4 cores). Playback was still reasonable but tearing was evident most noticeably in horizontally-moving visuals. Overall, the experience is much worse than VLC. And multi-tasking is out of the question with this unaccelerated Raspbian-compiled mpv.

With 720p H.264 videos, performance is much better. You’ll see CPU usage around 50-60% of 1 core, playback still suffers from distortion, panning problems, tearing etc.

The developers of Raspbian should make a hardware accelerated version of mpv available. For now, you’ll have to follow walkthroughs from RPI4 enthusiasts on the Raspberry Pi 4 forum showing you how to compile your own hardware accelerated version of mpv. But the problem with such guides is that they can quickly go out-of-date, and/or won’t work on your system for various reasons.

Nestling in the Raspbian repositories are lots of alternative video players. These include, in no particular order: Dragon Player, MPlayer, Kaffeine, Snappy, Totem, xine, and Parole. There are also various front-ends including Kylin Video, SMplayer, GNOME MPlayer, and MPlayer GUI. The underlying issue is that without hardware acceleration, RPI4 performance is very disappointing compared to OMXplayer or VLC.

I offer a few comments about a couple of other video players.

Kaffeine is a media player with an easy-to-use interface. With 1080p H.264 videos, CPU usage isn’t that hefty, we’re talking about 30% of 1 core for the Kaffeine process, whereas Xorg usage runs at around 12% of 1 core [which is higher than mpv and VLC].

Is 1080p watchable? Definitely not. While CPU usage is much less than mpv, playback is much worse. There’s loads of tearing, bitting, and panning problems. Videos encoded at lower resolutions fare better.

SMPlayer is a frontend to mpv, so it suffers the same issues as mpv. Unless you compile mpv with hardware acceleration, you’ll be very disappointed.

Raspbian’s package of xine is frankly a complete waste of time. Just don’t bother with it.

Summary

For videos compatible with OMXplayer, you’ll definitely be satisfied. And that’s the case for VLC too if you’re happy to run full-screen or watch 720p videos in windowed mode. For other video players that are available in Raspbian, I cannot recommend them on the RPI4. In fact, unless they support hardware acceleration on the RPI4, they should be removed from the Raspbian repositories. There’s absolutely no point having them present when they are just going to act as a massive disappointment. Many of them are competent media players running on my main Linux desktop. Just not on the RPI4.

If you can get mpv running with hardware acceleration, that’s all well and good. But life’s too short to follow forum scripts that, generally speaking, are poorly implemented. Well meaning enthusiasts I’m sure who spend considerable time and effort to find solutions, but Linux needs to be more than just a tinkerer’s paradise, or where regular users have to jump through hoop after hoop just to install a program.

Instead, what we need are easy-to-install Raspbian packages making use of the RPI4’s GPU acceleration to give us more choice than VLC as a universal media player. RPI4 has more than sufficient grunt to handle HD video with silky smooth playback. The ball’s in Raspbian’s court. The beauty of Linux is really about choice and freedom. And that’s not currently the case with video playback on RPI4, but at least there’s VLC with hardware acceleration.

Home Theatre software (HTPC) is obviously another solution to watching locally stored videos. And Kodi, a sublime HTPC solution, is available for the RPI4. But that’s out of scope for this article. I’ll definitely cover Kodi very shortly.

Read all my blog posts about the RPI4.

This blog is written on the RPI4.