Skip to content

F
Ffmpeg

小白菜888 / Ffmpeg

通知 3
Star 0
Fork 0
F
Ffmpeg

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 05 7月, 2020 3 次提交
    • A
      avformat/smacker: Check audio frame size · 2f687bc8
      由 Andreas Rheinhardt 提交于 
      The first four bytes of smacker audio are supposed to contain the number
of samples, so treat audio frames smaller than that as invalid.
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      2f687bc8
    • A
      avformat/smacker: Avoid potential inifinite loop on error · 02bbb370
      由 Andreas Rheinhardt 提交于 
      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: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      02bbb370
    • A
      avformat/smacker: Don't increase packet counter prematurely · 5fcc49e0
      由 Andreas Rheinhardt 提交于 
      The Smacker demuxer buffers audio packets before it outputs them, but it
increments the counter of buffered packets prematurely: If allocating
the audio buffer fails, an error (most likely AVERROR(ENOMEM)) is returned.
If the caller decides to call av_read_frame() again, the next call will
take the codepath for returning already buffered audio packets and it
will fail (because the buffer that ought to be allocated isn't) without
decrementing the number of supposedly buffered audio packets (it doesn't
matter whether there would be enough memory available in subsequent calls).
Depending on the caller's behaviour this is potentially an infinite loop.

This commit fixes this by only incrementing the number of buffered audio
packets after having successfully read them and unconditionally reducing
said number when outputting one of them. It also changes the semantics
of the curstream variable: It is now the number of currently buffered
audio packets whereas it used to be the index of the last audio stream
to be read. (Index refers to the index in the array of buffers, not to
the stream index.)
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
      5fcc49e0
  3. 04 7月, 2020 5 次提交
  5. 03 7月, 2020 4 次提交
  7. 02 7月, 2020 20 次提交
  9. 01 7月, 2020 8 次提交