Playback freeze at the end of the first period on multi-period Dash streams #9969

Activity

1. danielgliga3ss

   added

   bug

   needs triage

   on Feb 11, 2022
2. ojw28

   self-assigned this

   on Feb 11, 2022
3. ojw28 commented on Feb 12, 2022

   

   ojw28

   on Feb 12, 2022

   Contributor

   More actions

   The issue occurs because the manifest contains incorrect event presentation timestamps. For example, the first period in your manifest contains this:

       <Period start="PT0S" id="p_5_411053387" duration="PT8.72S">
           <EventStream schemeIdUri="urn:scte:scte35:2014:xml+bin" timescale="180000">
               <Event id="1073947003" presentationTime="295958438769600" duration="10800000">
                   <scte35:Signal>
                       <scte35:Binary>/DAlAAAAAs0wAP/wFAVAAyF7f+/+olw04P4AUmXAEiIAAAAA/WqzXg==</scte35:Binary>
                   </scte35:Signal>
               </Event>
           </EventStream>
   

   As per the DASH specification Event @presentationTime values are relative to the start of their containing period. This means the event occurs at 295958438769600/180000 = 1644213548s after the start of the period, however the period is only 8.72s long, so this is clearly incorrect. It looks like @presentationTime is being incorrectly set to be relative to the epoch, rather than to the start of the period.

   This is a problem for ExoPlayer, because the player is waiting until it's finished playing the period before advancing to the next one. This includes outputting this event at its specified time, and so the player is stuck waiting to do that.

   We should change ExoPlayer to discard events that are beyond the end of their containing period. We already clip audio and video at the period end point, which is in line with DASH-IF interoperability recommendations. The only reason we haven't done this for events defined in the manifest is because there's no legitimate reason for a manifest to ever include such events in the first place (where-as there are valid technical reasons why the final audio/video segments may contain media beyond the end point of the period).

   Marking as bad media, but also as a bug, since we'll implement clipping of such events. I suggest that you also fix your manifests, particularly if it's important to you that the events are output at the correct times.
4. ojw28

   added

   bad media

   and removed

   needs triage

   on Feb 12, 2022
5. ojw28

   assigned

   tonihei

   and unassigned

   ojw28

   on Jul 5, 2022