Hello folks,<br><br>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.<br>
<br>Our plugin has existed as its own GForge project since February 2009 located at <a href="http://gstreamer.ti.com">http://gstreamer.ti.com</a>.  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&#39;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).<br>
<br>Jason Kridner made an inquiry about setting up a repository in late 2007, located here:<br><br><a href="http://bugs.freedesktop.org/show_bug.cgi?id=13098">http://bugs.freedesktop.org/show_bug.cgi?id=13098</a><br><br>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&#39;re concerned will meet some resistance:<br>
<br>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.<br>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.<br>
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&#39;t always handled in the correct state transitions (some of which can&#39;t be helped).  We are working towards making our plugin behave more in accordance with the spec, but are not there yet.<br>
<br>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.<br><br>Thanks and best regards,<br>
Don Darling<br><br>