new ducati and friends update request

[Dan MacDonald]

It seems the new ducati gstreamer plugin and its supporting/related libs still haven't been released for Precise yet - any chance of a progress update please?

I recall ndec saying this was almost a ground-up rewrite of the video decoding and encoding pipeline but was it out of choice? If it was out of choice then what are the expected benefits?

Also, have TI said anything about potentially open sourcing all this stuff eventually?

Thanks!

Dan

[Vladimir Pantelic]

there are efforts to have the codec libs available for download
again, once they are, making a minimal ducati for video en/decoding
should be doable. You don't really want to see the code for all
the Android related OMX stuff in the existing ducati images... :)

[Nicolas Dechesne]

On Thu, Jun 14, 2012 at 9:08 AM, Dan MacDonald <all...@gmail.com> wrote:
> It seems the new ducati gstreamer plugin and its supporting/related libs
> still haven't been released for Precise yet - any chance of a progress
> update please?

we are almost there... the decoder at least is working. we haven't
'packaged' everything into PPA yet, but if you are impatient (and
brave) you can follow the development on the gitorious:
http://gitorious.org/gstreamer-omap.

I think we will push everything into PPA sometime b/o July, that will
include gst-ducati support and a new GFX driver (based on DDK1.9).

>
> I recall ndec saying this was almost a ground-up rewrite of the video
> decoding and encoding pipeline but was it out of choice? If it was out of
> choice then what are the expected benefits?

there are 2 things:
- gst-ducati vs gst-openmax: we made the decision to move away from
gst-omx for various technical reasons. as it happens OMX and GST
aren't really good friends and it has proven to be quite cumbersome
and difficult to associate them... to say the least. so we got rid of
all that and build a simpler, thinner codec layer, which has the big
advantages of 1) reusing the same codecs as OMX, e.g. no change in the
codec itself, 2) being very small, a few hundreds of line of code, so
very easy to write and debug, 3) to be a synchronous API from the
linux side, that removes all nasty racy conditions and corner cases
that we had observed with OMX/gst-omx.

- syslink transition. we have finally (yes, i know after 10+ years)
managed to converge on a sane IPC framework between the MPU and the
h/w accelerator. that's remoteproc/rpmsg which has been merged into
the mainline kernel. syslink2 was the previous IPC framework we used
up until 11.10, and this IPC is *drastically* different from the final
one (rpmsg). that's the transition which we are making now. rpmsg is
now an in-kernel IPC framework, so our DCE thin layer becomes now a
kernel driver (omapdce) instead of a user space shmi layer (libDCE).
There are many advantages of omapdce being a kernel driver that really
justify the cost of development : better power and resources
management and better memory management, and also the possibility to
upstream this driver into mainline kernel!

>
> Also, have TI said anything about potentially open sourcing all this stuff
> eventually?

everything is open source with the exception of the codecs that run of
the IVAHD, which is a TI specific IP for video. The DCE source code
both on the Linux and on the Ducati side is OSS.

[Dan MacDonald]

Thanks for that update Nicolas - it does indeed sound like you have some very good reasons to move to this new architecture.

Hopefully this new set up will last longer - it sounds like it will. Less code to do the same thing and integration with mainline are always good!