[FFmpeg-devel] [PATCH] Create separate pts fields for video (int64_t) and audio (double) in lavfi

[Michael Niedermayer]

On Fri, Sep 24, 2010 at 04:57:20PM -0700, S.N. Hemanth Meenakshisundaram wrote:
>  On 09/24/2010 04:42 PM, Michael Niedermayer wrote:
> > On Fri, Sep 24, 2010 at 03:22:38PM -0700, S.N. Hemanth Meenakshisundaram wrote:
> >> This creates separate pts fields for video and audio in the
> >> AVFilterBufferRef struct. Audio uses a double for storing pts in ffplay
> >> etc and the value can be a fraction. So it would be wrong to convert it
> >> to int64_t like in video. Alternatively, is it ok to store the video pts
> >> integer value as a double within lavfi?
> > i would prefer int64_t for both otherwise we risk issues with the regression
> > tests accross architectures
> > where is the problem with int64_t btw?
> > the demuxers all output integer timestamps ...
> >
> > [...]
> >
> 
> The problem is in ffplay.c : Before feeding audio data to lavfi, we call
> audio_decode_frame() which returns audio data and a pts as double.
> 
> The way the pts (and is->audio_clock) is updated inside
> audio_decode_frame() makes a non integer value possible:
> 
>             pts = is->audio_clock;
> 
>             *pts_ptr = pts;
> 
>             n = 2 * dec->channels;
> 
>             is->audio_clock += (double)data_size /
> 
>                 (double)(n * dec->sample_rate);
> 
> 
> Is it safe to ignore this and use a common int64_t pts for both audio
> and video?

yes but make sure that the timebase is precisse enough, 1/samplerate should
work (we might wish to rethink this at somepoint but for now this is more
than good enough for ffplay)

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

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100925/70cdbf74/attachment.pgp>