Opened 20 months ago

Closed 20 months ago

Last modified 20 months ago

#9910 closed enhancement (duplicate)

suggestion for faster accurate trimming

Reported by: Jozef Chutka Owned by:
Priority: normal Component: undetermined
Version: unspecified Keywords: Trim
Cc: Jozef Chutka Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description (last modified by Jozef Chutka)

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@1" -t 300 -c:v libx264 -x264-params keyint=600 -preset ultrafast -y source.mkv

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 out1.mkv
// 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 step:

ffmpeg -ss 282 -to 293 -i source.mkv -output_ts_offset 282 -c:v copy -y out4-tmp.mkv
ffmpeg -filter_complex "movie=out4-tmp.mkv,select=gte(t\,282)*lt(t\,293),setpts=PTS-STARTPTS" -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.

Change History (3)

comment:1 by Jozef Chutka, 20 months ago

Description: modified (diff)

comment:2 by Elon Musk, 20 months ago

Resolution: duplicate
Status: newclosed

Seeking for filters is known TODO and in another report.

comment:3 by Carl Eugen Hoyos, 20 months ago

Keywords: performance removed
Note: See TracTickets for help on using tickets.