[FFmpeg-devel] [PATCH] ffplay: more precise audio clock based on current time

Michael Niedermayer 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:
> http://www.youtube.com/watch?v=szoOsG9137U
> 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
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20110815/7417a9b1/attachment.asc>

More information about the ffmpeg-devel mailing list