Wow. Google is dropping H.264 support in Chrome.Though H.264 plays an important role in video, as our goal is to enable open innovation, support for the codec will be removed and our resources directed towards completely open codec technologies. Not sure how this is going to work in terms of Android, since as far as I know there are no mobile chipsets with hardware accelerated VP8 support. I guess maybe this move will force the creation of such chipsets? Or it's just not necessary any more since chips like Arm Cortex A9 are plenty powerful? (I don't really believe that last sentence.) I can truthfully say I did not see this one coming.
How does this affect YouTube? I thought Google was transitioning those to H.264. Does it mean their own browser won't play their own videos?
YouTube can afford to double encode. I need time to think about this, but my initial reaction is: stupid. Inferior codec with inadequate client support.
Prediction: plug in will be available. apple and or msft?
The Chrome Flash plug-in supports H.264. Not sure how that squares with Google's desire to support "open standards" though. I'm sure YouTube will re-encode. I wonder if this is a case of Google being so large that some parts of it (the Chrome team) aren't fully in line with other parts (the Android team)?
To clarify: Flash will play H.264, but only if you serve the video inside a Flash wrapper - not with the HTML5 <video> tag. For people building websites this makes the path of least resistance to just forget about HTML5 and <video> and serve all video wrapped in Flash. Except of course for all those iOS devices that don't play Flash. Interesting times. This could put Apple in a bit of a pickle.
I must say I feel somewhat vindicated regarding my kneejerk support of Ogg Theora even if this is all just some high-level machiavellian double fake out.
It's Google's very own VC-1, IMHO, with all that entails (poor compression efficiency, poor client HW support, questionable pedigree of IP). Although we were able to kill VC-1. Gonna be a mess.
In a conversation with someone who's very steeped in the field, "Will it be another VC-1, or something more?" I think that's the question.
For the cpu vs. accelerator issue, here's one to consider ... vlc on ipad vs. ipad's native media player. The vlc code does not have access to the HW accelerator and is very weak. Video decompression is hard. Computers have processor overkill, and often can enlist the GPU to help. Mobiles are much more parsimonious in resources. There are enough similarities between the various codecs that a multi-format codec isn't much harder to make than a single format codec. But an existing codec could very easily be incompatible with no fix whatsoever.
VP8 doesn't have B frames. B frames have been around since MPEG-2. (Silicon for MPEG-2 dates back to around '93-94.) They are used because they are awesome. In 264, I frames are huge, P frames are small, and B frames are fricking tiny. Now, mobile devices tend to implement baseline h.264, which lacks B-frames. This is done because B-frames consume a lot of memory bandwidth in the decoder. But, there's a clear path laid out for improvement in compression efficiency within the 264 family. VP8 not so much. What's the big hairy issue in the interwebs these days? Bandwidth.
Is google gonna give me the fibers to my house? unlimited downloads to my mobile? If not, why are they pushing an inferior technology?
/rant
also too, Apple needs to open up the accelerator on the ipad, and reach detente with vlc. They are fools if they don't.
Another guess: infrastructure cost reduction
ars technica: a step backward
So it is about YouTube? Putting on the brakes in transitioning to h.264 and abruptly changing to another standard?
So the world can continue to post its cats from every angle, in motion.
I don't think it's "about" YouTube. YouTube is just the leverage that Google has to wield. Without YouTube nobody would care what video codec Google wants us all to use. BUT, if they re-encode all YouTube videos into WebM, then people will be forced to use the codec since everybody wants to access YouTube.
But note, google has not said they are going to re-encode YouTube videos in WebM. My guess is they will not, but merely serve H.264 video wrapped in Flash. The winner in this scenario is Flash, and the loser is the HTML5 <video> tag, and to a lesser extent HTML5 itself, and of course Apple's iOS devices which don't have a Flash plug-in.
So this could be a move to hurt Apple. Or it could be a move to help Flash not lose to HTML5 for video (where Flash has much better DRM capabilities which might help Google if they are planning to monetize some video content with a pay wall; and where Flash allows for layering content on top of video which might be part of Google's plans for forcing advertising along with free video.) Or it could be a combination of these factors.
I don't think it's about "infrastructure cost reduction" since H.264 has better quality at smaller file sizes than WebM.
I don't buy the infrastructure argument either. Flash enforces commercials. I'm not aware of any other format (other than live UDP streaming and the like) that does. Google tipping the balance towards Adobe and away from apple is plausible. With the advent of android, google and apple are direct competitors.
Here are some blunt questions from an h.264 critic.
Turns out Chrome still hasn't dropped H.264 support, although the original claim was just that they would drop it "at some point" in the future so I guess it might still happen.
And, from the other direction, Mozilla is changing their hard line approach. Today they announced (via a simple post to a technical discussion list) that they will support decoding any audio/video format on mobile platforms if the underlying OS or hardware support it (this includes H.264 and gets around the licensing issues since Mobile FireFox won't be supplying the decoder.) Mozilla also states that adopting this approach on the desktop is under discussion. The original post is here. There is of course quite a bit of push back on this from people who *really* don't want Mozilla to support H.264.
|
- jim 1-12-2011 1:51 am
How does this affect YouTube? I thought Google was transitioning those to H.264. Does it mean their own browser won't play their own videos?
- tom moody 1-12-2011 4:58 am
YouTube can afford to double encode. I need time to think about this, but my initial reaction is: stupid. Inferior codec with inadequate client support.
- mark 1-12-2011 5:59 am
Prediction: plug in will be available. apple and or msft?
- mark 1-12-2011 6:00 am
The Chrome Flash plug-in supports H.264. Not sure how that squares with Google's desire to support "open standards" though. I'm sure YouTube will re-encode. I wonder if this is a case of Google being so large that some parts of it (the Chrome team) aren't fully in line with other parts (the Android team)?
- jim 1-12-2011 1:39 pm
To clarify: Flash will play H.264, but only if you serve the video inside a Flash wrapper - not with the HTML5 <video> tag. For people building websites this makes the path of least resistance to just forget about HTML5 and <video> and serve all video wrapped in Flash. Except of course for all those iOS devices that don't play Flash. Interesting times. This could put Apple in a bit of a pickle.
- jim 1-12-2011 2:10 pm
I must say I feel somewhat vindicated regarding my kneejerk support of Ogg Theora even if this is all just some high-level machiavellian double fake out.
- tom moody 1-12-2011 4:13 pm
It's Google's very own VC-1, IMHO, with all that entails (poor compression efficiency, poor client HW support, questionable pedigree of IP). Although we were able to kill VC-1. Gonna be a mess.
- mark 1-12-2011 5:45 pm
In a conversation with someone who's very steeped in the field, "Will it be another VC-1, or something more?" I think that's the question.
- mark 1-12-2011 7:52 pm
For the cpu vs. accelerator issue, here's one to consider ... vlc on ipad vs. ipad's native media player. The vlc code does not have access to the HW accelerator and is very weak. Video decompression is hard. Computers have processor overkill, and often can enlist the GPU to help. Mobiles are much more parsimonious in resources. There are enough similarities between the various codecs that a multi-format codec isn't much harder to make than a single format codec. But an existing codec could very easily be incompatible with no fix whatsoever.
VP8 doesn't have B frames. B frames have been around since MPEG-2. (Silicon for MPEG-2 dates back to around '93-94.) They are used because they are awesome. In 264, I frames are huge, P frames are small, and B frames are fricking tiny. Now, mobile devices tend to implement baseline h.264, which lacks B-frames. This is done because B-frames consume a lot of memory bandwidth in the decoder. But, there's a clear path laid out for improvement in compression efficiency within the 264 family. VP8 not so much. What's the big hairy issue in the interwebs these days? Bandwidth.
Is google gonna give me the fibers to my house? unlimited downloads to my mobile? If not, why are they pushing an inferior technology?
/rant
- mark 1-12-2011 10:52 pm
also too, Apple needs to open up the accelerator on the ipad, and reach detente with vlc. They are fools if they don't.
- mark 1-12-2011 10:54 pm
Another guess: infrastructure cost reduction
- mark 1-13-2011 9:30 am
ars technica: a step backward
- mark 1-13-2011 9:33 am
So it is about YouTube? Putting on the brakes in transitioning to h.264 and abruptly changing to another standard?
So the world can continue to post its cats from every angle, in motion.
- tom moody 1-13-2011 3:50 pm
I don't think it's "about" YouTube. YouTube is just the leverage that Google has to wield. Without YouTube nobody would care what video codec Google wants us all to use. BUT, if they re-encode all YouTube videos into WebM, then people will be forced to use the codec since everybody wants to access YouTube.
But note, google has not said they are going to re-encode YouTube videos in WebM. My guess is they will not, but merely serve H.264 video wrapped in Flash. The winner in this scenario is Flash, and the loser is the HTML5 <video> tag, and to a lesser extent HTML5 itself, and of course Apple's iOS devices which don't have a Flash plug-in.
So this could be a move to hurt Apple. Or it could be a move to help Flash not lose to HTML5 for video (where Flash has much better DRM capabilities which might help Google if they are planning to monetize some video content with a pay wall; and where Flash allows for layering content on top of video which might be part of Google's plans for forcing advertising along with free video.) Or it could be a combination of these factors.
I don't think it's about "infrastructure cost reduction" since H.264 has better quality at smaller file sizes than WebM.
- jim 1-13-2011 4:26 pm
I don't buy the infrastructure argument either. Flash enforces commercials. I'm not aware of any other format (other than live UDP streaming and the like) that does. Google tipping the balance towards Adobe and away from apple is plausible. With the advent of android, google and apple are direct competitors.
Here are some blunt questions from an h.264 critic.
- mark 1-13-2011 5:48 pm
Turns out Chrome still hasn't dropped H.264 support, although the original claim was just that they would drop it "at some point" in the future so I guess it might still happen.
And, from the other direction, Mozilla is changing their hard line approach. Today they announced (via a simple post to a technical discussion list) that they will support decoding any audio/video format on mobile platforms if the underlying OS or hardware support it (this includes H.264 and gets around the licensing issues since Mobile FireFox won't be supplying the decoder.) Mozilla also states that adopting this approach on the desktop is under discussion. The original post is here. There is of course quite a bit of push back on this from people who *really* don't want Mozilla to support H.264.
- jim 3-13-2012 10:55 pm