vf select doesn't work with multiple images output

[ubitux]

% ./ffmpeg -f lavfi -i testsrc -vf 'select=not(mod(n\,1000))' -frames:v 5 out%d.png
ffmpeg version N-43602-g569027e Copyright (c) 2000-2012 the FFmpeg developers
  built on Aug 16 2012 09:00:20 with gcc 4.7 (Debian 4.7.1-6)
  configuration: --enable-gpl --enable-fontconfig --enable-libfreetype --enable-libmp3lame --cc='ccache cc' --extra-cflags=-fstack-protector-all --enable-libx264 --enable-libvorbis --enable-libmodplug --enable-libass --samples=/home/cboesch/fate-samples --prefix=/home/cboesch/src/ff/ffmpeg/ffmpeg_build --enable-x11grab --enable-libvpx
  libavutil      51. 69.100 / 51. 69.100
  libavcodec     54. 53.100 / 54. 53.100
  libavformat    54. 24.100 / 54. 24.100
  libavdevice    54.  2.100 / 54.  2.100
  libavfilter     3.  9.100 /  3.  9.100
  libswscale      2.  1.101 /  2.  1.101
  libswresample   0. 15.100 /  0. 15.100
  libpostproc    52.  0.100 / 52.  0.100
[lavfi @ 0x2f10260] Estimating duration from bitrate, this may be inaccurate
Input #0, lavfi, from 'testsrc':
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: rawvideo (RGB[24] / 0x18424752), rgb24, 320x240 [SAR 1:1 DAR 4:3], 25 tbr, 25 tbn, 25 tbc
Output #0, image2, to 'out%d.png':
  Metadata:
    encoder         : Lavf54.24.100
    Stream #0:0: Video: png, rgb24, 320x240 [SAR 1:1 DAR 4:3], q=2-31, 200 kb/s, 90k tbn, 25 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo -> png)
Press [q] to stop, [?] for help
frame=    5 fps=0.0 q=0.0 Lsize=       0kB time=00:00:00.20 bitrate=   0.0kbits/s dup=3 drop=0    
video:13kB audio:0kB subtitle:0 global headers:0kB muxing overhead -100.000000%

Image 1 looks ok, but image 2 to 5 are identical; this is not correct.

On the other hand, the output is correct with:

% ./ffmpeg -f lavfi -i testsrc -vf 'select=not(mod(n\,1000)),tile=5x1' -frames:v 1 out.png
ffmpeg version N-43602-g569027e Copyright (c) 2000-2012 the FFmpeg developers
  built on Aug 16 2012 09:00:20 with gcc 4.7 (Debian 4.7.1-6)
  configuration: --enable-gpl --enable-fontconfig --enable-libfreetype --enable-libmp3lame --cc='ccache cc' --extra-cflags=-fstack-protector-all --enable-libx264 --enable-libvorbis --enable-libmodplug --enable-libass --samples=/home/cboesch/fate-samples --prefix=/home/cboesch/src/ff/ffmpeg/ffmpeg_build --enable-x11grab --enable-libvpx
  libavutil      51. 69.100 / 51. 69.100
  libavcodec     54. 53.100 / 54. 53.100
  libavformat    54. 24.100 / 54. 24.100
  libavdevice    54.  2.100 / 54.  2.100
  libavfilter     3.  9.100 /  3.  9.100
  libswscale      2.  1.101 /  2.  1.101
  libswresample   0. 15.100 /  0. 15.100
  libpostproc    52.  0.100 / 52.  0.100
[lavfi @ 0x1ec4260] Estimating duration from bitrate, this may be inaccurate
Input #0, lavfi, from 'testsrc':
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: rawvideo (RGB[24] / 0x18424752), rgb24, 320x240 [SAR 1:1 DAR 4:3], 25 tbr, 25 tbn, 25 tbc
Output #0, image2, to 'out.png':
  Metadata:
    encoder         : Lavf54.24.100
    Stream #0:0: Video: png, rgb24, 1600x240 [SAR 1:1 DAR 20:3], q=2-31, 200 kb/s, 90k tbn, 5 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo -> png)
Press [q] to stop, [?] for help
frame=    1 fps=0.0 q=0.0 Lsize=       0kB time=00:00:00.20 bitrate=   0.0kbits/s    
video:11kB audio:0kB subtitle:0 global headers:0kB muxing overhead -100.000000%

[Cigaes]

image2 is not capable of variable frame rate, so -vsync cfr is the default. Using -vsync vfr will force it and make your example work.

[ubitux]

Replying to Cigaes:

image2 is not capable of variable frame rate, so -vsync cfr is the default. Using -vsync vfr will force it and make your example work.

Interesting, but that default behavior is not expected... Any idea what could be done to improve that?

[rogerdpack]

Yeah I agree that for most people, their default thought is "I'm converting to images? It will output one output image per input frame" so +1 from me for making -vsync vfr default in this case... :)

[Cigaes]

Some people expect that. Other people output to images to apply some external processing and then re-encode, and expect this process to keep A-V sync even if the source material had a few skipped black frames.

Either behaviour makes sense as the default one. Changing the default is a severe interface change.

And using "smarter" heuristics would probably be more fragile.

[richardpl]

So can this bug be fixed at all?

[Cigaes]

IMHO, there is nothing to fix, as it is neither a bug nor a bad default behaviour.

[cehoyos]

I agree that there is no bug and that changing default behaviour should generally be avoided.