[9999]

Interesting article. I have a few comments/questions:

HLS support on Android is incredibly spotty. Do you mean in-app HLS support? The Android Chrome browser doesn't support it at all, and only a select few versions of the regular Android browser support it. Then again, there's not a great alternative.

Why offer the multiple bitrates on the HLS stream at all? You know what the client's bandwidth is, why perform three separate live transcodes? Is this because you're delivering the stream to an iOS app and Apple requires that? In Safari or a UIWebkitView based app you probably wouldn't have to do that... Or is it to compensate for potential bandwidth fluctuations?

You mentioned the mpeg-ts segmenter in more recent versions of ffmpeg but also mentioned that it has unacceptably high latency. I have not found this to be the case so long as you set the segment times individually and force new keyframes at given times (-force_key_frames and -segment_times flags, otherwise the segmenter ignores your segment time option and just creates TS chunks at whatever frequency it wants to).

Pre-transcoding the first few seconds is a really great approach that I had never considered before. Very cool.

[nairteashop]

> HLS support on Android is incredibly spotty

I assume you mean spotty in Android pre-4.0? I'd worked on HLS streaming for Android recently and didn't have issues with ICS and later. But then again with Android you can't possibly test on all OS/device combinations, so would love to know if there are things I should be watching out for.

> Why offer the multiple bitrates on the HLS stream at all? You know what the client's bandwidth is

If you're watching video over a cellular network, it's very difficult to use a single bandwidth since it can fluctuate a lot. So the best practice (as dropbox is doing) is to offer multiple streams at different bandwidths to the client, and allow the client to pick the best one for the following segment based on current network conditions.

[mackey]

Even post 4.0 it isn't super reliable. Basic playback of HLS works, but we have had issue seeking, pausing for long periods of time and resuming, etc. I wouldn't be surprised if things like WebVTT(Subtitles), ID3 tags and other advances features also don't work well.

4.4 is supposed to be much better but I don't work on Android anymore, so I am not really sure.

[pbacci]

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.

[enobrev]

As far as I know the only absolute requirement is to have at least a single 64K stream. All other bitrates come as general recommendations, but in my experience, offering a few different bitrates amount to far better, smoother playback, overall.

"Warning: These requirements apply to iOS apps submitted for distribution in the App Store for use on Apple products. Non-compliant apps may be rejected or removed, at the discretion of Apple."

https://developer.apple.com/library/ios/technotes/tn2224/_in...

[flavioribeiro]

At Globo.com we use HLS as our main protocol to stream live video for both desktop and mobile.

To have HLS audio track available "for free" (without the necessity of transcode it on backend) we built a nginx module: http://github.com/globocom/nginx-audio-track-for-hls-module

It would really great to see this module being used by Dropbox also.