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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #14 from Thiago Sousa Santos <thiagossantos at gmail.com> ---
(In reply to Duncan Palmer from comment #12)
> (In reply to Thiago Sousa Santos from comment #11)
> 
> > This is a tricky issue. At some point we had an infinite queue inside
> > hlsdemux so we could safely measure the bitrate as we would never block on a
> > full queue. The problem is that this can be used to explode our memory usage
> > with a malicious stream.
> 
> Wouldn't memory usage explode with any stream? At steady state, we need to
> be able to download a bit faster than we decode, so unless there is a limit
> imposed, our queues will just keep growing.

Our queues are limited, the ability to store to disk allows us to have a bit
larger queue that should be enough to accomodate at least 1 fragment safely.

There are also files where there is a single fragment (they use subfragments, a
kind of marked place inside the stream where you can switch bitrates safely).
The DASH ISOBMFF profile allows this.

> 
> 
> > I don't see any other option to have a good enough measure that doesn't
> > involve an infinite (or very very large) queue. As I said, this can be
> > exploited to consume the machine's RAM. So, we need to write to disk where
> > our limits are much larger. 
> 
> One problem with this is that writing to disk isn't really an option for
> many embedded platforms. The disk would also need to be fairly large, as the
> size of the on-disk buffer would grow indefinately.

We could limit disk queue with a large enough value that would be enough for a
high bitrate fragment.

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