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: <video class="video-stream" autoplay="autoplay" src="http:// v16.lscache7.c.youtube.com/videoplayback?ip=0.0.0.0&sparams=id %2Cexpire%2Cip%2Cipbits%2Citag%2Calgorithm%2Cburst%2Cfactor%2Coc %3AU0dWSFdOVV9FSkNNNl9PSFlH&algorithm=throttle- factor&itag=18&ipbits=0&burst=40&sver=3&expire=1273737600&key=yt1&signature=A1AE06C786790EAD074C789B07792DFAC9D283A4.26623FAB2D4133DD8747C12C6814AB0D4C24889F&factor=1.25&id=a51f4383727805ad"></ video> 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.