On Mon, 7 Dec 2015, Tomas Härdin wrote:
On Sat, 2015-11-28 at 02:56 +0100, Marton Balint wrote:
Regression since 53f2ef2c4afb1d49a679dea9163cb0e4671f3117.
Fixes ticket #5017.
Signed-off-by: Marton Balint <c...@passwd.hu>
---
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?
No, "paranoid check" in mxf_compute_ptses_fake_index should ensure that.
+ sample_time < t->ptses[0] &&
+ (t->fake_index[t->ptses[0]].flags & AVINDEX_KEYFRAME))
Do t->ptses always point inside t->fake_index?
Yes, if it is not AV_NOPTS_VALUE, that is made sure when setting the
ptses in mxf_compute_fake_index.
+ sample_time = t->ptses[0];
+
Should be OK otherwise, since it only affects seeking and fixes a
regression.
Ok, applied, thanks.
Ideally we should be doing something better for seeking, I
think..
Well, yes...
Regards,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
