Currently restricted to blending pixels that only contain either
0 or 255 in their alpha components
Signed-off-by: Donny Yang <work@kota.moe>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The spec specifies the dispose operation as how the current (i.e., currently
being rendered) frame should be disposed when the next frame is blended onto it
This is contrary to ffmpeg's current behaviour of interpreting the dispose
operation as how the previous (i.e., already rendered) frame should be disposed
This patch fixes ffmpeg's behaviour to match those of the spec, which involved
a rewrite of the blending function
Signed-off-by: Donny Yang <work@kota.moe>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This can be useful for debugging, or in scenarios where the user
doesn't want to use the system's DNS settings for whatever reason.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'bc76c46943272515805d7ac48ca39f14826d1fed':
aac: Wait to know the channels before allocating frame
Conflicts:
libavcodec/aacdec.c
See: 676a395ab9
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The channel configuration can be delivered only by the PCE,
try to parse it first and not try to decode until a channel
configuration is set.
CC: libav-stable@libav.org
These are defined in ISO/IEC 14496-3:2009/PDAM 4 for 6.1 and 7.1.
It also defines another 7.1 layout with configuration 14, that one
is not added here for now.
11: 3/3.1 FC FL+FR BL+BR BC LFE
12: 3/2/2.1 FC FL+FR SiL+SiR BL+BR LFE
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
FDK AAC encoder outputs SCE(front)+CPE(front)+CPE(back)+CPE(back) on
MODE_7_1_REAR_SURROUND configuration.
Since decoder couldn't properly map 4 back channels, decoding failed
unless -request_channel_layout 0x8000000000000000 has been specified.
Now we treat first CPE(back) as CPE(side) on channel mapping.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
calc_coefficients is no longer being called every frame
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This allows us to offer the same codec name that libav uses. We don't have
a special way to do aliases, so it's all a bit more verbose than you'd want
but such is life.
Signed-off-by: Philip Langdale <philipl@overt.org>
For the sake of compatibility, and because pretty much everything else in the
codebase calls it HEVC.
Signed-off-by: Philip Langdale <philipl@overt.org>
They are unused and colorspace.h is not a installed header
Found-by: Timo Rothenpieler <timo@rothenpieler.org>
Reviewed-by: Clément Bœsch <u@pkh.me>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Various header informations need to be reset when decoding next frame.
Regression since: 95582b5c
Fixes ticket #4597.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
They are inlined wrapper functions inside the time.h header on MinGW-w64, so
neither check_func() or check_func_headers() work with them.
Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: James Almer <jamrial@gmail.com>
