Saturday, November 27, 2010

Announcing libdce and gst-ducati

And now it is time to take the wraps off of a weekend/evening project I've been working on for the last couple weeks. Last weekend, I wrote libdce which is a small library to allow for remotely accessing the codec-engine API from linux (without needing OpenMAX). And in the last few evenings plus weekend, I wrote a GStreamer plugin, gst-ducati, to decode video using the codec-engine via libdce.

So far, the following decoders are working:
  • ducatih264dec - H.264 (bp/mp/hp)
  • ducatimpeg4dec - MPEG-4
  • ducativc1dec - VC-1 (sp/mp/ap)
  • ducativp6dec - On2 VP6
  • ducativp7dec - On2 VP7
(The H.264 and MPEG-4 decoders are provided in libdce/firmware/dce_app_m3.xem3 which replaces base_image_app_m3.xem3.. for the other codecs, contact your TI representative.)

Why do this, when (a heavily patched) gst-openmax is providing support for hw accelerated decoding? The main answer is that I thought it would be a fun project, and it gives me a way to play with the codecs directly without OpenMAX getting in the way.

Currently libdce is working with L24.9 versions of syslink and kernel, since that seems to be the versions commonly packaged. But next step I'll update libdce to L24.11 for those who like the bleeding edge.


Update: latest master libdce is working on L24.11.. for L24.9 use the corresponding git tag.

Monday, September 20, 2010

enna + gst + omap4

So.. I've been thinking for a while now that a great project would be an omap4 based media-center-pc. Hardware accelerated 1080p playback (including h264 high profile), dual cortex-a9 SMP, fast 3d acceleration, etc.. quite a worthy replacement for my aging, (ahem, umm.. "upgraded") appletv.

With that in mind, I found enna from the geexbox project. (Check out the slick looking screenshots.) It is built on the collection of EFL libraries for slick looking user interface (with both unaccelerated backend and gles backend for faster UI). It uses libplayer as the backend for media player(s), and libvalhalla for clever stuff like extracting and downloading media metadata (such as album/dvd cover art and info) automagically.

Since I'm currently working with an ubuntu filesystem, I decided to skip for now building the entire geexbox filesystem, and instead just build the equivalent versions of EFL libs, plus enna, libplayer, libvalhalla, etc, for ubuntu. The advantage being that I already have here setup gdb, oprofile, and all the other tools that I find so useful. Plus, it is the filesystem I'm working with day to day, so I don't have to constantly rebuild the userspace components of our multimedia stack for two different filesystems on a regular basis.

Enna's default theme, out of the box, has plenty of eye-candy and effects.. but is a bit sluggish unaccelerated. Especially because the elm_slideshow widget seems to be somehow causing the background images to be repeatedly rescaled, instead of cached.. it doesn't help that the smooth rescale code in evas is not neon optimized. But hopefully getting the SGX package installed and gl backend running will fix all that. But now, as of yesterday, there is a new 'stb' theme which is much more lightweight and fairly snappy without acceleration.

Since libplayer has a GStreamer backend, the goal would be to have accelerated video playback in enna. Although the current gst libplayer backend is experimental. But I've started hacking away to try and get the gst backend into good shape. The results of what I have are here:

video/audio playback is now integrated and working, and things like pause/seek seem to basically work. Some of the more advanced stuff like TV turner or DVD navigation are missing. But it's a start.

My here is my handy script to build this all:
And here is my config file (to go in ~/.enna): enna.cfg
(hint: click on the raw or download links)


update: the libplayer patches for better GStreamer support have been merged a couple weeks ago.. so you can pull libplayer from geexbox/openbricks tree.

Monday, August 23, 2010

ffpv8 + neon = 720p24

btw, been a long time since I had a chance to update the blog.. so I just thought I'd drop a quick note about something I've been playing with for the last few weekends.. the new ffvp8 decoder!

I've started writing the neon dsp functions for the VP8 decoder, as an excuse to learn a bit more about sw video codecs, neon, and VP8. At this point, not all of the dsp functions are implemented, but all the important ones for all the VP8 clips that I can find are implemented (loop filter, bicubic MC functions, and some misc other functions). Most of the major other ones, such as the bilinear MC functions, don't seem to be used in the clips that I can find, but should not be too hard to add when I find clips to test with.

The result is some 15-20% faster than libvpx, mostly thanks to ffvp8 being more cache friendly than libvpx decoder, and not doing silly things like memcpy of reference frames, rather than my hard-core neon optimizing skills.. and this is even without ffvp8 being a multi-threaded decoder, which is something that would benefit an SMP cortex-a9 platform like OMAP4 if done properly. And all this should be possible to get a bit faster by spending some time tweaking the instruction order to avoid stalls and some other tricks like that. (And hopefully I'll learn a few tricks in the process as the patches are reviewed.)

The result so far is here:

Current status is that it is all working, and producing bit exact output compared the plain 'C' versions of the DSP functions for all the test clips I have. I'll update again when I add more or when the patches are in upstream ffmpeg.

I also have some work-in-progress patches for gst-ffmpeg to avoid a memcpy for codecs that don't support edge emulation, although these depend on rowstride and some of the other related features that we've added to GStreamer for omap4.

Monday, March 8, 2010

git format-patch for specific commit-ids

for revision ranges, appending ^! (which appropriate escaping) to a commit-id causes it to represent that range beginning/ending with that commit-id inclusively instead of exclusively. So for specifying a revision range consisting of exactly one specific revision (let's call it r1), you can specify r1^! r1

And if you want to generate a patch from all your commits while ignoring all other commits:

for c in `git log --author=Clark | grep ^commit | awk '{print $2}'`; do
git format-patch "$c^\!" "$c";