On Sat, 2015-11-28 at 02:56 +0100, Marton Balint wrote: > Regression since 53f2ef2c4afb1d49a679dea9163cb0e4671f3117. > Fixes ticket #5017. > > Signed-off-by: Marton Balint <[email protected]> > --- > libavformat/mxfdec.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c > index 429f46a..926d2a3 100644 > --- a/libavformat/mxfdec.c > +++ b/libavformat/mxfdec.c > @@ -3181,6 +3181,16 @@ static int mxf_read_seek(AVFormatContext *s, int > stream_index, int64_t sample_ti > sample_time = FFMAX(sample_time, 0); > > if (t->fake_index) { > + /* The first frames may not be keyframes in presentation order, > so > + * we have to advance the target to be able to find the first > + * keyframe backwards... */ > + if (!(flags & AVSEEK_FLAG_ANY) && > + (flags & AVSEEK_FLAG_BACKWARD) && > + t->ptses[0] != AV_NOPTS_VALUE &&
Can the size of t->ptses ever be zero here? > + sample_time < t->ptses[0] && > + (t->fake_index[t->ptses[0]].flags & AVINDEX_KEYFRAME)) Do t->ptses always point inside t->fake_index? > + sample_time = t->ptses[0]; > + Should be OK otherwise, since it only affects seeking and fixes a regression. Ideally we should be doing something better for seeking, I think.. /Tomas
signature.asc
Description: This is a digitally signed message part
_______________________________________________ ffmpeg-devel mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
