[FFmpeg-devel] [PATCH] fftools/ffmpeg_opt: Add -toeof option to stop reading at position relative to EOF
Michael Niedermayer
michael at niedermayer.cc
Mon Jul 2 13:06:16 EEST 2018
On Fri, Jun 29, 2018 at 05:53:43PM +0200, morten.with at gmail.com wrote:
> From: withmorten <morten.with at gmail.com>
>
> Fixes ticket #7155: Add option to stop writing at position relative to EOF
>
> Signed-off-by: Morten With <morten.with at gmail.com>
> ---
> doc/ffmpeg.texi | 6 ++++++
> fftools/ffmpeg.h | 1 +
> fftools/ffmpeg_opt.c | 31 +++++++++++++++++++++++++++++++
> 3 files changed, 38 insertions(+)
>
> diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> index 3717f22d42..f627f0e8a5 100644
> --- a/doc/ffmpeg.texi
> +++ b/doc/ffmpeg.texi
> @@ -488,6 +488,12 @@ see @ref{time duration syntax,,the Time duration section in the ffmpeg-utils(1)
>
> -to and -t are mutually exclusive and -t has priority.
>
> + at item -toeof @var{position} (@emph{input})
> +Stop reading the input at @var{position} relative to the "end of file". That is,
> +larger negative values are later in the file, 0 is at EOF.
> +
> +-toeof and -to, as well as -toeof and -t, are mutually exclusive, and -to, or respectively -t, has priority.
> +
> @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 58ec13e5a8..30fd28ec3a 100644
> --- a/fftools/ffmpeg_opt.c
> +++ b/fftools/ffmpeg_opt.c
> @@ -159,6 +159,7 @@ static void init_options(OptionsContext *o)
> memset(o, 0, sizeof(*o));
>
> o->stop_time = INT64_MAX;
> + o->stop_time_eof = AV_NOPTS_VALUE;
> o->mux_max_delay = 0.7;
> o->start_time = AV_NOPTS_VALUE;
> o->start_time_eof = AV_NOPTS_VALUE;
> @@ -979,6 +980,16 @@ static int open_input_file(OptionsContext *o, const char *filename)
> av_log(NULL, AV_LOG_WARNING, "-t and -to cannot be used together; using -t.\n");
> }
>
> + if (o->stop_time_eof != AV_NOPTS_VALUE && o->recording_time != INT64_MAX) {
> + o->stop_time_eof = AV_NOPTS_VALUE;
> + av_log(NULL, AV_LOG_WARNING, "-t and -toeof cannot be used together; using -t for %s.\n", filename);
> + }
> +
> + if (o->stop_time != INT64_MAX && o->stop_time_eof != AV_NOPTS_VALUE) {
> + o->stop_time_eof = AV_NOPTS_VALUE;
> + av_log(NULL, AV_LOG_WARNING, "-to and -toeof cannot be used together; using -to for %s.\n", filename);
> + }
> +
> if (o->stop_time != INT64_MAX && o->recording_time == INT64_MAX) {
> int64_t start_time = o->start_time == AV_NOPTS_VALUE ? 0 : o->start_time;
> if (o->stop_time <= start_time) {
> @@ -1122,6 +1133,24 @@ static int open_input_file(OptionsContext *o, const char *filename)
> } else
> av_log(NULL, AV_LOG_WARNING, "Cannot use -sseof, duration of %s not known\n", filename);
> }
> +
> + if (o->stop_time_eof != AV_NOPTS_VALUE) {
> + if (o->stop_time_eof >= 0) {
> + av_log(NULL, AV_LOG_ERROR, "-toeof value must be negative; aborting\n");
> + exit_program(1);
> + }
> + if (ic->duration > 0) {
> + o->recording_time = ic->duration + o->stop_time_eof;
> + if (o->start_time != AV_NOPTS_VALUE) {
> + o->recording_time -= o->start_time;
> + if (o->recording_time <= 0) {
> + av_log(NULL, AV_LOG_WARNING, "-toeof value seeks to before start of file %s; ignored\n", filename);
> + o->recording_time += o->start_time;
> + }
> + }
> + } else
> + av_log(NULL, AV_LOG_WARNING, "Cannot use -toeof, duration of %s not known\n", filename);
> + }
In the previous discussion it was raised that the duration this is based on
can be unreliable.
There is duration_estimation_method, could this maybe be used to warn the user
of inaccuracies ?
Also if it doesnt fit exactly, keep in mind that you could extend
duration_estimation_method in a seperate patch.
Also whats your oppinon about adding some support for accuratly finding the
duration to libavformat in cases where the exact duration is important ?
This could be enabled with a flag passed to libavformat
Thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
You can kill me, but you cannot change the truth.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180702/2786b2d4/attachment.sig>
More information about the ffmpeg-devel
mailing list