#10780: Garbled output when doing colorspace conversion with zscale, since recent changes -------------------------------------+------------------------------------- Reporter: Marth64 | Owner: (none) Type: defect | Status: new Priority: normal | Component: | undetermined Version: unspecified | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Changes (by Marth64): * Attachment "output(6.0.1).mkv" added. -- Ticket URL: <https://trac.ffmpeg.org/ticket/10780> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

#10780: Garbled output when doing colorspace conversion with zscale, since recent changes -------------------------------------+------------------------------------- Reporter: Marth64 | Owner: (none) Type: defect | Status: new Priority: normal | Component: | undetermined Version: unspecified | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Description changed by Marth64: Old description:

**Summary of the bug:** Yesterday, a user on IRC #ffmpeg presented a sample image and said that when they were trying to re-encode it as a looping H265 video with some colorspace conversions, the output was garbled. The specific claim was that the resulting video was a half-black image, hiding most of the original source picture.

I was able to help the user verify this behavior and confirmed it was a bug, at least had them to roll back to an older version where this behavior does not exist.

This must have been recently introduced, since when I run from a build on 12-27 I was not able to reproduce the issue. So sometime between 12-27 and 1-4, this bug was introduced.

The user was kind enough to share the source image and give permission to post it here. Attached files: - colors2.exr - image from user - output(latest).mkv - buggy output - output(6.0.1).mkv - expected output

**How to reproduce:** {{{ ffmpeg -loop 1 -t 10 -i colors2.exr -filter:v 'zscale=rangein=full:primariesin=709:transferin=709:matrixin=709:range=full:primaries=2020:transfer=smpte2084:matrix=2020_ncl' -pix_fmt:0 yuv420p10 -colorspace:0 bt2020nc -color_primaries:0 bt2020 -color_trc:0 smpte2084 -color_range:0 pc -c:v libx265 -x265-params lossless=1 OUTPUT.mkv }}}

New description: **Summary of the bug:** Yesterday, a user on IRC #ffmpeg presented a sample image and said that when they were trying to re-encode it as a looping H265 video with some colorspace conversions, the output was garbled. The specific claim was that the resulting video was a half-black image, hiding most of the original source picture, and that the dynamic color range is lost. I am focusing this ticket on the half-black image part of the issue since the output is not watchable. I was able to help the user verify this behavior and confirmed it was a bug, at least had them to roll back to an older version where this behavior does not exist. This must have been recently introduced, since when I run from a build on 12-27 I was not able to reproduce the issue. So sometime between 12-27 and 1-4, this bug was introduced. The user was kind enough to share the source image and give permission to post it here. Attached files: - colors2.exr - image from user - output(latest).mkv - buggy output - output(6.0.1).mkv - expected output **How to reproduce:** {{{ ffmpeg -loop 1 -t 10 -i colors2.exr -filter:v 'zscale=rangein=full:primariesin=709:transferin=709:matrixin=709:range=full:primaries=2020:transfer=smpte2084:matrix=2020_ncl' -pix_fmt:0 yuv420p10 -colorspace:0 bt2020nc -color_primaries:0 bt2020 -color_trc:0 smpte2084 -color_range:0 pc -c:v libx265 -x265-params lossless=1 OUTPUT.mkv }}} -- -- Ticket URL: <https://trac.ffmpeg.org/ticket/10780#comment:1> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker