IOS 13 - HLS draft spec implementation - Rebuffer

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

Replies

Would you mind filing a bug report that includes a link to a sample stream? Please post the bug number here for reference.

Hi there,

Sure, I absolutely can do that.. I'm not very familiar with Apple developer bug filings, could you point me in the best direction to do that? My bad. I just want to make sure I go to the most appropriate spot.


Thanks!

You can go here:


https://developer.apple.com/bug-reporting/


then click the Feedback Assistant button in the top right and log into your developer account. That will take you to a page where you can create a bug report.

Ref Number is FB7378581

Got it, thanks!

Hi Brian
Did you get a response after submitting the bug? Could you link the bug too or add me to it?
We've got a similar issue and it would be great to understand if the fix proposed worked.
Thanks in advance
Ben
There was a bug in the implementation of the new timing rules in iOS 13 that triggered a premature variant switch. This should be fixed in the latest iOS 13 seed, and also in the WWDC seed of iOS 14. Please let us know.