[FFmpeg-devel] [PATCH 0/3] add vvc raw demuxer

[Mark Thompson]

On 21/11/2020 02:19, James Almer wrote:
> On 11/20/2020 10:55 PM, Nuo Mi wrote:
>> Hi Mark, James and all,
>> There are two ways to implement the parser.
>> 1. use cbs like av1 parser.
>> 2. follow h264/h265 parser method.
>> Which is your preferred?
>>
>> thanks
> 
> A CBS module for VVC is needed regardless of how the parser is ultimately implemented (There will be other uses, like bitstream filters), so might as well use it for it, like with AV1.

+1.

Attached is some initial investigation I did recently into CBS implementation.  The non-CBS parts are all hacks to get a raw stream fed into trace_headers, and can be ignored for non-test purposes.

My thoughts emerging from that:

* The commonality with H.26[45] is sufficient that it's probably best to extend that into CBS H.26[456].
   * All of the styling is the same, so doing that avoids duplicating a lot of templating code.
   * I haven't done that here because it was easier to hack in by starting with a new file.
   * Separately I've been looking at merging the implementation of more common elements of H.26[45], and that will apply here too (SEI in particular, where H.274 matches in parts as well).

* There is /a lot/ of boilerplate needed to get even a minimal version working.
   * The parameter sets are even bigger and more complex than they were in H.265 (and the VUI that you want for metadata is still right at the end of the SPS).
   * The clean specification is very appreciated - I haven't found any nasty interdependencies yet, though I haven't read all of it in detail.
   * Given the huge surface area for errors here, it may not be a good idea to include it until we have the full conformance test suite (like H.265.1) to test it with.

* It seemed like the right choice on naming was to use H.266 as the name everywhere and always refer to that:
   * It stays consistent with the most common name for H.264 (still the most-used codec).
   * It's a formal standard, unlike the JVET drafts.
   * Anyone can download the full specification for free (<https://www.itu.int/rec/T-REC-H.266-202008-I/en>), unlike the ISO/IEC 23090-3 version.

I'm not working on this right now, but I'll probably come back to it in the not-too-distant future.

So, any thoughts welcome - given the scope of this we should probably agree roughly what the intended structure will be before writing much more.

Thanks,

- Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-WIP-CBS-H.266.patch
Type: text/x-diff
Size: 53011 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20201121/ffaae52f/attachment.patch>