On Sun, Jun 10, 2018 at 10:39 PM, Morten With <morten.w...@gmail.com> wrote: > As Gyan clarified, this only affects one input file. Help text has been > modified as per Gyan's instructions (not yet submitted). > > This feature was specifically requested here (and I had the same issue as > the one who opened the ticket): https://trac.ffmpeg.org/ticket/7155 > > I think it's a lot cleaner to just solve this with one ffmpeg command > without any external scripting math, since ffmpeg knows the duration of the > file internally anyway. Otherwise, why would -sseof exist? >
Yes, programmatic things for things like these are often better. That said, the question regarding sseof can be answered by "the person who merged this stuff was OK with all the asterisks/caveats around it". Think of MPEG-TS, for example. I think - quite a bit simplified - it basically parses the timestamps until it finishes probing, and then extrapolates according to the size/bit rate of the file. That might be close, or that might be not close at all. At the end of the day, the libraries in FFmpeg are very much based on A->B access, not frame-exactness in access or figuring out the full length of a media file with any sort of precision. Of course, this doesn't mean that this base feature set cannot be utilized to gain such features - ffms2 (https://github.com/FFMS/ffms2/) is one example of this, which is a wrapper around FFmpeg's libraries that indexes the file, and then provides you (unless you hit a bug or special case) frame-exact access to the contents. Many people have their own use cases for various things and have enough leverage to get things that specifically work for their use case into the code base, which is why in the end we have three different ways of doing concatenation in the libraries (instead of implementing it in the API client), each with their own caveats (protocol, demuxer, filter). And the users will trust these features, and attempt to utilize them for their own use cases. That, in various cases, can lead to things just not working, as often the caveats are not mentioned and the attempted use cases are different from what those features were originally designed for. Best regards, Jan _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
