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

[FFmpeg]

#9910: suggestion for faster accurate trimming
-------------------------------------+-------------------------------------
             Reporter:  Jozef        |                    Owner:  (none)
  Chutka                             |
                 Type:  enhancement  |                   Status:  new
             Priority:  normal       |                Component:
                                     |  undetermined
              Version:  unspecified  |               Resolution:
             Keywords:  Trim         |               Blocked By:
  performance                        |
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Description changed by Jozef Chutka:

Old description:

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

New description:

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

--
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/9910#comment:1>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker