dynamic MPD with many SegmentTimeline S entries causes live edge calculation to be incorrect

[raylau1234]

It seems like the code in getSegmentsFromTimeline() is only looking at at most maxSegmentsAhead = 10 from the beginning.

With longer DVRs (say 15 minutes), and real world encoders that don't generate exactly identical duration segments, this max is rapidly exceeded.

I suggest both that the default be increased and this be made a configurable parameter.

Chrome on Windows 10 (but from the code, it's obvious that it ins't a browser issue)

[dsparacio]

Not sure I follow. Not sure that is the fix .

That is just a list that contains segments within that range. We search this list match current request time and use the FragmentRequest built in this list as the XHR request info. With each new segment for time request, this list is updated base on index +1 It does not care how long the DVR window is or is not.

[raylau1234]

You are right in that I am now also not sure that is the fix.

But here's the issue. I have a 330 seconds DVR as shown below. (From Wowza, extended from the default 50 seconds)

If I leave things as-is, it seems to always play from the 10th segment in on SegmentTimeline. If I make the change, at least things play, but you are right in that something is still wrong.

Namely, the time scrubber control shows from the availabilityStartTime, i.e. it shows almost 10 hours with the time marker stuck at the extreme left.

So I suspect some kind of offsets are missing (bec though availabilityStartTime is way in the past, we really want to show just the timeShiftBufferDepth at live edge)... and I suspect that root cause is also what's causing the playback to start at the 10th segment in instead of closer to the live edge.

`<?xml version="1.0" encoding="UTF-8"?> <MPD xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:mpeg:dash:schema:mpd:2011" xmlns:xlink="http://www.w3.org/1999/xlink" xsi:schemaLocation="urn:mpeg:DASH:schema:MPD:2011 http://standards.iso.org/ittf/PubliclyAvailableStandards/MPEG-DASH_schema_files/DASH-MPD.xsd" profiles="urn:mpeg:dash:profile:isoff-live:2011" type="dynamic" minimumUpdatePeriod="PT3.404S" publishTime="2016-05-02T20:08:37Z" availabilityStartTime="2016-05-02T09:34:39Z" timeShiftBufferDepth="PT330.0S" suggestedPresentationDelay="PT15.0S" minBufferTime="PT6.0S">

http://192.168.54.215:1935/live/_definst_/live_360p/manifest_mpm4sav_mvtime_w1243347692.mpd

`

[raylau1234]

Actually I may ahve a bug in my mods. Let me close this and study further.

[raylau1234]

Sorry for the back-and-forth, but I've now confirmed the original issue. Ignore the comments about the control bar -- I accidentally commented out ControlBar.js related stuff.

So, I ahve a test stream with a digital clock image in the video. The time was 8:49PM local time.

WIth the change (I changed the value from 10 to 300), my stream shows 8:48PM. The control bar (from ControlBar.js) is near the live edge, showing 13:51 of 14:50.

With the original 2.1.1 (value at 10), the stream shows 8:34PM. The control bar is all the way towards the left, at the 0:23 of 14:50 end.

I have a 15 minute DVR configured for this test.

If I walk the code, I do see getSegmentsFromTimeline() exiting bec it hit the limit of 10.

[dsparacio]

@raylau1234 What encoder are you using? Do you have an MPD we can use to test?

Here is a working stream with 5 minute DVR maybe to compare? http://vm2.dashif.org/livesim-dev/segtimeline_1/testpic_2s/Manifest.mpd

[LloydW93]

Potentially related, as part of my fix for #1362, I've changed getSegmentsFromTemplate to no longer have a limit, and was planning to do the same for others.

[raylau1234]

I am using Wowza, but modifying its DVR for DASH from the default 50 seconds to 15 or 30 minutes. I am going to try to see if there's an easy way to expose a test case outside our environment or if I can see something obvious in the code by comparing your stream. It may take a bit of time (i.e. likely won't happen today).

One quick thing I did notice about http://vm2.dashif.org/livesim-dev/segtimeline_1/testpic_2s/Manifest.mpd is that the segments do not contain sidx boxes thus the SegmentTimeline time codes may not match the real time codes in the segments. This appears to be in contravention of ISO 23009-1:2014(E) ss 5.3.9.6.1. Not sure if it is germaine or not.

My stream does contain sidx boxes and the time codes match.

[raylau1234]

I have isolated the root cause.

If is included with , the errant behavior occurs.

My new workaround is to only include when I cannot generate a (i.e. when 'sidx' boxes are not available.)

I am not sure how the is related (and I've verified that the correct string is generated, matching what the akamai time.iso URI generates).

Perhaps the fix on the dash.js side might be to just not use the UTCTiming uri when SegmentTimeline is present. It doesn't use the default akamai one in these circumstances, but does use the one provided in the mpd.

(P.S.: I had posted this comment earlier, but hit the X instead of the pencil to make an edit, and instinctively confirmed the delete... Sorry about that.)

[LloydW93]

Could you try changing the MPD url you are using in Wowza to use the "mvnumber" variation?

See https://www.wowza.com/forums/content.php?508-How-to-do-MPEG-DASH-streaming#profiles

For example, instead of http://wowza.local/app/instance/stream/manifest.mpd, try http://wowza.local/app/instance/stream/manifest_mvnumber.mpd.

[raylau1234]

Actually, what I've found is that using number is not as reliable in that if you're trying to run a 24x7 live stream, after a few hours, something fails. I suspect it's bec of varying duration segments, etc.

But to be clear, my actual use case is a layer on top of Wowza amongst other media sources, so the simple workaround of not having UTCTiming when $Time$ is used with a SegmentTimeline is a 100% fix when used with dash.js.

(I noticed that my previous comment had the angle brackets not rendering, so there are some places that should say angle UTCTiming angle, etc, that disappeared -- I hope that didn't cause too much confusion.)

[davemevans]

I thought we already ignored UTCTiming if SegmentTimeline was in use?

[raylau1234]

I believe that should be the ideal case (ignoring UTCTiming) but empirically, the observed behavior and network traffic in 2.11 is otherwise.

[davemevans]

Looking at this more closely, only the default timing source is excluded when using SegmentTimeline. If one or more UTCTiming elements are included in the manifest, these will still be used to attempt synchronisation.

So, as you have observed, that probably needs to be fixed.

As an aside:

Actually, what I've found is that using number is not as reliable in that if you're trying to run a 24x7 live stream, after a few hours, something fails. I suspect it's bec of varying duration segments, etc.

We have had great success with very long-running 24x7 simulcast streams using $Number$, but I guess it depends on encoder/packager configuration.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed because no further activity occurred. If you think this issue is still relevant please reopen it. Thank you for your contributions.