| Age | Commit message (Collapse) | Author |
|---|
|
Fixes invalid reads.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
|
|
|
|
This way it does not look like a constant.
|
|
This way it does not look like a constant.
|
|
This way it does not look like a constant.
|
|
This way it does not look like a constant.
|
|
This way it does not look like a constant.
|
|
This way it does not look like a constant.
|
|
|
|
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>
|
|
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>
|
|
It does not help as an abstraction and adds dsputil dependencies.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
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>
|
|
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>
|
|
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>
|
|
|
|
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
|
|
|
|
|
|
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
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>
|
|
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.
|
|
Avoid aliasing, unroll loops, and inline more functions.
|
|
Note: this is 4:4:4 from the 2007 spec revision, not the previous (now deprecated) 4:4:4 mode in H.264.
|
|
Needs some ARM/PPC asm modifications.
|
|
Note: this is 4:4:4 from the 2007 spec revision, not the previous (now deprecated) 4:4:4 mode in H.264.
|
|
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>
|
|
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>
|
|
Signed-off-by: Diego Biurrun <diego@biurrun.de>
|
|
Signed-off-by: Diego Biurrun <diego@biurrun.de>
|
|
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
|
|
|
when played with -flags emu_edge.
|
|
No speed improvement, but necessary for some future stuff.
Also opens up the possibility of asm chroma dc idct/dequant.
Originally committed as revision 26349 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Useful so that we don't have to run the hierarchical DC iDCT if there aren't
any coefficients. Opens up some future opportunities for optimization as well.
Originally committed as revision 26337 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
About 2.5x the speed.
NOTE: the way that the asm code handles large qmuls is a bit suboptimal.
If x264-style dequant was used (separate shift and qmul values), it might
be possible to get some extra speed.
Originally committed as revision 26336 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 24736 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Passing an explicit filename to this command is only necessary if the
documentation in the @file block refers to a file different from the
one the block resides in.
Originally committed as revision 22921 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
as i did nt find a limit in the spec)
This should stop cavlc_decode_residual() on a zero bitstream
Originally committed as revision 22429 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 22124 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
the row code. This function would only be needed on a MB basis for MBAFF+FMO
Originally committed as revision 21860 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
no speed change.
Originally committed as revision 21842 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Not benchmarked as i failed to find a sample that uses this one. But it should be faster.
Originally committed as revision 21435 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 21434 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Helps gcc not to add seperate -1 instructions.
Originally committed as revision 21432 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 21431 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 21430 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 21428 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 21425 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
This should be faster (couldnt meassue a difference), and its less picky
on slightly out of spec dquant.
Originally committed as revision 21373 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
