[FFmpeg-devel] [PATCH] av_get_delay

[Nicolas George]

Le duodi 12 messidor, an CCXIX, Michael Niedermayer a écrit :
> you seem to missunderstand this somehow.
> when you have 2 streams, 2 muxers, one only video and one only audio
> and you want to sync them but the video muxer tells you as delay
> only 0seconds or 30seconds you wont get sync better than 30seconds and
> thats really not good for a slideshow of lets say pictures in a museum
> that are being commented.

I believe the crux of the problem is this: there are two different possible
meanings for the delay:

- The data that is being output now is the data that I wrote <delay> ago.

- If I write data now, it will be output in <delay>.

For PCM streams fed continuously, this is the same down to the duration of
one sample, which is usually less than the OS scheduler's accuracy.

But for video display, for example, the former is the time since the last
screen refresh, and the latter is the time until the next screen refresh.

The first one (let's call it "past delay") can be used in such a way:

	while (1) {
	    av_write_packet(s, packet);
	    pos += packet->size / bps; /* or maybe packet->duration */
	    past_delay = av_get_output_past_delay(s);
	    display("Current time is %f\n", rescale(pos - past_delay));
	}

It can also be used for A-V sync if you assume that the future delay of the
video output device is zero or negligible:

	if (audio_written - audio_past_delay >= next_frame.pts)
	    display_next_frame();

I suppose, but this is purely speculation, that the past delay is more easy
to get.

If only the past delay is known, synchronization can be achieved by control
engineering.

An useful information may be how MPlayer handles delay for the video output
system. Reimar can possibly enlighten us.

Regards,

-- 
  Nicolas George
-------------- 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/20110630/e822444d/attachment.asc>