I was using artificial test source from ffmpeg, yuvtestsrc. It sounds very simple ffmpeg -f lavfi -color_range 2 -i yuvtestsrc -color_range 2 -frames 2 /dev/shm/yuv-pc-yuv444.y4m but here lies dragons, at least when roundtrip to RGB is needed. This old BBC article explained to me for the first time that YUV as color space fundamentally bigger than RGB! https://web.archive.org/web/20200719051405/http://downloads.bbc.co.uk/rd/pub... By way stuff defined normal calculations can give you negative RGB values! An normally those are clipped to either min or max allowed channel value. But result is ...unintuitive, at least for me Here is online calculator: https://kdashg.github.io/misc/colors/from-coeffs.html if you enter RGB 601, narrow range Y=16, Cb=100 Cr=100 R=-44.68875 (minus 44!) G=33.73244 B=-56.4825 (minus 56!) so, if both negative channels will be clipped to 0 we will have visually purely green pixel ?! This probably explains some STRANGE results I was seeing in compositor and vectoroscope, because even if timeline set to YUV- for display values converted to RGB, and scope also works in RGB ? There was another patent paper from broadcom aimed at fixing this issue https://patents.google.com/patent/EP1560417A2/en "System and method for clipping values of pixels in one color space so not to exceed the limits of a second color space Abstract A system and method that detects when pixels from one color space would exceed the range of a second color space, and restrict the range of the pixels without distorting their brightness, while preserving their color. The method may provide the ability to restrict the range of pixels in the first color space that may ordinarily transform to "illegal" values with erroneous brightness in the second color space, to a sub-space containing the entire second color space, while preserving the brightness of the pixels. The parameters used to define the sub-space may be programmable. The first color space may be YCrCb and the second color space may be RGB." ===== so, while in theory this problem is combatable in practice I do not think we have any out of the box plugin for dealing with this? So .... back to hunting for relevant test image, may be rgbtestsrc stored as y4m will do?