Opened 4 years ago

Last modified 4 years ago

#3156 new defect

Laggy a/v sync catch up after seeking with ffplay

Reported by: ubitux 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 ubitux)

$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 Changed 4 years ago by ubitux

  • Description modified (diff)

comment:2 Changed 4 years ago by cus

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.