Dash.js: detecting interupted live stream

[tony1377]

Hi

I think this might be similar to where you mention that it's not possible to detect when a live stream is ended

2145

If that's the case, in that ticket you mentioned that seeing the manifest after the stream has stopped might provide a way to reliably detect it, so I've added the manifest after interruption manifest at the bottom.

Any ideas what might be the best way to detect stream interrupted without any false positives?

<?xml version="1.0"?>

<MPD
  type="dynamic"
  xmlns="urn:mpeg:dash:schema:mpd:2011"
  xmlns:xsi="http://www.w3.org/2011/XMLSchema-instance"
  xsi:schemaLocation="urn:mpeg:DASH:schema:MPD:2011 DASH-MPD.xsd"
  profiles="urn:mpeg:dash:profile:isoff-live:2011"
  availabilityStartTime="2018-02-06T09:42:51-08:00"
  availabilityEndTime="2018-02-06T09:51:08-08:00"
  timeShiftBufferDepth="PT16S"
  suggestedPresentationDelay="PT2S"
  minBufferTime="PT1S"
  publishTime="2018-02-06T09:42:51-08:00"
  minimumUpdatePeriod="PT1S"
  publishFrameTime="0">
  <Period id="dash-md" start="PT0S">
    <AdaptationSet
      segmentAlignment="true"
      maxWidth="640"
      maxHeight="360"
      maxFrameRate="30">
      <Representation
        id="live-md-v"
        mimeType="video/mp4"
        codecs="avc1.4d401e"
        width="640"
        height="360"
        frameRate="30"
        startWithSAP="1"
        bandwidth="110155"
        FBQualityClass="sd"
        FBQualityLabel="360p">
        <SegmentTemplate
          presentationTimeOffset="0"
          timescale="1000"
          initialization="../live-md-v/156018491858762-init.m4v"
          media="../live-md-v/v2_QVRqa0w0eHJ5N0tWRmlOWW5ETQ==_156018491858762-$Time$.m4v">
          <SegmentTimeline>
            <S t="0" d="2000"/>
            <S t="2000" d="2000"/>
            <S t="4000" d="2000"/>
            <S t="6000" d="2000"/>
            <S t="8000" d="2000"/>
            <S t="10000" d="2000"/>
            <S t="12000" d="2000"/>
            <S t="14000" d="2000"/>
          </SegmentTimeline>
        </SegmentTemplate>
      </Representation>
    </AdaptationSet>
    <AdaptationSet segmentAlignment="true">
      <Representation
        id="live-md-a"
        mimeType="audio/mp4"
        codecs="mp4a.40.2"
        audioSamplingRate="48000"
        startWithSAP="1"
        bandwidth="64220">
        <SegmentTemplate
          presentationTimeOffset="0"
          timescale="1000"
          initialization="../live-md-a/156018491858762-init.m4a"
          media="../live-md-a/v2_QVRqa0w0eHJ5N0tWRmlOWW5ETQ==_156018491858762-$Time$.m4a">
          <SegmentTimeline>
            <S t="0" d="2000"/>
            <S t="2000" d="2000"/>
            <S t="4000" d="2000"/>
            <S t="6000" d="2000"/>
            <S t="8000" d="2000"/>
            <S t="10000" d="2000"/>
            <S t="12000" d="2000"/>
            <S t="14000" d="2000"/>
          </SegmentTimeline>
        </SegmentTemplate>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

[epiclabsDASH]

@sandersaares, one question, would it be appropriate to use availabilityEndTime as a way to detect the end of a live stream? Looking at spec it says

specifies the latest Segment availability end time for any Segment in the Media Presentation. When not present, the value is unknown.

I am not sure about the "scope" of this parameter. I mean, if it means Segment Availability end time for the segments referenced in the current mpd (and then we could assume it will be modified as soon as the player update the mpd) or if that parameter can be used as a way of signaling the end of a live stream.

[davemevans]

As you have pretty much surmised, the problems with using availabilityEndTime are that a) it is optional and b) it is allowed to change in a dynamic presentation.

It is impossible to know whether the presentation described above had actually ended - it may simply be experiencing a discontinuity at the point it was captured. Even if we decided it had ended by waiting some period of time, the same logic cannot be applied to manifests with no SegmentTimeline.

I believe the only certain way to know if a dynamic presentation has ended is when its duration is known (i.e. the manifest has been updated with the mediaPresentationDuration) and ast + duration < now. Unfortunately, I've never seen a content production system do this right :disappointed:

[sandersaares]

I agree with @bbcrddave. Overall, we as a community could do a lot to educate content packagers about how to properly format content. I think a lot of the lack in this area is simply a lack of awareness on how to do it right.

if it means Segment Availability end time for the segments referenced in the current mpd (and then we could assume it will be modified as soon as the player update the mpd) or if that parameter can be used as a way of signaling the end of a live stream.

I would view the end of a live stream as the moment in time when no more segments are added to the MPD. This is not necessarily when "the end" is actually reached by players. It is also not a moment signaled in the MPD. And this would not necessarily be the same as the availability end time (you would possibly want to keep segments available for longer).

Everything in DASH really just describes availability - the time range in which the player can expect a segment to be retrievable. Outside this range, one can expect a 404. It might be that this range moves through time at 1 second per second in live streams. It might be something different. But DASH itself has no explicit concept timing above segment availability timing (and below segment scope you just have the independent media timing of the content inside).

For example, you do not see the DASH standard talk of live edge because there is no such concept. There are just times when segments become available. IOP does define some algorithms for live edge logic but these are not prescribed by DASH itself and indeed, different players do it differently.

So there is a builtin limit to what DASH can meaningfully express here. When we speak of "end of live stream" are already outside the DASH standard, as it has not even a real concept of "live streams", it simply allows one to signal that a manifest will change in the future (very likely because new content gets added to the end in some relative synchrony with real time).