Opened 3 years ago

Last modified 3 years ago

#5170 open enhancement

Input option -r has no effect with -vcodec copy

Reported by: zhangweiwu Owned by:
Priority: wish Component: ffmpeg
Version: git-master Keywords: fps
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description

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
    
  1. 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
    
  1. 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).

Change History (4)

comment:1 Changed 3 years ago by cehoyos

Please provide your input sample 24fps_input.mp4.

comment:2 Changed 3 years ago by zhangweiwu

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.

Last edited 3 years ago by zhangweiwu (previous) (diff)

comment:3 Changed 3 years ago by cehoyos

  • Component changed from undetermined to ffmpeg
  • Keywords fps added
  • Priority changed from normal to wish
  • Reproduced by developer set
  • Status changed from new to open
  • Summary changed from feature request: conforming to Input option -r has no effect with -vcodec copy
  • Version changed from unspecified to git-master

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.

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

Last edited 3 years ago by Misaki (previous) (diff)
Note: See TracTickets for help on using tickets.