[FFmpeg-devel] [PATCH] ffplay: more precise audio clock based on current time
michaelni at gmx.at
Mon Aug 15 04:10:05 CEST 2011
On Sun, Aug 14, 2011 at 11:32:08PM +0200, Marton Balint wrote:
> On Sun, 14 Aug 2011, Michael Niedermayer wrote:
>> On Sun, Aug 14, 2011 at 08:21:25PM +0200, Marton Balint wrote:
>>> Since SDL has no audio buffer fullness info, one can get a much precise audio
>>> clock based on the last time of the audio callback and the elapsed time since.
>>> To achieve this I introduced the audio_current_pts and audio_current_pts_drift
>>> variables (similar to video_current_pts and video_current_pts_drift) and
>>> calculate them in the end of the audio callback, when VideoState->audio_clock
>>> is already updated. The reference time I use is from the start of the audio
>>> callback, because this way the amount of time used for audio decoding is not
>>> interfereing with calculation.
>>> I also replaced the audio_write_get_buf_size function with a calculated
>>> variable because when the audio frame decoding is in progress audio_buf_size
>>> and audio_buf_index are not stable, so using them from other threads are not a
>>> good idea.
>>> ffplay.c | 34 +++++++++++++++-------------------
>>> 1 files changed, 15 insertions(+), 19 deletions(-)
>> Is it possible to test this somehow to see the improvment?
> Yes, it is. When I tested the patch, I used this youtube video for
> checking A-V sync:
> For me it felt better, I know, it is not hard evidence.
> But here is another test I just made:
> I started the old ffplay version, the new ffplay version, and mplayer
> simultaneously. Let's assume that mplayer has the most precise A-V sync
> (because it has audio buffer fullness info).
> After starting the video players, I had to make the audio streams
> synchronized. The two ffplays were usually in sync from the start, I only
> had to tweak mplayer (I increased and decreased the speed until I heard
> only one clean beep per second, so the audio of the three players were
> finally in sync).
> After that I made some pictures of my screen with my mobile phone, and
> checked the shown video frame in the three players.
> It turned out, that the unpatched ffplay is usually two frames ahead of
> mplayer, the patched ffplay is only one frame ahead.
> So the patch really is an improvement.
patch applied & pushed. thanks
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel