In addition to avoiding undefined behaviour, an unsigned type
makes more sense for packing multiple 8-bit values.
Signed-off-by: Mans Rullgard <mans@mansr.com>
(cherry picked from commit bb59156606)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Since nnz can be zero, this is needed to avoid a shift by 32.
Signed-off-by: Mans Rullgard <mans@mansr.com>
(cherry picked from commit d12294304a)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
If flush_put_bits() is called when the 32-bit buffer is empty,
e.g. after writing a multiple of 32 bits, and invalid shift by
32 is performed. Since flush_put_bits() is called infrequently,
this additional check should have negligible performance impact.
Signed-off-by: Mans Rullgard <mans@mansr.com>
(cherry picked from commit ac6eab1496)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
It was wrong in colorspaces where horizontal and vertical chroma
subsampling are not the same, e.g. 422.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Based on code by DivX, Inc. / drffmpeg
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 51b0694bc0)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This fix is not ideal as it still limits the multithreading on field pictures
to the 2nd field only.
Ill try to fix it properly to allow both fields to decode concurrently but this
needs more work.
This bug exists since and was caused by:
commit ea6331f8bb
Author: Ronald S. Bultje <rsbultje@gmail.com>
Date: Mon Jun 20 10:24:33 2011 -0400
h264-mt: fix deadlock in packets with multiple slices (e.g. MP4).
(cherry picked from commit eaa21b6870)
This patch set the limit to 16.
For information, thoses previous commits:
41f7e2d11d5cbb0e70a0
assumed it was either 30 or 32.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit bcf881a685)
* qatar/release/0.7: (73 commits)
Update Changelog for 0.7.2 release
Update RELEASE file for 0.7.2
lavf: do not set codec_tag for rawvideo
fate: allow testing with libavfilter disabled
fate: separate lavf-mxf_d10 test from lavf-mxf
Fix memory (re)allocation in matroskadec.c, related to MSVR-11-0080.
movenc: fix NULL reference in mov_write_tkhd_tag
movenc: create an alternate group for each media type
flvdec: Check for overflow before allocating arrays
ppc: fix some pointer to integer casts
ppc: fix 32-bit PIC build
rv34: Check for invalid slice offsets
rv34: Fix potential overreads
rv34: Avoid NULL dereference on corrupted bitstream
rv10: Reject slices that does not have the same type as the first one
lavf: Fix context pointer in av_open_input_stream when avformat_open_input fails
oggdec: fix out of bound write in the ogg demuxer
Fixed size given to init_get_bits().
smacker: fix a few off by 1 errors
Check for invalid VLC value in smacker decoder.
...
Conflicts:
RELEASE
libavcodec/avs.c
libavcodec/ppc/asm.S
libavcodec/rv34.c
libavcodec/xan.c
libavdevice/alsa-audio.h
libavformat/flvdec.c
libavformat/gxf.c
libavformat/utils.c
libswscale/x86/swscale_template.c
tests/ref/lavf/mov
tests/ref/lavf/mxf
Merged-by: Michael Niedermayer <michaelni@gmx.at>
There is no valid reason the user should ever send such packets in the
first place, but the documentation for CODEC_CAP_DELAY states that the
codec is guaranteed not to get a NULL packet unless that capability is
set. That isn't true without preventing this case.
(cherry picked from commit 6326afd5e9)
