Stream interrupted playback with Live DASH Halo pakager using Shaka 2.3.0 version

[hdodev]

Have you read the FAQ and checked for duplicate open issues?:
Yes, it looks like item #838, and to problems related to "presentationTimeOffset" in general. But the error log I have in console is different, and version used is higher.

What version of Shaka Player are you using?: 2.3.0

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?: CUSTOM

If custom app, can you reproduce the issue using our demo app?: NO, HTTP_ERROR 1002, but I'm sure the manifest is accessible!

What browser and OS are you using?: CHROME on UBUNTU

What are the manifest and license server URIs?:
Clear DASH = http://195.36.159.232/cleardashSO_tml/france4/manifest.mpd

What did you do?
I try to playback a Live Stream from my packager. We've just corrected our manifest thanks to your analysis last year : The problem was the fact that presentationTimeOffset appeared to be modified when the manifest was updated.

What did you expect to happen?
Live playback works continuously. If you can please help us to understand the remaining problem. Thanks in advance for your help.

What actually happened?
The playback starts, and then pauses, and then starts again, and so on.
It can appear once, twice, or more, there is no rule. Here is the log with the debug version:
Refusing to rewrite original references on update!
segment_index.js:319 Assertion failed: SegmentReferences are incorrectshaka.media.SegmentIndex.assertCorrectReferences_ @ segment_index.js:319shaka.media.SegmentIndex.merge @ segment_index.js:203shaka.dash.SegmentTemplate.createStream @ segment_template.js:82shaka.dash.DashParser.parseRepresentation_ @ dash_parser.js:1092shaka.dash.DashParser.parseAdaptationSet_ @ dash_parser.js:991shaka.dash.DashParser.parsePeriod_ @ dash_parser.js:733shaka.dash.DashParser.parsePeriods_ @ dash_parser.js:634shaka.dash.DashParser.processManifest_ @ dash_parser.js:521xlinkOperation.promise.then @ dash_parser.js:432

[joeyparrish]

Here are some numbers from my analysis:

At time 1519673732 (seconds since 1970 UTC, the unix epoch), I fetched your manifest. At that moment, availabilityStartTime was 1970-01-01T00:00:00.000Z (same as the unix epoch) and the video segments were described as:

  <Period id="5074585002895" start="PT1519672808.560S">
    <AdaptationSet mimeType="video/mp4" ...>
      <SegmentTemplate
          timescale="90000"
          initialization="$RepresentationID$-Header-1519672026560.m4s"
          media="$RepresentationID$-0-T-$Time$.m4s"
          presentationTimeOffset="5074655382895">
        <SegmentTimeline>
          <S t="5074655382895" d="180000" r="449"/>
        </SegmentTimeline>

The live edge is now, which is 1519673732 seconds since availabilityStartTime. So the most recent segment should have roughly this timestamp in seconds.

The first segment has timestamp 5074655382895 (in timescale units), and the last segment has start time 5074655382895 + 180000 * 449 = 5074736202895. We then subtract the presentationTimeOffset of 5074655382895 (also in timescale units) to arrive at 80820000 in timescale units.

Converting 80820000 from timescale of 90000 to seconds yields 898 seconds. We then add the period start time of 1519672808.560 seconds and get 1519673706.560 seconds.

How far is that from "now"? We subtract the time the request was made (1519673732) and get -25.44, so this is 25.44 seconds in the past.

So the timestamps are not that far off. Probably, you just need a suggestedPresentationDelay attribute to cover up this lag. A value of 30s might suffice.

To test this theory, I seeked backward by about 45 seconds and playback started.

It's not clear why playback didn't start without this action, though, and the JS console still spits out many warnings:

streaming_engine.js:1330 (video:1) cannot find segment: currentPeriod.startTime=1519673416.56 lookupTime=933.4669899940491

streaming_engine.js:1330 (audio:8) cannot find segment: currentPeriod.startTime=1519673416.56 lookupTime=933.4669899940491

segment_index.js:163 Refusing to rewrite original references on update!

segment_index.js:323 Assertion failed: SegmentReferences are incorrect

I'll dig deeper and let you know what I find.

[joeyparrish]

A side-note: in this case, HTTP_ERROR 1002 is caused by your manifest being an http URL and the demo app being an https URL. This is a "mixed-content" error, in which https origins can't load plain http resources.

[joeyparrish]

Although the timestamps all make sense in a single snapshot of your manifest, comparing over time reveals problems.

First snapshot:

  <Period id="5075233002895" start="PT1519679226.561S">
    ...
      <SegmentTemplate
        timescale="90000"
        initialization="$RepresentationID$-Header-1519679226561.m4s"
        media="$RepresentationID$-0-T-$Time$.m4s"
        presentationTimeOffset="5075233002895">
        <SegmentTimeline>
          <S t="5075233002895" d="180000" r="449"/>
        </SegmentTimeline>
      </SegmentTemplate>

Second snapshot, a couple seconds later:

  <Period id="5075233002895" start="PT1519679232.561S">
    ...
      <SegmentTemplate
         timescale="90000"
         initialization="$RepresentationID$-Header-1519679226561.m4s"
         media="$RepresentationID$-0-T-$Time$.m4s"
         presentationTimeOffset="5075233542895">
        <SegmentTimeline>
          <S t="5075233542895" d="180000" r="449"/>
        </SegmentTimeline>
      </SegmentTemplate>

The timestamps are changing (period start and first segment time), but in both snapshots, these appear to be the same segment. You should use the startNumber attribute to indicate the position of the first segment listed, and you should not change the period start time.

I recommend you change:

• Add startNumber and keep it updated to reflect the first segment listed in <SegmentTimeline>
• Make Period@start fixed (at 0, perhaps)
• Adjust your use of presentationTimeOffset with respect to your adjustment of Period@start
• Add suggestedPresentationDelay to cover the lag in serving the content

[hdodev]

Hi Joey,

First, thank you for your detailed analysis. This will allow us to move forward. OK, the "mixed-content" error is clear!

Just to be sure to understand correctly, your conclusion is that for a absolute moment, the identified segment is not the same between successive manifests, as our timestamps are changing? Correct me please if I'm wrong.

Then, I thought "startNumber" and "suggestedPresentationDelay" were DASH optional parameters, and that "Period@start" could not be fixed. So are they really required if we adjust the use of "presentationTimeOffset" with respect to our adjustment of "Period@start"? Correct me please if I'm wrong.

Thank you in advance (and sorry if my questions do not make much sense :-) ).

[joeyparrish]

startNumber is optional in some circumstances, but not in this case. If segments were never dropped from the list, startNumber could default to 1. But if your segment list changes, your startNumber must be updated to reflect that. Otherwise, there is no (easy) way to correlate one list to another to merge them.

suggestedPresentationDelay is truly optional, but highly recommended. You should decide what your presentation delay will be, to handle lag properly and keep clients from buffering at the edge. If you omit this from the manifest, we will provide a default. You can configure this default value at runtime with the key manifest.dash.defaultPresentationDelay.

Period@start must be fixed, so it is the other things which must be adjusted as time passes.

[joeyparrish]

Does this answer all your questions?