This reverts commit 9d6b2077b2.
This error is annoying while debugging, and if someone disables it for
convenience, it raises the odds of leaving ffmpeg unbuildable by default.
With the current default PES packet size, and very small audio bitrates,
audio packet duration gets too long. For players, which wait for a whole
audio packet (or more) it takes a very long time to start playing sound.
For 24kbps audio, one PES packet is about 1 second long. On Motorola STBs,
we observe about 3 second delay before the playback starts with the
default setting.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Do not assume the audio packets being always smaller than
DEFAULT_PES_PAYLOAD_SIZE.
Signed-off-by: Jindřich Makovička <makovick@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
* qatar/master:
mpegvideo_enc: K&R cosmetics
doxygen: remove unreplaced variables from custom header and footer
threads: test for sys/param.h and include it for sysctl on OpenBSD
v4l2: remove unneded linux specific asm/types.h include
x86: Fix constraints for decode_significance*_x86
Conflicts:
libavcodec/mpegvideo_enc.c
libavdevice/v4l2.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The existing code expected a palette buffer holding 256 uint32_t's allocated in the data[1] field of the AVFrame structure, but data[1] was NULL. The bug is fixed by using a fixed local array (palette256) to hold the palette instead.
This solves http://ffmpeg.org/trac/ffmpeg/ticket/833
Signed-off-by: Frank Vernaillen <fr_ve@hotmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
av_samples_alloc() behavior changed in bbb46f3ec, resulting in random
data filling the data[] and linesize[] arrays of the returned
AVFilterBufferRef, which was resulting in wrong behavior in case of code
checking on data[i] nullity.
In particular fixes crash in avfilter_filter_samples():
for (i = 0; samplesref->data[i]; i++)
memcpy(link->cur_buf->data[i], samplesref->data[i], samplesref->linesize[0]);
and correctly fills the linesize[] array for planar data.
Originally, prior to 8742a4ff8, the caller code was compiled
within this condition:
ARCH_X86 && HAVE_7REGS && HAVE_EBX_AVAILABLE && !defined(BROKEN_RELOCATIONS)
Since HAVE_7REGS is defined as
(ARCH_X86_64 || (HAVE_EBX_AVAILABLE && HAVE_EBP_AVAILABLE))
the subcondition HAVE_7REGS && HAVE_EBX_AVAILABLE is equal
to HAVE_7REGS (for 32 bit at least). The correct simplification
of the original condition thus is HAVE_7REGS, not
HAVE_EBX_AVAILABLE.
This fixes compilation in some cases where HAVE_EBP_AVAILABLE = 0
and HAVE_EBX_AVAILABLE = 1.
Signed-off-by: Martin Storsjö <martin@martin.st>
* qatar/master:
fate: split off vqf/twinvq FATE tests into their own file
fate: split off mpc FATE tests into their own file
fate: split off libavcodec FATE tests into their own file
fate: split off Microsoft codec FATE tests into their own file
fate: group all VP* codec FATE tests together in one file
swscale: prevent invalid writes in packed_16bpc_bswap
Merged-by: Michael Niedermayer <michaelni@gmx.at>
