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, but I am curious as to where you have seen examples of negative
edit rates. (I have found examples in mxf code where signed and unsigned
have been muddled leading to invalid figures and I am wondering if this
is another)
--
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
