#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 )
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 , 2 years ago
Description: | modified (diff) |
---|
comment:2 by , 2 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
comment:3 by , 2 years ago
Keywords: | performance removed |
---|
Seeking for filters is known TODO and in another report.