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

[James Almer]

On 11/21/2020 2:18 PM, Mark Thompson wrote:
> 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.

The CBS module i absolutely agree should be named h266. Same with 
h2645_parse, which should be renamed to h26x_parse once adapted to also 
split H266 NALUs.
But for the decoder and parser, it will depend on how the codec turns 
out to be best known as. Take for example h265, which is called HEVC 
everywhere, and unlike h264 where AVC is seemingly not used as much.
Right now, VVC seems to get more relevant hits on google than h266.

And we can add two codec ids for it, like h265/HEVC (Or rather one, and 
a #define alias).

> 
> 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.

My opinion, judging by current name usage in most news articles and 
announcements:

h26x_parse
cbs_h26x (using h26x_parse for NAL splitting)
cbs_h266_syntax_template
h266_metadata_bsf (Using CBS)
vvc_parser (Using CBS for parameter set and frame header parsing. Raw 
bitstream merging is separate)
vvc_decoder (Maybe using CBS?)
AV_CODEC_ID_VVC
#define AV_CODEC_ID_H266 AV_CODEC_ID_VVC

> 
> Thanks,
> 
> - Mark
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>