Video Processing at Dropbox

Watching videos on dropbox.com with my head turned sideways is uncomfortable.

Please could you use the rotate flag for videos?

libfaac is a safe aac default, but aacplus works MUCH better at the the 8 - 16 kbps range, which seams to be a stated goal of this page. It turns on SBR+PS and has ffmpeg support.

If any Dropbox people are reading this, can you comment on what criteria you used to pick the audio codec?

Hello there, Pierpaolo from Dropbox here.

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 pierpaolo@dropbox.com and we can go from there.

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.

Thanks for your reply.

You are right - on the iPhone it does things correctly unless I rotate the phone again.

On my camera ffmpeg says it never sets the flag. So not your fault :)