[Bug 733959] hlsdemux: download bitrate algorithms don't reflect real download rate

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Tue Nov 10 15:42:02 PST 2015


https://bugzilla.gnome.org/show_bug.cgi?id=733959

--- Comment #52 from Thiago Sousa Santos <thiagossantos at gmail.com> ---
(In reply to Tim-Philipp Müller from comment #50)
> > Thanks! I suppose these patches can't be merged in 1.6
> > because of the queue2 signal/property, right?
> 
> Probably not, though it's possible, both are not very intrusive code-wise.
> Not sure about the adaptivedemux changes. The extra "up to 20MB" memory
> requirement introduced by the new queue seems quite hefty though, so that's
> perhaps not something we should pick into the stable branch.
> 
> I'm also not entirely happy about the new "overrun" property because that
> now basically imposes a non-trivial performance penalty in the main code
> path for everyone using the element even if the signal is not used. For the
> sole reason of printing a GST_WARNING debug log message in adaptivedemux! I
> wonder if you couldn't have just used the messages it posts by overriding
> the GstBin::handle_message() vfunc in adaptivedemux and dropping it there.

I was also thinking about this. Using the buffering messages is doable but we
need to enable buffering which will make it post messages. I wonder if that
won't be more overhead as we are only interested in buffering=100%. Also need
to make sure it is dropped in adaptivedemux to prevent messing with the real
buffering.

How about adding a 'silent' property to queue2 just like queue has? Or
'emit-signals' that is false by default.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list