1
0
mirror of https://github.com/FFmpeg/FFmpeg.git synced 2024-11-26 19:01:44 +02:00
Commit Graph

13 Commits

Author SHA1 Message Date
Niklas Haas
7bf08a5b2d avcodec/dovi_rpu: simplify vdr type
Storing the color metadata alongside the data mapping is no longer
needed, so we can simplify this array's type.
2024-06-18 21:18:30 +02:00
Niklas Haas
7ee64631f6 avcodec/dovi_rpu: fix dm_metadata_id handling
Despite the suggestive size limits, this metadata ID has nothing to do
with the VDR metadata ID used for the data mappings. Actually, the
specification leaves them wholly unexplained, other than acknowleding
their existence. Must be some secret dolby sauce. They're not even
involved in DM metadata compression, which is handled using an entirely
separate ID.

That leaves us with a lack of anything sensible to do with these IDs.
Since we unfortunately only expose one `dm_metadata_id` field to the
user, just ensure that they match; which appears to always be the case
in practice. If somebody ever hits this error, I would really much
rather like to see the triggering file.
2024-06-18 21:18:30 +02:00
Niklas Haas
68a22ac936 avcodec/dovi_rpu: properly handle vdr_dm_metadata_present
When this is 0, the metadata is explicitly inferred to stated default
values from the spec, rather than inferred from the previous frame's
values.

Likewise, when encoding, instead of checking if the value changed since
the last frame, we need to check if it differs from the default.
2024-06-18 21:18:30 +02:00
Niklas Haas
3306766608 avcodec/dovi_rpuenc: add ff_dovi_rpu_generate()
This function takes a decoded AVDOVIMetadata struct and turns it back
into a binary RPU. Verified using existing tools, and matches the
bitstream in official reference files.

I decided to just roll the EMDF and NAL encapsulation into this function
because the end user will need to do it otherwise anyways.
2024-04-22 12:17:56 +02:00
Niklas Haas
f140935005 avcodec/dovi_rpuenc: add ff_dovi_configure()
We need to set up the configuration struct appropriately based on the
codec type, colorspace metadata, and presence/absence of an EL (though,
we currently don't support an EL).

When present, we use the signalled RPU data header to help infer (and
validate) the right values.

Behavior can be controlled by a new DOVIContext.enable flag.
2024-04-22 12:17:51 +02:00
Niklas Haas
f131086a70 avcodec/dovi_rpu: split into dovi_rpu.c and dovi_rpudec.c
To allow compiling the decoding objects without the encoding objects and
vice versa. Common helpers that users of both APIs need are put into the
shared dovi_rpu.c.
2024-04-22 12:17:05 +02:00
Niklas Haas
2a99d3527b avcodec/dovi_rpu: expose guess_profile(), clarify semantics
To allow internally re-using it for both the encoder and decoder.

This is based on HEVC only, H.264/AV1 use their own (hopefully correctly
signalled) profiles (and in particular, the AV1 decoders implicitly
default the correct profile in the absence of a configuration record).
2024-04-22 12:17:05 +02:00
Niklas Haas
d0392619a7 avcodec/dovi_rpu: store entire config record
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.
2024-04-22 12:17:05 +02:00
Niklas Haas
3a1916c38a avcodec/dovi_rpu: add ext_blocks array to DOVIContext 2024-04-03 16:16:55 +02:00
Niklas Haas
b90c18b38c avcodec/dovi_rpu: verify RPU data CRC32
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>
2024-04-03 16:16:53 +02:00
Niklas Haas
a6c624f8f7 avcodec/dovi_rpu: strip container in separate step
This ensures that `gb` in the following section is fully byte-aligned,
points at the start of the actual RPU, and ends on the CRC terminator.

This is important for both calculation of the CRC, as well as dovi
extension block parsing (which aligns to byte boundaries in various
places).
2024-04-03 16:16:25 +02:00
Andreas Rheinhardt
61bc8764d4 avcodec/dovi_rpu: Use RefStruct API for Vdr data
It avoids allocations and the corresponding error checks.
Also avoids casts and indirections.

Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
2023-10-07 22:34:49 +02:00
Niklas Haas
fe04033739 lavc: Implement Dolby Vision RPU parsing
Based on a mixture of guesswork, partial documentation in patents, and
reverse engineering of real-world samples. Confirmed working for all the
samples I've thrown at it.

Contains some annoying machinery to persist these values in between
frames, which is needed in theory even though I've never actually seen a
sample that relies on it in practice. May or may not work.

Since the distinction matters greatly for parsing the color matrix
values, this includes a small helper function to guess the right profile
from the RPU itself in case the user has forgotten to forward the dovi
configuration record to the decoder. (Which in practice, only ffmpeg.c
and ffplay do..)

Notable omissions / deviations:
- CRC32 verification. This is based on the MPEG2 CRC32 type, which is
  similar to IEEE CRC32 but apparently different in subtle enough ways
  that I could not get it to pass verification no matter what parameters
  I fed to av_crc. It's possible the code needs some changes.
- Linear interpolation support. Nothing documents this (beyond its
  existence) and no samples use it, so impossible to implement.
- All of the extension metadata blocks, but these contain values that
  seem largely congruent with ST2094, HDR10, or other existing forms of
  side data, so I will defer parsing/attaching them to a future commit.
- The patent describes a mechanism for predicting coefficients from
  previous RPUs, but the bit for the flag whether to use the
  prediction deltas or signal entirely new coefficients does not seem to
  be present in actual RPUs, so we ignore this subsystem entirely.
- In the patent's spec, the NLQ subsystem also loops over
  num_nlq_pivots, but even in the patent the number is hard-coded to one
  iteration rather than signalled. So we only store one set of coefs.

Heavily influenced by https://github.com/quietvoid/dovi_tool
Documentation drawn from US Patent 10,701,399 B2 and ETSI GS CCM 001

Signed-off-by: Niklas Haas <git@haasn.dev>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
2022-01-04 11:59:41 +01:00