4 ms·

One downside of VP9: the VP9 spec is still under NDA from Google. There is no publicly available spec. As far as I know, the only people that have written a sof

One downside of VP9: the VP9 spec is still under NDA from Google. There is no publicly available spec. As far as I know, the only people that have written a software VP9 decoder are either Google employees (libvpx) or ex-Google-employees who worked on VP9 when they were there (rbultje, who wrote ffvp9 with Clément Bœsch).

DannyBee 11y ago
Which "spec" are you referring to? The bitstream spec is definitely public.
- TD-Linux 11y ago
  I have never seen a spec, do you have a link?
  - nickodell 11y ago
    This, perhaps? https://tools.ietf.org/html/draft-grange-vp9-bitstream-00 https://tools.ietf.org/html/draft-grange-vp9-bitstream-00 It's only a draft, and two years out of date, but it is public.
    - TD-Linux 11y ago
      It's a good overview of VP9, but it's certainly not enough to implement a decoder, or call it a "spec".
- mrb 11y ago
  I could only find an "overview", not a full spec: https://tools.ietf.org/html/draft-grange-vp9-bitstream-00 https://tools.ietf.org/html/draft-grange-vp9-bitstream-00
- Ace17 11y ago
  There's a public RFC, but it's by no means usable as a bitstream spec. There's an official text document describing the bitstream format (several hundreds pages), but it's under NDA. We use it at work, and getting an updated version is far more trouble than downloading a file on a public server. The document in itself is nearly worthless, though, as it's far from complete. In the end, you still need to dig into libvpx to understand how things work.
jimbankoski 11y ago
Lots of people have produced decoders for vp9 including both hardware and software vendors. Including companies like ittiam, Intel, samsung and qualcomm. Lack of a non NDA public spec may have made things more difficult for some but it certainly didn't stop everyone.
- deleted 11y ago
  [deleted]
- Ace17 11y ago
  Actually, as a decoder implementer, I found that having the C source code of a reference decoder (libvpx), whose behaviour is authoritative over any text document, actually made things a lot more easy. Because now, whenever you ask yourself "how should a VP9 decoder behave in this situation?", you have a non-ambiguous answer "do like libvpx does". We didn't have this luxury with HEVC. The HEVC reference decoder (HM) is horribly complex, and has been easy to crash in many different ways for years. As a consequence, it could by no means be considered as authoritative. Which is a pity, because there were a lot of discrepancies between the reference decoder and the .doc spec.
tagrun 11y ago
http://www.phoronix.com/scan.php?page=news_item&px=OpenCL-VP9-Encoder http://www.phoronix.com/scan.php?page=news_item&px=OpenCL-VP...

DannyBee 11y ago

Which "spec" are you referring to? The bitstream spec is definitely public.

TD-Linux 11y ago
I have never seen a spec, do you have a link?
- nickodell 11y ago
  This, perhaps? https://tools.ietf.org/html/draft-grange-vp9-bitstream-00 https://tools.ietf.org/html/draft-grange-vp9-bitstream-00 It's only a draft, and two years out of date, but it is public.
  - TD-Linux 11y ago
    It's a good overview of VP9, but it's certainly not enough to implement a decoder, or call it a "spec".
mrb 11y ago
I could only find an "overview", not a full spec: https://tools.ietf.org/html/draft-grange-vp9-bitstream-00 https://tools.ietf.org/html/draft-grange-vp9-bitstream-00
Ace17 11y ago
There's a public RFC, but it's by no means usable as a bitstream spec. There's an official text document describing the bitstream format (several hundreds pages), but it's under NDA. We use it at work, and getting an updated version is far more trouble than downloading a file on a public server. The document in itself is nearly worthless, though, as it's far from complete. In the end, you still need to dig into libvpx to understand how things work.

jimbankoski 11y ago

Lots of people have produced decoders for vp9 including both hardware and software vendors. Including companies like ittiam, Intel, samsung and qualcomm. Lack of a non NDA public spec may have made things more difficult for some but it certainly didn't stop everyone.

deleted 11y ago
[deleted]
Ace17 11y ago
Actually, as a decoder implementer, I found that having the C source code of a reference decoder (libvpx), whose behaviour is authoritative over any text document, actually made things a lot more easy. Because now, whenever you ask yourself "how should a VP9 decoder behave in this situation?", you have a non-ambiguous answer "do like libvpx does". We didn't have this luxury with HEVC. The HEVC reference decoder (HM) is horribly complex, and has been easy to crash in many different ways for years. As a consequence, it could by no means be considered as authoritative. Which is a pity, because there were a lot of discrepancies between the reference decoder and the .doc spec.

tagrun 11y ago

http://www.phoronix.com/scan.php?page=news_item&px=OpenCL-VP9-Encoder http://www.phoronix.com/scan.php?page=news_item&px=OpenCL-VP...