Hmm, finally got around to looking into this again and this still isn't
fixed. Just seeking a few times in ffplay can trigger this issue with the
clip linked in my original message:

http://storage.googleapis.com/dalecurtis-shared/buck480p30_na.mp4

./ffplay -v debug -drp 1 ~/Downloads/buck480p30_na.mp4
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fbce00008c0] invalid dts/pts combination
14583000
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fbce00008c0] invalid dts/pts combination
14586000
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fbce00008c0] found fragment index for track 1
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fbce00008c0] found fragment index entry for
track 1 and moof_offset 16686198
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fbce00008c0] found frag time 14589000, using
it for dts
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fbce00008c0] invalid dts/pts combination
14607000
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fbce00008c0] invalid dts/pts combination
14610000
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fbce00008c0] invalid dts/pts combination
14622000
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fbce00008c0] invalid dts/pts combination
14631000
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fbce00008c0] invalid dts/pts combination
14634000
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fbce00008c0] invalid dts/pts combination
14643000

Disabled sidx processing resolves this issue:

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 63f84be782..919475f12f 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -5497,7 +5497,7 @@ static const MOVParseTableEntry
mov_default_parse_table[] = {
 { MKTAG('a','l','a','c'), mov_read_alac }, /* alac specific atom */
 { MKTAG('a','v','c','C'), mov_read_glbl },
 { MKTAG('p','a','s','p'), mov_read_pasp },
-{ MKTAG('s','i','d','x'), mov_read_sidx },
+// { MKTAG('s','i','d','x'), mov_read_sidx },

Rodger, are you able to still look into this?

- dale

On Fri, Feb 12, 2016 at 2:21 AM, Rodger Combs <rodger.co...@gmail.com>
wrote:

> This issue is fixed by this patch, but I'm unsure of possible implications
> on other files. It passes FATE, at least.
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 149e3b4..c5e0a1e 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -3609,7 +3609,7 @@ static int mov_read_trun(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
>                  }
>                  av_log(c->fc, AV_LOG_DEBUG, "calculated into dts
> %"PRId64"\n", dts);
>              } else {
> -                dts = frag->time;
> +                dts = frag->time - sc->time_offset;
>                  av_log(c->fc, AV_LOG_DEBUG, "found frag time %"PRId64
>                          ", using it for dts\n", dts);
>              }
>
>
> > On Jan 15, 2016, at 16:57, Michael Niedermayer <mich...@niedermayer.cc>
> wrote:
> >
> > On Fri, Jan 15, 2016 at 10:24:43PM +0000, Dan Sanders wrote:
> >> Michael, I wanted to check if you have you looked into this playback
> issue,
> >> or were planning to?
> >
> > i didnt look into it, i had thought rodger would look into it as it
> > was his patch ...
> >
> > rodger, did you look into this ?
> >
> > [...]
> > --
> > Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > Rewriting code that is poorly written but fully understood is good.
> > Rewriting code that one doesnt understand is a sign that one is less
> smart
> > then the original author, trying to rewrite it will not make it better.
>
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to