avformat: validate dovi config in muxers

[gnattu]

FFmpeg tends to copy any available side packets from the input streams into the muxed output without considering their validity. This behavior is problematic for Dolby Vision configuration records, as invalid records might crash the player. I haven't found a better place to perform such validations with the current Dolby Vision handling process, so I had to place the validation code into each muxers.

This PR checks whether the Dolby Vision record is valid, meaning it is spec-compliant, so the player will likely handle it without issues in movenc, mpegtsenc, and matroskaenc. It first verifies if the codec matches the profile, then checks if the base layer (BL) is encoded as required by the compatibility ID. If the compatibility ID is 0, it also checks if the codec tag is explicitly set to the dovi fourcc, as these videos will not have backward compatibility.

The check in mpegtsenc is slightly stripped down as we are only passing HEVC with BL compat in that muxer.

Changes

Issues

Fixes #483

[nyanmisaka]

Is it really necessary to check color_range? Many Profile 5 videos are not correctly labeled. Doing so will prevent them from being recognized by ffprobe -show_streams and change the existing behavior.

[gnattu]

The intention for this is to not creating tv range profile 5 videos and the muxer will not affect ffprobe. The only problem is that this would prevent those buggy profile 5 videos being remuxed. Maybe we need to remove this check for Profile 5 videos as DoVi players tends to ignore what the container says.

[nyanmisaka]

The intention for this is to not creating tv range profile 5 videos and the muxer will not affect ffprobe. The only problem is that this would prevent those buggy profile 5 videos being remuxed. Maybe we need to remove this check for Profile 5 videos as DoVi players tends to ignore what the container says.

That's my concern. I haven't tested it yet, but the existing Profile 5 videos that are incorrectly tagged as TV range may not be streamed correctly over fMP4.

[nyanmisaka]

I suggest putting these validations in the public area like libavformat/dovi_isom.{c,h} to reuse them in multiple muxers. Then we can merge these two patches into one debian/patches/0031-pass-dovi-sidedata-to-muxers.patch.

my draft dovi-validation.patch

[gnattu]

movenc is slightly different as the code tag is in its own track instead of the par, so the interface needs to be modified slightly.

[nyanmisaka]

movenc is slightly different as the code tag is in its own track instead of the par, so the interface needs to be modified slightly.

+int ff_isom_validate_dovi_config(const AVDOVIDecoderConfigurationRecord *dovi,
+                                 AVCodecParameters *codec_par, int codec_tag);

I saw that. We can use a separate parameter to handle codec_tag. The upstream will have to deal with this one day.

[gnattu]

#8 179.7 error[E0425]: cannot find value `__deserializer` in this scope
#8 179.7    --> /opt/cargo/registry/src/index.crates.io-6f17d22bba15001f/cargo-0.83.0/src/cargo/core/features.rs:759:32
#8 179.7     |
#8 179.7 759 |     #[serde(deserialize_with = "deserialize_build_std")]
#8 179.7     |                                ^^^^^^^^^^^^^^^^^^^^^^^ not found in this scope
#8 179.7 
#8 179.7 error[E0425]: cannot find value `__deserializer` in this scope
#8 179.7    --> /opt/cargo/registry/src/index.crates.io-6f17d22bba15001f/cargo-0.83.0/src/cargo/core/features.rs:770:32
#8 179.7     |
#8 179.7 770 |     #[serde(deserialize_with = "deserialize_git_features")]
#8 179.7     |                                ^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in this scope
#8 179.7 
#8 179.7 error[E0425]: cannot find value `__deserializer` in this scope
#8 179.7    --> /opt/cargo/registry/src/index.crates.io-6f17d22bba15001f/cargo-0.83.0/src/cargo/core/features.rs:772:32
#8 179.7     |
#8 179.7 772 |     #[serde(deserialize_with = "deserialize_gitoxide_features")]
#8 179.7     |                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in this scope
#8 179.7 
#8 189.9 For more information about this error, try `rustc --explain E0425`.
#8 190.0 error: could not compile `cargo` (lib) due to 3 previous errors
#8 190.0 warning: build failed, waiting for other jobs to finish...
#8 198.8 error: failed to compile `cargo-c v0.10.5+cargo-0.83.0`, intermediate artifacts can be found at `/tmp/cargo-installfvANWQ`.
#8 198.8 To reuse those artifacts with a future compilation, set the environment variable `CARGO_TARGET_DIR` to that path.
#8 ERROR: process "/bin/sh -c curl https://sh.rustup.rs/ -sSf | bash -s -- -y --no-modify-path &&     cargo install cargo-c && rm -rf \"${CARGO_HOME}\"/registry \"${CARGO_HOME}\"/git" did not complete successfully: exit code: 101

ct-ng tools failed again...

[nyanmisaka]

#8 ERROR: process "/bin/sh -c curl https://sh.rustup.rs/ -sSf | bash -s -- -y --no-modify-path && cargo install cargo-c && rm -rf "${CARGO_HOME}"/registry "${CARGO_HOME}"/git" did not complete successfully: exit code: 101

ct-ng tools failed again...

It seems that there is no way to pin the version number in https://sh.rustup.rs/...

[gnattu]

#8 ERROR: process "/bin/sh -c curl https://sh.rustup.rs/ -sSf | bash -s -- -y --no-modify-path && cargo install cargo-c && rm -rf "${CARGO_HOME}"/registry "${CARGO_HOME}"/git" did not complete successfully: exit code: 101

ct-ng tools failed again...

It seems that there is no way to pin the version number in https://sh.rustup.rs/...

It is not the toolchain. It is the serde v1.0.211 breaks macros and that is a bit tricky due to it is a super basic package

[nyanmisaka]

#8 ERROR: process "/bin/sh -c curl https://sh.rustup.rs/ -sSf | bash -s -- -y --no-modify-path && cargo install cargo-c && rm -rf "${CARGO_HOME}"/registry "${CARGO_HOME}"/git" did not complete successfully: exit code: 101

ct-ng tools failed again...

It seems that there is no way to pin the version number in https://sh.rustup.rs/...

It is not the toolchain. It is the serde v1.0.211 breaks macros and that is a bit tricky due to it is a super basic package

This isn't the first time some of Rust's downstream dependencies broke the build. We can wait a few hours and usually they will release a hotfix.

• Build failure when pulled in via cargo-outdated rust-lang/git2-rs#1092
• serde 1.0.211 breaks with = "" inside of macros serde-rs/serde#2844

[gnattu]

This isn't the first time some of Rust's downstream dependencies broke the build. We can wait a few hours and usually they will release a hotfix.

• Build failure when pulled in via cargo-outdated rust-lang/git2-rs#1092
• serde 1.0.211 breaks with = "" inside of macros serde-rs/serde#2844

I checked that and the version is already pinned in cargo.lock for cargo-c and its dependencies to not use the buggy version so adding --locked to cargo install made the complication of cargo-c succeeded. Using --locked will probably made our CI more robust to broken lib releases as most libs won't move pinned version immediately.