[gst-devel] some gsoc ideas

Stefan Kost ensonic at hora-obscura.de
Thu Mar 25 21:46:58 CET 2010


Am 22.03.2010 20:23, schrieb Tristan Matthews:
> 
> 2010/3/21 Stefan Kost <ensonic at hora-obscura.de
> <mailto:ensonic at hora-obscura.de>>
> 
>     Am 21.03.2010 00:37, schrieb Christopher Harvey:
>     > Hello gstreamer developers,
>     >
>     > I'm going to put in a GSoC application for gstreamer. I have a few
>     ideas that
>     > I'm considering and I want to get some feedback (as google
>     suggests) before I
>     > write it up.
>     >
>     > -Jack output
>     > I saw the plugin in the bad section. The documentation was written
>     in '06.
>     > Jack seems like it would be important to gstreamer, since being
>     able to pass
>     > data from application to application is a natural extension of the
>     > element/pipeline paradigm. I think this deserves to be in the
>     "good" section.
>     >
>     If you want file a bug requesting the plugin to be moved to good.
>     You would need
>     to check the gstreamer/docs/random/moving-plugins checklist to see
>     whether it is
>     ready. I think there are some open feature requests. One thing I
>     have somewhere
>     on my todo list is to allow the application to set the jack-client.
>     This would
>     help to have a pesistent jack connection and is needed of one wants
>     to e.g.
>     support jack midi in addition or handling the jack transport control.
> 
> 
> Stefan, could you put your TODO in gst-plugins-bad/ext/jack? Maybe in
> the README
> 
> -Tristan
> 

I could do that once I am sure about wheter it makes sense or not. I'll write it
down below and maybe you can comment.

What I wonder is if it would make sense to add a gpointer property to
jacksrc/sink when one can access the
jack_client_t *client
This way an application can share a jackclient and also use that for jack midi.
On the other hand, this works fine:
gst-launch jackaudiosrc ! jackaudiosink jackaudiosrc ! jackaudiosink
and maybe there is no need to share the jackclient.

Regarding the jack transport control - at first it would be nice to slave to the
transport and emit GST_TAG_BPM message. This way one would get the BPM into the
file if e.g. one records from jack to an mp3. Beyond that having a property to
enable the gstreamer app to be a jack transport master would be nice. I have
this tempo interface in buzztard
http://buzztard.svn.sourceforge.net/viewvc/buzztard/trunk/gst-buzztard/libgstbuzztard/tempo.c?revision=2238&view=markup
which could be moved to base/gst-libs/gst/interfaces (or audio). jack could
implement it.

But none of this would in any way block jack plugin to be moved to good.

Stefan

>  
> 
>     Anyway, I am not sure if that is enough for a GSoC project :/
> 
>     >
>     > -Delay/reverb
>     > I believe this element could also use some attention. As per the
>     > documentation:
>     > audioecho adds an echo or (simple) reverb effect to an audio stream.
>     > Reverberation effects are rarely composed of one delay. In fact
>     just to
>     > simulate a simple square room you need to use many delays with
>     different
>     > intensities to account for the multiple more important sound
>     reflections. It
>     > is tedious to combine many identical elements in gstreamer, why
>     not make it
>     > possible to set the number of delays and their parameters inside one
>     > audioecho?
> 
>     Multiple delays are usualy done as a multitap delay, that is a
>     single delay line
>     with multiple taps. Still this makes no reverb. Adding some delay
>     variants would
>     be nice (a multitap delay, a cross-delays, a cross-delays with
>     filters in the
>     feedback loop, ...). And a real reverb would be nice (could e.g. be
>     build on
>     freeverb). Right now we can use this via ladspa bridge in gstreamer.
> 
>     Maybe both suggestions could be joined as a "creative audio" GSoC
>     bundle. Not
>     sure what others think.
> 
>     Stefan
> 
>     >
>     > -parameter input (gui)
>     > This one is a little sketchy imo because it goes against the theme
>     of other
>     > gst elements and would depend on GTK (or other). Rather than force
>     the user to
>     > write a gui to control values within a pipeline, it could be nice
>     to have an
>     > element that would create a new thread and spawn a gtk window
>     inside it. The
>     > user could tell the element how many, what type and a short label
>     for each gui
>     > control. The element would then in turn push the selected values
>     into the
>     > pipeline. (Think controls for things like fading, color
>     hue/saturation, file
>     > paths, ip addresses, etc)
> 
>     http://code.google.com/p/gst-gengui/
> 
>     >
>     > any comments and/or criticism is welcome,
>     > Chris.
>     >
>     >
>     ------------------------------------------------------------------------------
>     > Download Intel&#174; 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
>     > gstreamer-devel at lists.sourceforge.net
>     <mailto:gstreamer-devel at lists.sourceforge.net>
>     > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
> 
> 
>     ------------------------------------------------------------------------------
>     Download Intel&#174; 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
>     gstreamer-devel at lists.sourceforge.net
>     <mailto:gstreamer-devel at lists.sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
> 
> 
> 
> 
> -- 
> Tristan Matthews
> email: tristan at sat.qc.ca <mailto:tristan at sat.qc.ca>
> web: http://tristanswork.blogspot.com
> 
> 
> 
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel





More information about the gstreamer-devel mailing list