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@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
