[FFmpeg-devel] [patch 3/3] Make timing calculations less dependant on start_time being defined.
Fri Aug 24 01:50:45 CEST 2007
On Thu, Aug 23, 2007 at 02:23:36PM +1000, Neil Brown wrote:
> On Thursday August 23, michaelni at gmx.at wrote:
> > > Index: libavformat/asf.c
> > > ===================================================================
> > > --- libavformat/asf.c (revision 10189)
> > > +++ libavformat/asf.c (working copy)
> > > @@ -793,7 +793,7 @@
> > > /* new packet */
> > > av_new_packet(&asf_st->pkt, asf->packet_obj_size);
> > > asf_st->seq = asf->packet_seq;
> > > - asf_st->pkt.pts = asf->packet_frag_timestamp;
> > > + asf_st->pkt.pts = asf->packet_frag_timestamp - asf->hdr.preroll;
> > > asf_st->pkt.stream_index = asf->stream_index;
> > 1.
> > asf.c does
> > asf->packet_frag_timestamp= AV_NOPTS_VALUE;
> > at some point, so your code might fail fatally as
> > AV_NOPTS_VALUE - asf->hdr.preroll is not valid
> So maybe
> if (asf->packet_frag_timestamp == AV_NOPTS_VALUE)
> asf_st->pkt.pts = AV_NOPTS_VALUE;
> 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;
> > 2.
> > the av_find_stream_info() and related code will buffer packets which
> > have no timestamp until the first timestamp and then correct the
> > previous packets before passing them to te user app
> > so ffmpeg.c should not see audio packets without timestmamps as you
> > described (see code related to first_dts for the stuff which fixes up
> > the initial timestamps)
> I looked more deeply. The audio packets do have time stamps. But
> do_audio_out and do_video_out in ffmpeg.c take different approaches to
> dealing with a difference between expected and actual timestamp.
> At the beginning we expect 0 and get 1579ms. do_video_out makes 44
> copies of the first frame. do_audio_out doesn't seem to do anything
> useful unless I set "-async 1". But then I get 1.5 seconds of nothing
> at the start of the clip, which shouldn't be there.
> 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)
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I hate to see young programmers poisoned by the kind of thinking
Ulrich Drepper puts forward since it is simply too narrow -- Roman Shaposhnik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel