Catch-up, player stops when manifest transitions from 'dynamic' to 'static'

[mrp1977]

Have you read the FAQ and checked for duplicate open issues?
Yes.

What version of Shaka Player are you using?
2.5.11

Can you reproduce the issue with our latest release version?
Yes

Can you reproduce the issue with the latest code from master?
Yes

Are you using the demo app or your own custom app?
DEMO APP

If custom app, can you reproduce the issue using our demo app?
N/A

What browser and OS are you using?
Chrome on Mac (Same on all browsers)

For embedded devices (smart TVs, etc.), what model and firmware version are you using?
N/A

What are the manifest and license server URIs?

echo "https://live.unified-streaming.com/scte35/scte35.isml/.mpd?vbegin=$(($(date -u +%s)-240))&vend=$(($(date -u +%s)+30))"

This will give you the time relevant URL

What did you do?
Added a vbegin time in the past and a vend time in the future to the livestream URL

What did you expect to happen?
Clip plays from beginning to end based on times given

What actually happened?
Playback stops as soon as Manifest transitions from Dynamic to static (as vend time reaches wallclock)

I have attached an examples of the dynamic and static manifests

dynamicmanifest.txt
staticmanifest.txt

le of the dynamic and static manifests

[joeyparrish]

The usual problem we've seen in the past is that timestamps are changed when content transitions to static, and based on your attachments, it looks like that might be the case here, too.

If the MPD describes a segment with a presentation timestamp of (hypothetically) 1,000,000, then we update the manifest and that same segment now has a presentation timestamp of (for example) 12, playback will definitely break.

In your attachments, the dynamic version uses presentation timestamps which are aligned to the unix epoch of Jan 1, 1970. Then the static version uses presentationTimeOffset=1589965084, which aligns the content with the period start time of 0. Since this is fundamentally a different timeline, the player has no way to reconcile this.

The static version makes sense on its own, of course, as VOD content, but not as an update to the dynamic version.

[joeyparrish]

I would advise you to report this to Unified Streaming as a bug. If we can help explain this in any way, we would be happy to help. And if Unified Streaming has some advice about some way that players could hypothetically make this make sense across an update, we would be happy to hear that and make changes to Shaka Player if we can.

[boy-vd]

Hi @joeyparrish, thanks for picking up this issue and providing feedback so quickly. Like @mrp1977, I represent Unified Streaming and a more in-depth explanation on what you think is wrong with the content would be really helpful, especially if you have suggestions on how it should be improved.

I think I understand your point about the anchor of the timeline for the content in the dynamic MPD being UNIX epoch, while it is '0' for the static MPD. However, there doesn't seem to be a clear way to anchor the content in the static MPD to UNIX epoch as well, as 'availabilityStartTime' seems to be meaningful in a dynamic context only (although it's not forbidden to keep it when switching an MPD from dynamic to static according to paragraph 4.6.2 of the DASH-IF Guidelines for Implementation version 4.3:

The MPD@availabilityStartTime should be removed or be maintained from the live MPD since all resources referenced in the MPD are available. If the MPD@availabilityStartTime is maintained for a portion of the live program that is offered in the static MPD the Period@start value (including the presentation time offset and the start number) and the presentation duration shall be set accordingly. The relationship to the wall-clock time should be maintained by offsetting the Period@start without changing the MPD@availabilityStartTime.

Also, I'm sorry for only getting back to you about this now, but in the meantime we were waiting for a response from dash.js on this same issue. They have now made it work in their player: Dash-Industry-Forum/dash.js#3263.

[sandersaares]

This is an interesting scenario that I feel we should better illustrate also in the DASH-IF guidelines. I filed an issue in the DASH-IF repo for this, with some initial thoughts on how to handle it: Dash-Industry-Forum/Guidelines-TimingModel#56

Does the mechanism I propose in the referenced issue appear to be applicable to this scenario?

[martinstark]

Would be great to see full shaka support for this. We work with clients that have startover / record & watch features that we currently use manifest network filter "hacks" to make work in shaka.

[martinstark]

We're using the type of manifest described in this issue, with a network filter to make shaka able to play the stream and complete the dynamic to static transition without shutting down, and maintaining a sensical seekRange.

The network filter modifies the manifest before it is fed to shaka, by taking the t value of the SegmentTimeline S and applying it as the presentationTimeOffset on the SegmentTemplate while the manifest is still dynamic.

This has worked like a charm on versions of shaka up to and including 3.1.1. The commit that made it stop working is b3166db. Since this commit was made, the streams have started stalling unpredictably after the manifest turns static, with shaka unable to find the correct segment in maybe 20% of stream starts.

Internally, Shaka holds references to full arrays of variant segments, and shows the correct seekRange/duration, but can not play past a certain point in the stream due to some internal logic going wrong that I haven't been able to pin down.

Related #3902 (more debug info)

I was able to reproduce the issue using the reference stream from Unified Streaming (the url in the opening post seems to be outdated):

echo "https://demo.unified-streaming.com/k8s/live/stable/scte35.isml/.mpd?vbegin=$(($(date -u +%s)-2000))&vend=$(($(date -u +%s)+30))"

• apply network filter
• start stream, pause and wait for manifest to turn static
• attempt seeking close to end and let play
• stream may or may not stall, with shaka unable to internally resolve the next segment

@joeyparrish any input would be appreciated

[avelad]

Can you test with v4.3.4? Thanks!

[martinstark]

We're still seeing the issue in 4.3.3, is #4914 the commit that potentially fixes the issue in 4.3.4? I'll get it checked out tomorrow.

[avelad]

We're still seeing the issue in 4.3.3, is #4914 the commit that potentially fixes the issue in 4.3.4? I'll get it checked out tomorrow.

It fixes some cases, I hope it fixes this one.

[martinstark]

@avelad we're still seeing DASH stalls on 4.3.4, but our issue is probably different from the one in this particular ticket.

I opened my own ticket (and eventually closed it) here: #3902. The symptoms and way to reproduce #3902 are still the same in 4.3.4, but there is no longer a need for a custom network filter since shaka can handle the dynamic->static transition on its own now.

[joeyparrish]

I could definitely schedule fixes if I knew the cause of every bug. But then the schedule would be short indeed. 😁 Without knowing the cause, we can't know how long it will take to diagnose and fix. That makes sense, right?

But you could definitely contribute if you want to debug or work on a fix yourself. All are welcome! I don't believe anyone is actively working on this issue right now.

[nikhilxperi]

Hi we are able to reproduce the issue, i have shared the playback URL over the email([email protected]) To reproduce the issue, please keep the start time in past and end time in future. And seek the playback in past. when clock time reach to end time, manifest change from 'dynamic' to 'static'. that time playback should continue from seek position. but playback stop. request you to please check and help here

[avelad]

Hi we are able to reproduce the issue, i have shared the playback URL over the email([email protected]) To reproduce the issue, please keep the start time in past and end time in future. And seek the playback in past. when clock time reach to end time, manifest change from 'dynamic' to 'static'. that time playback should continue from seek position. but playback stop. request you to please check and help here

I sent you a reply to your email. Please check it.

[nikhilxperi]

Hi we are able to reproduce the issue, i have shared the playback URL over the email([email protected]) To reproduce the issue, please keep the start time in past and end time in future. And seek the playback in past. when clock time reach to end time, manifest change from 'dynamic' to 'static'. that time playback should continue from seek position. but playback stop. request you to please check and help here

I sent you a reply to your email. Please check it.

@avelad thank you for the help. we will check on it

[avelad]

@mrp1977 Your url echo "https://live.unified-streaming.com/scte35/scte35.isml/.mpd?vbegin=$(($(date -u +%s)-240))&vend=$(($(date -u +%s)+30))" returns a 404, can you review it? Thanks!

[mrp1977]

@avelad We have since changed our demo setup. The following should replace the above
"https://demo.unified-streaming.com/k8s/live/stable/scte35.isml/.mpd?vbegin=$(($(date -u +%s)-240))&vend=$(($(date -u +%s)+30))"

[avelad]

I have a local fix to make this work, I still have to make it pretty and make sure it doesn't break any other streams.