[FFmpeg-devel] [PATCH] ffplay: more precise audio clock based on current time
cus at passwd.hu
Sun Aug 14 23:32:08 CEST 2011
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.
> also has this been tested with various -sync ?
I tested the modes and they seemed fine. When using -sync video, the A-V
difference was usually below 0.01 for the patched version, while for the
unpatched version the A-V diff was alternating between 0.01 and 0.02. So
the audio clock seems more reliable with the patch.
More information about the ffmpeg-devel