* qatar/master:
aacenc: Fix LONG_START windowing.
aacenc: Fix a bug where deinterleaved samples were stored in the wrong place.
avplay: use the correct array size for stride.
lavc: extend doxy for avcodec_alloc_context3().
APIchanges: mention avcodec_alloc_context()/2/3
avcodec_align_dimensions2: set only 4 linesizes, not AV_NUM_DATA_POINTERS.
aacsbr: ARM NEON optimised sbrdsp functions
aacsbr: align some arrays
aacsbr: move some simdable loops to function pointers
cosmetics: Remove extra newlines at EOF
Conflicts:
libavcodec/utils.c
libavfilter/formats.c
libavutil/mem.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>
