Opened 10 years ago

Last modified 10 years ago

#3156 new defect

Laggy a/v sync catch up after seeking with ffplay

Reported by: Clément Bœsch Owned by:
Priority: normal Component: ffplay
Version: unspecified Keywords: ffplay seek
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description (last modified by Clément Bœsch)

$summary

☭ ./ffplay ~/samples/matrixbench_mpeg2.mpg
ffplay version N-58262-g0dd8e96 Copyright (c) 2003-2013 the FFmpeg developers
  built on Nov 19 2013 09:49:57 with gcc 4.8.2 (GCC)
  configuration: --enable-gpl --enable-libx264 --enable-libmp3lame --enable-x11grab --enable-libvorbis --samples=/home/ux/fate-samples --enable-libfreetype --enable-libvpx --cpu=native --cc='ccache cc'
  libavutil      52. 53.100 / 52. 53.100
  libavcodec     55. 43.101 / 55. 43.101
  libavformat    55. 21.100 / 55. 21.100
  libavdevice    55.  5.100 / 55.  5.100
  libavfilter     3. 91.100 /  3. 91.100
  libswscale      2.  5.101 /  2.  5.101
  libswresample   0. 17.104 /  0. 17.104
  libpostproc    52.  3.100 / 52.  3.100
[NULL @ 0x7f4494001720] start time is not set in estimate_timings_from_pts
[...]

After each seek, the video is laggy for about 1 sec.

It's not reproducible with any sample. Sample used available at http://samples.ffmpeg.org/benchmark/testsuite1/matrixbench_mpeg2.mpg

It doesn't appear to be a regression, and if it is, probably a very old one.

It's not reproducible with -an, hence the a/v sync catch up suggestion.

Change History (2)

comment:1 by Clément Bœsch, 10 years ago

Description: modified (diff)

comment:2 by Marton Balint, 10 years ago

It has always worked this way. Audio clock is the master sync source, so audio frames are never dropped, and video frame rate is halved until A-V sync is reached.

Note: See TracTickets for help on using tickets.