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

[Michael Niedermayer]

Hi

On Fri, Aug 24, 2007 at 09:38:38PM +1000, Neil Brown wrote:
> 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.

x11grab doesnt provide a AVInputFormat.read_timestamp() also it cannot
provide one or anything equivalent, you cant seek x11 to find the last
timestamp and thus duration ...


> 
> > > 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.

its very simple, av_find_stream_info() analyses a input file/stream and
buffers all packets which it had to read (so that theres no need to seek
back after av_find_stream_info() which with pipes would be impossible)

update_initial_timestamps() updates the timestamps of these buffered
packets in the case that the packets had no timestamp (that is libavformat
used the framerate / AVPacket.duration to set timestamps starting from a
arbitrary (=0) timestamt)

the first packet with a timestamp gets put in the buffer after 
update_initial_timestamps() is called thus if theres nothing in the buffer
the code to set start_time fails ...
solution seems to be to pass pkt->pts in addition to dts into
update_initial_timestamps() and then add an additional check to use that
if no packet in the buffer had a pts value

iam not sure if there is a simpler solution
doing it just after av_read_frame_intrnal() like i originally proposed wont
work if the initiakl packets have pts= AV_NOPTS_VALUE ...


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070824/a2dbb325/attachment.pgp>