Hardware-accelerated video playback on Odroid U2/U3
Thanks to the effort of many people, I have uploaded gstreamer 1.x libraries (1.4.3) (gstreamer2 and gst2-plugins-* in the repository) which provide support for video playback acceleration on Odroid U2/U3 on FatdogArm.The accelerated pipeline in Odroid U2/U3 goes like this:
- hardware decoding (Samsung S5P MFC codec) - use v4l2video8dec
- hardware colourspace conversion (Samsung FIMC) - use v4l2video10convert
- GPU-assisted rendering - use glimagesink
There were a few hassles to finally get to this.
The hardware decoding was quite a breeze. The kernel has supported the MFC codec for a while. The userspace support was done by a gstreamer plugin called mfcdec, but this was finally deprecated and replaced with v4l2-based decoder in the most recent gstreamer version.
Hardware colourspace conversion didn't work due to a bug in libv4l2, as found out by forum member "memeka" in this post. The library basically assumes that all v4l2 devices can use DMABUF interface to v4l2 devices, but Samsung FIMC kernel drivers don't support that, only normal mmap-ed access. Disabling libv4l2 forces gstreamer to use its own internal code which works with either. So, following his advice, FatdogArm gstreamer libraries are built without libv4l2 dependency. However, the default colourspace converter for gst-play and playbin is unchanged and is still the software decoder (videoconvert) - because forcing the default to Samsung converter results in colour artifacts. If you need to use hardware colourspace converter, you will need to build the pipeline yourself (and if you do this yourself, there is no artifact - the artifact is only seen when using gst-playback/playbin with hardware converter, which is odd).
GPU-assisted rendering is done by glimagesink. This component replaces eglglessink in earlier gstreamer version. Due to a long-standing bug in Mali driver (documented here, found in r3p2 and still exist in r4p0), it doesn't always work (well - it *mostly* doesn't work on my tests). To make it work, I patched the binary driver (it's also in the repo as libmail-odroid).
The result of the acceleration is decent, but it is not as smooth as I hope. "memeka" in another forum post said that the best sink is cluttersink (better than glimagesink). We'll see about that later.
To test that it is all working, try this pipeline (it is one long line):
gst-launch-1.0 filesrc location=/path/to/media.mp4 typefind=true ! qtdemux name=m m.video_0 ! h264parse ! video/x-h264, stream-format=byte-stream, alignment=au ! v4l2video8dec ! v4l2video10convert ! glimagesinkThis pipeline will only play the video and there is no buffering, but you get the idea.
Edit - Delete
No comments posted yet.
