Recently I’ve discovered some videos on archive.org that I’d like to watch. The problem is that they are VP8/VP9 plus Vorbis/Opus in WebMKV container which NihAV did not support. So I essentially had three options: re-encode it, use a third-party player, or implement support for it. Of course I went the fourth way—implement minimum support for the larger parts and re-encode the audio.
First thing was to determine what has to be done. Since avconv can’t put VP9 into MP4, I had to implement Matroska support. It was moderately annoying but not hard. And it did not lose much respect in my eyes either (mostly because there was not much of it in the first place). Of course I ignored a lot of finer details but it seems to be good enough for my needs, I’ll eventually try it on some 10-bit H.264 plus FLAC files I have somewhere around (another codec not fit for MP4; and don’t point out at the unofficial mapping schemes—my principles say no to it).
Then, audio track. That one was easy, just re-encode it to AC3 from whatever input format. It’s fast and beats writing decoders for Xiph formats.
Finally, video. I have VP8 decoder already (mostly written for the completeness sake) but no VP9 decoder. Re-encoding video is a long process, writing decoder is not particularly fast either. The not so obvious solution was to rely on VA-API for hardware decoder. One thing that’s definitely better in Duck codecs against ITU codecs is much simpler metadata and frame management, so VP9 VA-API decoder is much smaller and simpler than H.264 one. Essentially it’s just read frame header, generate some parameter structures, send it to the decoding and update frame references afterwards—compare that to parsing data in order to find frame header, picture parameter sets it references, sequence parameter set referenced by PPS and preparing various structures for that along with complex frame management rules. VP9 is not that simple either, with its potentially present segmentation and whatnot, but it’s much more manageable for the common case. As a side note, the follow-up codecs (VP 1.0 errata 1 and VP II) are much worse in that aspect, so I don’t know if I’ll ever want to deal with them.
And there it is, my solution for watching some files without wasting too much effort on implementing full support for all involved formats. Of course it would be easier just to re-use some existing code for demuxing support and wrap decoding libraries; some may even point out the futility of it all since there are perfectly working solutions already. But as I have committed to using my own software for my multimedia needs (except for the rare cases which avconv is allowed to handle), I’ll keep improving what I have. But had the things developed better in the past, I’d have no such problem as avp from rust-av project would be usable for my needs. Alas!
mkv’s ebml always scared me off, but i gather its not that complex.
It’s exactly like XML but in binary form and text labels replaced with binary ones 1-4 bytes long (and you need to know which labels are nodes instead of leaves). In other words, easy to mechanically parse but tedious to handle properly or validate—or Turing tar-pit for short.