[FFmpeg-devel] [PATCH v22 02/10] avcodec/evc_parser: Added parser implementation for EVC format

[James Almer]

On 4/27/2023 9:02 AM, Dawid Kozinski wrote:
> - Added constants definitions for EVC parser
> - Provided NAL units parsing following ISO_IEC_23094-1
> - EVC parser registration
> 
> Signed-off-by: Dawid Kozinski <d.kozinski at samsung.com>
> ---
>   libavcodec/Makefile     |    1 +
>   libavcodec/evc.h        |  155 ++++
>   libavcodec/evc_parser.c | 1497 +++++++++++++++++++++++++++++++++++++++
>   libavcodec/parsers.c    |    1 +
>   4 files changed, 1654 insertions(+)
>   create mode 100644 libavcodec/evc.h
>   create mode 100644 libavcodec/evc_parser.c

There seems to have been a regression in this version compared to v20. 
Try to compile with the libxevd decoder disabled and open a raw file 
(not mp4).

Whereas with v20 i was getting

> Input #0, evc, from 'akiyo_cif.evc':
>   Duration: N/A, bitrate: N/A
>   Stream #0:0: Video: evc (Baseline), none, 352x288, 25 fps, 25 tbr, 1200k tbn

I'm now getting

> Input #0, evc, from 'akiyo_cif.evc':
>   Duration: N/A, bitrate: N/A
>   Stream #0:0: Video: evc (Baseline), none, 555902582x0, 25 fps, 25 tbr, 1200k tbn

It seems that the problem showed up because you moved the parameter sets 
to stack to skip allocating them, and you no longer check if they exist 
or were parsed by looking at slice_pic_parameter_set_id and such.

That aside, i looked at the EVC spec and noticed that the "raw" format 
in Annex-B is unlike that of H.26{4,5,6}: There's no start code, and 
instead there's a NAL size prefix, which sounds like the isobmff way of 
encapsulating NALUs.
I also noticed that the syntax for nal_unit() contains an 
emulation_prevention_three_byte element, but there's no explanation for 
it in the semantics section. Its existence in H.26* is to prevent 
parsers from misinterpreting a sequence of two or more zeroes as a 
potential start code, but that's clearly not the case here, so why is it 
defined and present at all?

What this means is that the parser can't be made to assemble an AU. If 
you feed it data starting from the middle of a NAL, it will not be able 
to sync to the start of the next NAL because all it looks for is a four 
byte size value and will accept the very first four bytes its fed as one.
Since i doubt the spec can be changed at this point to amend this 
oversight, the AU assembling will have to occur in the evc demuxer, much 
like we do with AV1 (both raw obu and Annex-B formats as defined in the 
corresponding spec), and the parser be limited to parse fully assembled 
NALs with parse_nal_units().