Previously, the put_bits call writing the value wrote a value
larger than the number of bits specified, failing asserts
in debug mode. There was no actual bitstream writer corruption,
since the overwritten bit already always was set to 1.
Signed-off-by: Martin Storsjö <martin@martin.st>
Previously, the value given to put_bits was 10 bits long for positive
predictors, even though 9 bits were to be written. The extra bit could
in some cases overwrite existing bits in the bitstream writer cache.
This fixes a failed assert in put_bits.h, when running a version
built with -DDEBUG.
The fate test result gets slightly improved, thanks to getting rid
of the overwritten bits in the bitstream writer cache.
Signed-off-by: Martin Storsjö <martin@martin.st>
This may need some trial and error to find exactly how to identify them
so please report any intel jpegs that get fliped wrong.
Fixes Ticket511
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
While not that usefull, we can as well keep it until it breaks.
When it breaks for whatever reason ill likely remove it
Sorry for the revert spam, i had not realized this code compiles
and works fine.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/master:
build: avcodec: order cosmetics
intrax8dsp: Add missing #include to make header standalone
Delete motion-test tool; it is of doubtful utility.
Conflicts:
libavcodec/Makefile
libavcodec/motion-test.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
In avfilter_config_links(), if the current channel layout is not
specified, set the same value of the previous link in the filterchain.
Consistent with the logic used to set the other link parameters.
yasm generates a warning instead of an error when "CPU amdnop" is not supported, so the check always succeeds.
HAVE_CPUNOP as true when the available yasm version doesn't support amdnop doesn't make sense.
Check http://fate.ffmpeg.org/log.cgi?time=20120901143315&log=compile&slot=x86_64-archlinux-gcc-oldyasm to see the amount of warnings it generates.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This fixes stream lookup in flv demuxer. When used with librtmp
protocol streams are sometimes added after head arrived. If the
first stream added in flv header reader is Audio stream then it
is messed with Video stream added later in the code patched.
The result is I have 2 Audio streams (first of them is said to have
a video codec like h264) instead of Audio/Video pair.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* cus/stable:
ffplay: only free vfilters on exit
ffplay: replace SDL_delay in read thread with SDL_CondWait
ffplay: requeue last picture on forced video refresh
Merged-by: Michael Niedermayer <michaelni@gmx.at>