Fixes: https://trac.ffmpeg.org/attachment/ticket/685/movie.264
In the available testcase the actual PPS only uses a few bits
while there are 7kbyte of apparently random data after it
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
We assume an upper bound of 4096 bytes for each raw SPS/PPS. It's hard
to determine an exact maximum size, but this value was was considered
high enough and safe.
Needed for the following VideotoolBox commit.
The spec madandate both time_scale and num_units_in_tick greater than 0,
however since they are not essential for decoding, just ignore the whole
block and try to finish parsing the VUI.
Related to Ticket4445.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
* commit '84f226a3bcd8b39801a4c9051c033ab7d61aaf76':
h264: use the correct SPS during PPS parsing
Conflicts:
libavcodec/h264_ps.c
See: dc35b77b28
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Fixes out of array read
Fixes: asan_static-oob_30328b6_719_cov_3325483287_H264_artifacts_motion.h264
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'cba4e6062a02d5bf684e13a770be88aa1fec717e':
More correct printf format specifiers
Conflicts:
libavcodec/h264_ps.c
libavcodec/h264_refs.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'e70ab7c1f5005041bba0e4efc1165410f83495b2':
h264: add MVCD to the list of High profiles in SPS
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '614b9e4db8f3d7c23fc0410fc04745a727a82f4e':
h264: use avpriv_request_sample for chroma_format_idc
Conflicts:
libavcodec/h264_ps.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '3a0576702825423abecb32627c530dbc4c0f73bc':
h264: store current_sps_id inside the current sps
Conflicts:
libavcodec/h264.c
libavcodec/h264_ps.c
The current_sps_id is not removed as it used in security related code.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '73e8fab31dc19c4371499e612856accbc00b2820':
h264: print values in case of error
Conflicts:
libavcodec/h264.c
libavcodec/h264_ps.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '9ecabd7892ff073ae60ded3fc0a1290f5914ed5c':
h264: reset num_reorder_frames if it is invalid
Note, num_reorder_frames is not used in the failure case
Merged-by: Michael Niedermayer <michaelni@gmx.at>
An invalid VUI is not considered a fatal error, so the SPS containing it
may still be used. Leaving an invalid value of num_reorder_frames there
can result in writing over the bounds of H264Context.delayed_pic.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
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
* commit '94603feb1b3ad01a821a1a1cef1570b13f471821':
h264_ps: when parsing a VUI fails, only abort when explode is set
Merge only for metadata, ignoring invalid data can put the context
into an invalid state and can possibly be used for remote code
execution exploits.
Also we support all non standard VUIs that have been reported so
ignoring parsing failure makes no sense for us unless theres
some issue that has not been reported
Merged-by: Michael Niedermayer <michaelni@gmx.at>
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.
* commit 'c18838f5eb7d7001a9dc653f5162868c04c1b2a1':
h264_ps: Use more meaningful error values
Conflicts:
libavcodec/h264_ps.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Michael Niedermayer
wm4
Vittorio Giovara
Michael Niedermayer
Anton Khirnov
Christophe Gisquet
Gabriel Dume
Diego Biurrun