[Ffmpeg-devel] Re: [RFC] Improvement for the odd timestamp generation when parser is in use.

Michael Niedermayer michaelni
Mon Mar 19 22:05:52 CET 2007


On Mon, Mar 19, 2007 at 05:25:04PM +0000, elupus wrote:
> Michael Niedermayer <michaelni <at> gmx.at> writes:
> > 
> > Hi
> > 
> > > 
> > > The best way i can see to handle this is to make parser always output the 
> > > timestamp of the packet the current frame started in. (currently it only 
> > > does this if the demux packet that resulted in previous frame had a 
> > > timestamp and it's the first time we use data from it ). This would result 
> > > in multiple packets with the same timestamps, wich might not be the best, 
> > > but it would atleast be consistant.
> > 
> > the parser behavior is based on exact handling of mpeg-ps/ts timestamps
> > what you suggest would break that to support invalid ac3 streams in avi
> > slightly better, sorry but this is not a good tradeoff, avi does not
> > allow to chop up frames arbitrarily ...
> I can accept that avi isn't supposed to do this, but isn't the whole point of
> parser to handle arbitrarily chopped packets? 


> And in what way is only providing
> a timestamp for a frame if the packet that completed last frame had a timestamp
> a good idea? The point where the new frame starts in that packet doesn't need to
> be anywhere near the beginning of that packet, and thus the timestamp is
> probably very much off, or is that not an issue for mpeg-ps/ts?

what the parser does is exactly correct for mpeg-ps/ts, any +-1 change to the
timestamps or any duplicated timestamps would be wrong

so any change to the timestams must be limited to the avi case, or maybe
other similarely broken cases too ...

> > > 
> > > Now if the above way is acceptable, by making parser present the number of 
> > > bytes after the timestamp that was given, a player could atleast for cbr 
> > > streams correct the timestamp of the demux packet. The correction could 
> > > even be done in avformat by default, but that might not be good in the case 
> > > of stream copy.
> > 
> > lavf should always output timestamps as good as it can, so any workaround for
> > these avi-audio streams should produce proper timestamps for each frame
> > not leave that to the user app
> > 
> > [...]
> Allright, so I assume that means it is okey for lavf to try to construct
> timestamps based on bitrate or packet duration if available? If it is then the
> current situation could probably be improved by allowing it to generate dts
> values based on how far after timestamp given it is, whenever parser can give a
> timestamp that is.
> That would only require parser to output byte offset after the timestamp at the
> same time as it sets the dts/pts values, should be a very minor change and won't
> change the semantics on when to generate a timestamp, thus not really breaking
> anything.
> Should one use the avformat bitrate value as bitrate in that case, or the
> average bitrate of last packet based on it's duration and size?

id say add a time_per_byte variable to AVStream which contains the amount
of time to add to a timestamp per byte, the default of that would be 0
the avi demuxer then could set it to some bitrate based value ...

lavf or the parser then would change the timstamps depening on the distance
in bytes between frame start and packet start and this varable ...

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070319/44bf1da1/attachment.pgp>

More information about the ffmpeg-devel mailing list