Input option -r has no effect with -vcodec copy

[Weiwu Zhang]

When a playback device can only accept 25fps and input is 24fps, people usually have to re-encode. But some other software provided an alternative way called conforming.

Instead of re-encoding for a different framerate, the video stream can be copied with a different set of timestamps and duration. This is called conforming. The stretch of video length is usually not observable, and the audio is stretched at the same rate (ffmpeg's atempo filter can do that) and re-encoded.

This feature useful in the case that re-encoding video damages perceived quality more than alterating its duration.

It is especially useful when audio doesn't matter: e.g. when user wants slow-mo effect from a 240fps camera, or when user processes security camera output at low framerate.

Currently for this to work, users do the following:

1. mencoder allow users to specific framerate, overwriting the framerate specified in the source file. Use mencoder to conform the video:

   > mencoder -fps 25 -o conformed.avi -ovc copy -nosound 24fps_input.mp4
   

2. use ffmpeg to set tempo:

   > ffmpeg -i conformed.avi -i 24fps_input.mp4 -map 0 -map 1 -c:v copy -af "atempo=0.96" 25fps_output.mp4
   

3. delete the temp file

   > rm conformed.avi
   

where 0.96 equals 24⁄25.

This feature request propose to allow user do this without the need of mencoder.

This can be done by making -r parameter overwrite the framerate specified in input file when user specifies video stream to be copied instead of re-encoded.

If user specified -r when re-encoding the video, he could mean that input video's frames be dropped or duplicated, or that the output video should be encoded in the specified framerate.

However, if user specifies -r together with '-c:v copy' for video stream to be copied, he unambiguously means that he intends conforming. ffmpeg can proceed with conforming, and, by the end of the process, if it found that video and audio duration in input mathces each other, but in output different, it can give a warning, prompting the user to google for solution (which is to use atempo).

[Carl Eugen Hoyos]

Please provide your input sample 24fps_input.mp4.

[Weiwu Zhang]

This is not a bug report; the feature, conforming, is a generic one: it applies to every video codec at every framerate - 24fps is just an example for convenience. Again for convenience, a good sample input file is ​https://download.blender.org/durian/trailer/sintel_trailer-480p.mp4 which indeed is 24fps and can be conformed with mencoder.

[Carl Eugen Hoyos]

The following works as expected:

$ ffmpeg -r 25 -i sintel_trailer-480p.mp4 -qscale 2 -vcodec mpeg4 -af atempo=25/24 out.mov

The input option -r currently does not work for -vcodec copy.

[Misaki]

The -r option (for input methods) is not appropriate for variable-frame-rate video.

If the documented -time_base option worked, this would fix the problem.

ffmpeg -i "$in" -time_base 1 -f null -

Unrecognized option 'time_base'.
Error splitting the argument list: Option not found

(As an input option, the same error.)

From help pages:

time_base rational number

Set codec time base.

It is the fundamental unit of time (in seconds) in terms of which frame
timestamps are represented. For fixed-fps content, timebase should be "1
/ frame_rate" and timestamp increments should be identically 1.

When concatenating files, if they have different time bases, the later files will be sped up or slowed down. Unfortunately, this can't be used to accomplish the objective as there's no way to reliably set the timebase for an output file; it's some complicated result of the frame rate.

So if one file says it has "15360 tbn", and you want to slow it by 1/25, there's no way (for the typical user) to produce a file with "14746 tbn" (which is close to 15360*24/25=14745.6).