Opened 11 years ago
Closed 11 years ago
#2446 closed defect (fixed)
ffplay frame drop playback broken (regression)
Reported by: | Clément Bœsch | Owned by: | Marton Balint |
---|---|---|---|
Priority: | important | Component: | ffplay |
Version: | git-master | Keywords: | framedrop regression |
Cc: | cus@passwd.hu | Blocked By: | |
Blocking: | Reproduced by developer: | yes | |
Analyzed by developer: | yes |
Description
After de81d8da, ffplay -f lavfi mandelbrot doesn't play anymore here.
☭ ./ffplay -f lavfi mandelbrot ffplay version N-51656-g1adf54d Copyright (c) 2003-2013 the FFmpeg developers built on Apr 8 2013 01:34:48 with gcc 4.8.0 (GCC) configuration: --enable-gpl --enable-version3 --enable-fontconfig --enable-libfreetype --enable-libmp3lame --enable-libvorbis --enable-libxvid --enable-libx264 --enable-libvpx --enable-libtheora --enable-x11grab --enable-libopenjpeg --enable-libass --enable-libmodplug --enable-libv4l2 --cc=colorgcc --samples=/home/ubitux/fate-samples --prefix=/tmp/ffinstall --disable-runtime-cpudetect --enable-libcelt --enable-libopencv --enable-frei0r --enable-libcaca --enable-libiec61883 --enable-libopencore-amrwb --enable-libopencore-amrnb --enable-libopus --enable-libpulse --enable-libspeex libavutil 52. 25.100 / 52. 25.100 libavcodec 55. 2.100 / 55. 2.100 libavformat 55. 1.100 / 55. 1.100 libavdevice 55. 0.100 / 55. 0.100 libavfilter 3. 49.100 / 3. 49.100 libswscale 2. 2.100 / 2. 2.100 libswresample 0. 17.102 / 0. 17.102 libpostproc 52. 2.100 / 52. 2.100 Input #0, lavfi, from 'mandelbrot':0KB vq= 0KB sq= 0B f=0/0 Duration: N/A, start: 0.000000, bitrate: N/A Stream #0:0: Video: rawvideo (RGBA / 0x41424752), rgba, 640x480 [SAR 1:1 DAR 4:3], 25 tbr, 25 tbn, 25 tbc 4.01 A-V: 0.000 fd= 43 aq= 0KB vq= 0KB sq= 0B f=0/0
Note that a slowdown introduced in 0d6e5a17 made mandelbrot frame drop here with my configuration. And that frame-dropped playback got broke (freezed video) after de81d8da.
Change History (7)
comment:1 by , 11 years ago
Keywords: | playback removed |
---|---|
Priority: | normal → important |
comment:2 by , 11 years ago
comment:3 by , 11 years ago
Cc: | added |
---|
This seems like a bug and a regression, but it's not necessarily one.
By default, if ffplay is playing video without audio, it uses as external clock as a sync source. This basically means that video playback is synced to your PC clock and this ensures that video is played in realtime and with frame drops if displaying a frame or filtering a frame would take too much time.
In this case reading from the source is what's cannot be done in real time. FFplay early framedrop code drops the frames before passing them to the filter chain if the read frame's timestamp is late at the time of reading it, and that is always the case if the your source cannot be read in realtime.
Actually in this case there would be no point in dropping any of the frames, because by the time you get the next frame you will be more late than the last time. Syncing to external clock simply cannot be done.
A workaround for this is to use the -sync video paramter when playing the file.
comment:4 by , 11 years ago
Yes it works with -sync video, as well as -noframedrop. Though, with the default behaviour (framedrop then), it is expected from the player not to drop the frames when the decoding is slow, but just when the rendering is, no? Whatever time it takes to decode, maybe a forced minimum frame rate refresh of 1 frame/sec would be relevant? That freeze is not expected, and it's actually really a regression from previously AFAICT.
comment:5 by , 11 years ago
Analyzed by developer: | set |
---|---|
Owner: | set to |
Reproduced by developer: | set |
Status: | new → open |
comment:7 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | open → closed |
The speedloss introduced in 0d6e5a17 is now fixed by 51bcd5cd. To reproduce the slowdown, ./ffplay -f lavfi mandelbrot=morphamp=1.1 can be used.