Mar 15, 2021, 21:20 by fnou...@gmail.com: > Good to know the order doesn't matter. In that case I should be able to use > it! > > I don't have any docs about the format because it's all proprietary, but I > did some testing with the official codec for windows and the color > conversion I reverse engineered from the decoder used in ds games > r = y + (v << 1) > g = y - (u >> 1) - v > b = y + (u << 1) > results in colors that are equal to whatever I throw into the codec and > frames that are 1:1 equal to the output of the decoder included in the > windows codec. >
That's looking really close to YCoCg. In fact it probably is just a variant of YCoCg. You should be able to convert between both with no loss of quality or rounding errors and just mark the output frame as being YUV with a YCoCg colorspace. The wikipedia page on YCoCg has RGB<->YCoCg conversions you can follow. > I suppose that I would just have to allocate an extra frame if I wanted to > do conversion to normal yuv colors. That frame would then be returned and > the original frame would be put in the ref queue. > You could implement an inverse step when you use the reference frames, but for such a codec, where the frame size is going to be comparitively tiny, I think you can just get away quicker with copying and the converting the copied frame, while keeping your ref frames as-is. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
