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.kozin...@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().
_______________________________________________
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".
