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

Michael Niedermayer michaelni
Mon Mar 19 03:40:28 CET 2007


On Mon, Mar 19, 2007 at 01:47:29AM +0100, elupus wrote:
> Hi,
> I noticed some odd behavior with libavformat when AVParser is used to make 
> complete frames. Timestamps of output packets get's very jumpy and can't 
> easily be attributed to the original packet they came from.
> This post ended up a way bit longer than I expected so if you are only 
> interested in the proposed change to avformat/parser is to always output 
> the timestamp of the packet a frame started in, and provide a byteoffset 
> from that timestamp where frame starts. so player (or avformat if that is 
> ok to do internally) can correct the timestamp atleast for cbr streams.
> It's abit hard to explain what is going on so i'll try it using an example.
> Assume we have a cbr stream wich has a timebase set which results in 
> pts/dts values actually can be interpreted as what byte in the stream we 
> are at (ac3 in avi does this for example and is where i found the issue). 
> Now assume each packet comming out of the demuxer is of 10 bytes (or 
> duration 10 as our timebase equates that), however each full frame that 
> parser will find is of 6 bytes. The assumptions comes from a similar 
> situation with ac3 in avi where ech avi packet was of about 23xx bytes and 
> each ac3 frame of 17xx something bytes, don't remember the exact figures.
> This is the timestamps we then will get out. (best view with fixed font 
> width)
> pk1  i_size: 10  i_dts: 0   o_size: 6  o_dts: -   o_adts: -   actual: 0
>     i_size: 4   i_dts: -   o_size: -  o_dts: -   o_adts: -   actual:
> pk2  i_size: 10  i_dts: 10  o_size: 6  o_dts: 0   o_adts: 0   actual: 6
>     i_size: 8   i_dts: -   o_size: 6  o_dts: 10  o_adts: 10  actual: 12
>     i_size: 2   i_dts: -   o_size: -  o_dts: -   o_adts: -   actual:
> pk3  i_size: 10  i_dts: 20  o_size: 6  o_dts: -   o_adts: 16  actual: 18
>     i_size: 6   i_dts: -   o_size: 6  o_dts: 20  o_adts: 20  actual: 24
> pk4  i_size: 10  i_dts: 30  o_size: 6  o_dts: -   o_adts: 26  actual: 30
>     i_size: 4   i_dts: -   o_size: -  o_dts: -   o_adts: -   actual:
> pk5  i_size: 10  i_dts: 40  o_size: 6  o_dts: 30  o_adts: 30  actual: 36
>     i_size: 4   i_dts: -   o_size: -  o_dts: -   o_adts: -   actual: -
> pk6  i_size: 10  i_dts: 50  o_size: 6  o_dts: 40  o_adts: 40  actual: 42
> i_size: data from demuxer (or what is left after previous output)
> i_dts: timestamp on packet comming from demuxer (reset to nopts after 
> anything has been consumd)
> o_size: packet out from parser
> o_dts: timestamp out from parser
> o_adts: timestamp out from libavformat (cur_dts + duration, if parser 
> didn't give anything)
> So, we get timestamps -,0,10,16,20,26,30,40 out from the demuxer. This give 
> the following dts differences. -,10,6,4,6,4,10. where the 16 and 26 
> timestamps are invented timestamps based on previous frames timestamp + 
> duration (cur_dts). This makes is rather hard to know when to trust 
> timestamps comming out from libavformat.
> Now, if framesizes are small, this isn't a huge deal, as the absolute 
> timestamp error isn't that large. However, in the case of AC3 or DTS 
> frames, that are to be directly passed to a rendering device, there is 
> trouble, as you never know what timestamp to use to sync to.
> 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 ...

> 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

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The worst form of inequality is to try to make unequal things equal.
-- Aristotle
-------------- 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/956ae3e7/attachment.pgp>

More information about the ffmpeg-devel mailing list