Linked by Thom Holwerda on Mon 25th Mar 2013 21:09 UTC

Thread beginning with comment 556717
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Firstly it is pretty important seeing that Google Talk is probably using it that it uses twice as much bandwidth.
Goog Talk uses h.264...
https://developers.google.com/talk/call_signaling
So I don't think your point here has any merit at all.
Did you read what I said...? That comparison is purely about subjective quality:
The situation could be different if H.264 didn't have such a top-notch encoder as x264 or if we were only comparing to H.264 Baseline, but this comparison is about maximum[1] quality obtainable with each format (using the best encoders available).
and the target encode is:
"Best quality" 2-pass 13600 kbps encode at 1080p50.
No one streams 1080p50 on the internet at 13600 (!!!) khps - that is better than most commercial bluerays are mastered at. All I said is within the parameters I specified it is close enough to h.264 in quality that most people wouldn't notice. I never said (and do not think) it is technically better, and it is definitely slower. But for the common use case it is targeted at it is pretty damn good.
Clue: The reason you won't find many good comparisons between webm and h.264 at commonly used resoltuions and bitrates is because the result is very boring and neither side of the argument can use them as ammo...
Edited 2013-03-26 16:50 UTC
RE[7]: Big picture...
by lucas_maximus on Tue 26th Mar 2013 18:15
in reply to "RE[6]: Big picture..."
Member since:
2009-08-18
Firstly it is pretty important seeing that Google Talk is probably using it that it uses twice as much bandwidth.
In any case Okay, how about this one?
http://www.osnews.com/thread?556675
Except it doesn't look at the above link.
Well that might not be the case, we don't know yet.
Except it isn't.