[FFmpeg-devel] [patch 3/3] Make timing calculations less dependant on start_time being defined.

[Neil Brown]

On Friday August 24, michaelni at gmx.at wrote:
> > 
> > So maybe
> >   if (asf->packet_frag_timestamp == AV_NOPTS_VALUE)
> >       asf_st->pkt.pts = AV_NOPTS_VALUE;
> >   else
> >       asf_st->pkt.pts = asf->packet_frag_timestamp - asf->hdr.preroll;
> > 
> > ??
> 
> yes though id write
> 
> asf_st->pkt.pts = asf->packet_frag_timestamp;
> if(asf_st->pkt.pts != AV_NOPTS_VALUE)
>     asf_st->pkt.pts -= asf->hdr.preroll;
> 

:-)


> > So I could
> >    ffmpeg -ss 0:0:1.15  .... -async 1
> > 
> > And get a correctly decoded file, but that really shouldn't be needed.
> > 
> > So: would you accept this?
> 
> what about setting dts_delta_threshold to something small? (no iam not
> suggesting this as solution, just curious, it think it should fix this)

Yes, setting -dts_delta_threshold to 1 removes the leading black
silences, and gives my audio and video in sync.


Having reflected on this some more, I think a code problem is really
that start_time isn't being set properly.
ffmpeg clearly doesn't cope well with start_time being AV_NOPTS_VALUE
unless the first frame in the file has a pts of 0.
The MLT framework (used by kdenlive) also seem to handle this
situation poorly.

Maybe we should be reading the beginning of the stream and looking for
the pts in the first packet?

I note that 'utils.c' does this via av_estimate_timings_from_pts but
only for mpeg and mpegts.  I tried calling that if 'asf' as well, but
that didn't work - something got badly confused.

[asf @ 0x2b63e74d9780]ff asf bad header e1  at:9402
[asf @ 0x2b63e74d9780]invalid packet_length -511371426 at:9405
[asf @ 0x2b63e74d9780]freeing incomplete packet size 2437, new 4831

I guess it would need to be more careful about stepping over the file
header???


But for now, I'm happy if we can subtract preroll from pts.

Thanks.
NeilBrown