[gst-devel] [gst-embedded] Thoughts on moving the gstreamer.ti.com plugin to main GStreamer repository
felipe.contreras at nokia.com
Tue Mar 2 16:12:33 CET 2010
On Wed, Feb 10, 2010 at 07:32:51PM +0100, ext Don Darling wrote:
> 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:
I just read that bug report and I don't see any pre-requisites, just
submit your patches.
Although I thought GStreamer developers prefer to review patches through
> 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.
Personally I would rather get rid of the DMAI/CE dependency and access
dsp-link ioctls directly, just like gst-dsp does.
Unnecessary layers are not nice.
More information about the gstreamer-devel