Hello there, Pierpaolo from Dropbox here. Good questions!
HLS support on Android is quite spotty... yeah... We try our best to build a solution that works as ubiquitously as possible and indeed it gets challenging on Android. Given our engineering resources, we need to pick our battles so a good solution (even if not perfect) is better than no solution. Anecdotally, our code has quite a few conditional statements to deal with Android. For instance, at some point we dag into the code and found that certain useful tags like the EXT-X-PLAYLIST-TYPE (see http://tools.ietf.org/html/draft-pantos-http-live-streaming-...) are simply ignored. As other folks commented already, we did find the support to be much more stable on ICS and above.
Multiple bitrates is a must for a few of reasons. 1) Apple requires a minimum supported rate of 64Kbps, 2) networks are really still incredibly spotty and providing multiple representations enables the player to act intelligently and switch according to the instantaneously measured throughput of the channel. 3) providing a high quality gratifies the users that are previewing content on a fast wifi network.
Good point on the segmenter built in ffmpeg. I felt like this part of the explanation was a bit too technical for a general audience but I can comment here. There are several reasons why we went with our own solution. Some are because of the way our pipeline works and the fact that with our tool we can create segments with variable lengths to minimize the startup latency. Specifically, having shorter segments at the beginning of the video allows the player to download less data before starting playout. I want to warn the reader to be careful if you want to experiment this path because the standard poses some constraints on how fast you can change the segment duration. So far, our approach seems to work fine so we are happy with that. Also, at the time we started development we were on ffmpeg 0.8.x transitioning on 1.x and the builtin segmenter support was not great. As we move forward, we are likely to reconsider the builtin segmenter.
we are considering open sourcing the segmenter tool (3rd). As you can imagine it's very much tailored for our pipeline and as the internal tool built in ffmpeg matures, we think our solution will become of marginal value. I keep debating myself if/when to bite the bullet and try out the ffmpeg one.
The first tool is quite similar to the one that mau posted (https://github.com/danielgtaylor/qtfaststart). Given that we forked quite some time back, I'd suggest to start from that one since it has probably bug fixes on top of our version.
Indeed, we do try to extract the rotation flags from the original and apply them when we stream the video. One possible issue is that different devices seem to apply different criteria to determine the rotation. For instance, the iPhone seems to detect the rotation only at the beginning of the video capture so if you rotate your device after you started capturing, you end up with content that has a messed up rotation.
Having said that, there is a very good chance that you are simply hitting some bug that I'd love to fix :) If you are willing to share the problematic video, you can hit me up at [email protected] and we can go from there.
You correctly guessed that we picked libfaac as a safe option for compatibility. I never tried out aacplus and sounds indeed interesting so we'll likely try it out soonish. Our target rate is a bit higher than those you mention though. For audio, we target 32kbps at low quality layers and 96kbps at higher qualities. Couple of questions for you:
- how does aacplus works at these rates?
- what compatibility issues can we expect if we were to try it out?
HLS support on Android is quite spotty... yeah... We try our best to build a solution that works as ubiquitously as possible and indeed it gets challenging on Android. Given our engineering resources, we need to pick our battles so a good solution (even if not perfect) is better than no solution. Anecdotally, our code has quite a few conditional statements to deal with Android. For instance, at some point we dag into the code and found that certain useful tags like the EXT-X-PLAYLIST-TYPE (see http://tools.ietf.org/html/draft-pantos-http-live-streaming-...) are simply ignored. As other folks commented already, we did find the support to be much more stable on ICS and above.
Multiple bitrates is a must for a few of reasons. 1) Apple requires a minimum supported rate of 64Kbps, 2) networks are really still incredibly spotty and providing multiple representations enables the player to act intelligently and switch according to the instantaneously measured throughput of the channel. 3) providing a high quality gratifies the users that are previewing content on a fast wifi network.
Good point on the segmenter built in ffmpeg. I felt like this part of the explanation was a bit too technical for a general audience but I can comment here. There are several reasons why we went with our own solution. Some are because of the way our pipeline works and the fact that with our tool we can create segments with variable lengths to minimize the startup latency. Specifically, having shorter segments at the beginning of the video allows the player to download less data before starting playout. I want to warn the reader to be careful if you want to experiment this path because the standard poses some constraints on how fast you can change the segment duration. So far, our approach seems to work fine so we are happy with that. Also, at the time we started development we were on ffmpeg 0.8.x transitioning on 1.x and the builtin segmenter support was not great. As we move forward, we are likely to reconsider the builtin segmenter.