Shoah
Ten years ago, I put up a web page devoted to my father’s Holocaust survival story. The centerpiece was a 2-hour long video of an interview he did in 1993. Back in 2001, the Sorenson 3 Codec, and QuickTime Streaming, were the cat’s pajamas, so that was how I encoded the video. A decade later, Sorenson 3 won’t play on many installations. So, for this year’s Yom HaShoah, I revamped the web page, and re-encoded the video in H.264.
I’m still using QuickTime Streaming … which doesn’t work on the iPhone/iPad. They don’t support RTSP streaming and, instead, require some new-fangled technology, called HTTP Live Streams, to do streaming video (maybe by the next Yom HaShoah …).
Anyway, in honour of Yom HaShoah, 2011, here’s the revamped page1.
1 One glitch: in late-model Firefox, the controls for the QuickTime plugin sometimes fail to load. movie.GetPluginStatus() returns Error: -37. A simple Javascript hack, which reloads the movie, seems to fix the problem.
Update (5/6/2011): HTTP Live Streaming
OK, once I installed a new version of ffmpeg (the one that I had installed, in 2009, produced unplayable .ts files), producing an HTTP Live Streaming version wasn’t so hard. First, convert each H.244 video from an MPEG-4 to an MPEG-2 Transport Stream container, and run the segmenter (which comes with Snow Leopard) to break the latter into 10-second chunks (placed in the stream directory, along with an .m3u8 file for the stream):
ffmpeg -i interview-300.mp4 -acodec copy -vcodec copy -vbsf h264_mp4toannexb -f mpegts interview-300.ts mediastreamsegmenter -b http://golem.ph.utexas.edu/~distler/shoah/stream -B interview-300- -f stream -i interview-300.m3u8 -O -p < interview-300.ts
Repeat for each bitrate of movie, noting down the total bandwidth, for each, as reported by mediastreamsegmenter. Then create a variant playlist .m3u8 file. The first entry is the stream that gets loaded first. The order of the other entries doesn’t matter.
#EXTM3U #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=360000 http://golem.ph.utexas.edu/~distler/shoah/stream/interview-300.m3u8 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=50000 http://golem.ph.utexas.edu/~distler/shoah/stream/interview-40.m3u8 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=130000 http://golem.ph.utexas.edu/~distler/shoah/stream/interview-100.m3u8 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=940000 http://golem.ph.utexas.edu/~distler/shoah/stream/interview-800.m3u8
- There’s no support for Chapter Tracks, though in principle there ought to be. In compensation, iPad users get access to full-screen playback, which the standard Quicktime widget doesn’t support.
- Android 3.0 purportedly support HTTP Live Streaming (via the HTML5
<video>element), but apparently not … ☹.
Re: Shoah
The video doesn’t play for me on Ubuntu using a development version of Firefox 6 (with or without Totem QuickTime Plug-in emulation present).
Why make this Apple-dependent when this could be easily be made cross-browser without NPAPI or ActiveX plug-ins by putting the effort into making one WebM encode and one H.264 Baseline profile encode instead of putting the effort into multiple H.264 encodes and a JS hack?
Before you used HTTP Live Streaming, did your initial .mp4 file not start playing in Safari before the entire file was loaded? After all, since this is a recording, you shouldn’t need HTTP Live Streaming for streamability if your .mp4 file has the index in the front of the file if I’ve understood how .mp4 works correctly. In that case, HTTP Live Streaming provides just bandwidth adaptation.
Aside: WebM and Ogg are always streamable and live streamable without special steps, since they work even without an index. However, they don’t provide bandwidth adaptation that HTTP Live Streaming provides.