Youtube : All New Videos are transcoded into WebM


Recommended Posts

Andre S.

I just did a quick test with a random frame from a random 720p Youtube video:

h264

http://img692.imageshack.us/img692/6969/028mp4.png

WebM

http://img811.imageshack.us/img811/3798/028webm.png

How did you get the WebM version, was it by opting in on youtube.com/html5 ? It does look very similar to h264, although for my comparison I chose a frame where there was a lot of motion, which is where the difference between codecs really shows.
Link to post
Share on other sites
Pupik

Tested the differences myself and except seeing the crappy quality "directly', I also noticed that the html5 player only supports 720p as the highest quality with Firefox 4 (didn't test with other browsers). Videos that had an option for 1080p or higher ("original") before switching to /html5, no longer have it.

Link to post
Share on other sites
Andre S.

Well at least it's still opt-in only. H264 remains standard and if you don't have flash player it'll still tell you that you need it for viewing Youtube videos. So while they do plan on offering WebM for all their videos, H264 isn't going away anytime soon. At least that's what I figured out reading the blog entry carefully and some of the user comments.

So if that's the case I'm not really worried.

I'm all for replacing Flash with HTML5, but technically they could keep the same codecs and serve it in HTML5... I just don't see what's the big interest for that crappy VP8 codec.

Link to post
Share on other sites
OuchOfDeath

The "big interest" is that it's an open standard. h.264 is proprietary, patent-encumbared, and controlled by a few entities with profit in mind. You must pay royalties to use h.264 commercially. Opera as an example are unable to implement it because the royalties are too expensive. End-users are lucky for now, however there was a whole outburst many months ago where it was revealed h.264 would cease to be royalty-free for end users, possibly meaning every time you'd want to watch a video on the internet in h.264 you'd have to pay a royalty. The decision was reversed, however it goes to show what the organizations controlling h.264 would like to do. It stifles innovation at the expense of profit.

VP8 is an open codec in every sense and is not controlled by any entity. Nobody will ever have to pay anything, and it guarantees a crucial part of the web stays open.

Link to post
Share on other sites
Andre S.
Nobody will ever have to pay anything
I wouldn't be so sure:
3. How likely is VP8 to actually be free of patents? Even if VP8 is worse than H.264, being patent-free is still a useful attribute for obvious reasons. But as noted in my previous post, merely being published by Google doesn?t guarantee that it is. Microsoft did similar a few years ago with the release of VC-1, which was claimed to be patent-free ? but within mere months after release, a whole bunch of companies claimed patents on it and soon enough a patent pool was formed.

(...) the problem of patents appears to be rearing its ugly head again. VP8 is simply way too similar to H.264: a pithy, if slightly inaccurate, description of VP8 would be ?H.264 Baseline Profile with a better entropy coder?. Even VC-1 differed more from H.264 than VP8 does, and even VC-1 didn?t manage to escape the clutches of software patents. It?s quite possible that VP8 has no patent issues, but until we get some hard evidence that VP8 is safe, I would be cautious. Since Google is not indemnifying users of VP8 from patent lawsuits, this is even more of a potential problem. Most importantly, Google has not released any justifications for why the various parts of VP8 do not violate patents, as Sun did with their OMS standard: such information would certainly cut down on speculation and make it more clear what their position actually is.

Source

Link to post
Share on other sites
OuchOfDeath

I'm pretty sure VP8 will be defended from patent trolls the same way Linux is defended currently. There are many groups that have a vested interest in keeping these technologies free and open, and will defend them at their expense. We'll see how things turn out.

Link to post
Share on other sites
ichi

The video codec doesn't know what a texture is, the textures as far as it cares, IS details, and they are sharper and better in h.264. that was a horrible example to use though as the whole frame has no details, the whole thing is blurry from the source

That is not 'sharper'. That is 'pixelized'.

Yes, the source is indeed a bit crappy :unsure: the h264 video still looks more blurry though. The boxes on the left have some detail in WebM while in h264 it's just blur.

Maybe I'll try uploading a 1080p video from my GoPro later and see how it goes with that.

That seems like really high CPU usage, were you using an external player of Adobe Flash and browser's built in WebM thru HTML5 support? Those are performance-bad solutions for a NV 7300.

An Atom N270 without hardware acceleration and without CoreAVC will play 720p YT h264 just fine.

An external player. CPU usage could probably have been lower using mplayer, but anyway the point is that both videos performed the same.

How did you get the WebM version, was it by opting in on youtube.com/html5 ? It does look very similar to h264, although for my comparison I chose a frame where there was a lot of motion, which is where the difference between codecs really shows.

I downloaded the videos using the VideoDownloadHelper extension for Firefox. It showed all the available sources for different resolutions and codecs. I'm not sure if you need to opt-in to get the WebM sources, I did anyway.

Link to post
Share on other sites
HawkMan

I downloaded the videos using the VideoDownloadHelper extension for Firefox. It showed all the available sources for different resolutions and codecs. I'm not sure if you need to opt-in to get the WebM sources, I did anyway.

Meaning you used a different video decoder than the one the website/browser would use, possibly reducing the output quality of the h.264 video. The codec and encoding is only 2/3rds of the equation. and depending on what h.264 codec you have installed it may show the video at significantly lower quality.

Link to post
Share on other sites
ichi

Another test, two frames from a just uploaded 720p video I shot some time ago. Original res is 1080p, but Youtube isn't showing a 1080p WebM version for the video :huh:

File sizes:

WebM: 14,6MB

H264: 17MB

Average CPU usage (mplayer):

WebM: 41,6%

H264: 47%

webm: http://img812.imageshack.us/img812/4671/1webm.png

h264: http://img862.imageshack.us/img862/1276/1mp4.png

webm: http://img847.imageshack.us/img847/1052/3webm.png

h264: http://img855.imageshack.us/img855/9206/3mp4.png

I'm not a "videophile" but they all look the same to me :unsure: well, not exactly the same, but about the same quality.

Meaning you used a different video decoder than the one the website/browser would use, possibly reducing the output quality of the h.264 video. The codec and encoding is only 2/3rds of the equation. and depending on what h.264 codec you have installed it may show the video at significantly lower quality.

Or it might show it at significantly better quality :p I didn't take the screenshot from the external player, I extracted the frame using ffmpeg.

How do you take a frame out of a flash embedded video at the original resolution anyway? I only seem to be able to play them at the default player size or fullscreen, neither of which would be native resolution for a 720p video.

Link to post
Share on other sites
Miuku.

I wouldn't be so sure:

Quoting x264 devs is like quoting Microsoft on Linux.

Link to post
Share on other sites
HawkMan

Another test, two frames from a just uploaded 720p video I shot some time ago. Original res is 1080p, but Youtube isn't showing a 1080p WebM version for the video :huh:

File sizes:

WebM: 14,6MB

H264: 17MB

Average CPU usage (mplayer):

WebM: 41,6%

H264: 47%

webm: http://img812.imageshack.us/img812/4671/1webm.png

h264: http://img862.imageshack.us/img862/1276/1mp4.png

webm: http://img847.imageshack.us/img847/1052/3webm.png

h264: http://img855.imageshack.us/img855/9206/3mp4.png

I'm not a "videophile" but they all look the same to me :unsure: well, not exactly the same, but about the same quality.

Or it might show it at significantly better quality :p I didn't take the screenshot from the external player, I extracted the frame using ffmpeg.

How do you take a frame out of a flash embedded video at the original resolution anyway? I only seem to be able to play them at the default player size or fullscreen, neither of which would be native resolution for a 720p video.

you picked a pretty bad video it does however show a significantly lower quality on the WebM version. look at the ground, especially the lines between the different farm fields and the roads. on the MP4 version the roads and edges are sharp and crisp. on the WebM it looks like they did a gaussian blur. I'm not sure how you can say they look exactly the same, they're not even close. and this is on a still, in movement it's even worse. I wish there was an online version of the image viewer in 3dsmax where you can check out two renders and use a line you can drag across the images to check the differences.

and again, your second set of frames is useless since the source is to blurry to and out of focus for any differences to show up.

Link to post
Share on other sites
HawkMan

also, where h264 can use the seekbar reliably in ie9. the seekbar doesn't work very well at all in WebM. might be the codec/webplayer used, or a peculiarity in the format.

Link to post
Share on other sites
lalalawawawa
I'm not a "videophile" but they all look the same to me :unsure: well, not exactly the same, but about the same quality.

If you have a laptop, try moving the display up and down. Depending on the angle, you'll clearly see that VP8 pixalizes the whole frame. It is very noticeable. :)

Link to post
Share on other sites
Yusuf M.

Although H.264 offers better quality and support, the main issue with it is that it costs money. It's why Opera Software can't include support for it in their browser. And despite the fact that it'll stay royalty-free until 2015, the cost of royalties will be staggering for web content. Sadly, that's exactly what the MPEG LA wants. They want people to ignore the long-term and to make it the most-preferred video codec on the web.

Fortunately, Google are thinking ahead. By supporting WebM, they're pushing for a more open video/audio codec that will inevitably be improved over time. Also, it stands a much better chance than Ogg Theora as being the HTML5 codec of choice. This is a good thing because WebM is already supported by the latest versions of Firefox, Chrome, and Opera.

Link to post
Share on other sites
Boz

The question is are videos transcoded ONLY in WebM or ALSO in WebM? If H.264 is gone for new videos, Google just damaged YouTube.

Nope.. it damaged Apple really because Apple doesn't support WebM on iOS devices.

As far as quality, I believe it will be the same, no difference... It's like saying Apple damaged 1080p video because iTunes store and none of their videos are even 720p but mediocre quality at best as well as on AppleTV not being able to output 1080p at all..and you pay for those. Don't hear people complaining.

It's gonna be great.. and btw, Google is doing this because they don't want to pay royalty fees to MPEG-LA.. so it's pretty safe to say that you won't be seeing any more h.264 videos on YouTube.

Btw, it's win for everyone.. Flash Player supports all codecs (h.264, vp6, vp8, sorenson, mpeg2) while HTML5 video will work with webM..

This just shows why Flash is still going to be the best video technology for a long time to come but I definitely appreciate having HTML5 video solution + webM for a lot of completely free, simple videos online.. It's a win for users either way.

Link to post
Share on other sites
lalalawawawa

Although H.264 offers better quality and support, the main issue with it is that it costs money.

But it costs Apple and Microsoft money. Not the browser developers.

Link to post
Share on other sites
ThaCrip

personally i think it's a bad idea... CPU use goes up quite a bit with that vs the current Flash methods.

Link to post
Share on other sites
OuchOfDeath

personally i think it's a bad idea... CPU use goes up quite a bit with that vs the current Flash methods.

On the contrary. Browsers "natively" supporting the codecs seem to be more efficient than flash currently.

But it costs Apple and Microsoft money. Not the browser developers.

This has already been addresed a hundred times. It costs -anyone who wants to use h.264- money. This is a huge amount of organizations and products that covers billions of dollars. Opera has already been mentioned as one of those groups that cannot afford the h.264 licence for their browser, and they're one of the "main" contenders in the browser war. Opera notably have their product on the Wii and NintendoDS systems, yet apparently the money that makes them is not nearly enough to cover an h.264 licence. Opera is just one of the many examples of h.264's proprietary and licence-based nature that makes it bad for innovation and bad for the web.

Link to post
Share on other sites
Udedenkz

Quality is different, WebM looks more pixelated.

I must once again say that your CPU usage is way too high.

Although H.264 offers better quality and support, the main issue with it is that it costs money. It's why Opera Software can't include support for it in their browser. And despite the fact that it'll stay royalty-free until 2015, the cost of royalties will be staggering for web content. Sadly, that's exactly what the MPEG LA wants. They want people to ignore the long-term and to make it the most-preferred video codec on the web.

Fortunately, Google are thinking ahead. By supporting WebM, they're pushing for a more open video/audio codec that will inevitably be improved over time. Also, it stands a much better chance than Ogg Theora as being the HTML5 codec of choice. This is a good thing because WebM is already supported by the latest versions of Firefox, Chrome, and Opera.

Opera, Firefox, and Chrome can include native support for the system h264 codec thus AVOIDING ALL ISSUES.

Firefox, Opera, and Chrome have their own agenda - they support only the video formats which they approve and nothing else.

A fine example of hypocrisy - support D2D and DW, closed Windows only technologies that you have to buy an OS for, but reject h264.

Mac and Windows have built in h264 support.

Link to post
Share on other sites
Flawed

So what does this mean for overall audio quality? I use Youtube as a source for music streaming (no, I do not download from there, as the current quality is yuck), and I'm curious what bitrates the new codec's qualities offer.

If you use html and join the html test at youtube.com/html5 you can see for your self. Personally, the quality seems much improved over all vs flash.

Link to post
Share on other sites
OuchOfDeath

Opera, Firefox, and Chrome can include native support for the system h264 codec thus AVOIDING ALL ISSUES.

Firefox, Opera, and Chrome have their own agenda - they support only the video formats which they approve and nothing else.

A fine example of hypocrisy - support D2D and DW, closed Windows only technologies that you have to buy an OS for, but reject h264.

Mac and Windows have built in h264 support.

The issue with using the included codecs in the operating system is the implementation, and the fact that plugins may have to be included. There's also the issue that the support then becomes entirely platform-dependant. As an example, Linux and the many other mobile platforms would be entirely out of the question. Opera and Firefox all have mobile products, and this leaves them without any h.264 codecs that are on the platform itself. It's not a good solution, and it fragments their products and makes inter-usability between desktop operating systems and mobile operating systems a nightmare.

Firefox have an agenda in supporting an open web. H.264 is proprietary and requires licensing so it's obviously out of the question. Google definitely has their own agenda. Opera I believe do not have their own agenda(I could be wrong though, not certain) and simply could not afford an h.264 licence.

Supporting D2D and DW are entirely different. Those are API's that are free to use with no licensing costs at all. Microsoft include these API's in their operating system to make their operating system more competitive with others. This is a completely different matter and is not comparable to h.264.

Link to post
Share on other sites
HawkMan

If you use html and join the html test at youtube.com/html5 you can see for your self. Personally, the quality seems much improved over all vs flash.

you haven't paid attention at all have you ? WebM has far lower quality and is far blurrier than h.264. IE9 html5 as well as Flash HD video uses h.264

The issue with using the included codecs in the operating system is the implementation, and the fact that plugins may have to be included. There's also the issue that the support then becomes entirely platform-dependant. As an example, Linux, Android, and the many other mobile platforms(except for iOS) would be entirely out of the question. Opera, Android, and Firefox all have mobile products, and this leaves them without any h.264 codecs that are on the platform itself. It's not a good solution, and it fragments their products and makes inter-usability between desktop operating systems and mobile operating systems a nightmare.

all browsers use platform specific code and API's anyway, there would be no need for codecs or anything, just built in support for platform codecs. no more than what they already do.

as for mobile devices. unlike WebM, all android and iOS and WP7 smartphones as well as millions of other video and net capable devices already support h.264, these won't be able to fully support hardware decoding of WebM, most of them won't be able to support it all all.

so you're kind of missing the target you where trying to, and instead proving the opposite point.

Link to post
Share on other sites
Flawed

Quality is different, WebM looks more pixelated.

Must be the video you were watching. I'm using html5 webm on firefox for most of the youtube content I watch and the quality has much improved.

Opera, Firefox, and Chrome can include native support for the system h264 codec thus AVOIDING ALL ISSUES.

Firefox can't include it because h.264 conflicts with most FOSS licences. Besides, why would anyone choose a patent encumbered with a precarious future, to a patent-free alternative?

Another thing to seem to be forgetting is that there are far more FOSS browsers out there than proprietary ones. Even amongst the main browsers, Opera, Firefox, and Chrome all support WebM/Theora exclusively. Only IE, which can play WebM if the codec is installed, and Safari don't have WebM/Theora out of the box. Clearly the majority of browsers are going FOSS/Patent free codecs. And now with youtube as well, the most popular site on the web now supports a patent free alternative. H.264 is dead :D

Firefox, Opera, and Chrome have their own agenda - they support only the video formats which they approve and nothing else.

Ye, their agenda is to free society from patent encumbered codecs, a noble one if I might say. Now we just need to fully replace mp3 with ogg theora; it's getting there :D

A fine example of hypocrisy - support D2D and DW, closed Windows only technologies that you have to buy an OS for, but reject h264.

Mac and Windows have built in h264 support.

And GNU/Linux has built in support for WebM, Ogg/Theora etc, your point being? Firefox and Chrome use OpenGL for hardware accleration on OSX and GNU/Linux not DirectX.

It's very cool. I suggest everyone who uses Firefox 4 / Chrome enable WebM join the html5 trial at http://www.youtube.com/html5 . I've been using it for a while, and It's very sweet. No more laggy flash, or patent encumbered H.264 videos :D

Link to post
Share on other sites
Udedenkz

The issue with using the included codecs in the operating system is the implementation, and the fact that plugins may have to be included. There's also the issue that the support then becomes entirely platform-dependant. As an example, Linux and the many other mobile platforms would be entirely out of the question. Opera and Firefox all have mobile products, and this leaves them without any h.264 codecs that are on the platform itself. It's not a good solution, and it fragments their products and makes inter-usability between desktop operating systems and mobile operating systems a nightmare.

Firefox have an agenda in supporting an open web. H.264 is proprietary and requires licensing so it's obviously out of the question. Google definitely has their own agenda. Opera I believe do not have their own agenda(I could be wrong though, not certain) and simply could not afford an h.264 licence.

Supporting D2D and DW are entirely different. Those are API's that are free to use with no licensing costs at all. Microsoft include these API's in their operating system to make their operating system more competitive with others. This is a completely different matter and is not comparable to h.264.

I see nothing wrong with Firefox and Opera using system codec (whether or not this includes h264) to avoid all costs and all issues.

The fact that they refuse to do this is illogical.

Mobile platforms will have to adopt. Whether the plague or h264 will win, they will have to adopt.

Both D2D/DW and MS DTV-DVD codecs are free to use for any Windows software without any costs associated to them aside from, getting Windows 7.

Link to post
Share on other sites
OuchOfDeath

all browsers use platform specific code and API's anyway, there would be no need for codecs or anything, just built in support for platform codecs. no more than what they already do.

as for mobile devices. unlike WebM, all android and iOS and WP7 smartphones as well as millions of other video and net capable devices already support h.264, these won't be able to fully support hardware decoding of WebM, most of them won't be able to support it all all.

so you're kind of missing the target you where trying to, and instead proving the opposite point.

That's true there is platform-specific code and API's, however the issue is having to depend on the platform the codec instead of having control over the implementation in the browser code. This can be both limiting and problematic. As an example, the current way h.264 has been implemented in Firefox and Chrome by Microsoft and DivX is through the browser plugin architecture, and this is a flawed approach.This is the issue here.

Yes the 3 major mobile platforms support h.264, but is the support fully open for developers to use in their applications for free? If so then yes I did prove the opposite point.

Link to post
Share on other sites
This topic is now closed to further replies.
  • Recently Browsing   0 members

    No registered users viewing this page.