Playback of live content wont start for few minutes

[jakubvojacek]

Have you read the FAQ and checked for duplicate open issues?:
yes. I believe this is related to #999
What version of Shaka Player are you using?:
ef61081
Can you reproduce the issue with our latest release version?:
yes, tried it also with https://nightly-dot-shaka-player-demo.appspot.com/
Can you reproduce the issue with the latest code from master?:
yes
Are you using the demo app or your own custom app?:
both
If custom app, can you reproduce the issue using our demo app?:
yes
What browser and OS are you using?:
mac and chrome
What are the manifest and license server URIs?:
https://goo.gl/pCCrkT

What did you do?
tried to play given MPD.

What did you expect to happen?
To have smooth playback. Please note that the video started playing immediately with dashjs

What actually happened?
I received around 300 warnings

(audio:1) cannot find segment: currentPeriod.startTime=0 lookupTime=317473.40000009537
(video:2) cannot find segment: currentPeriod.startTime=0 lookupTime=317473.40000009537

and after that it started to play

Is this an issue with the content or shaka player?

Thank you

[jakubvojacek]

We had to restart transcoding on the URL I shared in my previous post, please check https://goo.gl/dmZ2K7 instead.

[vaage]

@joeyparrish Could you take a look at this one?

It is very interesting in that if you seek to "live" it sits into the buffering state until it falls back far enough and starts playing. However you don't need to wait as if you seek backwards far enough it will start playing again.

[joeyparrish]

That's the classic symptom of drift. The live edge in practice is before the live edge we computed.

After #999 was closed, this should only be possible with SegmentTemplate+duration. All other DASH manifest types should be immune, since we now look at the actual segment descriptions to decide where the live edge is. But with SegmentTemplate+duration, there are no segment descriptions, so we must calculate the live edge based on availabilityStartTime.

I haven't been able to look at the manifest yet. @vaage, can you check and see if this is the case?

[vaage]

So @joeyparrish, if I understand you correctly: drift is still possible when SegmentTemplate and duration are used? If so then I believe that is exactly what's happening because in the manifest we have entries that look like:

<SegmentTimeline>
  <S t="5216257200" d="288000" r="4688"/>
</SegmentTimeline>

and

<SegmentTimeline>
  <S t="5216385840" d="288000" r="942"/>
  <S t="5487969840" d="291090"/>
  <S t="5488257840" d="288000" r="3744"/>
</SegmentTimeline>

[joeyparrish]

With SegmentTemplate+SegmentTimeline, we should be immune to drift. (Assuming the manifest is accurate, and we don't have a bug in the timeline calculations.)

@vaage, if you have reproduced with the latest from master, try to analyze the manifest and media segments to see if they match.

The t attributes are in timescale units, using the manifest timescale (media timescale may differ). You can reconstruct a segment URL from the manifest, fetch a segment, and compare the timestamp of the first frame with the one from the manifest.

When constructing the URL, the first S element in the SegmentTimeline corresponds to segment number startNumber, which you fill in for $Number$ in the template. The t attribute is what you fill in for $Time$ in the template.

We really need a tool to automate this kind of analysis. Parse, interpret manifest, fetch media, extract timestamp, compare.

[chrisfillmore]

@joeyparrish If you file a ticket listing requirements for a DASH analysis tool, I may be able to get it assigned to someone on my team. We face similar troubleshooting scenarios frequently, so I think we could contribute.

[vaage]

I went back and double check with with the 2.5 beta demo and it appears to be working (I swear I checked that). However it does struggle to keep at the live edge without buffering.

@jakubvojacek Could you check using the 2.5 beta demo and see if you get the behaviour you want? I had no issues when I tried it today.

[jakubvojacek]

@vaage no, does not work for me, still getting tons of cannot find segments error
. Took around 1:40 (which is the difference in between tracks) for the playback to start. The encoder drift here is really big and we would have restarted the process already normally (we don't let it go beyond one minute), but I am keeping this alive for testing purposes. I can share some more streams with encoder drift for testing if needed.

[TheModMaker]

Looking at this again today, it works fine for me (https://nightly-dot-shaka-player-demo.appspot.com/demo/#asset=https://edge1.cablecolor.net//channels/hch-10/live/hch-10.mpd;lang=en-US;build=uncompiled). Did you restart the stream again? Could you provide another stream that has this issue?

[jakubvojacek]

@TheModMaker yes, unfortunately, there was HW replacement on the server and all the channels were restarted. They're up for a day or so. It takes a few more days for the drift to build up.

I will post here once I have got a malfunctioning stream.

Thank you for your assistance.

[jakubvojacek]

@TheModMaker please check https://goo.gl/27Kqof, it's a live stream that has the issues described above

[TheModMaker]

The problem is the last segment in the manifest of the audio stream is much further in the past than the video streams. When I fetched the manifest, all the video streams ended at 1720929840, or a presentation time of ~19121 seconds; the audio stream ends at 1710721200, or a presentation time of ~19008 seconds. So the audio stream is 113 seconds in the past.

Now that we ignore the availabilityStartTime attribute (so we are resilient against drift), we assume that the streams are aligned and being generated at the live edge. Even if we used the availabilityStartTime, I think it would put us at the end of the video stream and we would still not be able to find the audio segments at the end.

It looks like the audio and video aren't aligned.

[jakubvojacek]

@TheModMaker when watching the input in multicast, the audio and video are in sync. Therefore this looks like shaka packager issue, right?

[TheModMaker]

Yes this would be a packager issue.

[jakubvojacek]

@TheModMaker thank you, reported in shaka packager, closing here.