Posts

Post not yet marked as solved
3 Replies
478 Views
Hi there... I was wondering if any one might be experiencing an issue that I'm actively trying to hunt it down. This seems to be specific to Apple devices. In this case I am using Safari on a MacBook Pro (Catalina 10.15.7) to directly load the m3u8, but have also observed in iTunes. I have 4 ABR variants of packed AAC-LC, from 32kbps to 192kbps. Each segment between the variants has matching ID3 timestamps. Hlsmediavalidator reports no problems at all, and shows that all of my variants are tightly time-locked together - no deviation. Discontinuity and media sequences all matching up. Now, when I choke the network around areas of the live playlist that have a discontinuity, everything seems to work fine and the upshift or downshift happens somewhat seamlessly. Sometimes there is not an exact audio lock on the shifts, but that is for another battle.. However.. When I choke/unchoke the network in areas of the playlist that don't have discontinuities, I can see the player shift to the variants and download segments, but eventually playback stalls for a rather significant amount of time. If I wait long enough, playback does begin again. This is true even when going from choked to 1gbs. Also, if a discontinuity shows up, that seems to kick everything back into gear again. At least this is what seems to be happening, I am still gathering data to see if that's truly the case. It does seem to be, though. I've tried some crazy stuff, like adding an #EXT-X-PROGRAM-DATE-TIME to every segment, making sure my BANDWIDTH properties are calculated instead of static, etc. Any ideas to try out would be greatly appreciated! Thanks! ps- Each variant plays fine if network conditions are left alone. pss- I have tested choke points from 50kbps to 100kbps in these cases, by proxy, targeted only for the HLS and segment requests.
Posted Last updated
.
Post not yet marked as solved
7 Replies
1.3k Views
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/frag3In 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
Posted Last updated
.