ISOC LIVE NOTICEBOARD

isoc-ny 2:36 pm on May 19, 2010 Permalink | Reply
Tags: open ( 20 ), video ( 21 ), WebM ( 2 )   

• 

  Joly MacFie 3:21 pm on May 20, 2010 Permalink | Reply

  Some detailed analysis is on http://x264dev.multimedia.cx/?p=377

  Google’s choice of container and audio format for HTML5

  Google has chosen Matroska for their container format. This isn’t particularly surprising: Matroska is one of the most widely used “modern” container formats and is in many ways best-suited to the task. MP4 (aka ISOmedia) is probably a better-designed format, but is not very flexible; while in theory it can stick anything in a private stream, a standardization process is technically necessary to “officially” support any new video or audio formats. Patents are probably a non-issue; the MP4 patent pool was recently disbanded, largely because nobody used any of the features that were patented.

  Another advantage of Matroska is that it can be used for streaming video: while it isn’t typically, the spec allows it. Note that I do not mean progressive download (a’la Youtube), but rather actual streaming, where the encoder is working in real-time. The only way to do this with MP4 is by sending “segments” of video, a very hacky approach in which one is effectively sending a bunch of small MP4 files in sequence. This approach is used by Microsoft’s Silverlight “Smooth Streaming”. Not only is this an ugly hack, but it’s unsuitable for low-latency video. This kind of hack is unnecessary for Matroska. One possible problem is that since almost nobody currently uses Matroska for live streaming purposes, very few existing Matroska implementations support what is necessary to play streamed Matroska files.

  I’m not quite sure why Google chose to rebrand Matroska; “WebM” is a stupid name.

  The choice of Vorbis for audio is practically a no-brainer. Even ignoring the issue of patents, libvorbis is still the best general-purpose open source audio encoder. While AAC is generally better at very low bitrates, there aren’t any good open source AAC encoders: faac is worse than LAME and ffmpeg’s AAC encoder is even worse. Furthermore, faac is not free software; it contains code from the non-free reference encoder. Combined with the patent issue, nobody expected Google to pick anything else.

  Summary for the lazy

  VP8, as a spec, should be a bit better than H.264 Baseline Profile and VC-1. It’s not even close to competitive with H.264 Main or High Profile. If Google is willing to revise the spec, this can probably be improved.

  VP8, as an encoder, is somewhere between Xvid and Microsoft’s VC-1 in terms of visual quality. This can definitely be improved a lot, but not via conventional means.

  VP8, as a decoder, decodes even slower than ffmpeg’s H.264. This probably can’t be improved that much.

  With regard to patents, VP8 copies way too much from H.264 for anyone sane to be comfortable with it, no matter whose word is behind the claim of being patent-free.

  VP8 is definitely better compression-wise than Theora and Dirac, so if its claim to being patent-free does stand up, it’s an upgrade with regard to patent-free video formats.

  VP8 is not ready for prime-time; the spec is a pile of copy-pasted C code and the encoder’s interface is lacking in features and buggy. They aren’t even ready to finalize the bitstream format, let alone switch the world over to VP8.

  With the lack of a real spec, the VP8 software basically is the spec–and with the spec being “final”, any bugs are now set in stone. Such bugs have already been found and Google has rejected fixes

  Google made the right decision to pick Matroska and Vorbis for its HTML5 video proposal.

• 

  joly 12:44 pm on May 21, 2010 Permalink | Reply

  Google Has A Problem: VP8 Is Not As Good As H.264

  “Based on test results from two different codec experts, Jan Ozer (test results link to come shortly) and Jason Garrett-Glaser (test results), they both came to the conclusions that the VP8 codec provides similar quality to H.264, but in most cases, H.264 is still better quality wise than VP8. Both also stated that most won’t notice the difference between VP8 and H.264, but that’s not what VP8 was suppose to be about. VP8 was touted as the video codec that was suppose to replace H.264 because it could offer better quality at half the bandwidth, something both reviewers said is not possible.”