[gst-devel] Thoughts on moving the gstreamer.ti.com plugin to main GStreamer repository

Don Darling don.osc2 at gmail.com
Wed Feb 10 19:32:51 CET 2010


Hello folks,

We are considering trying to move our plugin to the main GStreamer source
code repository, and could really use some help identifying the most
important things we should be thinking about if we want to make this happen.

Our plugin has existed as its own GForge project since February 2009 located
at http://gstreamer.ti.com.  The goal of this project is to provide a
GStreamer plugin that enables hardware accelerators, V4L2 display, and the
transparent use of DSP codecs on a wide variety of TI devices.  This is
accomplished by using TI's DMAI/Codec Engine/DSPLink framework.  Our
immediate benefit from the initial effort was that we were able to leverage
AV sync capabilities from GStreamer, as well as seamless integration with
the rich assortment of plugins available.  As time goes on, we would also
like to flesh out the remaining functionality required to enable features
such as trickmode playback (which is currently an ongoing effort on a
development branch).

Jason Kridner made an inquiry about setting up a repository in late 2007,
located here:

http://bugs.freedesktop.org/show_bug.cgi?id=13098

The result was that we were given a repository under the condition that we
run our first few patches by the mailing list.  No action has been taken yet
on our end for this, as there are a few things about our plugin that we're
concerned will meet some resistance:

1)  In order to build our plugin, you need to use proprietary TI software.
Some of the tools required are freely available, but others are still only
available to customers.
2)  We do not yet have an automated test suite, and even if we did, the
tests will need to be run on hardware that not everyone has available.
3)  We have not yet implemented support for all events, we currently use
posix-threads directly in some places to enable real-time scheduling for DSP
codec handlers, and our resource-management isn't always handled in the
correct state transitions (some of which can't be helped).  We are working
towards making our plugin behave more in accordance with the spec, but are
not there yet.

It would be much appreciated if you could help us to identify the main
blockers that absolutely must be taken care of before we can start
submitting patches and migrating our source code repository.

Thanks and best regards,
Don Darling
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20100210/2a89c4d5/attachment.htm>


More information about the gstreamer-devel mailing list