Several files use values for primaries and transfer characteristics other than
BT709 and IEC_61966 respectively, while still being GBR.
Also always set color_range while at it. It's always coded in the bistream.
Fixes part of #21304.
Signed-off-by: James Almer <jamrial@gmail.com>
In general, a provider code corresponds to a company/organization, and
the name should be that of the company, not of a given feature.
The feature is signalled in the "provider oriented code".
The exception is HDR Vivid, where the code 0x0004 indicates the HDR Vivid
feature itself rather than CUVA (China UHD Video Industry Alliance),
according to the UHD World Associations 'HDR Video Technology Part 2-1
Application Guide to System Integration' document.
ITU_T_T35_PROVIDER_CODE_CUVA -> ITU_T_T35_PROVIDER_CODE_HDR_VIVID
ITU_T_T35_PROVIDER_CODE_LCEVC-> ITU_T_T35_PROVIDER_CODE_VNOVA
ITU_T_T35_PROVIDER_CODE_SMTPE -> ITU_T_T35_PROVIDER_CODE_SAMSUNG
Signed-off-by: Maryla Ustarroz-Calonge <maryla@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
ITU-T T.35 provider codes are attributed by national bodies and it's
possible to have collisions across countries. This is why the country code
must always be checked as well.
Use if statements rather than nested switches which would be unreadable.
Signed-off-by: Maryla Ustarroz-Calonge <maryla@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is in preparation to change the switch statement to if/else.
Signed-off-by: Maryla Ustarroz-Calonge <maryla@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
These properties are unreliable because they depend on the frames decoded so
far, users should check directly the presence of the decoded AVFrame side data
or AVFrame flags.
Signed-off-by: Marton Balint <cus@passwd.hu>
Should ensure avcodec_send_packet() doesn't return EAGAIN in scenarios where it's not
meant to (e.g., ffmpeg_dec.c where avcodec_receive_frame() is called in a loop to drain
all produced frames before trying to submit more packets).
Fixes ticket #11377.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
And make it public.
For encoding, users may also be interested in the configured level and
compatibility ID. So generalize the dv_profile field and just expose the
whole configuration record.
This makes the already rather reductive ff_dovi_update_cfg() function
almost wholly redundant, since users can just directly assign
DOVIContext.cfg.
The Dolby Vision RPU contains a CRC32 to validate the payload against.
The implementation is CRC32/MPEG-2.
The CRC is only verified with the AV_EF_CRCCHECK flag.
Co-authored-by: quietvoid <tcChlisop0@gmail.com>
Not directly signalled by AV1, but we should still set this accordingly
so that users will know what the original intended video characteristics
and chroma resolution were.
This is thankfully passed through verbatim by libdav1d, so we can parse
it in our own code.
In theory, taking the DV profile from the packet-level configuration
struct is redundant since there is currently only one possible DV level
for AV1 (and all others would fail parsing), but this marginally
future-proofs it against possible new AV1-specific profiles being added
in the future.
info level will be too noisy if several instances of the decoder are fired
at the same time, as will be the case with tiled AVIF.
Signed-off-by: James Almer <jamrial@gmail.com>
Unnecessary since acf63d5350;
also avoids relocations.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes decoding packets containing split temporal units, as generated for example
by the av1_frame_split bsf.
Signed-off-by: James Almer <jamrial@gmail.com>
As this is an AV_CODEC_CAP_OTHER_THREADS decoder, threading is handled by the
underlying library. In this case, the frame delay is calculated by libdav1d
based on the values from avctx->thread_count and the private max_frame_delay
option.
Export said delay reported by the library in AVCodecContext.delay
Reviewed-by: Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Attach the AVPacket instead of only a few values to the corresponding Dav1dData
struct and use it to set all output frame props.
Signed-off-by: James Almer <jamrial@gmail.com>
It reduces typing: Before this patch, there were 105 codecs
whose long_name-definition exceeded the 80 char line length
limit. Now there are only nine of them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
and remove FF_CODEC_CAP_INIT_THREADSAFE
All our native codecs are already init-threadsafe
(only wrappers for external libraries and hwaccels
are typically not marked as init-threadsafe yet),
so it is only natural for this to also be the default state.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
A bug was found in dav1d <= 1.0.0 where the event flag New Sequence Header would
not be signaled for some samples using delayed random access points.
It has since been fixed, but nonetheless it's best to ensure the AVCodecContext
is filled with parameters when parsing the first frame, regardless of what events
were signaled.
Fixes ticket #9694.
Signed-off-by: James Almer <jamrial@gmail.com>
This is possible, because every given FFCodec has to implement
exactly one of these. Doing so decreases sizeof(FFCodec) and
therefore decreases the size of the binary.
Notice that in case of position-independent code the decrease
is in .data.rel.ro, so that this translates to decreased
memory consumption.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, codec.h contains both public and private parts
of AVCodec. This exposes the internals of AVCodec to users
and leads them into the temptation of actually using them
and forces us to forward-declare structures and types that
users can't use at all.
This commit changes this by adding a new structure FFCodec to
codec_internal.h that extends AVCodec, i.e. contains the public
AVCodec as first member; the private fields of AVCodec are moved
to this structure, leaving codec.h clean.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also move FF_CODEC_TAGS_END as well as struct AVCodecDefault.
This reduces the amount of files that have to include internal.h
(which comes with quite a lot of indirect inclusions), as e.g.
most encoders don't need it. It is furthemore in preparation
for moving the private part of AVCodec out of the public codec.h.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
We still own it on failure, and there's no point trying to feed it again.
This should address the issue reported in dav1d #383 and part of VLC #26259.
Signed-off-by: James Almer <jamrial@gmail.com>
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
