| Message ID | 20180610163118.5692-1-morten.with@gmail.com |
|---|---|
| State | New |
| Headers | show |
On Sun, 10 Jun 2018, morten.with@gmail.com wrote: > From: withmorten <morten.with@gmail.com> > > Signed-off-by: Morten With <morten.with@gmail.com> > --- > doc/ffmpeg.texi | 4 ++++ > fftools/ffmpeg.h | 1 + > fftools/ffmpeg_opt.c | 9 +++++++++ > 3 files changed, 14 insertions(+) > > diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi > index 3717f22d42..fe635d0e42 100644 > --- a/doc/ffmpeg.texi > +++ b/doc/ffmpeg.texi > @@ -488,6 +488,10 @@ see @ref{time duration syntax,,the Time duration section in the ffmpeg-utils(1) > > -to and -t are mutually exclusive and -t has priority. > > +@item -toeof @var{position} (@emph{input}) > +Stop writing the output at @var{position} relative to the "end of file". That is negative > +values are later in the file, 0 is at EOF. end of file is misleading, you are simply using the input duration as far as I see. So write that in the help text. Also what happens if the output is generated from multiple inputs? Also I am not sure your use case needs a separate option. Anybody willing to use this in an automated way can also get the input duration with ffprobe and use the good old -timestamp option to achieve the same result. Regards, Marton
On 10-06-2018 10:01 PM, morten.with@gmail.com wrote: > > +@item -toeof @var{position} (@emph{input}) > +Stop writing the output at @var{position} relative to the "end of file". That is negative > +values are later in the file, 0 is at EOF. Should be, "Stop reading the input at @var{position} relative to the "end of file". That is, larger negative values are earlier in the file, 0 is at EOF." > + { "toeof", HAS_ARG | OPT_TIME | OPT_OFFSET | OPT_INPUT, { .off = OFFSET(stop_time_eof) }, > + "record or transcode stop time relative to EOF", "time_stop" }, "input stop time relative to EOF" Regards, Gyan
On 10-06-2018 11:28 PM, Marton Balint wrote: > > end of file is misleading, you are simply using the input duration as > far as I see. So write that in the help text. Also what happens if the > output is generated from multiple inputs? This is the counterpart to `to` as -sseof is to -ss. This is a per-input option, so it just limits input packets. Regards, Gyan
On 10-06-2018 10:01 PM, morten.with@gmail.com wrote: > + if (o->stop_time_eof != AV_NOPTS_VALUE) { > + if (ic->duration>0) { > + o->recording_time = ic->duration + o->stop_time_eof; > + } else > + av_log(NULL, AV_LOG_WARNING, "Cannot use -toeof, duration of %s not known\n", filename); You need to make sure input -t and -to are both not set. You need to check that sseof if set isn't greater than toeof. And ss if set isn't beyond toeof either. Your recording time has to account for a input start from the middle of the file. Regards, Gyan
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? Regards, Morten 2018-06-10 19:58 GMT+02:00 Marton Balint <cus@passwd.hu>: > > > On Sun, 10 Jun 2018, morten.with@gmail.com wrote: > > From: withmorten <morten.with@gmail.com> >> >> Signed-off-by: Morten With <morten.with@gmail.com> >> --- >> doc/ffmpeg.texi | 4 ++++ >> fftools/ffmpeg.h | 1 + >> fftools/ffmpeg_opt.c | 9 +++++++++ >> 3 files changed, 14 insertions(+) >> >> diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi >> index 3717f22d42..fe635d0e42 100644 >> --- a/doc/ffmpeg.texi >> +++ b/doc/ffmpeg.texi >> @@ -488,6 +488,10 @@ see @ref{time duration syntax,,the Time duration >> section in the ffmpeg-utils(1) >> >> -to and -t are mutually exclusive and -t has priority. >> >> +@item -toeof @var{position} (@emph{input}) >> +Stop writing the output at @var{position} relative to the "end of file". >> That is negative >> +values are later in the file, 0 is at EOF. >> > > end of file is misleading, you are simply using the input duration as far > as I see. So write that in the help text. Also what happens if the output > is generated from multiple inputs? > > Also I am not sure your use case needs a separate option. Anybody willing > to use this in an automated way can also get the input duration with > ffprobe and use the good old -timestamp option to achieve the same result. > > Regards, > Marton > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >
On Sun, Jun 10, 2018 at 10:39 PM, Morten With <morten.with@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
2018-06-10 22:07 GMT+02:00 Jan Ekström <jeebjp@gmail.com>: > > 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 > I can see what you mean, but this is such a trivial little addition, I really fail to see how any big problems would arise from this. Perhaps a disclaimer that file duration can be inaccurate and should not be relied upon should be added to sseof and also toeof then? The options already fail if duration is completely unknown. Anyway, since I'm not really sure how to update the patch with git send-email without creating another patch on the tracker (I changed the commit message to "stop reading"), here is the revised patch attached. If I should add it as a new patch, please let me know and I will do so. Regards, Morten
On 12-06-2018 12:48 AM, Morten With wrote:
> commit message to "stop reading"), here is the revised patch attached.
Maybe I missed it, but in the new patch, you don't vet ss against toeof
i.e. for a 10-second file, -ss 7 -toeof -4 should be declared invalid.
Also, this isn't an issue with your patch but ss / sseof dual setting
isn't checked nor is the validity of the sseof value.
Let me get a patch in first to rectify that.
Regards,
Gyan
Yeah, I was thinking that there seemed to be very little validation of -sseof combinations. That's why I initially didn't add any of those for -toeof. You are correct, that is missing, I'll add that once your patch is done then. Also, was this the correct way to send in a revised patch? I'm completely new to this. Regards, Morten 2018-06-11 22:23 GMT+02:00 Gyan Doshi <gyandoshi@gmail.com>: > > > On 12-06-2018 12:48 AM, Morten With wrote: > > commit message to "stop reading"), here is the revised patch attached. >> > > Maybe I missed it, but in the new patch, you don't vet ss against toeof > i.e. for a 10-second file, -ss 7 -toeof -4 should be declared invalid. > > Also, this isn't an issue with your patch but ss / sseof dual setting > isn't checked nor is the validity of the sseof value. > > Let me get a patch in first to rectify that. > > Regards, > Gyan > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >
On Mon, Jun 11, 2018, at 1:00 PM, Morten With wrote: > > Also, was this the correct way to send in a revised patch? I'm completely > new to this. Yes, that is acceptable. We are not too picky about that. It can be helpful to rename the subject, such as [PATCH v2], if desired: especially if multiple iterations are to be expected. Also see the "-v" and "--in-reply-to" options in "git format-patch".
Just reread this as the patch was pinged for needing review ... On Sun, Jun 10, 2018 at 11:07:58PM +0300, Jan Ekström wrote: [...] > 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. The reason why we do not have concatenation support in the API client (ffmpeg) as you suggest is because noone implemented it. And it would be great if someone did implement this. The reason why concatenation is supported at various other layers is because someone implemented it and because its a usefull feature in each layer. That is if you see these layers as general purpose things, and not with only a narrow purpose in mind. I am not sure your argumentation about people is correct. (i suspect its not) But it sounds certainly a bit rude to me ... No question though the lack of clean high level concatenation support causes problems [...]
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi index 3717f22d42..fe635d0e42 100644 --- a/doc/ffmpeg.texi +++ b/doc/ffmpeg.texi @@ -488,6 +488,10 @@ see @ref{time duration syntax,,the Time duration section in the ffmpeg-utils(1) -to and -t are mutually exclusive and -t has priority. +@item -toeof @var{position} (@emph{input}) +Stop writing the output at @var{position} relative to the "end of file". That is negative +values are later in the file, 0 is at EOF. + @item -fs @var{limit_size} (@emph{output}) Set the file size limit, expressed in bytes. No further chunk of bytes is written after the limit is exceeded. The size of the output file is slightly more than the diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h index eb1eaf6363..70026b376e 100644 --- a/fftools/ffmpeg.h +++ b/fftools/ffmpeg.h @@ -149,6 +149,7 @@ typedef struct OptionsContext { int64_t recording_time; int64_t stop_time; + int64_t stop_time_eof; uint64_t limit_filesize; float mux_preload; float mux_max_delay; diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c index a2ecddae71..ed28111dc4 100644 --- a/fftools/ffmpeg_opt.c +++ b/fftools/ffmpeg_opt.c @@ -1103,6 +1103,13 @@ static int open_input_file(OptionsContext *o, const char *filename) } } + if (o->stop_time_eof != AV_NOPTS_VALUE) { + if (ic->duration>0) { + o->recording_time = ic->duration + o->stop_time_eof; + } else + av_log(NULL, AV_LOG_WARNING, "Cannot use -toeof, duration of %s not known\n", filename); + } + if (o->start_time_eof != AV_NOPTS_VALUE) { if (ic->duration>0) { o->start_time = o->start_time_eof + ic->duration; @@ -3334,6 +3341,8 @@ const OptionDef options[] = { "duration" }, { "to", HAS_ARG | OPT_TIME | OPT_OFFSET | OPT_INPUT | OPT_OUTPUT, { .off = OFFSET(stop_time) }, "record or transcode stop time", "time_stop" }, + { "toeof", HAS_ARG | OPT_TIME | OPT_OFFSET | OPT_INPUT, { .off = OFFSET(stop_time_eof) }, + "record or transcode stop time relative to EOF", "time_stop" }, { "fs", HAS_ARG | OPT_INT64 | OPT_OFFSET | OPT_OUTPUT, { .off = OFFSET(limit_filesize) }, "set the limit file size in bytes", "limit_size" }, { "ss", HAS_ARG | OPT_TIME | OPT_OFFSET |