[FFmpeg-devel] [PATCH] Create separate pts fields for video (int64_t) and audio (double) in lavfi
Sat Sep 25 02:05:25 CEST 2010
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel