Google Summer of Code: Proposals and Mentors

[Stefan Sauer]

On 02/28/2015 07:26 PM, Rob wrote:
> On 27 February 2015 at 18:59, Stefan Sauer <ensonic at hora-obscura.de
> <mailto:ensonic at hora-obscura.de>> wrote:
>
>     On 02/27/2015 12:38 AM, Rob wrote:
>     >
>     > On Thursday, 26 February 2015, Stefan Sauer
>     <ensonic at hora-obscura.de <mailto:ensonic at hora-obscura.de>
>     <mailto:ensonic at hora-obscura.de> <mailto:ensonic at hora-obscura.de>>
>     wrote:
>     >
>     >
>>     On 02/18/2015 12:53 PM, Sebastian Dröge wrote:
>>     > On Di, 2015-02-17 at 16:59 +0000, Luis de Bethencourt wrote:
>>     >> Hello everyone,
>>     >>
>>     >> GStreamer is going to apply for Google Summer of Code 2015.
>>     But we need
>>     >> your help!
>>     >>
>>     >> We would really appreciate if you suggested proposals,
>>     volunteered for
>>     >> mentoring, or added content to the proposals.
>>     >>
>>     >> Current list of proposals is here:
>>     >> http://gstreamer.freedesktop.org/GSOC/socprojects.html
>>
>>     > Does anybody have any other ideas, or would like to be added as a
>>     > potential mentor for any of these projects? Would be great to
>>     get some
>>     > more ideas and potential mentors so we can properly handle all
>>     > projects :)
>>
>>     What about porting gst-debug-viewer to gtk+3 and improving it?
>>
>     Are you suggesting to make this a web-app? If done cleverly (e.g.
>     open log from url) could be sweet.
>
>  
> Imagine a world where for any GStreamer process, you can do something
> like:
>
> GST_DEBUG_PORT=8080
>
> and then open http://localhost:8080/graphs for a list of pipelines
> which you can then open to see their graphs and see them update
> dynamically. They're perhaps SVG pipelines that are interactive and
> inspectable. Maybe you can even track buffers through the paths
> through the pipeline or get statistics about how long each element
> spends processing buffers, see each element's latency contribution,
> see where overruns (full queues) or underruns (empty queues) and a
> bunch of other stuff are. I would love something like this.
We all would love that. With the gst-tracer branch we can expose such
data over a socket. One such consumer could be gst-debug-viewer.
Running this inprocess + the html rendering would have the benefit that
we could access arbitrary data without that we need to change the socket
protocol.

But sofar I was under impression that running this in-process would be
less preferable as it could potentially affect performance quite a bit.
>
> Random side-thought: An element knows best how its input buffers map
> to output buffers, why not make it an element's responsibility to
> indicate that mapping somehow so that all buffer life cycles are
> completely mapped? That plus hooks to get information about a buffer
> when it is created / modified / copied / transformed into another
> buffer / destroyed should allow some pretty shiny investigative tools.
You get such this information in the gst-tracer. The buffer mapping is
more complicated. E.g. imagine buffers read from a file, processed by 
demuxer. Should the outputs of the demuxer still be marked as stemming
from the input buffers? Then you do processing, e.g. audio-resampling
and video-rate adaptation. Now mapping buffer-ids gets tricky for sure.
Finally you mux into an output stream. While there where input buffers
containing the information that also goes into e.g. stream headers, this
is practically unmappable.

Regarding the tracer:
https://bugzilla.gnome.org/show_bug.cgi?id=733187

Stefan
>
> Rob
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20150306/e265414b/attachment.html>