Yeah i thought i had already read it, but i frequent several news aggregate sites so it becomes a blur at times.
Still it was not mentioned previously that Apple wasn’t on board which was actually i had noticed the first time around i read about it. Not that they need Apple to make it a new standard, but it is something to consider because Apple would decide to do their own new codec… which wouldn’t be surprising.
I would have appreciated Rob’s spin on it regardless, I just couldn’t resist 
Obligatory XKCD comic relevant to this 
(sung to the tune of Ten Green Bottles)
Ten comm standards described in the specs,
Ten comm standards described in the specs,
Make one that covers all uses, what the heck,
Now there’s eleven described in the specs.
…repeat until zero.
Also works with things like bugs in the code.
idiot here, but I thought webm files did this already. almost nobody uses them, including BB, but they’re awesome. what gives?
Pretty much, except this one is supposed to be newer and more awesome.
WebM is very much Google’s baby and with neither Microsoft nor Apple on board it never really reached the mainstream.
Webm always struck me as completely pointless when MKV already exists. MKV is goddamn magic as far as I can tell, and at this point works basically 100% of the time for any use I can think of.
All the working parts in Webm cleanly fit into MKV, and the advantage with MKV is you can use any codecs you want, even obscure ones.
Webm is just more restricted, it’s only supposedly compatible with VP8/9 and Xiph audio codecs, and honestly the only Xiph codec worth a fart anymore is Opus. OGG never was all that great (in reference implementation. The AoTuV codecs optimized for SSE3 and SSSE3 actually produce better quality-per-bitrate in OGG than LAME does for MP3, so there’s that.) and speex isn’t useful for storage unless you’re in 1998 and a gigabyte costs $80. Theora never made it to the same quality levels as the custom MPEG-4 ASP codecs (DivX, Xvid, 3ivx, Nero Digital), and even VP8 and useable implementations of VP9 doesn’t stack up against H.264.
I guess Webm works as a standard in that it gives you a template of 4 codecs to choose from, and says “that’s all you got, for the sake of interoperability” So I guess I can’t be too hard on it. It’s just, there’s much better alternatives that are widely supported already.
The problem is with the plethora of codecs for the MKV container. Having just a few is way easier to support on the endpoint devices, and increases the odds that the flavor of the file on the server will be palatable for the client.
A file encoded with a fancy first-grade codec is inferior to a file with a second-grade codec if the client you’re using can play the latter than the former.
BUT EVERYTHING PLAYS AAC and H.264! They’re supported by everything! But yeah, I guess if you want a low-complexity option for end users that uses only open codecs, then I guess you need to not allow closed codecs in the first place.
BUT NEITHER IS OPEN!
And that causes problems in many different situations.
Absolutely. I get it. I’m just doing the thinking now that I should have done quite a while ago.
[quote=“LDoBe, post:9, topic:64947”]
Webm always struck me as completely pointless when MKV already exists. MKV is goddamn magic as far as I can tell, and at this point works basically 100% of the time for any use I can think of.
[/quote]If you want any kind of interoperability, then you need a safe baseline. You could do this by endorsing a container and a list of codecs. Now MKV exists already and is intentionally very open-ended. Trying to communicate to users why some MKV files work and others don’t is a nightmare. The distinction between containers and various codecs is lost on people without any technical interest.
(Btw. look at your own comment. Your knowledge of these things is far above average and you still said Ogg when you meant Vorbis. Of course it is a harmless slip or intentional simplification, but I think it highlights the complications involved in this.)
So I think the WebM approach of taking MKV, filing the name off, giving it a new file name suffix and initially limiting it to just the most suitable open video codec and open audio codec made a lot of sense.
That way if you could handle one WebM file you could generally handle them all and all aspects could be handled by open software completely above board and royalty free. Later they added VP9 and Opus to the mix and made things slightly more complicated.
Normal MKV is still around for people who are interested in niche codecs, have access to licensed codecs or are willing to go with grey-market solutions.
Yeah. I’m working out how I feel about it, as I write. I ought to just shut up and see what everyone has to say first.
H264 is old news. H265 is where it’s at.
Except there’s two competing patent pools trying to scam people out of as much money as possible for using it. Plus the actual developers.
Which browser does mkv work in?
Which browser does every MKV work in?
Same answer: none
