RPI4 - video playback

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

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?


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.



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.


RPI4 - mpvI’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.


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.

Raspberry Pi 4 Blog
Week 36Manage your personal collections on the RPI4
Week 35Survey of terminal emulators
Week 34Search the desktop with the latest version of Recoll
Week 33Personal Information Managers on the RPI4
Week 32Keep a diary with the RPI4
Week 31Process complex mathematical functions, plot 2D and 3D graphs with calculators
Week 30Internet radio on this tiny computer. A detailed survey of open source software
Week 29Professionally manage your photo collection with digiKam
Week 28Typeset beautifully with LyX
Week 27Software that teaches young people how to learn basic computing skills and beyond
Week 26Firefox revisited - Raspbian now offers a real alternative to Chromium
Week 25Turn the Raspberry Pi 4 into a low power writing machine
Week 24Keep the kids learning and having fun
Week 23Lots of choices to view images
Week 22Listening to podcasts on the RPI4
Week 21File management on the RPI4
Week 20Open Broadcaster Software (OBS Studio) on the RPI4
Week 19Keep up-to-date with these news aggregators
Week 18Web Browsers Again: Firefox
Week 17Retro gaming on the RPI4
Week 16Screen capturing with the RPI4
Week 15Emulate the Amiga, ZX Spectrum, and the Atari ST on the RPI4
Week 14Choose the right model of the RPI4 for your desktop needs
Week 13Using the RPI4 as a screencaster
Week 12Have fun reading comics on the RPI4 with YACReader, MComix, and more
Week 11Turn the RPI4 into a complete home theater
Week 10Watching locally stored video with VLC, OMXPlayer, and others
Week 9PDF viewing on the RPI4
Week 8Access the RPI4 remotely running GUI apps
Week 7e-book tools are put under the microscope
Week 6The office suite is the archetypal business software. LibreOffice is tested
Week 5Managing your email box with the RPI4
Week 4Web surfing on the RPI4 looking at Chromium, Vivaldi, Firefox, and Midori
Week 3Video streaming with Chromium & omxplayerGUI as well as streamlink
Week 2A survey of open source music players on the RPI4 including Tauon Music Box
Week 1An introduction to the world of the RPI4 looking at musikcube and PiPackages

This blog is written on the RPI4.

Share this article


  1. Excellent details. Thank you for writing this and your other Rpi4 blog posts.
    Which an enabled hardware H.264 video decoding, how much program app dram memory is necessary to pass through the video stream from local storage into gpu memory for display.? The percentage of cpu useage was a useful measurement.

    Fascinating life time going from 64Kilobyte dram memory in 1982 to hardware decoding 720p or 1080p H.264 or H.263 video streams for the $55 USD Raspi4. How much Dram memory you recommend 4 , 2, 1 gig on the Raspi4

    1. That’s a good question Fred. I’m going to devote a blog post to memory looking at how much is consumed by the system and various desktop apps, which should help folk decide which of the RPI4 models is best suited for their specific requirements.

Share your Thoughts

This site uses Akismet to reduce spam. Learn how your comment data is processed.