[FFmpeg-devel] [PATCH] mxfdec: check edit_rate also for physical_track

[Andreas Cadhalpun]

On 16.11.2015 09:02, tim nicholson wrote:
> On 15/11/15 18:07, Andreas Cadhalpun wrote:
>> Previously only the edit_rate of material_track was checked.
>> If it's negative, it causes assertion failures in av_rescale_rnd.
>>
>> Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun at googlemail.com>
>> ---
>>  libavformat/mxfdec.c | 10 ++++++++++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
>> index 99c8fed..429f46a 100644
>> --- a/libavformat/mxfdec.c
>> +++ b/libavformat/mxfdec.c
>> @@ -1776,6 +1776,16 @@ static int mxf_parse_physical_source_package(MXFContext *mxf, MXFTrack *source_t
>>                  continue;
>>              }
>>  
>> +        if (physical_track->edit_rate.num <= 0 ||
>> +            physical_track->edit_rate.den <= 0) {
>> +            av_log(mxf->fc, AV_LOG_WARNING,
>> +                   "Invalid edit rate (%d/%d) found on structural"
>> +                   " component #%d, defaulting to 25/1\n",
>> +                   physical_track->edit_rate.num,
>> +                   physical_track->edit_rate.den, i);
>> +            physical_track->edit_rate = (AVRational){25, 1};
>> +        }
>> +
>>              for (k = 0; k < physical_track->sequence->structural_components_count; k++) {
>>                  if (!(mxf_tc = mxf_resolve_timecode_component(mxf, &physical_track->sequence->structural_components_refs[k])))
>>                      continue;
>>
> 
> LGTM,

Pushed.

> but I am curious as to where you have seen examples of negative
> edit rates.

I've fuzzed with afl [1] and noticed the assertion failures.

Best regards,
Andreas

1: http://lcamtuf.coredump.cx/afl/