[FFmpeg-devel] Change 9963 introduces regression - start_time in asf.c
Mon Aug 13 14:16:57 CEST 2007
On Mon, Aug 13, 2007 at 07:12:26AM +1000, Neil Brown wrote:
> On Sunday August 12, Reimar.Doeffinger at stud.uni-karlsruhe.de wrote:
> > > The documentation says:
> > > decoding: pts of the first frame of the stream, in stream time
> > > base.
> > >
> > > and while I guess that is better than nothing, it isn't a lot better
> > > than nothing.
> > Well, what else to say? It has to be the pts that is associated with the
> > first packet that is returned when reading from this stream.
> But why would it ever be non-zero. That is what I don't get.
> The time stamp of the first frame in a stream, with-respect-to that
> stream: sounds like it has to be zero.
the first timestamp is what is stored in the file for the first packet
of the stream and that does (well should) conform to the respective spec
mpeg-ps/ts for example allow timestamps to start at arbitrary points or
to have pretty much arbitrary discontinuities (and they do in practice)
also the video or audio grab code will currently simply use the current
time as timestamp, that also normally doesnt start at 0 (unless you have
a time machine or play with the system clock)
> Or is it to allow different stream in one file to have different start
> points? That might make sense....
yes that too
> but then if there are two streams
> and they both have an undefined start point.... what would you do
the demuxer would use AV_NOPTS_VALUE
and lavf (av_find_stream_info() and the functions called by it should
fill in the start time if they run across the first packet in that stream
they dont currently IIRC but they should ...)
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
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel