> While i would love to see Daala, or a codec from Mozilla rather then Google to succeed. It is just not going to happen. Mozilla has never been known for fast moving, and the amount of engineering required for a Video Codec is just huge.
Clearly Mozilla and Xiph couldn't, in your world, have pulled off an audio codec that blows everything away.
Oh, wait, they did!
Worth noting they also got Opus standardized through the IETF[1] and, furthermore, it's mandatory to implement in the WebRTC spec[2]. So Opus is not only technically superior to other audio codecs, it's also better situated politically than Xiph.org's past efforts (eg. Vorbis, which sounds great but never really achieved relevance).
I can't encode my video files or music with Opus because you can't arbitrarily seek the track without backing up around 80ms and playing back up to the point where I want. So it isn't available in webm containers yet for that reason.
It won't be in "webm" because WebM is a very narrowly defined profile of MKV+Vorbis+VP8 (which is important for compatibility), and Google already made a decision to not use Opus in "WebM" to avoid confusion.
Perhaps you instead meant MKV? (now responding to the comment on frames/MP3) Yes. That is an issue for MKV with Opus. The problem is that the MKV container has no mechanism to signal a stream level or seeking level preroll other than just having frame boundaries. With Opus you need to seek several frames back and decode forward (not just a single frame) in order to converge. This isn't unique to Opus: Various video formats can be encoded with rolling intra (e.g. H.264) a mode which is useful for conferencing because it avoids fat keyframes. Since the movie 'backup' scene doesn't encode this way the mkv ecosystem's solution to these sorts of streams appears to be, so far, to fail to seek in them. I'm sure it will get worked out eventually.
--
It won't be in "webm" because WebM is a very narrowly defined profile of MKV+Vorbis+VP8 (which is important for compatibility), and Google already made a decision to not use Opus in "WebM" to avoid confusion.
--
The same is true for seeking in MP3, FYI. You can only 'seek' to a specific frame in the file, and frames have a fixed length. Sub-frame seeking in MP3 only came later and it works the same way - seeking to the nearest frame, and then discarding some audio to get to the desired point.
I would be interested to know why that is a blocker for you. For media consumption, at least as I normally practice it, that sounds like a detail I'd only notice by reading the code rather than perceiving it in the audio.
It isn't blocking me, but it is blocking wider adoption. I'm not really an audiophile that fine tweaks my encoder settings per file, so trying to convert with the opus library is grating, but it doesn't really have any mainstream encoder support yet (it is experimental in ffmpeg).
>Clearly Mozilla and Xiph couldn't, in your world, have pulled off an audio codec that blows everything away. Oh, wait, they did!
Clearly, in your misplaced sarcasm, you didn't read what he wrote. He didn't say anything about Mozilla being unable to write a codec that "blows everything away".
He wrote that Mozilla couldn't make that codec a _successful standard_. And, oh wait, they did not.
Even Opus (re: WebRTC) is a standard, but not successful at all, and it probably would not go anywhere.
Oh, and I would take the BS marketing page from Opus with a grain of salt, too, re: blowing everything away.
Clearly Mozilla and Xiph couldn't, in your world, have pulled off an audio codec that blows everything away. Oh, wait, they did!
http://www.opus-codec.org/comparison/