Michael Niedermayer: > On Mon, Jul 22, 2019 at 05:27:13AM +0200, Andreas Rheinhardt wrote: >> 1. Currently during parsing the extradata, h264_mp4toannexb checks for >> overreads by adding the size of the current unit to the current position >> pointer and comparing this to the end position of the extradata. But >> pointer comparisons and pointer arithmetic is only defined if it does not >> exceed the object it is used on (one past the last element of an array >> is allowed, too). In practice, this might lead to overflows. Therefore >> the check has been changed. >> 2. The minimal size of an AVCDecoderConfigurationRecord is actually 7: >> Four bytes containing version, profile and level, one byte for length >> size and one byte each for the numbers of SPS and PPS. This has been >> changed. The byte for the number of PPS has been forgotten. > >> 3. The earlier code also did not detect an error if the extradata ended >> directly after the last SPS in the SPS array (if any) although the >> number of PPS has to come afterwards. A check for this has been >> integrated into the general overread check. > > what if there is no pps afterwards and instead in stream? > could this change break such streams ? > This patch increases the strictness for exactly one scenario: If the extradata immediately ends after the SPS array, without the numOfPictureParameterSets byte (that has to be present). This is now considered invalid data, earlier code read into the padding and therefore concluded that the number of PPS is zero. If the byte is present and zero, then nothing changes: the stream will be playable if the PPS is available in-band. > >> 4. The earlier code also might overread when reading the size of the >> next unit. Given that this overread is not dangerous (the extradata is >> supposed to be padded), only a comment for it has been added; the error >> itself will be detected as part of the normal check for overreads. >> >> Signed-off-by: Andreas Rheinhardt <andreas.rheinha...@gmail.com> >> --- >> libavcodec/h264_mp4toannexb_bsf.c | 16 +++++++++------- >> 1 file changed, 9 insertions(+), 7 deletions(-) > > changes feel ok but this should be split as they are independant issues > Ok, will split into 1. + (2. + 3.) + 4.
- Andreas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
