- 03 Feb, 2014 1 commit
-
-
Michael Niedermayer authored
Such changes are forbidden in H.264 and lead to race conditions Fixes out of array read Fixes: signal_sigsegv_f9796a_1613_cov_3114610371_FM1_BT_B.h264 Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 28 Dec, 2013 1 commit
-
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 09 Dec, 2013 1 commit
-
-
Vittorio Giovara authored
-
- 31 Oct, 2013 1 commit
-
-
John Stebbins authored
This can be optionally disabled whith the "output_corrupt" flags option. When in "output_corrupt" mode, incomplete frames are signalled through AVFrame.flags FRAME_FLAG_INCOMPLETE_FRAME. Signed-off-by: Anton Khirnov <anton@khirnov.net>
-
- 15 Oct, 2013 2 commits
-
-
Ronald S. Bultje authored
-
Yusuke Nakamura authored
Signed-off-by: Anton Khirnov <anton@khirnov.net>
-
- 28 Sep, 2013 1 commit
-
-
Ronald S. Bultje authored
This prevents emulated_edge_mc from not undoing mvy*stride-related integer overflows. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 21 Jul, 2013 1 commit
-
-
Joakim Plate authored
This matches the matroska defintion of stereo_mode, with no metadata written if no info exist in sei Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 24 May, 2013 1 commit
-
-
Yusuke Nakamura authored
Signed-off-by: Anton Khirnov <anton@khirnov.net>
-
- 19 Apr, 2013 1 commit
-
-
Anton Khirnov authored
Based on a patch by Vittorio Giovara <vittorio.giovara@gmail.com> Fixes Bug 378.
-
- 21 Mar, 2013 10 commits
-
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
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.
-
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
It is not called from outside h264.c
-
- 08 Mar, 2013 1 commit
-
-
Anton Khirnov authored
-
- 07 Mar, 2013 1 commit
-
-
Diego Biurrun authored
-
- 03 Mar, 2013 1 commit
-
-
Ronald S. Bultje authored
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 23 Feb, 2013 1 commit
-
-
Diego Biurrun authored
The init functions marked as av_cold have to be executed in any case, so there is no gain from trying to mark paths leading to such functions as unlikely.
-
- 20 Feb, 2013 1 commit
-
-
Michael Niedermayer authored
Fixes out of array accesses Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 19 Feb, 2013 3 commits
-
-
Ronald S. Bultje authored
Instead, only extend edges on-demand when the motion vector actually crosses the visible decoded area using ff_emulated_edge_mc(). This changes decoding time for cathedral from 8.722sec to 8.706sec, i.e. 0.2% faster overall. More generally (VP8 uses this also), low-motion content gets significant speed improvements, whereas high-motion content tends to decode in approximately the same time. Signed-off-by: Martin Storsjö <martin@martin.st>
-
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>
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 18 Feb, 2013 2 commits
-
-
Ronald S. Bultje authored
Instead, only extend edges on-demand when the motion vector actually crosses the visible decoded area using ff_emulated_edge_mc(). This changes decoding time for cathedral from 8.722sec to 8.706sec, i.e. 0.2% faster overall. More generally (VP8 uses this also), low-motion content gets significant speed improvements, whereas high-motion content tends to decode in approximately the same time. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
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>
-
- 06 Feb, 2013 2 commits
-
-
Anton Khirnov authored
They serve no useful purpose and wreak all kind of havoc when h264.h is included elsewhere.
-
Diego Biurrun authored
-
- 24 Jan, 2013 1 commit
-
-
Mans Rullgard authored
The sh4 optimizations are removed, because the code is 100% identical to the C code, so it is unlikely to provide any real practical benefit. Signed-off-by: Diego Biurrun <diego@biurrun.de> Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com> Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
-
- 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>
-
- 18 Jan, 2013 1 commit
-
-
Anton Khirnov authored
ref_list is constructed from other fields per slice when needed, so do not copy it for both frame and slice threading. default_ref_list is constructed per frame and still needs to be copied to per-slice contexts for slice threading, but a copy is not needed for frame threading.
-
- 15 Jan, 2013 1 commit
-
-
Ronald S. Bultje authored
Clobbering these tables will temporarily clobber the template used as a basis for other threads to start decoding from. If the other decoding thread updates from the template right at that moment, subsequent threads will get invalid (or, usually, none at all) mmco tables. This leads to invalid reference lists and subsequent decode failures. Therefore, instead, decode the mmco tables only for the first slice in a field or frame. For other slices, decode the bits and ensure they are identical to the mmco tables in the first slice, but don't ever clobber the context state. This prevents other threads from using a clobbered/invalid template as starting point for decoding, and thus fixes decoding in these cases. This fixes occasional (~1%) failures of h264-conformance-mr1_bt_a with frame-multithreading enabled. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-
- 14 Jan, 2013 2 commits
-
-
Anton Khirnov authored
It's been returning an error value since bad446e2 Also check for the errors it returns.
-
Ronald S. Bultje authored
Clobbering these tables will temporarily clobber the template used as a basis for other threads to start decoding from. If the other decoding thread updates from the template right at that moment, subsequent threads will get invalid (or, usually, none at all) mmco tables. This leads to invalid reference lists and subsequent decode failures. Therefore, instead, decode the mmco tables only for the first slice in a field or frame. For other slices, decode the bits and ensure they are identical to the mmco tables in the first slice, but don't ever clobber the context state. This prevents other threads from using a clobbered/invalid template as starting point for decoding, and thus fixes decoding in these cases. This fixes occasional (~1%) failures of h264-conformance-mr1_bt_a with frame-multithreading enabled. Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
-
- 19 Dec, 2012 1 commit
-
-
Michael Niedermayer authored
Based on code by Janne Grunau Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
-