Mar
7th
Thu
7th
HTTP Live Streaming in iOS using AVPlayer
I’ve become very intimate with my video player class recently and we’ve been spending lots of quality time together, in fact just last week I rewrote large parts of her.
She is built on the AVPlayer Class and it’s probably just me, but there were a couple things about this class that was just a bit unclear. Here are some things that I found out that might help someone else:
- How do you determine which stream is currently being played by the player? avplayer.currentItem.accessLog.events.lastObject.URI (can’t believe I couldn’t find this out had to read the documentation 3 times before figuring this one out, we actually resorting to burning the stream names into the video files itself to test)
- What is the bitrate / bandwidth that the player is seeing / using / reporting / observing? avplayer.currentItem.accessLog.events.lastObject.observedBitrate (AVAssetTrack.estimatedDataRate lead me on a wild goose chase…)
- What are the rules for switching between streams? avplayer.currentItem.accessLog.events.lastObject.indicatedBitrate will be the bitrate that you define in your playlist which is paired with each stream. So what I have observed (this was done purely by using Network Link Conditioner to modify my network bandwidth and see which stream was played, not at all scientific) the player will play the default stream (first stream in playlist) and will start observing the bitrate. Once the observed bitrate increases to twice of the next stream’s indicated bitrate, it will switch to that next stream and will remain there until it drops below that indicated bitrate or if it becomes twice the next one, it will switch up again.
This meant a couple of things:
- Chose your indicatedBitrate carefully. Let’s assume the Network Link Conditioner’s profiles are correct and that for an average 3G connection the bandwidth is 780kbps, from what I observed the player only really gets 680kpbs so if your stream was indicated as 380kpbs, there is a high chance that someone on an average 3G connection will never be able to play it despite getting as high as 680kbps (will need 760kbps observedbitrate to switch up). So take note of the different network conditions like Edge, 3G and LTE and encode accordingly.
- Have more streams to cater to lower bandwidth connections rather that having them equally spaced out. With more people getting cable network speeds, having more streams above 500kpbs doesn’t seem to make a difference visually on the device (airplay is another story). Once users go on Wifi, they can get 2Mbps which would give them really good quality video. The devices that really benefit from HLS are those with low bandwidth and lossy connection. This is where HLS really shines. So have more streams to cater for Edge to 3G instead of 3G to Wifi.
Hopefully this discovery will lead to better quality videos for our users. They are a lovely bunch…

