Apple HTTP Live Streaming (HLS) has been a nightmare to get working. Below, I’ll go through some of my trials and tribulations in getting HLS encoding for non-live streams working in Windows. In summary, I couldn’t get the bitrate I wanted on my videos. I’ll provide explanations (and rants) below, but first, for the impatient, here is the solution.
In the end, here is exactly what I did:
- Download FFMPEG, latest stable release (0.6.1 in my case) Windows build from VideoHelp.com(FFMPEG.org doesn’t do their own builds for some reason?)
- Download x264 Windows build from x264.nl (once again,the x264 team doesn’t do their own windows builds)
- Download the Nero AAC Encoder from nero (this is NOT open source)
- Download the open source segmenter from here (author’s site is here)
Here’s how I have created my streams in a Windows environment:
- Extract WAV file from original video:
ffmpeg.exe -i INPUT.AVI -vn -acodec pcm_s16le AUDIO.WAV
- Produce an AAC file:
neroAacEnc.exe -cbr 64000 -he -if AUDIO.WAV -of AUDIO.AAC
- Produce the required audio-only MPEG2-Transport Stream:
ffmpeg.exe -i AUDIO.AAC -vn -f mpegts -acodec copy AUDIO.TS
- Go ahead and segment the audio-only MPEG2-Transport Stream (this can be done later):
segmenter.exe AUDIO.TS 10 STREAMNAME/AUDIO STREAMNAME/AUDIO.M3U8 http://mydomain.com/virtual/path/to/STREAMNAME/
Note that this will dump AUDIO-*.TS and AUDIO.M3U8 files into the .\STREAMNAME directory which must exist prior to running.
- Choose a bitrate, and encode the video for one of those bitrates. Apple recommends 96 kb/s, 256 kb/s, and 800 kb/s for video. This example will use 96 kb/s (“low” bitrate):
x264.exe --level 30 --profile baseline --bitrate 96 --keyint 30 -o LOW.MP4 INPUT.AVI
- Mux the audio and video together to produce an MPEG2 Transport Stream:
ffmpeg.exe -i LOW.MP4 -i AUDIO.AAC -f mpegts -vcodec copy -acodec copy -vbsf h264_mp4toannexb LOW.TS
- Segment the stream:
segmenter.exe VIDEO-96KBPS.TS 10 STREAMNAME/LOW STREAMNAME/LOW-TMP.M3U8 http://mydomain.com/virtual/path/to/STREAMNAME/
- Optional: Make all URLs relative in STREAMNAME/LOW.M3U8… Apple’s mediastreamvalidator will issue warnings if you don’t do this. I use a sed script:
sed.exe "s/http\:\/\/mydomain.com\/virtual\/path\/to\/STREAMNAME\///" STREAMNAME/LOW-TMP.M3U8 > LOW.M3U8
- Repeat steps 5-8 for Medium (256 kb/s) and High (800 kb/s) bitrates.
- Generate the final playlist:
echo #EXTM3U> STREAMNAME\STREAMNAME.M3U8
echo #EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=320000>> STREAMNAME\STREAMNAME.M3U8
echo med.m3u8>> STREAMNAME\STREAMNAME.M3U8
echo #EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=864000>> STREAMNAME\STREAMNAME.M3U8
echo high.m3u8>> STREAMNAME\STREAMNAME.M3U8
echo #EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=160000>> STREAMNAME\STREAMNAME.M3U8
echo low.m3u8>> STREAMNAME\STREAMNAME.M3U8
echo #EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=64000>> STREAMNAME\STREAMNAME.M3U8
echo audio.m3u8>> STREAMNAME\STREAMNAME.M3U8
So what’s going on above? What’s the gist of an HLS stream? Briefly, setting up a static compliant HLS stream involves the following: Encode your video at varying bitrates. Then slice each of those encoded videos into even chunks (10 seconds recommended) and output a playlist. A master playlist (aka variant playlist) points to each bitrate-playlist. Let the player, based on bandwidth constraints, figure out what bitrate it wants on the fly. If it has to switch to a different bitrate-playlist, it merges segments by matching up the audio (which should be encoded identically between streams). This seems to fit Apple’s general philosophy: your video will stream; it will work regardless of your bandwidth limitations.
A couple of important notes:
- One benefit: No streaming server is needed to make this work. Any HTTP server will work, including Apache and IIS.
- As mentioned here, “If your app delivers video over cellular networks, and the video exceeds either 10 minutes duration or 5 MB of data in a five minute period, you are required to use HTTP Live Streaming.”(You have to wonder if any of this is to simply protect AT&T’s bandwidth?)
- Apple has proposed HLS as a standard.
- So far as I can tell, Apple doesn’t provide an encoder to produce the needed MPEG-2 Transport Stream, nor does any SINGLE Apple tool to encode and dump out the necessary files for HLS. They do give you command-linetools for segmenting, creating a variant playlist (aka master-playlist), and verifying streams. This seems like a glaring omission from QuickTime Pro honestly. It does seem from forum posts that QuickTime Pro can output a format that the Apple’s segmenter (a command line tool on MacOS) can deal with though.
- It’s all standards based (x264, AAC/MP3, MPEG2-TS) with recommendations for settings provided in theirFAQ. So we should be able to cobble the necessary files together from free tools that run on Windows. Almost all of them are open source…
So off I went, in an attempt to figure all this out from available, free tools. I came across a very helpful article atwww.ioncannon.net, iPhone HTTP Streaming with FFMpeg and an Open Source Segmenter and initially got a stream up and running quite quickly. But the bitrates of the resultant streams just didn’t come close to the bitrates I wanted. (Knowing how HLS works, it seems it would be fairly important to have bitrates that come close to what is advertised in the main playlist.) I spent the next few days trying my best to getFFMPEG to cooperate, but to no avail… on a 150 kbit/s stream, it produced 220 kbit/s… on a 800 kbit/s stream, it produced a 250 kbit/s stream. On top of this, if I told FFMPEG to use AAC, the audio sounded horrible (MP3 was much better at the same bitrate!)
After days of experimentation, I finally got the results I wanted from free tools for creating HTTP Streams for use with iPhone, iPad, iPod. The information out there on how to get these tools to do what you want is pretty horrible. Especially for the video processing layman like myself, who “just wants it to work!”
In summary, FFMPEG fails on two fronts here:
- FFMPEG is horrible at AAC audio encoding. The resultant audio sounds horrible. The free NeroAacEnc does a much better job. Yes, we could use MP3, but AAC supposedly provides better sound at similar compression rates versus MP3.
- FFMPEG simply doesn’t (by any of my tests) come close to honoring a recommended bitrate for x264 video encoding. I have tried suggestions from theFFmpeg x264 encoding guide, including two pass encoding, but to no avail. Video bitrates were simply way off.
So I am using a combination of executables: ffmpeg (extract audio for Nero), Nero AAC Encoder (audio encoding), x264 (video encoding), ffmpeg (mux audio/video to create TS file), and an open source segmenter (to create m3u8 for each bitrate). The resulting output looks great, and at least comes pretty close to desired bitrate… finally!
Hope this helps someone out there!