Linked by Thom Holwerda on Fri 14th Jan 2011 22:33 UTC
Google I didn't plan on this, but there's really nothing I can do. Unless you want me to write about the upcoming ten billionth download from the iOS App Store, you'll have to settle for this. On the Chromium blog, Google has clarified its decision to drop H.264 support from the Chrome web browser, and in it, Google basically repeats the things that those concerned about the future of video on the web have been saying for a long time now: H.264 on the web kills innovation.
Thread beginning with comment 458030
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Reasonable overview
by galvanash on Sat 15th Jan 2011 00:05 UTC in reply to "Reasonable overview"
Member since:

Love it or hate it, Appleā€™s devices, and particularly their mobile devices, are way too popular to ignore.

Really? Look, I have an iPad... I even like it. I have some other Apple hardware too and I do a bit of iOS development. Call me weird, but for whatever reason I have so far proven immune to Steve's "Reality Distortion Field"...

iOS is a drop in the bucket as far as the web goes as a whole - it might represent 1% of all clients. It is by no reasonable definition "too popular to ignore".

Regardless, no one says you have to ignore it - if you want to push video to iOS use h.264. Everyone keeps talking about how oh so horrible having to manage 2 formats is - that is bullshit.

As it stands now - if you want to actually stream video to iOS over 3G the only endorsed method on iOS is to use HTTP Live Streaming... Guess what? That requires using MPEG-TS transport streams for the container format. Not MP4, yet another format. There are lots of other examples of stuff like this - what about baseline vs main profile for h.264? You have to take that into account as well if you target non-streaming devices primarily with your encodes.

The point is anyone doing commercial video streaming is already re-encoding the content. If the content comes from 3rd parties doing that is basically required. You don't have to ignore iOS - you just have to encode twice if you want the widest coverage. Get over it. Or you can just do h.264 and ignore WebM - no one is going to arrest you or anything.

All Google has done here is shock people back to reality. It seems that everyone had fallen into a comfortable delusion thinking that h.264 was the "standard" for the web...


Reply Parent Score: 8

RE[2]: Reasonable overview
by brichpmr on Sat 15th Jan 2011 22:55 in reply to "RE: Reasonable overview"
brichpmr Member since:

Take a look at the content at this linked site in Berlin. I doubt they will be chomping at the bit to replace their high quality H.264 content with WebM any time soon. And, there are millions of devices worldwide (outside of the web) that are already H.264 savvy.

Like it or not, the H.264 train left the station a long time ago; and by comparison, WebM is a solution to a non-existant problem, IMHO.

Reply Parent Score: 1

RE[3]: Reasonable overview
by galvanash on Sun 16th Jan 2011 06:56 in reply to "RE[2]: Reasonable overview"
galvanash Member since:

Take a look at the content at this linked site in Berlin. I doubt they will be chomping at the bit to replace their high quality H.264 content with WebM any time soon.

First, from a simple practical point of view, they don't need to. Google removing h.264 from chrome would not affect a chrome user's ability to view that content were it offered using the <video> tag, it would simply fall back to Flash and most users wouldn't even notice the difference.

Which brings us to point two: That site doesn't even USE the video tag!!!. They serve all video using Flash...

That is what is so infuriating about debating this issue - those against this are starting from Google=BAD and just making up bullshit arguments to support their prejudiced viewpoint.

The H.264 train left the station a long time ago; and by comparison, WebM is a solution to a non-existant problem, IMHO.

WebM will allow an open source developer to implement a browser or other software which incorporates a video encoder/decoder which will be inter operable with the HTML5 <video> tag - without having to worry about royalty payments. It is a solution to a VERY serious problem - if you can't see what is plainly obvious and right in front of your face I don't know what else to tell you.

Here is a simple list of problems with h.264 that WebM solves in one way or another:

1. Firefox will not and can not EVER include h.264 - they have made that quite plain. That is a browser that represents an absolutely huge number of users...

2. Anyone wanting to write a browser in the future that incorporates the video tag will be expected to support h.264 if it becomes the defacto standard. If they do not wish to pay royalties they simply CAN'T implement one. That eliminates non-commercial browsers, which is ironic because the web was BUILT upon non-commercial browsers...

3. Software like Handbrake, VLC, Memcoder, FFMpeg, etc. ALL of these use unlicensed h.264 encoders. MPEG-LA could try to shut any or all of these down any time they felt like it. The fact that they don't and they let it slide doesn't change the fact that if you want to do things without violating US patent laws you can't use h.264 in open source software.

4. Sites that charge subscriptions to access their content, even if it is very small amounts or micro-payments, are technically required to pay royalties for h.264 if they offer ANY content using it.

5. There is simply no guarantee that MPEG-LA will keep non-commercial h.264 content royalty free. Sites that use it on a large scale (like youtube, vimeo, etc.) are at the mercy of MPEG-LA hitting them with unpredictably large royalty fees in the future.

Think about it....

Edited 2011-01-16 07:06 UTC

Reply Parent Score: 3