This commit removes the badly duplicated code between the encoder and
the muxer. That may sound surprising, but the encoder is now responsible
from the encoding of the picture when muxing to a .gif file. It also
does not require anymore a manual user intervention such as a -pix_fmt
rgb24 to work properly. To summarize, output gif are now easier to
generate, code is saner and simpler, and files are smaller (thanks to
the lzw encoding which was unused so far with the default .gif output).
We can certainly make things even better, but this is the first step.
FATE is updated because of the output being produced by the encoder and
not the muxer (no lzw in the muxer), and in the seek test only the size
mismatches.
Fixes Ticket #2262
* commit '69f6f03cd16a09e4e848b4e82bae4993bc361cd0':
rv10: cosmetics, reformat
qdm2: check that the FFT size is a power of 2
Conflicts:
libavcodec/rv10.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'b1bb8fb860b47e90dd67f0c5740698128fc82dcc':
svq1dec: check that the reference frame has the same dimensions as the current one
Conflicts:
libavcodec/svq1dec.c
See: 3b57bb478f
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The data offsets are relative to the bistream header, which is 16 bytes
after the start of the data.
Fixes invalid reads with corrupted files.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
Also add an additional sanity check to the alt_quant table.
Fixes invalid reads with corrupted files.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
They can be different if the last keyframe failed to decode correctly.
Fixes possible invalid reads in such a case.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
* commit '015821229f96bf7e677f2a711a58dbea3009f574':
vp3: Use full transpose for all IDCTs
Conflicts:
libavcodec/vp3.c
libavcodec/vp3dsp.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'c46819f2299c73cd1bfa8ef04d08b0153a5699d3':
x86: Move constants to the only place where they are used
Conflicts:
libavcodec/x86/vp3dsp.asm
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This way, the special IDCT permutations are no longer needed. This
is similar to how H264 does it, and removes the dsputil dependency
imposed by the scantable code.
Also remove the unused type == 0 cases from the plain C version
of the idct.
Signed-off-by: Martin Storsjö <martin@martin.st>
While this change isn't bitexact, the IDCTs weren't bitexact to
start with either.
This simplifies decoupling vp3 from dsputil.
Signed-off-by: Martin Storsjö <martin@martin.st>
Just like get_buffer, get_format should not be called from a different
thread if thread_safe_callbacks is not set.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
With the current code it fails due to running out
of registers.
So code the store offsets manually into the assembler
instead.
Passes "make fate-dts".
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
dsputil_init() is deprecated and not meant to be exported.
ff_dsputil_init() is internal to libavcodec and thus can not be used.
avpriv_dsputil_init() is the version shared between libraries.
This commit fixes 3 unjustified libavfilter deprecated warnings.
* commit 'e027032fc6a49db5a4ce12fc3e09ffb86ff20522':
x86: dsputil: ff_h263_*_loop_filter declarations to a more suitable place
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'a89c05500f68d94a0269e68bc522abfd420c5497':
x86: h264qpel: int --> ptrdiff_t for some line_size parameters
Conflicts:
libavcodec/x86/qpelbase.asm
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Using the first names of authors sounds somewhat unprofessional
and might be considered offensive which is not intended.
The new names use the initials of the authors due to simplicity
and the possibility to apply it consistently without the need
to find political correct names for each future case where
alternative codecs might exist. Also its shorter ...
If someone has a better idea, like maybe 2 random letters
and people prefer it then iam happy to switch to that ...
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '9de9b828ef005dec37052548c195a6b4f18fc701':
lavc: don't overwrite display dimensions with coded dimensions.
lavc: extend / update the [coded_]{width,height} doxy
Conflicts:
libavcodec/avcodec.h
libavcodec/utils.c
The change to the w/h handling is not merged as it breaks lowres
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '8a776ad90e00ab2b98e8683ac6182d641a383c3a':
h261: Move shared data tables from a header to a proper C file
Conflicts:
libavcodec/Makefile
libavcodec/h261data.c
libavcodec/h261dec.c
libavcodec/h261enc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '85deb51a01f1ecc5ac5faa52ad8ea141c384e23a':
h264: Only initialize dsputil if error resilience is enabled
Conflicts:
libavcodec/h264.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'e8cafd2773bc56455c8816593cbd9368f2d69a80':
h264: Clear the mb members via memset instead of using dsputil
Conflicts:
libavcodec/h264.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '6d25c9db11e87ec58652de6588448225137b0c57':
dsputil: Make square put/avg_pixels functions local to h264qpel
Conflicts:
libavcodec/dsputil.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
It is only used for error resilience. This allows building the
h264 decoder without dsputil, if error resilience is disabled.
Signed-off-by: Martin Storsjö <martin@martin.st>
The non-intra-pcm branch in hl_decode_mb (simple, 8bpp) goes from 700
to 672 cycles, and the complete loop of decode_mb_cabac and hl_decode_mb
(in the decode_slice loop) goes from 1759 to 1733 cycles on the clip
tested (cathedral), i.e. almost 30 cycles per mb faster.
Signed-off-by: Martin Storsjö <martin@martin.st>
Put a copy of the 8bit functions only in dsputil, where they are
used for some other things (e.g. mpeg4qpel, mspel, cavsqpel).
Signed-off-by: Martin Storsjö <martin@martin.st>
The EC code does not support fields currently thus it makes no
sense to wait for these cases (which also the check doesnt handle
correctly)
Fixes Ticket 2454
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The pointers that get assigned ff_cropTbl were made const in
9e0f14f1, but other variables that transitively are assigned
based on these variables were missed.
Signed-off-by: Martin Storsjö <martin@martin.st>
* qatar/master:
lavc: Move ff_cropTbl and ff_zigzag_direct from dsputil to mathtables
Conflicts:
libavcodec/mathtables.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '610b18e2e3d8ef5eca3e78f33a0625689b8d2bb9':
x86: qpel: Move fullpel and l2 functions to a separate file
bfin: Make vp3 functions static
Conflicts:
libavcodec/bfin/vp3_bfin.c
libavcodec/x86/Makefile
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'aa8d89536d35af0a0c8d8bac2b452ffe7b82cae5':
bfin: Don't use the vp3 idct functions if bitexact behaviour is expected
Conflicts:
libavcodec/bfin/vp3_bfin.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
These are widely used throughout libavcodec, nothing dsputil-specific.
Change ff_cropTbl to a statically initialized table, to avoid
initializing it with a function call.
Signed-off-by: Martin Storsjö <martin@martin.st>
This way, they can be shared between mpeg4qpel and h264qpel without
requiring either one to be compiled unconditionally.
Signed-off-by: Martin Storsjö <martin@martin.st>
This makes the vp3 decoder less dependent on dsputil, and will aid
in making it (eventually) dsputil-independent.
Signed-off-by: Martin Storsjö <martin@martin.st>
In the non-bitexact mode, vp3 currently decodes to the same
frame crcs as before 28f9ab702 (and the output visually looks
correct).
Signed-off-by: Martin Storsjö <martin@martin.st>
From 312 to 89/68 (sse/sse2) cycles on Arrandale and Win64.
Sandybridge: 68/47 cycles.
Having a loop counter is a 7 cycle gain.
Unrolling is another 7 cycle gain.
Working in reverse scan is another 6 cycles.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Text subtitles packets are not 0-terminated (and if they are,
it is handled by the recoding process since 0 is a valid
Unicode code point). The terminating 0 would overwrite the
last payload octet.
OTOH, packets must be 0-padded.
Fix a problem reported in trac ticket #2431.
This patch can be controversial, by assuming floats are IEEE-754 and
particular behaviour of the FPU will get in the way.
Timing on Arrandale and Win32 (thus, x87 FPU is used in the reference).
sbr_qmf_pre_shuffle_c: 115 to 76
sbr_neg_odd_64_c: 84 to 55
sbr_qmf_post_shuffle_c: 112 to 83
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Timing on Arrandale:
C SSE
Win32: 57 44
Win64: 47 38
Unrolling and not storing mask both save some cycles.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Timing on Arrandale:
C SSE
Win32: 57 44
Win64: 47 38
Unrolling and not storing mask both save some cycles.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/master:
libopenjpeg: Add support for XYZ colorspace, found in DCINEMA frames
Conflicts:
libavcodec/libopenjpegdec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'd1016dccdcb10486245e5d7c186cc31af54b2a9c':
xmv: check audio track parameters validity.
bmv: check for len being valid in bmv_decode_frame().
Conflicts:
libavformat/xmv.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '8d617b11cfc87b2c6056fee029ac5bc760af874a':
id3v2: pad the APIC packets as required by lavc.
dfa: check for invalid access in decode_wdlt().
Conflicts:
libavformat/id3v2.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
It can be 0 or -1 for invalid files, which may result in invalid memory
access.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
This can happen when the number of skipped lines is not consistent with
the number of coded lines.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Fixes inconsistency ultimately leading to an out of array read
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This fixes out of array writes after resolution changes
No FFmpeg releases are known to be affected by this
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The gmc functions access more pixels than there is allocated memory.
Fixes out of array reads
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/master:
vmdav: convert to bytestream2
FATE: add a test for the join filter
FATE: add a test for the volume filter
Conflicts:
libavcodec/vmdav.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'b4d24b471bc52f1f78a43ee330199e70483e51c3':
build: Remove configure-generated .config file on distclean
msmpeg4: Split decoding related functions to a separate file
Conflicts:
Makefile
libavcodec/Makefile
libavcodec/msmpeg4.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'e557584aa7df6ac9f52af7ee7e5c963437da2e2f':
mpeg12: Move Mpeg1Context declaration to the only place it is used
Conflicts:
libavcodec/mpeg12.h
libavcodec/mpeg12dec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '1b6d66745ac1768adb387c2227cdcf4452271149':
Split MPEG-1/2 decoder code off from MPEG-1/2 common code
Conflicts:
libavcodec/Makefile
libavcodec/mpeg12.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'eee2000b41234ae9465c314e18bfec1700181f32':
mpeg12: Move some ff_mpeg1_* function declarations to a more suitable place
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '1db6a080bddd14fed6b29140ecd2e21e42b1c022':
dca: Move ff_dca_convert_bitstream() to the DCA common code
vdpau: wrap codec specific functions in appropiate #ifs
Conflicts:
libavcodec/Makefile
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Instead of this it would be possible to change the code to support
larger K but that would make the code slower and probably still need
checks on K.
This variant is choosen as there are no known valid files that need
larger K
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This fixes standalone compilation of the msmpeg4v2, msmpeg4v3
and wmv2 encoders, that previously failed to link due to the
decoder codepaths requiring error_resilience.
Signed-off-by: Martin Storsjö <martin@martin.st>
* qatar/master:
hwaccel: fix use with frame based multithreading
Conflicts:
libavcodec/h263dec.c
libavcodec/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Allows use of AVHWAccel based decoders with frame based multithreading.
The decoders will be forced into an non-concurrent mode by delaying
ff_thread_finish_setup() calls after decoding of the current frame
is finished.
This wastes memory by unnecessarily using multiple threads and thus
copies of the decoder context but allows seamless switching between
hardware accelerated and frame threaded software decoding when the
hardware decoder does not support the stream.
Since c977039e58 plane count for
PIX_FMT_HWACCEL pixel formats is 0 instead of 1. The created dummy
AVBuffers are still bogus since AVFrame does not hold frame data when
AVHWAccels are used.
* qatar/master:
h264: Make it possible to compile without error_resilience
Conflicts:
configure
libavcodec/h264.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'e5c2794a7162e485eefd3133af5b98fd31386aeb':
x86: consistently use unaligned movs in the unaligned bswap
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Error resilience is enabled by the h264 decoder, unless explicitly
disabled. --disable-everything --enable-decoder=h264 will produce
a h264 decoder with error resilience enabled, while
--disable-everything --enable-decoder=h264 --disable-error-resilience
will produce a h264 decoder with error resilience disabled.
Signed-off-by: Martin Storsjö <martin@martin.st>
Also move the declaration to internal.h, and add restrict qualifiers
to the declaration (as in the implementation).
Signed-off-by: Martin Storsjö <martin@martin.st>
This allows dropping the mpegvideo dependency from a number of
components.
This also fixes standalone building of the h264 parser, which
was broken in 64e438697.
Signed-off-by: Martin Storsjö <martin@martin.st>
It appears gcc forgets to increment the byte stream pointer at -O3
I was not able to spot a reason/excuse for it to do that. It
also disappears if the function isnt inlined.
This should fix the gif fate failures on open & free bsd
See: [FFmpeg-devel] [PATCH] gifdec: workaround old gcc 4.2 mis-compiling code
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This should silence many valgrind warnings about use of uninitialized
data, all the warnings i looked at where false positives having their
uninitialized data not actually used.
The same effect could be achieved by listing all code that touches
the pixel buffer in the valgrind suppression file.
Note, valgrind also fails to trace the origins correctly.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '23e85be58fc64b2e804e68b0034a08a6d257e523':
h264: add a parameter to the CHROMA444 macro.
h264: add a parameter to the CHROMA422 macro.
Conflicts:
libavcodec/h264.c
libavcodec/h264.h
libavcodec/h264_cavlc.c
libavcodec/h264_loopfilter.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '6d2b6f21eb45ffbda1103c772060303648714832':
h264: add a parameter to the CABAC macro.
h264: add a parameter to the FIELD_OR_MBAFF_PICTURE macro.
Conflicts:
libavcodec/h264.c
libavcodec/h264_cabac.c
libavcodec/h264_cavlc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '7fa00653a550c0d24b3951c0f9fed6350ecf5ce4':
h264: add a parameter to the FIELD_PICTURE macro.
h264: add a parameter to the FRAME_MBAFF macro.
Conflicts:
libavcodec/h264.c
libavcodec/h264_loopfilter.c
libavcodec/h264_refs.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'da6be8fcec16a94d8084bda8bb8a0a411a96bcf7':
h264: add a parameter to the MB_FIELD macro.
h264: add a parameter to the MB_MBAFF macro.
Conflicts:
libavcodec/h264.c
libavcodec/h264_cabac.c
libavcodec/h264_cavlc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The metadata must be set before saving the frame to avci->to_free,
otherwise it will leak.
Signed-off-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: Clément Bœsch <ubitux@gmail.com>
Floating point FFT (nips optimized) breaks when hard coded tables are
not enabled because MIPS optimization of floating point FFT uses only
ff_init_ff_cos_tabs(16) which is not enabled by default in that case.
This patch is fixing it.
Signed-off-by: Nedeljko Babic <nbabic@mips.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
AVCodecContext.bits_per_raw_sample is updated from the previous thread
in the generic update function before the codec specific update_thread
function is called. The check for reinitialization of dsp functions uses
bits_per_raw_sample. When called from update_thread_context it will be
already at the current value and the dsp functions aren't updated if
only the bit depth changes.
* commit 'c3ebfcd6e1327ca7bbcaee822e593c2da6cfd352':
mpegvideo: allocate hwaccel privdata after the frame buffer
h264: allocate hwaccel privdata after the frame buffer
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '4e70d66ded537cadd32dbd02a38c3d86a203c812':
mpegvideo: fix allocation of the hwaccel_picture_private data
lavc: update the doxy for avcodec_decode_{video,audio} wtih refcounting.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '6599b087de62a5f9f2a8d61a1952d777d1bff804':
buffersrc: fix a typo.
lavc, lavfi: fix counting number of planes in AVBufferRef wrappers
Merged-by: Michael Niedermayer <michaelni@gmx.at>
For some obscure reasons avcodec_set_dimensions() resets the width/height
so that the resulting value set in the stream is equal to the
corresponding coded_width/height, which is not the same as the correct
width/height in case of the H.264 and VP6F codecs.
This adds a codec-specific hack for VP6F which disables the call to
avcodec_set_dimensions() in avcodec_open2(), like it is done with H264. A
proper fix needs to be found yet.
Fix trac ticket #1386.
Based on a patch by Michael Niedermayer.
Trolled-By: Daemon404
See thread:
Subject: [FFmpeg-devel] [PATCH] ffprobe: Stash and use width and height before opening the codec
Date: Fri, 1 Mar 2013 10:41:34 -0500
List of clobbered registers fixed and added where it is lacking.
Signed-off-by: Nedeljko Babic <nbabic@mips.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This ensures the hwaccel privdata does not leak when a frame buffer could
not be allocated (and toggle the assert when the frame is re-used).
Having no frame buffer available is quite common when using the DXVA2
hwaccel in situations where the DXVA2 renderer is being re-allocated, for
example when moving between displays.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This ensures the hwaccel privdata does not leak when a frame buffer could
not be allocated (and toggle the assert when the frame is re-used).
Having no frame buffer available is quite common when using the DXVA2
hwaccel in situations where the DXVA2 renderer is being re-allocated, for
example when moving between displays.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Number of planes is not always equal to the number of components even
for formats marked with PIX_FMT_PLANAR -- e.g. NV12 has three components
in two planes.
* qatar/master:
print_options: do not generate docs for options without enc or dec flags
mpeg12: do not fail on zero dimensions in the sequence header.
Conflicts:
libavcodec/mpeg12.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The total frame size is a combination of the 12 bits in the sequence
header and 2 more bits in the the sequence extension. While the
specification explicitly forbids the dimensions from the sequence header
from being 0 (thus ruling out multiples of 4096), such videos
apparrently exist in the wild so we should attempt to decode them.
Based on a patch by Michael Niedermayer <michaelni@gmx.at>
Fixes Bug 416.
The two types of packets (PCI and DSI) are passed untouched but combined by the new codec ID AV_CODEC_ID_DVD_NAV.
The first 980 bytes in the packet contain the PCI data. The next 1018 are the DSI data.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
