Thoughts on moving the gstreamer.ti.com plugin to main GStreamer repository

[Don Darling]

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


------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Felipe Contreras-2]

Hello Don,

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:
>
> http://bugs.freedesktop.org/show_bug.cgi?id=13098

[...]

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
bugzilla.

> 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.

Cheers.

--
Felipe Contreras

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Arnout Vandecappelle]

On Tuesday 02 March 2010 16:12:33, Felipe Contreras wrote:
> > 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.

 I completely agree on that count.  I've been hacking away at the resizer
element and it took me hours to understand how it worked because of all
these layers, while it actually is a bunch of simple v4l2 and cmem ioctl
calls.

 However, this is not at all a blocker for moving the repository.  Other
plugins have dependencies, too.

 Regards,
 Arnout
--
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 [phone]
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  31BB CF53 8660 6F88 345D  54CC A836 5879 20D7 CF43

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel