## May 1, 2011

### 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 … ☹.
Posted by distler at May 1, 2011 10:08 PM

TrackBack URL for this Entry:   http://golem.ph.utexas.edu/cgi-bin/MT-3.0/dxy-tb.fcgi/2395

### 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.

Posted by: Henri Sivonen on May 10, 2011 3:06 PM | Permalink | Reply to this

### Re: Shoah

The video is 2 hours in length. If you wanted to listen to 2 minutes near the end, you would have to download the full 596MB file. That would be annoying for you and costly for my server bandwidth.

With streaming, you can download just the last 2 minutes (about 10 MB), which makes both of us much happier.

Non-streaming video, on the web, is invariably restricted to 10 minutes in length, or shorter, for just that reason.

Now, if Firefox supported HTTP Live Streaming with the vp-8 CODEC, I’d be happy to provide an appropriately-encoded stream (which would work just fine in the HTML5 <video> element).

Aside: WebM and Ogg are always streamable and live streamable without special steps, since they work even without an index.

I think you are conflating “streamability” with “progressive downloadability”. Streamability (at least, in the sense it’s used here) means being able to start the video in the middle, without having to download the whole file up to that point.

Theoretically, that’s possible (for H.264, WebM and Ogg) with byte-range GET requests. But that requires extra smarts, either on the server or on the client side, neither of which is available out-of-the box. Darwin Streaming Server provides the requisite server-side intelligence. But, AFAIK, it only works with a .mov container.

The advantage of HTTP Live Streaming is that it requires no intelligence on the server side. It uses ordinary HTTP GET requests; all intelligence is on the client side.

Posted by: Jacques Distler on May 10, 2011 5:03 PM | Permalink | PGP Sig | Reply to this

### Re: Shoah

It usually means being able to watch the video as it is being downloaded. I think the right word for what you mean is “seekability”.

Theoretically, that’s possible (for H.264, WebM and Ogg) with byte-range GET requests. But that requires extra smarts, either on the server or on the client side, neither of which is available out-of-the box. Darwin Streaming Server provides the requisite server-side intelligence.

I believe the required smarts (support for Range requests) is available by default in Apache without having to have Darwin Streaming Server or anything fancy like that. It seems to me the client-side smarts for using Range requests for seeking ahead of the download point in a WebM file that has an index in the beginning are in Firefox, Opera and in Chrome 12, though not in Chromium 11, it seems.

Posted by: Henri Sivonen on May 11, 2011 2:55 AM | Permalink | Reply to this

### Re: Shoah

Chrome 11 seems to support Range-based seeking. Dunno what the deal with the difference in Chromium is, but it’s probably not worth worrying about considering the tiny userbase.

Posted by: Henri Sivonen on May 11, 2011 3:16 AM | Permalink | Reply to this

### Re: Shoah

The first kind of “streamability” (the ability to start playing the video immediately, while the download is still in progress) is a necessary pre-requisite for the second kind “streamability” (the ability to start playing at an arbitrary point in the video, without having downloaded the prior bits).

But it’s the latter capability (the term “seekability” does not seem to be in common usage) that leads people to install the Flash Server (streaming over RTMP) or the Darwin Streaming Server (streaming over RTSP), instead of simply serving the same files over HTTP, with Apache.

Of course, Apache supports byte-range requests. It’s the clients that (typically) just request the whole file.

Indeed, I’d be surprised if that didn’t happen, even using WebM, under Firefox/Opera/Chrome 12. Are you saying that if you

1. Start playing a WebM video.
2. Push the stop button.

If you, the client, aren’t paying by the byte, you probably don’t care whether your browser continues downloading the video, even after you press the stop button. But I, the server, care. And, if you were on a mobile device (with a restrictive data plan) you would care, too.

Posted by: Jacques Distler on May 11, 2011 9:35 AM | Permalink | PGP Sig | Reply to this

### Re: Shoah

Are you saying that if you

No, I’m not saying anything about that at this time. Intentionally refraining from buffering to the fullest extent possible is yet another different thing. I was saying stuff about being able to skip to the middle without downloading all data up to that point in response to this bit:

Streamability (at least, in the sense it’s used here) means being able to start the video in the middle, without having to download the whole file up to that point.

Posted by: Henri Sivonen on May 15, 2011 12:05 PM | Permalink | Reply to this

### Re: Shoah

Thanks for sharing your father’s story with us. It is important for the world to always remember what happened during WW2 and to hear such stories.

Posted by: karmaloop coupon code on May 17, 2011 12:30 PM | Permalink | Reply to this

### Re: Shoah

would it be possible for you to upload the video to youtube or vimeo? not all people have the quicktime plugin.. thanks

Posted by: sarah ford on May 28, 2011 12:23 PM | Permalink | Reply to this

### Re: Shoah

I never saw the original but thank you for this new version it’s very interesting especially in light of what’s happening in the Middle East right now.

Posted by: Jim on June 20, 2011 8:31 PM | Permalink | Reply to this

### Re: Shoah

Thank you for sharing this. It’s so important to have a record of the Holocaust stories.

In kindergarten a classmate’s mom came and told us of how she had escaped from Germany. And now the wall is down. Kids today will have little concept of it.

What happened needs to be known and never forgotten, which is emphasized even more with yesterday being the 10th anniversary of 9/11.

Thanks,
~Roger

Posted by: Roger on September 12, 2011 5:47 PM | Permalink | Reply to this
Read the post Those \$1000 Said No New Physics At The TeV Scale... And They Did Not Lie
Weblog: Science 2.0
Excerpt: In September 2006 I was in Ponta Delgada, the main town of the island of San Miguel in the Azores, for a physics conference where I was presenting results of the CDF experiment. I remember listening to a very nice talk by Guido Martinelli, who was discuss
Tracked: June 25, 2013 9:31 AM

Post a New Comment