tonemap_cuda and tonemap_opencl do not strip DOVI sidedata when targeting SDR
#483
Comments
|
Frame filters cannot remove the metadata from lower level packets and streams. |
|
Not sure if you can use this before the input file, otherwise you have to run the ffmpeg command twice to get rid of it. |
Oh, you're right. The
It works if I copy the video stream, but not if I transcode it. Removing it beforehand would affect tone-mapping, right? Is there a way to remove it afterwards for H.264? |
|
That's an HLG-compatible DoVi video, meaning DoVi dynamic metadata is not necessary for tonemapping. |
|
Nice, so it's fine to remove it beforehand after all. It does work if I run these commands:
A bit unfortunate that it has to be in two passes, but it seems it can't be helped. |
|
Hmm, I just tested with system FFmpeg 7.1 and found that Edit: I downgraded to system 7.0.2 and found that it also leaves DOVI side data. I guess this is something that will be fixed on its own. |
|
7.1 refactored dovi related stuff, so the behavior may change. |
|
7.1 has its own dovi_rpu encoder and that seems will not blindly copy all dovi config records from input. BUT that is a bit buggy and I've seen issues with that with dolby official glassblowing 8.1 samples and remuxing to mkv straight failed. I think we could inject some handling but I don't know where such things could be placed? If there is no clean way we may only attach config record when the stream is HEVC and AV1 as a workaround and adding that into the muxers individually. |
|
Just realized that dovi on H264 BL is a thing, which is the Profile 9, the dolby vision on SDR base layer encoded in H264, so we cannot "just" use codec to check that, we need to cross-check with the profile and base layer compatibility id. |
|
You may try the action builds once completed: https://github.com/jellyfin/jellyfin-ffmpeg/actions/runs/11432498384 I added validation to movenc, matroskaenc and mpegtsenc so that the configuration records violating the spec will not be muxed into the container. |
|
Wow, that's awesome! I just tested this command: And the output of this command looks good: Thanks for fixing this! |
Describe The Bug
When tone-mapping to SDR, this side data can cause playback issues on some clients, especially on iOS and Android.
On iOS with AVPlayer, it is ignored if the transcode uses H.264, but transcoding to HEVC leads to the video stream not being displayed (audio plays).
On Android with Exoplayer, it is ignored if the transcode uses HEVC, but transcoding to H.264 leads to an assertion failure because the DOVI metadata is only valid for HEVC.
tonemapxdoesn't have this issue because it strips DOVI side data.Steps To Reproduce
tonemap_cudaortonemap_opencland converts to bt709. I tested with this:ffmpeg -hwaccel cuda -hwaccel_output_format cuda -noautorotate -threads 1 -i IMG_3218.MOV -y -tune hq -qmin 0 -rc-lookahead 20 -i_qfactor 0.75 -c:v h264_nvenc -c:a copy -movflags faststart -fps_mode passthrough -map 0:0 -strict unofficial -map 0:1 -bf 4 -refs 4 -g 256 -b_ref_mode middle -b_qfactor 1.1 -temporal-aq 1 -v verbose -vf tonemap_cuda=desat=0:matrix=bt709:primaries=bt709:range=pc:tonemap=hable:transfer=bt709:format=nv12:tradeoff=0:tonemap_mode=itp -preset p7 -cq:v 23 IMG_3218_cuda.mp4ffprobe IMG_3218_cuda.mp4and observe this entry in the side data:DOVI configuration record: version: 1.0, profile: 8, level: 5, rpu flag: 1, el flag: 0, bl flag: 1, compatibility id: 4Expected Behavior
The video shouldn't have incompatible DOVI metadata.
System (please complete the following information):
jellyfinbranch)MediaInfo
FFmpeg Logs
Additional Context
This side data is only added when
-strict unofficialis used. We removed this flag for now, but it's not ideal since it also means spherical metadata etc. is removed.The text was updated successfully, but these errors were encountered: