I found the origin of this color system. It was originally used with
the first gba video paks (which used a way different codec).
It is being described in this patent by Majesco (the 7th image, FIG.
4A and FIG. 4B): https://patents.google.com/patent/US7253819B1/en
Later gba video paks seem to use t
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
On Mon, Mar 15, 2021 at 10:02 PM Florian Nouwt 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 actimagi
On Tue, Mar 16, 2021 at 8:22 AM Florian Nouwt wrote:
> Alright, I'll just convert to rgb then. Both the windows codec and the ds
> decoder decode the subsampling by simply duplicating the u/v samples within
> a 2x2 block (no interpolation). Should I do that too? Or would
> interpolation be prefer
Alright, I'll just convert to rgb then. Both the windows codec and the ds
decoder decode the subsampling by simply duplicating the u/v samples within
a 2x2 block (no interpolation). Should I do that too? Or would
interpolation be preferred? As far as I was able to see the windows codec
takes the av
On Mon, Mar 15, 2021 at 10:55 PM Florian Nouwt wrote:
>
> Now that I think about it, it might not be possible to an accurate
> straightforward conversion to regular yuv because of the subsampling. The u
> and v cannot just linearly be scaled to line up with the required values
> for regular yuv. T
Mar 15, 2021, 22:54 by fnou...@gmail.com:
> Now that I think about it, it might not be possible to an accurate
> straightforward conversion to regular yuv because of the subsampling. The u
> and v cannot just linearly be scaled to line up with the required values
> for regular yuv. That would mean
Now that I think about it, it might not be possible to an accurate
straightforward conversion to regular yuv because of the subsampling. The u
and v cannot just linearly be scaled to line up with the required values
for regular yuv. That would mean the output would have to be in rgb format.
It woul
Mar 15, 2021, 22:02 by fnou...@gmail.com:
> 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 +
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
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 e
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
Mar 15, 2021, 19:37 by fnou...@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
Florian Nouwt:
> I applied the few changes you suggested. I moved the shared tables to
> h264_cavlc_data.c. Am I supposed to share the actual vlc tables (such
> as "static VLC_TYPE coeff_token_vlc_tables[520+332+280+256][2];")
> which are generated by actimagine_init_static respectively
> ff_h264_d
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
Mar 15, 2021, 16:09 by fnou...@gmail.com:
> Signed-off-by: Florian Nouwt
> ---
> Changelog|1 +
> configure|1 +
> doc/general_contents.texi|2 +
> libavcodec/Makefile |3 +-
> libavcodec/actimagine.c | 1523 ++
I applied the few changes you suggested. I moved the shared tables to
h264_cavlc_data.c. Am I supposed to share the actual vlc tables (such
as "static VLC_TYPE coeff_token_vlc_tables[520+332+280+256][2];")
which are generated by actimagine_init_static respectively
ff_h264_decode_init_vlc as well?
I have uploaded an example video here:
https://mega.nz/file/PVwGAbbB#9tL6p3uE-Ej1DP7ngovAPqYghkQckTpW26XlrpAop9w
There's both an .avi file which can be read by ffmpeg and a vx file
containing the exact same video data, for which I will write a demuxer
soon (note that the vx is smaller because it co
Florian Nouwt:
> This video format is mainly used in older Nintendo DS games in a .vx
> container. It is the predecessor of the Mobiclip format.
>
> Signed-off-by: Florian Nouwt
> ---
> Changelog |1 +
> configure |1 +
> doc/general_contents.texi |2
19 matches
Mail list logo
