#11182: yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge
difference
-------------------------------------+-------------------------------------
Reporter: Andrew-R | Owner: (none)
Type: defect | Status: closed
Priority: normal | Component: swscale
Version: unspecified | Resolution: invalid
Keywords: colorspace | Blocked By:
color_primaries |
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
Comment (by Andrew-R):
Replying to [comment:35 Balling]:
> >Honestly, until now I was under impression RGB was superset of YUV, not
other way around ... I was wrong!
>
> You just read one small text in
https://stackoverflow.com/questions/17892346/how-to-convert-rgb-yuv-rgb-
both-ways "Since the 8 bit YUV only uses Y values [16, 235] and U, V
values [16, 240] it has less possible colors than RGB using [0, 255].",
which is simply not true, there is a comment from me under that answer
that says: It is not on any flagship TV. If you send YCbCr it will show
superwhite and supercolors no problem. In some cases even xvYCC. LG C9
does it even in internal files player."
Hm, well, I guess I just confused usual chroma subsampling and associated
loss of information with colorspace itself.
There is post titled "U and V ranges for valid RGB" from 2010, it has
animated illustration.
https://forum.doom9.org/showthread.php?t=154731
ffmpeg -i /dev/shm/yuv-mpeg-yuv444p.y4m -vf
"signalstats,metadata=print:file=logfile.txt" -f null /dev/null
from logfile it says
{{{
frame:0 pts:0 pts_time:0
lavfi.signalstats.YMIN=0
lavfi.signalstats.YLOW=76
lavfi.signalstats.YAVG=127.733
lavfi.signalstats.YHIGH=178
lavfi.signalstats.YMAX=255
lavfi.signalstats.UMIN=0
lavfi.signalstats.ULOW=76
lavfi.signalstats.UAVG=127.733
lavfi.signalstats.UHIGH=178
lavfi.signalstats.UMAX=255
lavfi.signalstats.VMIN=0
lavfi.signalstats.VLOW=76
lavfi.signalstats.VAVG=127.733
lavfi.signalstats.VHIGH=178
lavfi.signalstats.VMAX=255
}}}
so full-range y4m file from yuvtestsrc contain all Y, U, V values (as
requested!), even illegal (for RGB conversion later on) ones?
But then one method to kill illegal colors in yuv was said to be to
convert it to rgb and back ....
Not sure how specific figure in YUView should look for invalid colors
after such roundtrip? Right now it still look like limited range
conversion was applied twice at the end of range?
--
Ticket URL: <https://trac.ffmpeg.org/ticket/11182#comment:36>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker_______________________________________________
FFmpeg-trac mailing list
[email protected]
https://ffmpeg.org/mailman/listinfo/ffmpeg-trac
To unsubscribe, visit link above, or email
[email protected] with subject "unsubscribe".
