3 ms·
Ok, I take it back, vaporware is a little harsh. But in order for Daala to win, it will not only have to beat H.264, but also H.265 and significantly. Otherwise
by cromwellian 13y ago
Ok, I take it back, vaporware is a little harsh. But in order for Daala to win, it will not only have to beat H.264, but also H.265 and significantly. Otherwise, the argument of the powers that be is that H.264/265 are the established standard, widely deployed, low-power hardware implementations, and here is this spec, which doesn't meaningful improve on quality, bandwidth, or battery life, but is license free.
In other words, Daala will have to hit a homerun out of the park to convince all of the major players to endorse it over their existing deployed infrastructure.
If they do, I will be the first one cheering in the streets. But I'm skeptical, hence again, like with WebP, we see Mozilla opposing something that offers immediate offers benefits now in favor of something that in a few years might be.
This Cisco blob, what if it significantly underperforms x264 in encoding quality and CPU. Would we then be stuck with crappy WebRTC video quality because you can't drop in better implementations?
- BrendanEich 13y agoWebP does not offer immediate benefits by our measurement: http://people.mozilla.org/~josh/lossy_compressed_image_study_october_2013/ http://people.mozilla.org/~josh/lossy_compressed_image_study... https://groups.google.com/forum/#!topic/mozilla.dev.platform/9NKc7OeEFLM https://groups.google.com/forum/#!topic/mozilla.dev.platform... If you work at Google, please point out errors in our methods or data, give us better metrics, or otherwise correct us. > This Cisco blog, what if... "What if?" What if Google fails to get VP9 codecs into h/w? (See my response above; half-way [decoder only] does not count.) Lots of what-ifs here, but I believe OpenH264 is Cisco's best s/w codec. Let's see, shall we, and not speculate idly. /be
- cromwellian 13y agoThat's for JPEG, I had a long discussion on HN with someone, apparently from Mozilla, over what I meant by this. My social network streams are more and more filled up with multi-megabyte animated GIFs, and WebP is a reasonable replacement for both animated GIFs and transparent PNGs. Today, we have three formats to serve three needs: lossy, you choose jpeg, transparency, you choose PNG, animated, you choose gif. Animated and transparent? Out of luck. Lossy animated? Out of luck. Lossy and transparent? Out of luck. I don't care so much about replacing JPEG as replacing GIF and PNG. APNG might fit the bill for animated, but given how much information GIF throws away, and given the 2M-5M GIFs I see out there already, it's likely to exacerbate the bandwidth problem, not make it better. I don't really care if WebP is the replacement, maybe the replacement of mjpeg, or some other format so that people post short 5-6 second clips using <video> instead of <img>. But animated GIFs are chewing up a lot of mobile bandwidth and there is no solution out there right now that mitigates the problem.
- pornel 13y ago> My social network streams are more and more filled up with multi-megabyte animated GIFs, and WebP is a reasonable replacement for both animated GIFs and transparent PNGs. It's only slightly better than lossy PNG: http://pngmini.com/vs-webp/ http://pngmini.com/vs-webp/ It doesn't appear to be good at beating GIF, and loses to APNG in compression (and I suspect also decoding speed): http://littlesvr.ca/apng/gif_apng_webp1.html http://littlesvr.ca/apng/gif_apng_webp1.html and I find it highly questionable whether a new format that is exactly as expensive as WebM intra frames should be used instead of WebM.
- maxst 13y ago> Lossy and transparent? Out of luck. Well, you could lossy-optimize PNGs if you really want to. Take Google front page logo, for example: not a lot of colors to justify using 32 bpp PNG. Just sacrifice some alpha bits, and you can switch to 256-color indexed PNG. I bet nobody would notice the difference, and the result would be a lot smaller.