[FFmpeg-devel] [patch 3/3] Make timing calculations less dependant on start_time being defined.
Fri Aug 24 13:38:38 CEST 2007
On Friday August 24, michaelni at gmx.at wrote:
> 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
More information about the ffmpeg-devel