On 21/11/14 12:52, Vittorio Giovara wrote:
> On Sun, Nov 16, 2014 at 11:58 PM, Luca Barbato <[email protected]> wrote:
>> On 17/11/14 00:22, Vittorio Giovara wrote:
>>> Do not write negative values in CodecDelay as the embl accepts only
>>> unsigned integers.
>>>
>>> CC: [email protected]
>>> Bug-Id: CID 1238790
>>> ---
>>>  libavformat/matroskaenc.c | 11 +++++++----
>>>  1 file changed, 7 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
>>> index 4ec474d..6571de1 100644
>>> --- a/libavformat/matroskaenc.c
>>> +++ b/libavformat/matroskaenc.c
>>> @@ -767,14 +767,17 @@ static int mkv_write_track(AVFormatContext *s, 
>>> MatroskaMuxContext *mkv,
>>>          put_ebml_uint(pb, MATROSKA_ID_TRACKFLAGDEFAULT, !!(st->disposition 
>>> & AV_DISPOSITION_DEFAULT));
>>>
>>>      if (codec->codec_type == AVMEDIA_TYPE_AUDIO && codec->initial_padding) 
>>> {
>>> +        int delay = av_rescale_q(codec->initial_padding,
>>> +                                 (AVRational) { 1, codec->sample_rate },
>>> +                                 (AVRational) { 1, 1000000000 });
>>> +        if (delay < 0)
>>> +            return AVERROR_INVALIDDATA;
>>
>>
>> Can we really have negative padding? I'd check it outside the muxer if
>> possible.
> 
> We can if codec->sample_rate is borked.

We have a check for it already I think.

> I think coverity is complaining that the put_embl is unsigned, while
> av_rescale_q may return a negative value.

If initial_padding can't be less than 0 then it is a false positive.

lu
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to