Chrome 52 beta channel release notes were published covering over 30 bug fixes, enhancements to the support for H.264 in Chrome and changes to default DTLS certificate generation algorithm for more privacy and better performance. This version is expected to hit your browser on July 26. The support for WebRTC H.264 in browsers is required by the IETF
There are 2 main decision criteria for choosing a video codec – technical and business. Tsahi touched the technical part in his post. While I’ll get a bit into the technical aspects as well, in this post I also want to cover some of the business considerations. Let’s put one thing behind us. The difference between H.264 and VP8 from quality perspective is more of a religion than anything else.
Google published the release notes of Chrome 50. It now supports H.264 (behind a flag). Google adds H.264 to Chrome. This was an expected addition to Chrome given the WebRTC Mandatory to Implement video codec decision at the IETF that both VP8 and H.264 should be supported by browsers. Does this put an end to the need for WebRTC video transcoding and to server side decode and encode?
If you thought that the WebRTC MTI video codec battle is about to be settled, think again because the seeds for a new battle have been planted at the last IETF meeting. The idea is to follow the footsteps of Opus and the 2 main benefits it offers:High quality codec; Patent and royalty free… no real essential patent claims. With video, current status is problematic.
The WebRTC Mandatory To Implement (MTI) video codec has been a battleground in WebRTC where each camp has its claims why VP8 or H.264 is the right one to go for. Although the set is technical, the considerations behind the scenes are business, involve large companies and big money. Based on the last IETF meeting it looks like a solution is underway