Signed-off-by: Florian Nouwt
---
* fixed style issues
* ff_h264_cavlc_data_init_vlc now only uses ff_thread_once if the vx decoder
is enabled
* made tables static which are not used outside h264_cavlc_data.c
---
Changelog |1 +
configure |1
Andreas Rheinhardt:
- Why are these tables not internal to actimagine_vx.c?
I separated the data because for parsing the vx container files I will
need a parser, which will be in a separate file from the decoder and
requires those tables.
- You wasted an opportunity to add a space before '=' (th
Signed-off-by: Florian Nouwt
---
Changelog |1 +
configure |1 +
doc/general_contents.texi |2 +
libavcodec/Makefile |3 +-
libavcodec/actimagine_vx.c | 1150 +++
libavcodec
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
just wrong colors I think.
Op di 16 mrt. 2021 08:55 schreef Paul B Mahol :
> 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 =
s the average of 2x2 blocks to create the subsampled data.
Op ma 15 mrt. 2021 23:35 schreef Hendrik Leppkes :
> 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
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
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
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
o add it or
so? The regular yuv coefficients do look alright, but it is not correct.
Everything is a bit less saturated or so.
Op ma 15 mrt. 2021 18:34 schreef Lynne :
> Mar 15, 2021, 16:09 by fnou...@gmail.com:
>
> > Signed-off-by: Florian Nouwt
> > ---
> > Changel
Signed-off-by: Florian Nouwt
---
Changelog|1 +
configure|1 +
doc/general_contents.texi|2 +
libavcodec/Makefile |3 +-
libavcodec/actimagine.c | 1523 ++
libavcodec/allcodecs.c
lc as well?
Op ma 15 mrt. 2021 om 16:10 schreef Florian Nouwt :
>
> Signed-off-by: Florian Nouwt
> ---
> Changelog|1 +
> configure|1 +
> doc/general_contents.texi|2 +
> libavcodec/Makefile |3 +-
> l
ff is kinda new to me.
Op ma 15 mrt. 2021 om 14:47 schreef Andreas Rheinhardt
:
>
> 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: Fl
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 +
libavcodec/Makefile
schreef Paul B Mahol :
> OK, assuming you are really that person.
>
> On Mon, Mar 8, 2021 at 12:02 PM Florian Nouwt wrote:
>
>> The Mobiclip related code was based on Mobius (
>> https://github.com/adibsurani/Mobius), which was based on my original
>> reve
The Mobiclip related code was based on Mobius
(https://github.com/adibsurani/Mobius), which was based on my original reverse
engineering efforts (https://github.com/Gericom/MobiclipDecoder). This commit
adds the appropriate copyright headers on the related files.
Signed-off-by: Florian Nouwt
0001-mobiclip-fix-copyright-headers.patch
Description: Binary data
___
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 s
17 matches
Mail list logo
