Peter White <peter.wh...@posteo.net> writes: > 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.
No, libx264. What I think happened that the input was stopped, but the timestamp copied from the original. But I will keep playing with it. By the way when I crop the video afterwards the end time is correct. But it would be better to do everything in one swoop of-course. (At the moment I am just finding out what to do.) > 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. Well I enter them as timestamps and my script convert it to seconds. (It is quit an old script.) And when I use the first as input and the second as output I need to convert them so I can calculate the length. > 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. That was my understanding also. -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof _______________________________________________ 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".
