[FFmpeg-trac] #9167(undetermined:closed): Color changed when an image converting to video
FFmpeg
trac at avcodec.org
Wed Mar 31 03:22:03 EEST 2021
#9167: Color changed when an image converting to video
-------------------------------------+-------------------------------------
Reporter: kvsico | Owner:
Type: defect | Status: closed
Priority: normal | Component:
| undetermined
Version: unspecified | Resolution: invalid
Keywords: | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
Comment (by Balling):
Replying to [comment:16 pdr0]:
>but for the most part you can see much better superblack and superwhite
tones than on a computer monitor
Superblack must be invisible on default brightness (a.k.a. black level).
It should be the same as black that is.
>EBU r103
Yeah, I read it.
>So Y=14,CbCb128 <=> RGB 14,14,14
I agree.
>Consumer TV's vary widely on how they display
I have LG C9: in version 4 of firmware they output superwhite values even
in internal player, you can calibrate 8.6% Superwhite overshot. And it
supports both sYCC and xvYCC digital formats (as can be forced by Nvidia
control panel digital format option).
>In broadcast and professional video distribution, 0 and 255 are reserved
for sync.
In HDMI too, the HDMI spec is on archive.org. But not in files.
>you'd clip to [1,254] before you do anything;
Frankly speaking Nvidia driver does it for you. Just like MFF can do it.
>but preferred min/max is usually [5,246]
Yeah, that is also per EBU R103. But that is for HDR mainly.
>No "superblack" by your definition
There is no superblack in bmp. It is full range, superblack does not exist
in full range. But it does exist in avc stream. That is again, if there is
no another bug in --gamut-warning. See https://github.com/mpv-
player/mpv/issues/8161
--
Ticket URL: <https://trac.ffmpeg.org/ticket/9167#comment:17>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list