Google Summer of Code: Proposals and Mentors

[Stefan Sauer]

On 03/06/2015 05:40 PM, Stefan Sauer wrote:
> 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
and of course:
http://gstconf.ubicast.tv/videos/a-new-tracing-subsystem-for-gstreamer/

>
> Stefan
>>
>> Rob
>>
>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
>
> _______________________________________________
> 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/761aa39c/attachment-0001.html>