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

Neil Brown neilb
Fri Aug 24 13:38:38 CEST 2007

On Friday August 24, michaelni at gmx.at wrote:
> Hi
> On Fri, Aug 24, 2007 at 12:31:13PM +0200, Michael Niedermayer wrote:
> > but none of this is really needed for solving the start_time issue its
> > needed for finding a accurate duration though if none is provided by
> > the file header ... actually i dont know if there are many cases where
> > thats the case

One case that I am aware of (where the duration is not in the header)
is when you x11grab to an mpeg.

> > to find the start_time simply setting it if its unknown from the
> > pkt.pts after the call to av_read_frame_internal() in av_find_stream_info()
> > should do the trick ...
> acually iam wrong ...
> we already have code to do the above and even at a more correct place
> that is in update_initial_timestamps()
> iam wondering why the:
> if(st->start_time == AV_NOPTS_VALUE && pktl->pkt.pts != AV_NOPTS_VALUE)
>     st->start_time= pktl->pkt.pts;
> in there fails ...

It doesn't fail.  We just never get there.
For my file:
  The first call to update_initial_timestamps is for stream 0
      st->first_dts == AV_NOPTS_VALUE
      dts == 1579  (the same as preroll)
      pktl == NULL

   so ->first_dts gets set, but no packet is found to set start_time
   from.  Future calls for stream 0 exit immediately because first_dts
   is now set.

   The second call is for stream 1.
      first_dts and dts are the same as for stream 0, but this time
      there is one packet in pktl.
      However that packet is for stream 0, so again, start_time does
      not get set.

I'm having a hard time understanding the point of some of (well... all
of) the code in update_initial_timestamps.
I tried hacking it so that it would not give up if first_dts were set,
and thus have some chance of setting start_time.
However start_time got set to 3158 as the line following the //FIXME
effectively doubled pkt.pts before that value was assigned to

Very strange....


More information about the ffmpeg-devel mailing list