[FFmpeg-user] Cutting out part of a video does not work

[Peter White]

On Sat, Mar 27, 2021 at 05:53:56AM +0100, Cecil Westerhof via ffmpeg-user wrote:
> Peter White <peter.white at posteo.net> writes:
> 
> > On Fri, Mar 26, 2021 at 07:02:13PM +0100, Cecil Westerhof via ffmpeg-user wrote:
> >> Carl Zwanzig <cpz at tuunq.com> writes:
> >> 
> >> > On 3/26/2021 9:28 AM, Cecil Westerhof via ffmpeg-user wrote:
> >> >> There is only one problem. The video is 7:21 long, but both mpv and
> >> >> vlc think it is 7:30 long.
> >> >
> >> > IME, the metadata length often lies. When you say it's 7:21, is that
> >> > exactly how long it plays for or how long it ought to be?
> >> 
> >> I almost never have this. (If I remember well, only with videos
> >> created with ffmpeg. Sometimes it started on a negative timestamp
> >> instead of 00:00:00.)
> >> 
> >> Looking at the -to you would expect 7:22, but when I just play it, it
> >> ends at 7:21.
> >
> > You can try using -to as an input option as well. I am not sure, but I
> > seem to remember having similar problems once. Also, have a look at -t
> > for defining the length of the file as opposed to cutting on time code.
> 
> That is what I did first. Then I got 1:34:19 (or something like it).
> So even worse.

When you say "first", was that with -vcodec copy? Because that might
explain it. Although, I do not know why the file would be so much
longer. May be that data stream.

BTW, you can use "time codes" for -ss, -to and -t, too. Personally, I do
not like having to calculate in seconds when I can simply use the
timestamps shown by a player. It is much more intuitive, to me at least,
to just say: cut from (-ss) 19:45 -to 27:11 instead of from 1190 to
1631. But that, of course, depends on how you retrieved those timestamps
in the first place.

I now think, I know why I had problems in the past with -ss as an input
and -to as an output option in combination. By using -ss as input
option, the output timestamps start at 0, thus -to, in this scenario, is
the same as -t, resulting a file of that length. Hence, I suggest to
either use both -ss and -to as input or as output options and not mix
them as one input and the other as output option.

>From my understanding the difference between them being used as input or
output options, respectively, is that when used as input options they
tell the *demuxer* to seek and stop at the given timestamps. Or, more
precisely, the demuxer seeks to the last keyframe before the -ss
timestamp and the decoder starts decoding from there, discarding all
frames before the accurate timestamp.

When used as output option that applies to the *decoder*, with "copy"
being a special case. Because of this, you might need to wait a long
time for the encoding to start, when using them as output options, since
the decoder needs to get to the -ss timestamp by decoding frames which
get discarded.

What I am trying to say is: use -ss and -t(o) as input option whenever
you can, unless there is a very good reason--whatever that might be--for
using them as output options.


Cheers,
Peter