[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 #18 from Duncan Palmer <dpalmer at digisoft.tv> ---
(In reply to Thiago Sousa Santos from comment #14)
> (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.

What I'm trying to get at is that because the queue size is limited, we will
always end up, after some time, with all queues full. This is because we
download faster than we decode.

So, even with the scheme which has the on-disk queue, we are in no better place
than we are now, as we can't accurately measure download rate unless we're
pushing into a non-blocking queue.

So, we would need to wait for a queue to have enough free space to accomodate a
whole fragment before attempting to download and measure download rate.

Also, if we have small fragments, we can't accurately measure download rate, so
we need to measure it across a few of them.

I'm wondering if it would be simpler to define a minimum amount of data which
can be used to measure download rate, have a queue which can hold that amount
of data, and simply measure how long it takes to fill that queue?  Then emppty
the queue and repeat. If we don't fill it e.g. because we switch variant, then
we don't measure bitrate that time around. Again, we run into trouble with low
bitrate variants, as the queue could end up being quite long in stream time.

> > 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.

As I mention above, once the queue becomes full because of the limit, then we
can no longer measure bitrate accurately.

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