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-03 02:27:25 +02:00
|
|
|
/*
|
|
|
|
|
* Dolby Vision RPU decoder
|
|
|
|
|
*
|
|
|
|
|
* Copyright (C) 2021 Jan Ekström
|
|
|
|
|
* Copyright (C) 2021 Niklas Haas
|
|
|
|
|
*
|
|
|
|
|
* This file is part of FFmpeg.
|
|
|
|
|
*
|
|
|
|
|
* FFmpeg is free software; you can redistribute it and/or
|
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
|
|
|
|
*
|
|
|
|
|
* FFmpeg is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
|
* Lesser General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
|
* License along with FFmpeg; if not, write to the Free Software
|
|
|
|
|
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef AVCODEC_DOVI_RPU_H
|
|
|
|
|
#define AVCODEC_DOVI_RPU_H
|
|
|
|
|
|
|
|
|
|
#include "libavutil/dovi_meta.h"
|
|
|
|
|
#include "libavutil/frame.h"
|
2024-04-12 13:24:22 +02:00
|
|
|
#include "avcodec.h"
|
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-03 02:27:25 +02:00
|
|
|
|
|
|
|
|
#define DOVI_MAX_DM_ID 15
|
|
|
|
|
typedef struct DOVIContext {
|
|
|
|
|
void *logctx;
|
|
|
|
|
|
2024-04-12 13:24:22 +02:00
|
|
|
/**
|
|
|
|
|
* Enable tri-state. For encoding only. FF_DOVI_AUTOMATIC enables Dolby
|
|
|
|
|
* Vision only if avctx->decoded_side_data contains an AVDOVIMetadata.
|
|
|
|
|
*/
|
|
|
|
|
#define FF_DOVI_AUTOMATIC -1
|
|
|
|
|
int enable;
|
|
|
|
|
|
2024-03-22 22:24:43 +02:00
|
|
|
/**
|
|
|
|
|
* Currently active dolby vision configuration, or {0} for none.
|
2024-04-12 13:24:22 +02:00
|
|
|
* Set by the user when decoding. Generated by ff_dovi_configure()
|
|
|
|
|
* when encoding.
|
2024-03-22 22:24:43 +02:00
|
|
|
*
|
|
|
|
|
* Note: sizeof(cfg) is not part of the libavutil ABI, so users should
|
|
|
|
|
* never pass &cfg to any other library calls. This is included merely as
|
|
|
|
|
* a way to look up the values of fields known at compile time.
|
|
|
|
|
*/
|
|
|
|
|
AVDOVIDecoderConfigurationRecord cfg;
|
|
|
|
|
|
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-03 02:27:25 +02:00
|
|
|
/**
|
2024-03-30 19:12:35 +02:00
|
|
|
* Currently active RPU data header, updates on every ff_dovi_rpu_parse()
|
|
|
|
|
* or ff_dovi_rpu_generate().
|
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-03 02:27:25 +02:00
|
|
|
*/
|
|
|
|
|
AVDOVIRpuDataHeader header;
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Currently active data mappings, or NULL. Points into memory owned by the
|
|
|
|
|
* corresponding rpu/vdr_ref, which becomes invalid on the next call to
|
2024-03-30 19:12:35 +02:00
|
|
|
* ff_dovi_rpu_parse() or ff_dovi_rpu_generate().
|
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-03 02:27:25 +02:00
|
|
|
*/
|
|
|
|
|
const AVDOVIDataMapping *mapping;
|
|
|
|
|
const AVDOVIColorMetadata *color;
|
|
|
|
|
|
2024-03-23 17:52:41 +02:00
|
|
|
/**
|
|
|
|
|
* Currently active extension blocks, updates on every ff_dovi_rpu_parse()
|
2024-03-30 19:12:35 +02:00
|
|
|
* or ff_dovi_rpu_generate().
|
2024-03-23 17:52:41 +02:00
|
|
|
*/
|
|
|
|
|
AVDOVIDmData *ext_blocks;
|
|
|
|
|
int num_ext_blocks;
|
|
|
|
|
|
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-03 02:27:25 +02:00
|
|
|
/**
|
|
|
|
|
* Private fields internal to dovi_rpu.c
|
|
|
|
|
*/
|
2022-08-04 12:53:28 +02:00
|
|
|
struct DOVIVdr *vdr[DOVI_MAX_DM_ID+1]; ///< RefStruct references
|
2024-03-23 16:59:44 +02:00
|
|
|
uint8_t *rpu_buf; ///< temporary buffer
|
|
|
|
|
unsigned rpu_buf_sz;
|
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-03 02:27:25 +02:00
|
|
|
|
|
|
|
|
} DOVIContext;
|
|
|
|
|
|
2022-08-04 12:53:28 +02:00
|
|
|
void ff_dovi_ctx_replace(DOVIContext *s, const DOVIContext *s0);
|
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-03 02:27:25 +02:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Completely reset a DOVIContext, preserving only logctx.
|
|
|
|
|
*/
|
|
|
|
|
void ff_dovi_ctx_unref(DOVIContext *s);
|
|
|
|
|
|
|
|
|
|
/**
|
2024-03-22 22:24:43 +02:00
|
|
|
* Partially reset the internal state. Resets per-frame state, but preserves
|
|
|
|
|
* the stream-wide configuration record.
|
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-03 02:27:25 +02:00
|
|
|
*/
|
|
|
|
|
void ff_dovi_ctx_flush(DOVIContext *s);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Parse the contents of a Dovi RPU NAL and update the parsed values in the
|
|
|
|
|
* DOVIContext struct.
|
|
|
|
|
*
|
|
|
|
|
* Returns 0 or an error code.
|
2024-03-22 22:25:35 +02:00
|
|
|
*
|
|
|
|
|
* Note: `DOVIContext.cfg` should be initialized before calling into this
|
|
|
|
|
* function. If not done, the profile will be guessed according to HEVC
|
|
|
|
|
* semantics.
|
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-03 02:27:25 +02:00
|
|
|
*/
|
2024-03-23 17:29:12 +02:00
|
|
|
int ff_dovi_rpu_parse(DOVIContext *s, const uint8_t *rpu, size_t rpu_size,
|
|
|
|
|
int err_recognition);
|
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-03 02:27:25 +02:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Attach the decoded AVDOVIMetadata as side data to an AVFrame.
|
|
|
|
|
*/
|
|
|
|
|
int ff_dovi_attach_side_data(DOVIContext *s, AVFrame *frame);
|
|
|
|
|
|
2024-04-12 13:24:22 +02:00
|
|
|
/**
|
|
|
|
|
* Configure the encoder for Dolby Vision encoding. Generates a configuration
|
|
|
|
|
* record in s->cfg, and attaches it to avctx->coded_side_data. Sets the correct
|
|
|
|
|
* profile and compatibility ID based on the tagged AVCodecContext colorspace
|
|
|
|
|
* metadata, and the correct level based on the resolution and tagged framerate.
|
|
|
|
|
*
|
|
|
|
|
* Returns 0 or a negative error code.
|
|
|
|
|
*/
|
|
|
|
|
int ff_dovi_configure(DOVIContext *s, AVCodecContext *avctx);
|
|
|
|
|
|
|
|
|
|
|
2024-04-12 13:11:10 +02:00
|
|
|
/***************************************************
|
|
|
|
|
* The following section is for internal use only. *
|
|
|
|
|
***************************************************/
|
|
|
|
|
|
|
|
|
|
typedef struct DOVIVdr {
|
|
|
|
|
AVDOVIDataMapping mapping;
|
|
|
|
|
AVDOVIColorMetadata color;
|
|
|
|
|
} DOVIVdr;
|
|
|
|
|
|
|
|
|
|
enum {
|
|
|
|
|
RPU_COEFF_FIXED = 0,
|
|
|
|
|
RPU_COEFF_FLOAT = 1,
|
|
|
|
|
};
|
|
|
|
|
|
2024-03-30 19:12:35 +02:00
|
|
|
/**
|
|
|
|
|
* Synthesize a Dolby Vision RPU reflecting the current state. Note that this
|
|
|
|
|
* assumes all previous calls to `ff_dovi_rpu_generate` have been appropriately
|
|
|
|
|
* signalled, i.e. it will not re-send already transmitted redundant data.
|
|
|
|
|
*
|
|
|
|
|
* Mutates the internal state of DOVIContext to reflect the change.
|
|
|
|
|
* Returns 0 or a negative error code.
|
|
|
|
|
*
|
|
|
|
|
* This generates a fully formed RPU ready for inclusion in the bitstream,
|
|
|
|
|
* including the EMDF header (profile 10) or NAL encapsulation (otherwise).
|
|
|
|
|
*/
|
|
|
|
|
int ff_dovi_rpu_generate(DOVIContext *s, const AVDOVIMetadata *metadata,
|
|
|
|
|
uint8_t **out_rpu, int *out_size);
|
|
|
|
|
|
2024-03-22 22:25:35 +02:00
|
|
|
/**
|
|
|
|
|
* Internal helper function to guess the correct DV profile for HEVC.
|
|
|
|
|
*
|
|
|
|
|
* Returns the profile number or 0 if unknown.
|
|
|
|
|
*/
|
|
|
|
|
int ff_dovi_guess_profile_hevc(const AVDOVIRpuDataHeader *hdr);
|
|
|
|
|
|
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-03 02:27:25 +02:00
|
|
|
#endif /* AVCODEC_DOVI_RPU_H */
|
