[The Java Posse] H.264 explainers

Chris Adamson Wed, 12 May 2010 19:31:25 -0700

Seemed like there was some confusion and misstatements regarding video
support in the weekly anti-Apple tirade.  Let's see if we can clear
some of that up.

I'm going to fork this conversation for the sake of two readerships.

FOR LINUX ADVOCATES:

This entire discussion is pointless, because everything should be in
Ogg. Also, nothing should cost anything, "Serenity" was the best
movie ever made, unicorns really exist, and they fart rainbows.

FOR EVERYONE ELSE:

H.264 is just a video codec, a patent-encumbered, widely-licensed
scheme for encoding and decoding video streams. Saying something is
in H.264 implies nothing about platforms or transport technology. H.
264 is used, among other things, as one of the three video codecs for
Blu-Ray (the others are MPEG-2 and VC-1, which is Windows Media 9 as
ratified by a standards body), and is used by DirecTV for HD local
channels in most markets. It is also supported in hardware by many
mobile devices, and is even supported by Flash, where it is largely
displacing "FLV" (usually meaning Sorenson Spark or VP6) as the go-to
codec for reasons of quality, widespread client-side support, and
encoder expertise. Frankly, people who are paid to know this stuff
called the race for H.264 years ago (consider:
http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=65306
). Theora advocates register with media professionals pretty much the
same way Intelligent Design advocates come across to genuine
biologists.

Dick is right that he can't buy a video off the iTunes store and play
it in Linux, not because it's H.264, but because [aside from the fact
that everything should be in Ogg, unicorns and ponies, and all that…]
iTunes videos are wrapped in an Apple-proprietary DRM called FairPlay
that the company does not license out to third parties. If not for
the DRM, iTunes movies and TV shows would be widely playable beyond
the Apple ecosystem. Will that ever happen? Well, they used to sell
music wrapped in FairPlay, but convinced the record labels to agree to
go DRM-free. But nobody expects video to lose the DRM encumbrance
anytime soon. Rights-holders still think it's awesome (they also
believe in unicorns, ponies, etc.)

The HTML5 <video> tag doesn't say anything about DRM. Indeed, it
doesn't even specify what payloads should/must be supported. Most
commercial interests, including Apple and Microsoft, support H.264,
while Firefox has vowed support for Theora and not 264.

In some ways, this moves the problem to the server. Not only does a
content provider potentially now have to provide multiple encodings
and possibly a client-sniffing script to write the <video> tag
(somewhat reminiscent of the bad old pre-Flash days when video had to
be re-encoded and served up in WMP, Real, and QuickTime variants), but
they also don't want the "src" URL in a <video> tag to be something
you can just slurp down and store forever. If you activate YouTube's
HTML5 trial, you'll find that most commercial content still gets sent
to you in a Flash container, where the DRM story is much more solid
(aside: how would Linux advocates feel about Flash if it still
neglected Linux like it did for the first half of the 2000s?). For
user-generated content on YouTube, you can turn on developer mode in
your browser to get the script-written <video> tag. On an anime music
video, I found this:

Still, when I try to curl that URL, I get 0 bytes. HIghly likely that
YouTube is setting a cookie and expecting it back, or doing something
else to keep the video from being easily grabbed.

But the video tag is just one web container for H.264, and a very file-
oriented one at that (though you can start playback before the whole
file is downloaded, provided the metadata atoms are at the beginning
of the file, which seems to always be the case in MPEG-4 files).
Another one that most people don't know or talk about is "HTTP Live
Streaming". This is an Apple-sponsored protocol for multimedia
streaming that has been proposed as an IETF standard (draft here:
http://tools.ietf.org/html/draft-pantos-http-live-streaming-03 ). The
gist of HLS is that rather than create some new socket-based protocol
(that Stalinist net admins will just block anyways), you segment a
potentially endless media stream into individual files representing
small segments of time (10 seconds by default), and then provide a
constantly-updating m3u8 playlist via a URL. A client gets the
playlist, downloads the first few segments as flat files over http
(probably on the never-blocked port 80) and starts playing them,
continually refreshing the playlist for more segments to download and
queue up.

I worked briefly with a company last year on an iPhone app that used
HLS to stream radio broadcasts of professional sports events. It's
worth noting that the major content delivery networks (CDNs) like
Akamai and Brightcove already support HLS. And on the client side,
it's supported in hardware by iPhone OS devices, as well as by
QuickTime X in Snow Leopard. Oh, and Apple did another one of those
license agreement fiat moves and declared that it's the only way you
may stream video to an iPhone OS client. One other nit-pick: because
of the inherent latency of a queue of 10-second segments, it's
anything but "live". App Store reviews dinged the app for being 30
seconds behind local television broadcasts, something that's inherent
to the technology.

The reason I bring up HLS is because it might actually afford the best
hope -- better than the HTML5 <video> tag -- for a cross-platform
video standard that can still handle DRM for those rights-holders who
insist on it. Section 6.2.3 of the spec indicates how a stream may be
encrypted with a decryption key available via a URI to authorized
clients (somewhere, I think the spec also allows for the keys to
change in mid-stream). My reading of that gives me hope that we can
get away from implementing DRM in the client (an app, a plugin, a
library, whatever), and instead do so in the network. If my reading
of this is right, an arbitrary platform should be able to participate
in a DRM-ed HTTP Live Stream, provided it succeeds in some sort of
negotiation with the server and is provided with decryption keys.
Also, despite the name, HTTP Live Streaming is not only for live
events or streams of unknown length; the spec is also clear about how
you'd segment a distinct media file into a playlist and make that
available to clients. So in that sense, it could potentially offer a
direct replacement for the <video> tag, and also provide DRM, meaning
that big-money rights-holders would actually use it. What's not clear
is whether it will get any traction outside of the Apple sphere of
influence.

Anyways, brain-dump over. Suffice to say that neither H.264, nor the
HTML5 video tag, is the end of the story.

--Chris

--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.

[The Java Posse] H.264 explainers

Reply via email to