Freeze availabilityStartTime and adjust timeShiftBufferDepth

[mattpepin]

I was not able to use Dash.js to play live DASH stream. After much investigation, I figured that the standard says that availabilityStartTime should not increase (in the MPD file). I created a patch that freezes availabilityStartTime and adjusts timeShiftBufferDepth instead. Now my live streams play perfectly. Tell me what you think.

[sergey-dryabzhinsky]

I'll check this. Idea looks good.

But start_time modification a little confusing.
Is it always equal to first segment creation time?

[mattpepin]

Yes exactly. According to the DASH spec, it should never change (even though a bit counter-intuitive since Nginx starts removing segments after a while). Here are a few related bugs:

Dash-Industry-Forum/dash.js#531
Dash-Industry-Forum/dash.js#497
arut#614

[mattpepin]

Looks like Wowza had this bug too. They introduced "mpegdashStrictSpecComplianceForAST" config flag for the same reasons. Maybe this patch could be toggled on/off through nginx.conf.

[sergey-dryabzhinsky]

I'm about that code: ngx_libc_localtime(ctx->start_time.sec, &tm);

Maybe it must refer to ngx_rtmp_dash_get_frag(s, 0)->timestamp?

[sergey-dryabzhinsky]

Can you post two examples of mpd - before and after code changes?

[mattpepin]

Ah I understand what you mean. But no I don't think so. The timestamp of the first fragment will change over time when Nginx starts removing fragments. To follow the spec, it should always be the same for the whole duration of the stream.

[mattpepin]

Sure I will post them. Give me a few minutes. Also, I found a little mistake in my patch. I will correct it (the msec should have 2 decimals places, but since the value could be > 100, there would be 3 decimal places).

[mattpepin]

Here's the relevant parts in the MPD file with 2 decimals places (patch coming) with my branch:

One of the first MPD:

<MPD
type="dynamic"
xmlns="urn:mpeg:dash:schema:mpd:2011"
availabilityStartTime="2015-10-23T10:44:29-04:00"
availabilityEndTime="2015-10-23T10:44:34-04:00"
minimumUpdatePeriod="PT5S"
minBufferTime="PT5S"
timeShiftBufferDepth="PT0H00M05.93S"
suggestedPresentationDelay="PT10S"
profiles="urn:hbbtv:dash:profile:isoff-live:2012,urn:mpeg:dash:profile:isoff-live:2011"
xmlns:xsi="http://www.w3.org/2011/XMLSchema-instance"
xsi:schemaLocation="urn:mpeg:DASH:schema:MPD:2011 DASH-MPD.xsd">

After a few seconds:

<MPD
type="dynamic"
xmlns="urn:mpeg:dash:schema:mpd:2011"
availabilityStartTime="2015-10-23T10:44:29-04:00"
availabilityEndTime="2015-10-23T10:45:22-04:00"
minimumUpdatePeriod="PT5S"
minBufferTime="PT5S"
timeShiftBufferDepth="PT0H00M31.99S"
suggestedPresentationDelay="PT10S"
profiles="urn:hbbtv:dash:profile:isoff-live:2012,urn:mpeg:dash:profile:isoff-live:2011"
xmlns:xsi="http://www.w3.org/2011/XMLSchema-instance"
xsi:schemaLocation="urn:mpeg:DASH:schema:MPD:2011 DASH-MPD.xsd">

[mattpepin]

Alright, changes are in. Only 2 decimals places for msec are allowed in spec (according to what I could find online). I tried adding days but it seems Dash.js can't parse the timestamps anymore.

[sergey-dryabzhinsky]

For days string must be like P20Y10M23DT19H36M49S.

According to durationRegex here: https://github.com/Dash-Industry-Forum/dash.js/blob/development/src/dash/DashParser.js

And months and years are not precise counters. So better keep days only: P35DT19H36M49S

[mattpepin]

You're right I was using the wrong format. Here's the correct one on Wikipedia:

https://en.wikipedia.org/wiki/ISO_8601#Durations

Patch coming.

[sergey-dryabzhinsky]

Live streams works like expected now?

[mattpepin]

With my branch and latest dash.js, yes.
Le ven. 23 oct. 2015 à 13:56, Sergey notifications@github.com a écrit :

Live streams works like expected now?

—
Reply to this email directly or view it on GitHub
#48 (comment)
.

[sergey-dryabzhinsky]

Merged

[sergey-dryabzhinsky]

Fix gcc warning in cd416d5