Live DASH manifest fails to play

[DanielBaulig]

I've been playing around with the RTMP module for nginx. (https://github.com/arut/nginx-rtmp-module). It takes a RTMP stream and outputs a DASH manifest and segments for the RTMP stream effectively converting it from RTMP to DASH.

Here is an example DASH manifest generated by the nginx module:
http://pastebin.com/SsKXY8rk

I've been testing it with Shaka v1.6.3-debug. Shaka will not successfully play the manifest at all. Here's the debug log output from Shaka:
http://pastebin.com/xNVezCN8

Why won't the manifest not play? It looks like the seekable range is effectively an empty range. That is probably a problem, but I'm not sure why that is. The player is sending requests to segments that complete successfully , but it doesn't play anything nevertheless.

Any ideas?

[tdrews]

Hi,

@availabilityStartTime seems to be inaccurate; some segments may not be available yet: currentPresentationTime 11.00600004196167 latestAvailableSegmentEndTime 549.754

indicates that there is a discrepancy between where the Player thinks the live-edge of the stream is (based on MPD@availabilityStartTime) and the times within the SegmentTimeline(s). However, these discrepancies are usually tolerable by the player.

It looks like the seekable range has collapsed, so there could be a bad interaction between the aforementioned issue and a small MPD@timeShiftBufferDepth... Are you able to give the RTMP module a specific (larger) MPD@timeShiftBufferDepth?

[DanielBaulig]

I increased timeShiftBufferDepth and now it plays, thanks! Can you elaborate a little what these errors mean?

E.g. is currentPresentationTime and latestAvailableSegmentEndTime on the same timeline? Does that mean these values are more than 530 seconds apart form each other even though they should overlap? What could cause that?

Setting different values from timeShiftBufferDepth seems to affect the delay between live head and play head. What's a good approach to minimize this delay?

[tdrews]

currentPresentationTime is the amount of time that has passed since the live stream began (streaming/broadcasting), i.e., currentTime - MPD@availabilityStartTime.

latestAvailableSegmentEndTime is the time when the last segment specified in the SegmentTimeline ends. Typically this value should be <= currentPresentationTime (e.g., if a stream has been broadcasting for 60 seconds then no segment should end past 60 seconds).

If latestAvailableSegmentEndTime is greater than currentPresentationTime then the first segment in the live stream likely doesn't start at t=0. If this is the case then the manifest should specify SegmentTemplate@presentationTimeOffset. For example, if the first segment starts at t=20s then @presentationTimeOffset should equal 20s. This lets the player know that it should offset every segment by -20s to align the segments to the start of the Period.

Another method to align the segments (which is the method that many packagers use) is to offset MPD@availabilityStartTime. For example, if you begin streaming at 11:00:00 and the first segment starts at t=20s then you can set MPD@availabilityStartTime to 10:59:40. By doing this the player will compute currentPresentationTime=20 right away and end up doing the right thing.

In Shaka v1 we try to handle a number of corner cases related to this stuff and the resulting logic is fairly tricky, we hope that our implementation in Shaka v2 simplifies things.

Setting different values from timeShiftBufferDepth seems to affect the delay between live head and play head. What's a good approach to minimize this delay?

timeShiftBufferDepth shouldn't affect how close the player starts to the live-edge. However, the player does have to do a little more work at startup for larger timeShiftBufferDepth values... we had a performance regression in v1.6.3 that perhaps could be the culprit, how does v1.6.4 work?

Moreover, MPD@minBufferTime will affect how close the player starts to the live-edge: the smaller the value, the closer you'll get.

EDIT: Note that timeShiftBufferDepth=0 should work (it means that at least one segment is available IIRC from the spec.). I will have to investigate why it isn't working.

[DanielBaulig]

Thanks a lot for the great feedback!

Just so that I understand correctly:
The nginx module drops segments from the timeline as playback progresses and shifts availability start and end time accordingly. So e.g. early in playback it could have an MPD@availabilityStartTime of 06:33:12 and a MPD@availabilityEndTime of 06:33:37 with 5 segments starting at t=0 and a duration of 5 seconds each.
After 20 seconds have passed there will still be 5 segments but now beginning at t=20 and availabilityStartTime and availabilityEndTime will both have shifted by 20 seconds forward.

Do I understand you correctly that in such a case the SegmentTemplate@presentationTimeOffset should be 20s? Or am I misreading your explanation?

EDIT: Note that during playback of the given manifest that currentPresentationTime never actually moves away from around the 11 - 12 second mark. Is that due to the missing presentationTimeOffset?

[tdrews]

Typically MPD@availabilityStartTime remains fixed. The player determines which segments are available based upon currentTime and timeShiftBufferDepth. So, all the packager has to do is add more S elements to the SegmentTimeline each time the MPD is updated.

Although, after reviewing DASH IOP section 4.4.3.3 (starting at line 12) I see that updating MPD@availabilityStartTime is valid so long as a number of other attributes are updated as well (including @presentationTimeOffset).

However, from what I've seen this approach is not typical, and we don't directly support it. Does the nginx module have some sort of option to fix MPD@availabilityStartTime?

We would like to avoid directly supporting MPD@availabilityStartTime updates in Shaka v1, but we can consider it for Shaka v2 based on demand. I can also walk you through some possible changes you can make in v1 to make AST updates work (better) if you are unable to configure or modify the nginx module suitably.

[DanielBaulig]

I think the primary concern is to blow up manifest size for very long streams with very small segment durations.

I would be interested in applying these changes in v1. That said, I don't think the nginx module does the changers to @presentationTimeOffset or @startNumber correctly. Also not sure what section 4.4.3.3 is referencing when it talks about "S values" (S elements in the SegmentTimeline?) or how they need updating.

[tdrews]

I think the primary concern is to blow up manifest size for very long streams with very small segment durations.

Well, normally packagers just drop the S elements that are outside of the time shift buffer. For example, the first MPD might specify segments 1 through 10, and the second MPD might specify segments 4 through 14. This can be done without changing AST.

Also not sure what section 4.4.3.3 is referencing when it talks about "S values"

Yes, these would be the S elements in the SegmentTimeline(s). These values need to be relative to the start of the Period... So, if you're updating AST and Period@start then the S elements need to change so they're relative to the new Period@start.

So, to confirm, with a larger timeShiftBufferDepth value, are you able to playback the stream normally (except for the warning messages)?

[DanielBaulig]

Yes, adjusting timeShiftBufferDepth by setting it to a reasonable value (e.g. 10 seconds) or completely removing it, fixed the playback issues.

So dropping segment elements from the SegmentTimeline is possible, while keeping availabilityStartTime at it's original value? I changed the RTMP module to do that, and it looks like this fixed the warning messages too.

[tdrews]

So dropping segment elements from the SegmentTimeline is possible, while keeping availabilityStartTime at it's original value?

That's right.

I changed the RTMP module to do that, and it looks like this fixed the warning messages too.

Great. Yeah it seems like the nginx module is doing the kind of update that Shaka expects except for the AST updating part. So, just keeping AST constant seems like the right fix.

Alright, I'll keep this issue open now to track the timeShiftBufferDepth=0 issue.

[tdrews]

Since we're closing in on v2.0 we're going to avoid making any changes to v1.0 to support @timeShiftBufferDepth=0. I'll file a new bug against v2.0 for this.