Carl Eugen Hoyos ceho...@rainbow.studorg.tuwien.ac.at added the comment:
Fixed in r26309.
--
status: open - closed
substatus: analyzed - fixed
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2502
Justin Ruggles justin.rugg...@gmail.com added the comment:
The heart of the issue seems to be that voc_get_packet() changes the codec_id
when reading each packet based on input stream data. If a file is damaged, a
random value will most likely make it CODEC_ID_NONE since there are only 8 valid
Justin Ruggles justin.rugg...@gmail.com added the comment:
change status
--
substatus: open - analyzed
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2502
Carl Eugen Hoyos ceho...@rainbow.studorg.tuwien.ac.at added the comment:
First 200kb moved to /samples/ffmpeg-bugs/roundup/issue2502.
--
priority: normal - important
FFmpeg issue tracker iss...@roundup.ffmpeg.org
New submission from Daniel Kang daniel.d.k...@gmail.com:
ffmpeg crashes with a sample_size of 0. n is then calculated by: n =
avctx-channels * sample_size. When buf_size % n is taken, a SIGPE is raised.
The patch attached fixes this by adding a check for n=0.
The pcm audio is contained in a c93
Daniel Kang daniel.d.k...@gmail.com added the comment:
I have uploaded a sample to /MPlayer/incoming/pcm_mod_by_zero_issue2502.
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2502
