Opened 4 years ago

Last modified 3 years ago

#3990 open defect

Video duration increases when reducing frame rate

Reported by: t.rapp Owned by:
Priority: normal Component: ffmpeg
Version: git-master Keywords: fps
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description

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%

Attachments (4)

test-25hz-framemd5.log (39.2 KB) - added by t.rapp 4 years ago.
test-1hz-framemd5.log (1.9 KB) - added by t.rapp 4 years ago.
test-1hz-fps-framemd5.log (1.8 KB) - added by t.rapp 4 years ago.
test-1hz-framestep-framemd5.log (1.7 KB) - added by t.rapp 4 years ago.

Download all attachments as: .zip

Change History (8)

Changed 4 years ago by t.rapp

Changed 4 years ago by t.rapp

comment:1 Changed 4 years ago by cehoyos

Please test the fps filter.

comment:2 Changed 4 years ago by 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.

Changed 4 years ago by t.rapp

Changed 4 years ago by t.rapp

comment:3 Changed 4 years ago by 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?

Last edited 4 years ago by t.rapp (previous) (diff)

comment:4 Changed 3 years ago by cehoyos

  • Keywords fps added
  • Reproduced by developer set
  • Status changed from new to open

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

Note: See TracTickets for help on using tickets.