5 Replies
      Latest reply on Oct 14, 2019 9:39 AM by Polyphonic
      brianonymous Level 1 Level 1 (0 points)

        Hello all,

        We have noticed that IOS 13 has changed the timing mechanism for fetching new manifests (section 6.3.4).

        This actually creates a new problem with streams that have multiple rollover entries in the master playlist.

         

        The new change uses the last received manifest duration as the timing used to fetch the next manifest. If all fragments have the same duration, this is typically not a problem. However, if there is a content boundary where the fragment size ends up being smaller, this causes a pretty significant problem.

         

        Lets walk through it:

         

        #EXTM3U

        #EXT-X-VERSION:3

        #EXT-X-TARGETDURATION:11

        #EXT-X-MEDIA-SEQUENCE:4

        #EXT-X-DISCONTINUITY-SEQUENCE:0

        #EXTINF:10.030,

        server_1/frag1

        #EXTINF:10.030,

        server_1/frag2

        #EXTINF:2.600,

        server_1/frag3

         

        In this live situation, our average fragment size is going to be 10 seconds. However, with the HLS implementation in IOS 13, this last fragment sets the manifest fetch timing for the next manifest pull.. So, the AVPlayer waits 2.6 seconds, and requests the next manifest. The problem is, the next fragment in line is currently being built in realtime, and will be 10 seconds long. The manifest returned will have the same fragment list as before.

        This causes the AV player to wait for half of the target duration, or in this case, another 5.5 seconds before asking for the next manifest.

        This is where things go south.

         

        The next manifest pull also does not have the new fragment, because only a total of 8 seconds has passed, not the 10 seconds that is needed to build up the next live fragment. This sends the AVPlayer into a rebuffer state, and switches itself over to the next rollover entry in master playlist.

         

        We have found that the only way to get the behavior to switch back to the way it used to be is to change the target duration to some unreasonably high number, like 22. That forces IOS 13 to give enough waiting headroom to allow the 10 second fragment to be built.

         

        We do not understand why IOS 13 works this way, or how this implementation will actually work in live cases where durations can change to below the target duration. Is there something we need to change in our manifest headers to revert back to the previous behaviors? The 22 second target duration is a bandaid, but we worry about other platforms, older IOS and rebuffer management in general with that kind of hack.

         

        Thanks in advance for any insight you can provide,

         

        Brian Bosworth