[FFmpeg-devel] [PATCH] fftools/ffmpeg_opt: Add -toeof option to stop writing relative to EOF

Jan Ekström jeebjp at gmail.com
Sun Jun 10 23:07:58 EEST 2018

On Sun, Jun 10, 2018 at 10:39 PM, Morten With <morten.with at 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,

More information about the ffmpeg-devel mailing list