Put the zero length check in place of code that was never used
during decoding, as zero-length slices were generally refused
in decode_frame().
Signed-off-by: Kostya Shishkov <kostya.shishkov@gmail.com>
General cosmetics, such as keeping lines under 80 characters,
fixing a couple of typos (predition -> prediction) and a
general style fix that was pointed out by Derek when I was having
my sliced multithreading patch in review by him.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
>> 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>
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>