aboutsummaryrefslogtreecommitdiffstats
path: root/libavcodec/h261.c
diff options
context:
space:
mode:
authorAndreas Rheinhardt <andreas.rheinhardt@gmail.com>2020-06-23 13:34:02 +0200
committerAndreas Rheinhardt <andreas.rheinhardt@gmail.com>2020-07-04 19:19:34 +0200
commit02bbb3700670cc0bcf2c267ae48b21b0a9d7b599 (patch)
tree0cc6c66b9724ac1b90de6aa2b5dd6b6e55f7e6e7 /libavcodec/h261.c
parent5fcc49e0d18a78a668a0f24a9344fab4ce648138 (diff)
downloadffmpeg-02bbb3700670cc0bcf2c267ae48b21b0a9d7b599.tar.gz
avformat/smacker: Avoid potential inifinite loop on error
When reading a new frame, the Smacker demuxer seeks to the next frame position where it excepts the next frame; then it (potentially) reads the palette, the audio packets associated with the frame and finally the actual video frame. It is only at the end that the frame counter as well as the position where the next frame is expected get updated. This has a downside: If e.g. invalid data is encountered when reading the palette, the demuxer returns immediately (with an error) and if the caller calls av_read_frame again, the demuxer seeks to the position where it already was, reads the very same palette data again and therefore will return an error again. If the caller calls av_read_frame repeatedly (say, until a packet is received or until EOF), this meight become an infinite loop. This could also happen if e.g. the size of one of the audio frames was invalid or if the frame size was gigantic. This commit changes this by skipping a frame if it turns out to be invalid or an error happens otherwise. This ensures that EOF will be returned eventually in the above scenario. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Diffstat (limited to 'libavcodec/h261.c')
0 files changed, 0 insertions, 0 deletions