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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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-embedded/attachments/20100210/2a89c4d5/attachment.htm>


[Index of Archives]     [Linux Embedded]     [Linux ARM Kernel]     [Linux for ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux Media]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux