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.cadhal...@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/
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
