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 ! glimagesink

This pipeline will only play the video and there is no buffering, but you get the idea.

Posted on 3 Oct 2014, 6:41 - Categories: FatdogArm Linux Arm
Comments - Edit - Delete


FatdogArm Beta2 release

FatdogArm Beta2 is a minor release, mainly:
- bugfixes and upstream update from Fatdog64 700
- updated kernel package for Odroid U2/U3 with r4p0 Mali driver
- introducing support for cubox-i (Freescale i.MX6DL/i.MX6Q SoC)

Release note here.
Get it from here or any of ibiblio mirrors.

Posted on 1 Oct 2014, 19:04 - Categories: FatdogArm Linux Arm
Comments - Edit - Delete


1080p video playback on cubox-i

I have been experimenting with hardware acceleration for video playback on i.MX6 (cubox-i), that came with Freescale BSP. The most recent released for Freescale BSP is version 3.10.17, for their kernel GA 3.10.17.

Hardware acceleration of anything is a fickle thing, because there are non-standard ways of doing things (one may disagree and says that there are too many standards to choose from: vdpau, vaapi, openmax, gstreamer, and others). In the end, different hardware vendors supports their hardware with different libraries.

Freescale chooses to use gstreamer to support video playback acceleration. It comes are a set of open-source gstreamer plugins, which links to closed-source VPU* and IPU* libraries, for gstreamer 0.10. Yeah that's the old version but it still works. Freescale has a newer (semi-official?) "community"(?) gstreamer 1.0 libraries but the support is not identical with 0.10 libraries.

[*Note: VPU is Freescale's hardware video processing unit, and IPU is Freescale's hardware Image Processing Unit]

The 0.10 libraries are purely VPU/IPU based and does not depend on a working GPU. It has a few plugins: a demux plugin ("aiurdemux") that recognises certain common formats like AVI, MKV, WEBM, MP4 and others, a VPU-assisted video decoder ("vpudec") and a video renderer (sink) that is IPU-assisted (mfw_v4lsink), among others.

If this sounds like alien language, let me translate it for you: "demux" is the one that splits a media file into its video and audio component (so they can be routed and processed by different components). "video decoder" is the one that decompress the video file and outputs raw video data, and "video renderer" is the component that takes that raw video data and display it on screen (possibly converting the formats in between).

Together they form a hardware accelerated video playback pipeline that can play 1080p video effortlessly with less than 10% CPU usage. As a comparison, even the quad-core i.MX6Q cannot play 1080p video smoothly using only its ARM cores alone.

There are just a few hiccups. The plugins apparently can't rotate the playback when you launch it using gst-launch (e.g see here - although if you use the gplay tool it would work), and if you try to use the plugin to play video on a rotated display (rotated using xrandr etc), then video playback gets totally wrong. This is mainly because certain parts of plugin follows X coordinate orientation, while other parts of it are stuck with real CRTC coordinates (that is, they aren't rotated).

I've done some fixes on that and the gstreamer plugins can now play video in any orientation (even from gst-launch) as well as in any display orientation. As a bonus, I have the code that makes video playback rotated following the display rotation automatically. Of course, because the final rendering is done by IPU, this is only possible if the size of the video output is not more than 1024x1024 pixels - this is an IPU limitation which isn't easily bypassed.

Combined with this: gstreamer npapi plugin, one can make an alternative video player plugin that provides accelerated video playback (compared to xine-plugin or vlc-plugin, for example); and when built with the "fixed" version, the video will play correctly on any display orientation. I know that, I've built one myself. It runs nicely on FatdogArm :)

Posted on 27 Sep 2014, 4:51 - Categories: FatdogArm Linux Arm
Comments - Edit - Delete


FatdogArm on Cubox-i - update

FatdogArm now runs with Cubox-i i2w and i4p; supporting all features of FatdogArm plus i.MX6-specific hardware acceleration (vivante video driver, VPU, gstreamer, ALSA hardware resampler). Cubox-i is the *the only* ARM platform I have where you xrandr works correctly and you can change resolution on the fly. Kudos to Freescale to make this happen.

On the other hand, the only thing currently not working on Cubox-i is the GPU (OpenGLES stuff). I have an open thread in the forum here: http://www.solid-run.com/community/post9713.html#p9713. All my other ARM platforms have their GPUs running, this is the only platform which it isn't (you've got Xorg hard lockups when trying to run any OpenGLES programs with GPU acceleration).


Posted on 8 Jul 2014, 4:23 - Categories: FatdogArm Linux Arm
Comments - Edit - Delete


FatdogArm on Cubox-i

As part of an on-going project that I'm doing with someone, I have received Cubox-i devices and is currently porting FatdogArm to them. It is still early days, but I've got FatdogArm running on Cubox-i i4p.



Posted on 12 Jun 2014, 4:35 - Categories: FatdogArm Linux Arm
Comments - Edit - Delete


FatdogArm Beta1 kernel packages re-uploaded

If you have downloaded FatdogArm Beta1 recently, please re-download the kernel packages again. The ones I uploaded before have one leftover settings from my development that I forgot to turn off: they have SSH server enabled by default. You can easily turn them off using the Control Panel --> Services Manager, or just
chmod -x /etc/init.d/S50dropbear
but it is a hassle.

The newly-uploaded kernel packages have SSH disabled by default.

Note: I have just re-uploaded the kernel packages, and it usually takes about 24 hours for the mirrors to sync. So either hit ibiblio.org directly or wait 24 hours from this post before hitting your favorite mirror.

Posted on 13 Mar 2014, 19:33 - Categories: FatdogArm Linux Arm XO
Comments - Edit - Delete


FatdogArm Beta1 is released.

After being in the cooker for over two months, I can happily announced the next release of FatdogArm: the Beta1 release.

Get it from ibiblio.org as usual, or from one of ibiblio's popular mirrors: nluug.nl and uoc.gr if you're in Europe, or aarnet.edu if you are in Australia. Many thanks for ibiblio and the mirrors for providing this public service.

Read the release notes first; and if you are new to FatdogArm, please also read the INSTALL instructions. Unlike many of Linux ARM distributions out there, FatdogArm is *not* distributed as images.

Forum announcement here.

FatdogArm Beta1 is the second-generation of FatdogArm; despite its name it is *not* a continuation of Alpha: it is in fact a full-rebuild using LFS 7.4 as the base (I would like to claim "the latest LFS" but LFS 7.5 had just been released as I was gearing for release, oh well) with glibc 2.18 and gcc 4.8.1 but otherwise with many of the packages remain identical with its Alpha counterpart (updates are only done for stability reasons).

The major goal of Beta is a change of hardware platform (from VFPv3-d32 to VFPv3-d16 *without* NEON) to enable it to run on larger class of hardware; as well as a fully-reproducible build system. As a bonus, Beta1 also supports 3D GPU acceleration for all supported platforms, which are: Odroid-U2, Odroid-U3, A10/Mele A1000, A20/Cubieboard2, OLPC XO-1.75 and OLPC XO-4.

Just like Alpha4, Beta1 also ships as a "meta-distribution" (now conveniently provided as a tarball instead of fossil repository) that enables you to build your own customised version as you see fit: headless console-only version; etc. All the kernel sources are provided (kernels were cross-compiled using Linaro cross-toolchain)) so you can also also build new modules etc if you need.

Special thanks to mavrothal and 01micko for OLPC XO support and testing.

Enjoy.


Posted on 11 Mar 2014, 23:11 - Categories: FatdogArm Linux Arm XO
Comments - Edit - Delete


Gearing for FatdogArm Beta1 release

In preparation for FatdogArm Beta1 release, I have removed Alpha3 images and binaries from ibiblio to make some space. Alpha4 will remain for the moment, I will probably remove them when Beta is considered "stable" enough.

I have also updated the article about how to run FatdogArm in Qemu (and the example shell script) for use with Alpha4 onwards (which no longer ships as images) - the instruction will also be useful for Beta1 when it is released.

Posted on 10 Mar 2014, 17:48 - Categories: FatdogArm Linux Arm
Comments - Edit - Delete


3D hardware acceleration on FatdogArm Beta

FatdogArm beta hits another milestone today: I've got 3D hardware acceleration running on Mele/Cubieboard2 and Odroid-U2. As it happens all of them use the Mali GPU variants.

It's quite cool to watch es2gears and glmark2-es2 running on all these boards.
As a reference, here are their glmark2-es2 scores:
Mele A1000 (A10) - 53
Cubieboard2 (A20) - 63
Odroid-U2 (Exynos4412) - 123

Remember that FatdogArm Beta is built with VFPv3-d16 (just like Debian armhf) and no NEON.

The 3D acceleration on all these uses the same Xorg driver (fbturbo) and the appropriate version of Mali blobs, all coming from sunxi-mali (from linux-sunxi repository).

All of this is made possible by the hard work of linux-sunxi folks; especially Siarhei Siamashka (ssvb) who maintains xf86-video-fbturbo (formerly xf86-video-sunxi), Luc Verhaegen (libv) who maintains the sunxi-mali repo (Luc is also the man behind the Lima open-source Mali driver effort), and Dmitriy Beykun (rzk) who ported version 20 of Mali kernel interface from upstream to Odroid kernel.

Thanks guys!

Note: I managed to get 3D acceleration done (but not tested) on XOs much earlier last year (with dovefb/libgfx-marvell); but in FatdogArm beta it will ship disabled by default as enabling it will corrupt the display on some circumstances.


Posted on 26 Feb 2014, 5:57 - Categories: FatdogArm Linux Arm
Comments - Edit - Delete


FatdogArm Beta reaches parity with Alpha4 today

As the title says. The (unreleased) Beta version of FatdogArm reaches functional parity with Alpha4 today. All that is needed to be done now is testing on all the supported platforms; then we should be good for release.

Posted on 9 Feb 2014, 3:41 - Categories: FatdogArm Linux Arm XO
Comments - Edit - Delete


Pages: [1] [2] [3] [4] [5] [6]