Adjust default knee_offset for bt2390 tonemapper

[nyanmisaka]

Changes

• Adjust default knee_offset for bt2390 tonemapper
• Respect bl_video_full_range_flag for DoVi video
• Unbreak X265_BUILD >= 213
• Pin x265 commit
• Bump version to 7.0.2-4

Issues

• Continuation of avfilter/tonemap**: use more stable range and peak handling #472 (comment)

Alternatively, we can adjust the BT.2390 EETF similar to how it's done in libplacebo. They modify the 0.5 knee offset from the ITU standard to a 1.0 knee offset, which makes the curve to roll off earlier. This makes the overall brightness transition smoother for such videos with extreme highlights.

[nyanmisaka]

@gnattu Found a similar overflow issue in dolby-vision-art.mp4. Does the previous fix also apply to 420p10 paths?

dovi_420p10

[gnattu]

Does the previous fix also apply to 420p10 paths?

No, previous fix only applies to p010, and actually 420p10 overflowing makes more sense than it only happens to p010 and now I have a sample to verify my theory.

[gnattu]

Also that particular sample is super broken. It is declaring tv range for dolby vision profile 5 which should always use full range.

It seems like we need to do overwrite on input range as well because such broken files exists.

It actually is not that bright and should not trigger overflow when the range is corrected:

But I'm going to add safety check in 420p10 code paths just in case

[nyanmisaka]

Also that particular sample is super broken. It is declaring tv range for dolby vision profile 5 which should always use full range.

It seems like we need to do overwrite on input range as well because such broken files exists.

https://github.com/FFmpeg/FFmpeg/blob/f339169f35bc3edd250062d613a7de957ad5a877/libavutil/dovi_meta.h#L96

Can you check if the full range flag in the RpuHeader is not propagated to the AVFrame? I have many Profile 5 videos that are not marked as full range.

[gnattu]

Can you check if the full range flag in the RpuHeader is not propagated to the AVFrame? I have many Profile 5 videos that are not marked as full range.

It does not matter what the DoVi metadata says because the IPT-PQ-C2 colorspace that Dolby is using does not have limited range quantizations at all, it always uses full 10 bit 0-1023 with no reserved values, and if the metadata says otherwise it only means that file is mastered poorly and providing incorrect information.

For this particular file the bl_video_full_range_flag is 1 however, so it is the container info disagrees with dovi metadata, and ffmpeg does not handle that in this case.

[nyanmisaka]

It does not matter what the DoVi metadata says because the IPT-PQ-C2 colorspace that Dolby is using does not have limited range quantizations at all, it always uses full 10 bit 0-1023 with no reserved values, and if the metadata says otherwise it only means that file is mastered poorly and providing incorrect information.

Indeed.
https://github.com/FFmpeg/FFmpeg/blob/f339169f35bc3edd250062d613a7de957ad5a877/libavcodec/dovi_rpu.c#L76

For this particular file the bl_video_full_range_flag is 1 however, so it is the container info disagrees with dovi metadata, and ffmpeg does not handle that in this case.

The ideal place to fix this is in AVCodec. There is no way to get the RpuHeader before decoding the DOVI NAL. But this is beyond our use case and just following this flag in the tonemap filter should good enough.