On Sat, Mar 27, 2021 at 05:53:56AM +0100, Cecil Westerhof via ffmpeg-user wrote: > Peter White <peter.wh...@posteo.net> writes: > > > On Fri, Mar 26, 2021 at 07:02:13PM +0100, Cecil Westerhof via ffmpeg-user > > wrote: > >> Carl Zwanzig <c...@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 _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
