| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Also shorten HuffYUV context member names to avoid clutter.
|
|
|
|
| |
libavcodec/lagarith.c:671:16: warning: '#' flag used with ‘%u’ gnu_printf format [-Wformat]
|
| |
|
|
|
|
|
|
|
| |
Fixes invalid writes on pixel format changes.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
|
|
|
|
|
|
|
|
|
|
| |
They end up overwriting past the line end.
Partially based on a patch by Michael Niedermayer <michaelni@gmx.at>
Bug-Id: vlc/9700
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|
| |
|
| |
|
| |
|
|
|
|
| |
It's got_frame, not data size
|
| |
|
|
|
|
|
|
|
| |
Fixes CVE-2012-2793
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|
|
|
|
|
|
|
| |
About 2x speedup going from 1 to 2 threads.
1.7s to 0.85s on foreman CIF.
Signed-off-by: Janne Grunau <janne-libav@jannau.net>
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
For left HFYU prediction, we predict from the buffer buf+1 using 8- or
16-byte reads. This means that aligning the buffer by 16 bytes is in
itself not sufficient, because if the width itself is 16- or 8-byte
aligned, the buffer will not be padded, and thus a read of size 16 at
buf+1 will overflow boundaries at the right edge. Padding the buffer by
1 byte is sufficient to not overflow its boundaries.
Fixes bug 342.
|
|
|
|
|
|
|
| |
Unlike other variants, for YUY2 we need to use different prediction:
* on line 0 for luma we should left predict starting from the second pixel
* on line 1 we should left predict first 4 pixels for luma and 2 for chroma
* median prediction employed here is taken directly from HuffYUV
|
|
|
|
| |
Signed-off-by: Kostya Shishkov <kostya.shishkov@gmail.com>
|
|
|
|
| |
This is logical and also fixes checking for the fourth plane offset.
|
|
|
|
|
|
|
| |
Also break some long lines, remove codec function placeholder comments
and add spaces in sample/pixel format lists.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
|
| |
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
|
|
|
|
| |
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
| |
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
| |
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|
|
|
|
| |
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
| |
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
| |
It's more readable and less prone to breakage.
|
|
|
|
| |
Signed-off-by: Diego Biurrun <diego@biurrun.de>
|
|
|
|
| |
The filename is unnecessary and brittle across file renames.
|
|
|
|
| |
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
|
|
|
|
|
| |
Tested to compile with lavc major bump.
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
|
|
|
|
|
|
| |
None of these symbols should be accessed directly, so declare them as
hidden.
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
|
|
|
|
|
|
| |
color value instead of always taking 0 (resulting in green frames).
Fixes issue issue2531.
Originally committed as revision 26363 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 26270 to svn://svn.ffmpeg.org/ffmpeg/trunk
|