- 28 Mar, 2013 1 commit
-
-
Michael Niedermayer authored
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 21 Mar, 2013 6 commits
-
-
Anton Khirnov authored
This way it does not look like a constant.
-
Anton Khirnov authored
This way it does not look like a constant.
-
Anton Khirnov authored
This way it does not look like a constant.
-
Anton Khirnov authored
This way it does not look like a constant.
-
Anton Khirnov authored
This way it does not look like a constant.
-
Anton Khirnov authored
This way it does not look like a constant.
-
- 08 Mar, 2013 1 commit
-
-
Anton Khirnov authored
-
- 19 Feb, 2013 1 commit
-
-
Ronald S. Bultje authored
Instead, keep them in the bitstream buffer until we read them verbatim, this saves a memcpy() and a subsequent clearing of the target buffer. decode_cabac+decode_mb for a sample file (CAPM3_Sony_D.jsv) goes from 6121.4 to 6095.5 cycles, i.e. 26 cycles faster. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 18 Feb, 2013 1 commit
-
-
Ronald S. Bultje authored
Instead, keep them in the bitstream buffer until we read them verbatim, this saves a memcpy() and a subsequent clearing of the target buffer. decode_cabac+decode_mb for a sample file (CAPM3_Sony_D.jsv) goes from 6121.4 to 6095.5 cycles, i.e. 26 cycles faster. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 15 Feb, 2013 1 commit
-
-
Anton Khirnov authored
Most of the changes are just trivial are just trivial replacements of fields from MpegEncContext with equivalent fields in H264Context. Everything in h264* other than h264.c are those trivial changes. The nontrivial parts are: 1) extracting a simplified version of the frame management code from mpegvideo.c. We don't need last/next_picture anymore, since h264 uses its own more complex system already and those were set only to appease the mpegvideo parts. 2) some tables that need to be allocated/freed in appropriate places. 3) hwaccels -- mostly trivial replacements. for dxva, the draw_horiz_band() call is moved from ff_dxva2_common_end_frame() to per-codec end_frame() callbacks, because it's now different for h264 and MpegEncContext-based decoders. 4) svq3 -- it does not use h264 complex reference system, so I just added some very simplistic frame management instead and dropped the use of ff_h264_frame_start(). Because of this I also had to move some initialization code to svq3. Additional fixes for chroma format and bit depth changes by Janne Grunau <janne-libav@jannau.net> Signed-off-by: Anton Khirnov <anton@khirnov.net>
-
- 23 Jan, 2013 1 commit
-
-
Diego Biurrun authored
It does not help as an abstraction and adds dsputil dependencies. Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
-
- 08 Dec, 2012 1 commit
-
-
Ronald S. Bultje authored
Prevent an invalid write into coeffs[scantable[-1]] if zeros_left itself was an invalid VLC code (and thus -1). Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
-
- 18 Nov, 2012 1 commit
-
-
Michael Niedermayer authored
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 27 Oct, 2012 1 commit
-
-
Mans Rullgard authored
Subtracting a (positive) value from the address of an array violates C99 section 6.5.6: If both the pointer operand and the result point to elements of the same array object, or one past the last element of the array object, the evaluation shall not produce an overflow; otherwise, the behavior is undefined. Signed-off-by: Mans Rullgard <mans@mansr.com>
-
- 05 Oct, 2012 2 commits
-
-
Ronald S. Bultje authored
The variable is copied to subsequent threads at the same time, so this may cause wrong ref_count[] values to be copied to subsequent threads. This bug was found using TSAN and Helgrind. Original patch by Ronald, adapted with a local_ref_count by Clément, following the suggestion of Michael Niedermayer. Signed-off-by: Clément Bœsch <clement.boesch@smartjog.com>
-
Ronald S. Bultje authored
The variable is copied to subsequent threads at the same time, so this may cause wrong ref_count[] values to be copied to subsequent threads. This bug was found using TSAN. Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
-
- 13 Aug, 2012 1 commit
-
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 26 Jul, 2012 1 commit
-
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 30 May, 2012 1 commit
-
-
Michael Niedermayer authored
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 05 Apr, 2012 1 commit
-
-
Diego Biurrun authored
-
- 10 Feb, 2012 1 commit
-
-
Ronald S. Bultje authored
Conversion of the luma intra prediction mode to one of the constrained ("alzheimer") ones can happen by crafting special bitstreams, causing a crash because we'll call a NULL function pointer for 16x16 block intra prediction, since constrained intra prediction functions are only implemented for chroma (8x8 blocks). Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind CC: libav-stable@libav.org
-
- 28 Jan, 2012 1 commit
-
-
Alex Converse authored
-
- 18 Dec, 2011 1 commit
-
-
Michael Niedermayer authored
in ffmpegs h264 decoder. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 12 Dec, 2011 1 commit
-
-
Diego Biurrun authored
-
- 21 Oct, 2011 1 commit
-
-
Baptiste Coudurier authored
Signed-off-by: Diego Biurrun <diego@biurrun.de> Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
-
- 11 Oct, 2011 1 commit
-
-
Mans Rullgard authored
The level_code expression includes a shift which is invalid in those cases where the value is not used. Moving the calculation to the branch where the result is used avoids these. Signed-off-by: Mans Rullgard <mans@mansr.com>
-
- 02 Oct, 2011 1 commit
-
-
Laurent Aimar authored
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 14 Aug, 2011 1 commit
-
-
Baptiste Coudurier authored
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 10 Jul, 2011 1 commit
-
-
Diego Biurrun authored
FF_COMMON_FRAME holds the contents of the AVFrame structure and is also copied to struct Picture. Replace by an embedded AVFrame structure in struct Picture.
-
- 03 Jul, 2011 1 commit
-
-
Jason Garrett-Glaser authored
Avoid aliasing, unroll loops, and inline more functions.
-
- 14 Jun, 2011 1 commit
-
-
Jason Garrett-Glaser authored
Note: this is 4:4:4 from the 2007 spec revision, not the previous (now deprecated) 4:4:4 mode in H.264.
-
- 13 Jun, 2011 2 commits
-
-
Jason Garrett-Glaser authored
Needs some ARM/PPC asm modifications.
-
Jason Garrett-Glaser authored
Note: this is 4:4:4 from the 2007 spec revision, not the previous (now deprecated) 4:4:4 mode in H.264.
-
- 10 May, 2011 2 commits
-
-
Oskar Arvidsson authored
In high bit depth, the QP values may now be up to (51 + 6*(bit_depth-8)). Preparatory patch for high bit depth h264 decoding support. Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
-
Oskar Arvidsson authored
In high bit depth the pixels will not be stored in uint8_t like in the normal case, but in uint16_t. The pixel size is thus 1 in normal bit depth and 2 in high bit depth. Preparatory patch for high bit depth h264 decoding support. Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
-
- 02 May, 2011 4 commits
-
-
Stefano Sabatini authored
-
Stefano Sabatini authored
-
Stefano Sabatini authored
Signed-off-by: Diego Biurrun <diego@biurrun.de>
-
Stefano Sabatini authored
Signed-off-by: Diego Biurrun <diego@biurrun.de>
-