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

Submitted by morten.with@gmail.com on June 10, 2018, 4:31 p.m.

Details

Message ID 20180610163118.5692-1-morten.with@gmail.com
State New
Headers show

Commit Message

morten.with@gmail.com June 10, 2018, 4:31 p.m.
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(+)

Comments

Marton Balint June 10, 2018, 5:58 p.m.
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
Gyan June 10, 2018, 6:10 p.m.
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
Gyan June 10, 2018, 6:19 p.m.
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
Gyan June 10, 2018, 6:26 p.m.
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
morten.with@gmail.com June 10, 2018, 7:39 p.m.
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
>
Jan Ekström June 10, 2018, 8:07 p.m.
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
morten.with@gmail.com June 11, 2018, 7:18 p.m.
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
Gyan June 11, 2018, 8:23 p.m.
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
morten.with@gmail.com June 11, 2018, 9 p.m.
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
>
Lou Logan June 11, 2018, 9:38 p.m.
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".
Michael Niedermayer July 2, 2018, 9:57 a.m.
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 

[...]

Patch hide | download patch | download mbox

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 |