Hardware accelerated playback on PineTab 2 (RK3566)
Want to quickly document how I got my PineTab 2 to play 1080p videos smooth(-ish) with hardware acceleration.
- PineTab2 can play 1080p 60fps perfectly smooth with hardware acceleration
ffmpeg-v4l2-request-gitfrom the AUR
- Play with
mpv --hwdec=drm --vo=gpu-next --wayland-disable-vsync=yes
- There'll be lag when MPV first shows control UI. But non after that.
- If you are on a Wlroots based compositor, use
--vo=dmabuf-waylandto reduce CPU usage
Enabling hardware acceleration
With the defaul DanctNIX image, it was quite easy. Simply install
ffmpeg-v4l2-request-git from the AUR. Then, pass pass
mpv and you're good to go. This will replace replace the system's
ffmpeg with your custom build. If you run into ABI issues (random crashes), you can try building MPV from source.
$ yay -S mpv ffmpeg-v4l2-request-git
For Ubuntu, you can simply look at Arch's PKGBUILD and replicate the steps.
According to Pine64's wiki, the mainline kernel supports the following formats:
IMPORTANT: As of writing, it DOES NOT support H.265/HEVC and VP9. Which YouTube uses by default. Thus, even though Chromium might pick up the fact that hardware acceleration is available, YouTube will still use software decoding. Also, this only supports up to 1080p even though the hardware is capable of higher resolutions.
I did some quick tests with various videos I grabbed from YouTube and transcoded to H.264 using the
slower preset. Then played them back with
mpv --hwdec=drm --vo=gpu-next on KDE Plasma. The results are as follows:
Without hardware acceleration:
- 720p 24fps: No dropped frames
- 720p 60fps: ~30 dropped frames per second (half the frames missing!!)
- 1080p 60fps: Don't even bother
With hardware acceleration:
- 720p 24fps: No dropped frames
- 720p 60fps: ~1 dropped frame per second
- 1080p 25fps: No dropped frames
- 1080p 60fps: Running at about 45FPS in average.
Finally, seems like decoding H.264 is slightly more efficient than VP8. Stick to H.264 if you can.
I'm curious about how the frame drops happened. Seems the hardware decoder is cabible. Something on the software side is messing up. Maybe some setting up can resolve it. I've noticed lag in KWin when I started using the PineTab 2. Maybe it's a compositor issue? Or is it actually because of copying the frames?
So I tried the
dmabuf-wayland backend but MPV reported the compositor does not support passthrough for NV12. This forced me to use another compositor (Weston). It resulted in 20% less dropped frames. But at the cost of frame tearing when frames are dropped. (Weston is buggy on the PineTab 2, the terminal failed to render properly. I had to type commands blindly and redirect to see the output.)
--vo=gpu but it resulted in 10% more dropped frames. Definitely stick to
Output scaling doesn't seem to affect performance.
Switching to Sway
I decided I don't want to use KDE. It's touch friendly. But I don't see myself using this "tablet" without a keyboard. A large in part due to planing on mostly coding on it. So I switched to Sway. That had an surprising effect on performance. I'm now getting almost no dropped frames on 1080p 60fps videos using
gpu-next and fullscreened. Playback is perfectly smooth. Droppig only 600 frames in a 4:30 video.
dmabuf-wayland is also qutie good. But more dropped frames. Which is very unexpected.
GALLIUM_HUD="fps,cpu" and discovered during 720p playback, the FPS is stadity right below 60. Instinctly I suspect this is a vsync issue. So I tried
--wayland-disable-vsync=yes and it worked! No more dropped frames, not even in 1080p 60fps videos. The same is true on KDE. I suspect there's a bug in how the driver handles vsync.
- 720p 60fps: No dropped frames
- 1080p 60fps: No dropped frames
Furthermore, with a perfect playback. I can now use
--vo=dmabuf-wayland to get a nice CPU use reduction. Playing a 1080p 60fps video now only uses 80% out of 400% CPU.
Systems software, HPC, GPGPU and AI. I mostly write stupid C++ code. Sometimes does AI research. Chronic VRChat addict
- marty1885 \at protonmail.com
- Matrix: @clehaxze:matrix.clehaxze.tw
- Jami: a72b62ac04a958ca57739247aa1ed4fe0d11d2df