| Age | Commit message (Collapse) | Author |
|---|
|
There is no point in delaying the check and it avoids bugs with a
half-initialized context.
Fixes invalid reads.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
|
|
A VUI doesn't contain anything strictly necessary for decoding.
Apparently there are many samples with truncated VUIs in the wild, this
commit should allow decoding them.
|
|
|
|
|
|
|
|
|
|
Based on a patch by Vittorio Giovara <vittorio.giovara@gmail.com>
Fixes Bug 378.
|
|
|
|
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>
|
|
Some 3D systems overload the meaning of the field for other purposes.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
|
|
Fixes bug 396.
CC: libav-stable@libav.org
|
|
Introduced in d7d6efe42b0d.
|
|
Fixes a crash in the fuzzed sample sample_varPAR.avi_s26638 with
alternating bit depths.
|
|
Fixes infinite or long taking loop in frame num gap code in
the fuzzed sample bipbop234.ts_s223302.
CC: libav-stable@libav.org
|
|
|
|
Fixes crashes in codepaths not covered by original checks.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
|
|
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
Fixes a crash when FF_DEBUG_PICT_INFO is used.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
Parsing the entire NAL as SPS fixes decoding of some AVC bitstreams
with broken escaping. Since the size of the NAL unit is known and
checked against the buffer end we can parse it entirely without buffer
overreads.
Fixes playback of
http://streams.videolan.org/streams/mp4/Mr_MrsSmith-h264_aac.mp4
Signed-off-by: Janne Grunau <janne-libav@jannau.net>
|
|
|
|
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
The bit_rate_value_minus1 and cpb_size_value_minus1 elements
allow a wider range than get_ue_golomb() supports. This
adds a get_ue_golomb_long() function supporting up to 31
leading zeros, which is the maximum for these syntax
elements, and uses it in decode_hrd_parameters().
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
|
The PPS may contain a few trailing elements whose presence is
only signalled by data remaining after the the mandatory part
has been parsed. The current code fails to take into account
the rbsp_trailing_bits() when deciding whether to parse these
optional elements. Assuming no unnecessary padding bytes are
passed to this function, the optional elements are present if
either more than 8 extra bits remain or the remaining bits do
not form a valid rbsp_trailing_bits() after the mandatory PPS
elements have been parsed.
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
|
|
|
|
|
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>
|
|
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
|
It is pretty hopeless that other considerable projects will adopt
libavutil alone in other projects. Projects that need small footprint
are better off with more specialized libraries such as gnulib or rather
just copy the necessary parts that they need. With this in mind, nobody
is helped by having libavutil and libavcore split. In order to ease
maintenance inside and around FFmpeg and to reduce confusion where to
put common code, avcore's functionality is merged (back) to avutil.
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
|
|
|
|
Contrary to progressive, just being able to crop up to 14/15 pixels
is not enough to encode all supported resolutions, and the new
behaviour is also consistent with e.g. MPEG-2 etc.
Originally committed as revision 25669 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Patch by John Stebbins stebbins jetheaddev com.
Originally committed as revision 25374 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
missed.
This preempts issues with av_cmp_q(0/0, X)
Originally committed as revision 25337 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 25058 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
av_check_image_size() instead.
Originally committed as revision 24711 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
This helps the video from issue1831
Originally committed as revision 23328 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
|
|
Originally committed as revision 21668 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Fixed issue1633
Originally committed as revision 21636 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 21286 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
no speedloss meassured, also its really not touching anything that is speed relevant.
Originally committed as revision 21169 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
