[FFmpeg-devel] [PATCH] avcodec: add Actimagine VX video decoder

[Florian Nouwt]

It's actually closer to normal yuv than ycocg. If you look at the
coefficients of normal yuv
r = y + 1.14v
g = y - 0.39u - 0.58v
b = y + 2.03u

ycocg
r = y + co - cg
g = y + cg
b = y - co - cg

the format used in actimagine
r = y + 2v
g = y - 0.5u - v
b = y + 2u

You can see it's more like yuv than ycocg. That's also why currently the
decoded colors still look "alright". I think it wouldn't be a good idea to
use converted ref frames and then convert back as it would likely introduce
errors. But like you are saying, this coded is as far as I know, never used
for large frame sizes, so it shouldn't really be an issue to have an extra
frame and it prevents other problems.

Op ma 15 mrt. 2021 21:42 schreef Lynne <dev at lynne.ee>:

> Mar 15, 2021, 21:20 by fnouwt2 at 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 at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".