Wow, for something as generic as h.264 you sure get around Apple a lot, more than twice as much as you get around unicorns. Anyway, how about the prospect of Google cornering the marked, by releasing VP8 which they got from their On2 purchase?
/Casper On 13 Maj, 04:31, Chris Adamson <[email protected]> wrote: > 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group > athttp://groups.google.com/group/javaposse?hl=en. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
