[MPlayer-dev-eng] libmpeg2 and lavc don't agree on PTS values

Michael Niedermayer michaelni at gmx.at
Mon Nov 27 13:50:09 CET 2006


Hi

On Mon, Nov 27, 2006 at 02:07:13PM +0200, Uoti Urpala wrote:
> On Mon, 2006-11-27 at 12:26 +0100, Michael Niedermayer wrote:
> > maybe -correct-pts should set AVFMT_FLAG_GENPTS
> > ?
> 
> With that it seems to work with the lavf mpeg demuxer. Is there a reason
> not to set that flag by default in demux_lavf.c?

yes, if a parser/framer is used it will need an extra memcpy
aviding this is possible but VERY tricky (patch welcome if you find a clean
solution)

the problem with the memcpy is that tha AVParser will either return a pointer
into the source packet (=zero memcpy parsing case) or append the contents
into its internal buffer and return a pointer to that, either way the
packet must be allocated & memcpied if its not "consumed" "immedeatly"

for the gen pts case we need to buffer a few packets ahead so a malloc&memcpy
becomes needed, if the parser would alloc a new packet instead of reusing its
internal buffer then this would be needed rarer but the parser generally
doesnt know how large the buffer needs to be during the first memcpies into
it
and for the zero memcpy case where the parser returns a pointer into the
source packet things get somewat ugly, you need to keep track how many packets
reference a allocated block of memory but the problem is that these packets
could end up being freed from different threads ...

so i think the memcpy for the case where pts != dts && pts not known && parser
is the lesser evil 


furthermore the genpts adds a few packets delay (maybe bad for low delay
network stuff at low packet rates)

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

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is



More information about the MPlayer-dev-eng mailing list