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

[Florian Nouwt]

Why would those equations not make sense?? I literally looked the top two
up on wikipedia. And the bottom one was reverse engineered from the ds
decoder and I verified it to be accurate for this codec.
I too think that converting to rgb is not the most elegant solution, but it
would be better than just wrong colors I think.

Op di 16 mrt. 2021 08:55 schreef Paul B Mahol <onemda at gmail.com>:

> On Mon, Mar 15, 2021 at 10:02 PM Florian Nouwt <fnouwt2 at gmail.com> wrote:
>
> > 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
> >
>
>
> Something is very wrong with those equations.
> They do not have sense.
>
> Next time make sure to use real player like mpv, and set frame color_space
> to ycgco or ycocg.
>
>
> > 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".
> > _______________________________________________
> > 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".
> _______________________________________________
> 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".