Chiebot-Mirror/FFmpeg - FFmpeg - Gitea: Git with a cup of tea

Author	SHA1	Message	Date
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.	9 months ago
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.	9 months ago
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.	9 months ago
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).	9 months ago
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.	9 months ago
Niklas Haas	3a1916c38a	avcodec/dovi_rpu: add ext_blocks array to DOVIContext	9 months ago
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>	9 months ago
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).	9 months ago
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>	1 year ago
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>	3 years ago