Google Summer of Code: Proposals and Mentors
Stefan Sauer
ensonic at hora-obscura.de
Fri Mar 6 08:42:42 PST 2015
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>
More information about the gstreamer-devel
mailing list