[FFmpeg-devel] [PATCH 2/2] avformat/wavdec: check sample count validity

Ganesh Ajjanagadde gajjanag at mit.edu
Fri Jul 31 00:11:51 CEST 2015


On Thu, Jul 30, 2015 at 6:02 PM, Michael Niedermayer
<michael at niedermayer.cc> wrote:
> On Thu, Jul 30, 2015 at 11:46:43PM +0200, Michael Niedermayer wrote:
>> On Thu, Jul 30, 2015 at 04:06:54PM -0400, Ganesh Ajjanagadde wrote:
>> > Can be used to fix Ticket4577
>> >
>> > Signed-off-by: Ganesh Ajjanagadde <gajjanagadde at gmail.com>
>> > ---
>> >  libavformat/wavdec.c | 9 +++++++--
>> >  1 file changed, 7 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c
>> > index 1803b5c..ba70da6 100644
>> > --- a/libavformat/wavdec.c
>> > +++ b/libavformat/wavdec.c
>> > @@ -434,8 +434,13 @@ break_loop:
>> >          data_size = 0;
>> >      }
>> >
>> > -    if (   data_size > 0 && sample_count && st->codec->channels
>> > -        && (data_size << 3) / sample_count / st->codec->channels > st->codec->bits_per_coded_sample) {
>> > +    if (st->codec->channels && sample_count > (INT64_MAX/st->codec->channels)) {
>> > +        av_log(s, AV_LOG_WARNING, "Sample count %"PRId64" is too large\n", sample_count);
>> > +        sample_count = 0;
>> > +    }
>> > +
>>
>> > +    if (data_size > 0 && st->codec->bit_rate > 0 && sample_count && st->codec->sample_rate
>> > +        && (data_size << 3) / st->codec->bit_rate > (sample_count * st->codec->channels) / (st->codec->sample_rate)) {
>> >          av_log(s, AV_LOG_WARNING, "ignoring wrong sample_count %"PRId64"\n", sample_count);
>> >          sample_count = 0;
>>
>> this condition triggers even with many ffmpeg generated files
>> (you can add a abort() and run "make fate" to see the failures)
>>
>> To write a heuristic like this its needed to test it against a few
>> files first.
>> Using a hard == or >= check on the bitrate from the header will not
>> work. bitrates can vary throughout the file and the header value may
>> or may ot be the average.
>> Using the bitrate in a test would be more complex
>> i should have been more clear but what i suggested previously where
>> more a bunch of ideas that a list of things that i tested and that
>> will work without adjustment
>>
>> using the G729 specific bit_rate limits is likely going to work and
>> would be easy to do
>> but is not the most generic solution.
>
> or another way that should work for this file but might not work
> for other is
> if (data_size >= sample_count && "is a codec that never can reach a
>     bitrate of 8bit per sample")
>
> or data_size >= sample_count && G729
>
> 8...]

Thanks a lot for your patience. Dealing with these kinds of things is
much harder than I anticipated in my naivety.
If only specs could be followed more tightly; but then again specs
have many bugs/quirks of their own.
I think I will go with a G.729 specific hack (on the lines of your
second point above),
unless people object.
Hopefully we won't run into more of these abnormal files; if we do we
will need to find a cleaner solution.

>
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I have often repented speaking, but never of holding my tongue.
> -- Xenocrates
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


More information about the ffmpeg-devel mailing list