[FFmpeg-devel] [PATCH 6/6] lavf: count skipped samples for initial timestamps.

[Michael Niedermayer]

On Thu, Jul 19, 2012 at 04:31:42PM +0200, Nicolas George wrote:
> Le primidi 1er thermidor, an CCXX, Michael Niedermayer a écrit :
> > does this affect stream copy ?
> 
> Yes:
> 
> [PACKET]               [PACKET]
> pts=0 (0.000000)       pts=-25 (-0.025000)
> dts=0 (0.000000)       dts=-25 (-0.025000)

> dur=N/A (N/A)          dur=26 (0.026000)

do you know why this changes ?
its not wrong but unexpected ...


> [PACKET]               [PACKET]
> pts=26 (0.026000)      pts=1 (0.001000)
> dts=26 (0.026000)      dts=1 (0.001000)
> dur=26 (0.026000)      dur=26 (0.026000)
> [PACKET]               [PACKET]
> pts=52 (0.052000)      pts=27 (0.027000)
> dts=52 (0.052000)      dts=27 (0.027000)
> dur=26 (0.026000)      dur=26 (0.026000)
> [PACKET]               [PACKET]
> pts=78 (0.078000)      pts=53 (0.053000)
> dts=78 (0.078000)      dts=53 (0.053000)
> dur=26 (0.026000)      dur=26 (0.026000)
> 
> I edited the output of ffprobe to make it more readable. Left it the current
> code, mp3 remuxed into Matroska, time_base=1/1000; right is the modified
> code.
> 
> > i mean when stream copying something with skiped samples the
> > underlaying packet timestamps have to stay as they are
> 
> I completely agree with that, but my patch addresses a case where there are
> no underlying packet timestamps, lavf is completely inventing them by
> deciding that the first packet starts at 0 and then adding the durations.
> This patch only changes the position of the arbitrary 0.

That should be ok, i was affraid that the change might leak through
when there are timestamps later but from a second look i cant see
how this could happen unless they come "too late" in which case the
initial ones are arbitrary anyway


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
            conveniently.
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120719/1aa95613/attachment.asc>