[FFmpeg-trac] #9910(undetermined:new): suggestion for faster accurate trimming

FFmpeg trac at avcodec.org
Wed Sep 7 16:22:38 EEST 2022

#9910: suggestion for faster accurate trimming
             Reporter:  Jozef        |                     Type:
  Chutka                             |  enhancement
               Status:  new          |                 Priority:  normal
            Component:               |                  Version:
  undetermined                       |  unspecified
             Keywords:  Trim         |               Blocked By:
  performance                        |
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
 While working with various options to trim video accurately (using `-ss`,
 `trim`, `select`), I believe to have discovered 2 step process which
 executes faster then a single step. Please consider if my findings can be
 incorporated into the `trim` or another filter.

 Lets have some (300 sec) long video with 10s keyframe interval (600 / 60),
 to demonstrate both trim accuracy and performance:

 ffmpeg -filter_complex
 "smptehdbars=size=1920x1080:rate=60,drawtext=fontfile=c\\:/Windows/Fonts/arial.ttf:timecode=00\\:00\\:00.00:rate=60:fontsize=300:fontcolor=white:x=(w-tw)/2:y=10*h/100:box=1:boxcolor=0x00000000 at 1"
 -t 300 -c:v libx264 -x264-params keyint=600 -preset ultrafast -y

 Lets cut this video accurately at time 282 (4:42) to 293 (4:53) so neither
 of the time points is keyframe:

 ffmpeg -i source.mkv -ss 282 -to 293 -c:v libx264 -preset ultrafast -y
 // takes 14.8 sec to complete

 ffmpeg -i source.mkv -vf trim=start=282:end=293 -c:v libx264 -preset
 ultrafast -y out2.mkv
 // takes 14.7 sec to complete

 ffmpeg -i source.mkv -vf "select=between(t\,282\,293)" -c:v libx264
 -preset ultrafast -y out3.mkv
 // takes 15.1 sec to complete

 Now here is the two step much faster accurate trim, in first step lets
 create inaccurate intermediate file, and fix the accurancy in the second

 ffmpeg -ss 282 -to 293 -i source.mkv -output_ts_offset 282 -c:v copy -y
 ffmpeg -filter_complex
 -c:v libx264 -preset ultrafast -y out4.mkv
 // takes 0 + 2.4 sec to complete

 I believe the internal seeking within `trim` and `select` filters is much
 slower then the one used by `-ss (before `-i`)`. If the video is fast-
 seeked in first step, even though inaccurately, it can be fixed in the
 second step.

 The trick is `-output_ts_offset` argument in first step and `select`
 filter in the second. Both, out1.mkv and out4.mkv have same size and
 binary comparision seems almost perfect match. Although the first took
 14.8 sec to complete, second one just 2.4.

 This process works ok with mkv and mp4 formats.
Ticket URL: <https://trac.ffmpeg.org/ticket/9910>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker

More information about the FFmpeg-trac mailing list