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 )
$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 , 10 years ago
Description: | modified (diff) |
---|
comment:2 by , 10 years ago
Note:
See TracTickets
for help on using tickets.
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.