[Bug 752415] dashdemux: provide a default suggestedPresentationDelay

[GStreamer (GNOME Bugzilla)]

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

--- Comment #3 from A Ashley <bugzilla at ashley-family.net> ---
(In reply to Thiago Sousa Santos from comment #2)
> Review of attachment 307468 [details] [review]:
> 
> ::: ext/dash/gstdashdemux.c
> @@ +188,3 @@
>  #define DEFAULT_BANDWIDTH_USAGE         0.8     /* 0 to 1     */
>  #define DEFAULT_MAX_BITRATE        24000000     /* in bit/s  */
> +#define DEFAULT_PRESENTATION_DELAY       12     /* in seconds */
> 
> This seems rather arbitrary. I'd prefer having it as 0 as default to just go
> to the current time rather than being 12s behind.
> Another option is try to base on the fragment durations, like going 1
> fragment behind or 3 (like HLS does).

Yes, it's an arbitrary value. The problem is that for a live stream, once the
client has chosen its start position, it can't adjust this position without
impacting the viewer (e.g. by pausing the playback to build up a buffer).

My reasoning for choosing seconds rather than fragments is because different
streams might have quite different sized fragments. I am using streams with
segment durations between 2 and 5 seconds. Using number of fragments would
cause a large variance in start position. If we're feeling really keen, the
property could be a string so that we can specify either fragments or seconds
(e.g. "3f", "12s") depending upon the use case.

I don't think one or zero fragments behind is sufficient, because it means the
DASH client can never buffer more than a fragment. Three fragments (like HLS)
is a reasonable value. However, if it makes this patch more acceptable, I'm ok
with making the default zero.

> 
> Also, how is the application supposed to know what value to use here? Maybe
> just having a better heuristic would be enough or do you have an use case
> where the application actually suggest a value?

The tricky thing is that the start position has to be decided before
downloading any fragments, so the adaptive bitrate algorithm doesn't help. In
theory an application could use something like prior history, but in practice
it is most likely to be a fixed value.

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