Video duration increases when reducing frame rate

[t.rapp]

When reducing the frame rate of a 25Hz/20sec AVI/HuffYUV video test file to 1Hz the duration increases to 22sec.

Comparing the framemd5 output of input file and output file (see attachments) it seems that the first two frames of the input file are passed through, then each frame at the middle of the output interval is passed (frame 13 for the first 1sec interval, frame 38 for the second 1sec interval, ...).

How to reproduce:

# create 25Hz test input file
% ffmpeg -f lavfi -graph "testsrc=size=pal:rate=25 [out0]" -i dummy \
  -f avi  -codec:v huffyuv -pix_fmt yuv422p -t 20 /tmp/test-25hz.avi

# create 1Hz test output file
% ffmpeg -i /tmp/test-25hz.avi -f avi -codec:v huffyuv -r 1 /tmp/test-1hz.avi

ffmpeg version N-66544-g61c0683 Copyright (c) 2000-2014 the FFmpeg developers
  built on Sep 30 2014 09:02:33 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1)
  configuration: --cc='ccache gcc' --enable-debug --enable-version3
  libavutil      54.  7.101 / 54.  7.101
  libavcodec     56.  1.101 / 56.  1.101
  libavformat    56.  7.101 / 56.  7.101
  libavdevice    56.  1.100 / 56.  1.100
  libavfilter     5.  1.102 /  5.  1.102
  libswscale      3.  1.100 /  3.  1.100
  libswresample   1.  1.100 /  1.  1.100
Input #0, avi, from '/tmp/test-25hz.avi':
  Metadata:
    encoder         : Lavf56.7.101
  Duration: 00:00:20.00, start: 0.000000, bitrate: 46859 kb/s
    Stream #0:0: Video: huffyuv (HFYU / 0x55594648), yuv422p, 720x576, 46945 kb/s, SAR 1:1 DAR 5:4, 25 fps, 25 tbr, 25 tbn, 25 tbc
[huffyuv @ 0x1be5a20] using huffyuv 2.2.0 or newer interlacing flag
Output #0, avi, to '/tmp/test02-1hz.avi':
  Metadata:
    ISFT            : Lavf56.7.101
    Stream #0:0: Video: huffyuv (HFYU / 0x55594648), yuv422p, 720x576 [SAR 1:1 DAR 5:4], q=2-31, 200 kb/s, 1 fps, 1 tbn, 1 tbc
    Metadata:
      encoder         : Lavc56.1.101 huffyuv
Stream mapping:
  Stream #0:0 -> #0:0 (huffyuv (native) -> huffyuv (native))
Press [q] to stop, [?] for help
frame=   22 fps= 13 q=0.0 Lsize=    5040kB time=00:00:22.00 bitrate=1876.8kbits/s dup=0 drop=478
video:5034kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.124002%

[Carl Eugen Hoyos]

Please test the fps filter.

[t.rapp]

OK, when using the fps filter the duration is increased only by 1sec to 21secs. It passes through input frames [0, 13, 38, 63, ...] instead of [0, 1, 13, 38, 63, ...] as it does when using -r.

Have right now stumbled over the framestep filter and noticed that this filter keeps the duration and passes through input frames [0, 25, 50, 75, ...]. See attached files for details.

[t.rapp]

After some more trial-and-error testing I think I understand the "round" argument of fps a bit better. fps=fps=1:round=zero seems to do the same as framestep=25 for PAL but should also work for NTSC. So my use-case is solved.

Maybe the documentation of the "round" argument could be updated with some details/examples about which frame numbers are passed through. It remains unclear for me, though, why the -r option behaves different than fps filter. Is using -r deprecated?

[Carl Eugen Hoyos]

The issue that the first two frames are not 1 second apart with -r 1 is still reproducible.