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

[elupus]

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?

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

/Joakim