果然是支持, 需要加 --output-csp 参数指定输出格式

貌似目前的ffmpeg还不支持rgb编码,或者是需要设置什么解码参数?
[h264 @ 003E51D0] top block unavailable for requested intra4x4 mode -1 at 2 0
[h264 @ 003E51D0] error while decoding MB 2 0, bytestream (td)
[h264 @ 003E51D0] concealing 16 DC, 16 AC, 16 MV errors

YUV444的编码, ffmpeg解码也有错误, 等查一下ffmpeg对4:4:4编码的支持情况吧.

貌似ffmpeg对H.264的4:4:4支持还不完善,最近有很多相关修改,过段时间稳定下来再测吧.

发现8楼的错误信息是旧的ffmpeg输出的, 新版的已经能解码了, 但UCI要做一些调整才能正常处理.

rgb的支持, 我觉得就是利用4:4:4来做的, 据说压缩率不如转成YUV的, 这个以后我会实验的.

找了个样本用x2_6_4实验一下, 发现YUV4:4:4效率很高, 只比YUV4:2:0多了5%的体积,
而UCI的4:4:4比4:2:0多50%的体积. 下个版本的UCI的4:4:4模式就直接用x2_6_4提供的.
但x2_6_4的rgb模式效率就低多了,体积比4:4:4模式的多了一倍多,暂不打算在UCI中支持了.

已经改进过UCI,使之支持x2_6_4的YUV444编码和ffmpeg的YUV444解码,测试顺利通过,效果确实不错,压缩体积比以前分3次压缩小多了.
嗯...下一版的UCI在压缩YUV444的情况不再支持以前的模式,而是直接压缩单帧.
解码器会同时支持以前的格式.
alpha通道的压缩方式不变, 至于YUV和BMP的色彩空间暂时不做调整, x2_6_4的RGB模式也暂时不打算支持.

full range YUV 只是改换一下转换矩阵的参数而已, 暂时不调整还是考虑到兼容以前的版本, 不过在发布之前, 可能会考虑一下.
RGB编码我觉得和YUV444相比意义不大,YUV空间确实更适合压缩,否则JPEG也应该考虑RGB空间了. 当然转换后的UV参数确实损失了一点精度, 但这也是在有损压缩的原则之中.
YUV420和YUV444模式都会保留,在写实照片类图像中,YUV420几乎没有什么瑕疵.

full range打算用这个常用的矩阵参数, JPEG应也用的是这个吧
Y = 0.11448 * B + 0.58661 * G + 0.29891 * R
U = 0.50000 * B - 0.33126 * G - 0.16874 * R + 128
V =-0.08131 * B - 0.41869 * G + 0.50000 * R + 128
优化后的公式如下:
Y = (120041*B + 615105*G + 313430*R + 0x007FFFF) >> 20
U = (524288*B - 347351*G - 176937*R + 0x807FFFF) >> 20
V = (-85260*B - 439028*G + 524288*R + 0x807FFFF) >> 20

转换回的优化公式如下:
B = Fix(0x007FFFF + 0x100000*Y + 1857070*(U-128)) >> 20
G = Fix(0x007FFFF + 0x100000*Y - 361883*(U-128) - 748988*(V-128)) >> 20
R = Fix(0x007FFFF + 0x100000*Y + 1470292*(V-128)) >> 20
测试大量结果,转换回的误差不超过1.

这个转换公式损失最大的是U通道,主要是蓝色部分,也是人眼识别能力最差的一个三原色. 转换回的蓝色精度比7位略多一点, 但我还是在以后的实测中观察7位的蓝色值是否够用.
另外,红色精度比蓝色高一些,但也没到7.5, 绿色精度高于7.5