| Commit message (Collapse) | Author | Age |
|---|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* qatar/master:
bfi: Use bytestream2 functions to prevent buffer overreads.
dpcm: Fix invalid writes
utvideo: frame multithreading.
vorbis: An additional defense in the Vorbis codec.
vorbisdec: Fix decoding bug with channel handling
Conflicts:
libavcodec/dpcm.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
>> time ./avconv -i file.avi -f null -
Before : real 0m7.784s
After : real 0m3.662s
Tested on a Intel Core i3 Processor (2 cores, 4 threads).
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
| |\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* qatar/master:
fate: add dxtory test
adx_parser: rewrite.
adxdec: Validate channel count to fix a division by zero.
adxdec: Do not require extradata.
cmdutils: K&R reformatting cosmetics
alacdec: implement the 2-pass prediction type.
alacenc: implement the 2-pass prediction type.
alacenc: do not generate invalid multi-channel ALAC files
alacdec: fill in missing or guessed info about the extradata format.
utvideo: proper median prediction for interlaced videos
lavu: bump lavu minor for av_popcount64
dca: K&R formatting cosmetics
dct: K&R formatting cosmetics
lavf: flush decoders in avformat_find_stream_info().
win32: detect number of CPUs using affinity
Add av_popcount64
snow: Restore three mistakenly removed casts.
Conflicts:
cmdutils.c
doc/APIchanges
libavcodec/adx_parser.c
libavcodec/adxdec.c
libavcodec/alacenc.c
libavutil/avutil.h
tests/fate/screen.mak
Merged-by: Michael Niedermayer <michaelni@gmx.at>
|
| | | |
|
| |/
|
|
|
|
|
|
|
| |
I am not sure these new values are correct, not am I sure
the semantics are a good idea since we do not seem to make any
use of them but they caused a lot of confusion, but this
seems to make things closer to matching the documentation.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
|
| |
|
|
|
|
|
|
|
| |
If the frame is filled with the same colour, encoder may produce no data
and the fill value is indicated by zero code length (the rest of symbols
will have 0xFF for code length, meaning invalid). So such Huffman trees
should be treated specially.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
|
| |
|
|
|
|
|
| |
Luma slices in YUV420 colourspace should have height in multiple of two since
they have the same line of chrominance data corresponding to pair of them.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
|
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|
