On 12/28/2011 06:07 PM, Måns Rullgård wrote: > "Ronald S. Bultje" <[email protected]> writes: > >> Hi, >> >> 2011/12/28 Måns Rullgård <[email protected]>: >>> Derek Buitenhuis <[email protected]> writes: >>> >>>> From: Stefano Sabatini <[email protected]> >>>> >>>> Prevent error condition in case sample_rate is unset or set to a negative >>>> value. In particular, fix divide-by-zero error occurring in ffmpeg due to >>>> sample_rate set to 0 in output_packet(), in code: >>>> >>>> ist->next_pts += ((int64_t)AV_TIME_BASE * >>>> ist->st->codec->frame_size) / >>>> ist->st->codec->sample_rate; >>>> --- >>>> libavformat/rawdec.c | 6 ++++++ >>>> 1 files changed, 6 insertions(+), 0 deletions(-) >>>> >>>> diff --git a/libavformat/rawdec.c b/libavformat/rawdec.c >>>> index 33a0447..6be48c5 100644 >>>> --- a/libavformat/rawdec.c >>>> +++ b/libavformat/rawdec.c >>>> @@ -57,6 +57,12 @@ int ff_raw_read_header(AVFormatContext *s, >>>> AVFormatParameters *ap) >>>> >>>> if (s1 && s1->sample_rate) >>>> st->codec->sample_rate = s1->sample_rate; >>>> + if (st->codec->sample_rate <= 0) { >>>> + av_log(s, AV_LOG_ERROR, "Invalid sample rate %d >>>> specified\n", >>>> + st->codec->sample_rate); >>>> + return AVERROR(EINVAL); >>>> + } >>>> + >>>> if (s1 && s1->channels) >>>> st->codec->channels = s1->channels; >>>> >>>> -- >>> >>> Looks like it belongs in a more central place to avoid scattering such >>> checks across all demuxers. Hasn't this come up before? >> >> A check was placed in av_set_pts_info() which helps for callers that >> do av_set_pts_info(1, samplerate);. It doesn't help callers that do >> not do this. > > Does that not mean that the proper fix is to use this function, not > littering more such checks all over the place?
That function is already used in this case. The patch doesn't fix anything related to time_base. It fixes cases where the user divides by sample_rate without checking if it's zero. We could possibly add a check to avformat_find_stream_info(). Otherwise I think it's on the user to validate it before using it. -Justin _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
