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

Florian Nouwt fnouwt2 at gmail.com
Mon Mar 15 22:20:06 EET 2021


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.
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.

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

> Mar 15, 2021, 19:37 by fnouwt2 at gmail.com:
>
> > I'll have a look if functions can be reused. If it's the case, the same
> > could likely be done to the mobiclip decoder too since that one does a
> lot
> > of stuff in a similar way.
> > The "idct" looks very similar to "ff_h264_idct_add" in
> h264idct_template.c.
> > Which would make sense since the codec is largely based on techniques
> used
> > in h264. In that function the order seems to be reversed though
> > (column->row, row->row instead of row->column, row->row) and I wonder if
> > that can have any impact on the output? (Rounding errors or so)
> > I think there's a good chance that h264 prediction functions can also be
> > used. I will check if they are 100% equal.
> >
>
> The order doesn't matter, and rounding errors shouldn't occur as all your
> coefficients are left-shifted by 6.
>
>
> > I have a question about the color space btw. This format uses a yuv
> > approximation based on bit shifting as I described in the init function.
> > Currently it is not supported by ffmpeg. Would there be a way to add it
> or
> > so? The regular yuv coefficients do look alright, but it is not correct.
> > Everything is a bit less saturated or so.
> >
>
> Are there any docs or code on what the encoder uses? In general we don't
> do colorspace conversions in decoders, but if it's close enough that some
> correction can make it fit into bt601 or bt709, I think it would be okay.
> _______________________________________________
> 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".


More information about the ffmpeg-devel mailing list