On 12/15/2020 10:43 AM, Nuo Mi wrote:
On Tue, Dec 15, 2020 at 4:44 AM Mark Thompson <s...@jkqxz.net> wrote:
On 14/12/2020 13:31, Nuo Mi wrote:
Hi Mark,
I have almost done the cbs for sps, pps, and slice header. I will start
to
implement the parser.
This looks fun :)
Few questions for you:
1. We need over-read some nals to detect the frame boundaries. But those
nals may switch/replace sps/pps. Do we need to use an output cbs and get
frames from the output cbs?
I'm not seeing where this can happen - if you see a new parameter set then
you must be in a new AU so you don't parse it, while a new VCL NAL as part
of a new frame with no PS before it must have a parsable header? (Or am I
missing some problematic case?)
2. We can't handle an incompleted nal in current cbs.
https://github.com/FFmpeg/FFmpeg/blob/03c8fe49ea3f2a2444607e541dff15a1ccd7f0c2/libavcodec/h2645_parse.c#L437
,
do we have a plan to fix it? What's your suggstion for the frame split?
I'm unsure what the question is. You will always need to keep reading
until you split a valid NAL unit which isn't in the current AU (noting that
a slice is the last slice in the current frame is never sufficient, because
suffixes might follow).
I want to feed the input buffer to cbs and get nal units from it. Seems it
does not work like this.
We still need a frame split in the parser. And feed the entire frame to
cbs.
The parser is meant to look byte by byte until it has found enough data
to complete an entire Access Unit worth of NALUs.
See how hevc does it in
https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/hevc_parser.c;h=463d352055b971bdcc27a27b3fcd7aa4b609286e;hb=HEAD#l261
Once the delimitation of an AU is found, then the resulting buffer can
be parsed (In VVC's case, we want that to be done by CBS) and ultimately
propagated so the generic demux code in libavformat can create complete
packets.
3. How to well test the cbs?
Passthrough is the best initial test, by making an h266_metadata bsf (even
if it has no options). The existing test coverage in FATE of CBS is
primarily driven by this - for H.26[45], the input streams there are a
subset of the H.26[45].1 conformance test streams chosen to cover as much
of the header space as possible.
I recommend enabling the write support ASAP (by adding the second include
of cbs_h266_syntax_template.c), because the double build can shake out
other problems too.
My original plan is cbs->parser->vvdec decoder->60% comfornace passrate ->
check in -> h266_metadata.
are you suggest we implement h266_metadata firstly?
thanks
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".
_______________________________________________
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".
