[FFmpeg-devel,v3] fftools/ffmpeg_filter: add -autoscale to disable/enable the default scale

Submitted by Linjie Fu on July 19, 2019, 5:34 p.m.

Details

Message ID 20190719173439.25077-1-linjie.fu@intel.com
State New
Headers show

Commit Message

Linjie Fu July 19, 2019, 5:34 p.m.
Currently, ffmpeg inserts scale filter by default in the filter graph
to force the whole decoded stream to scale into the same size with the
first frame. It's not quite make sense in resolution changing cases if
user wants the rawvideo without any scale.

Using autoscale/noautoscale to indicate whether auto inserting the scale
filter in the filter graph:
    -noautoscale or -autoscale 0:
        disable the default auto scale filter inserting.

Update docs.

Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
---
 doc/ffmpeg.texi         | 17 +++++++++++++----
 fftools/ffmpeg.c        |  1 +
 fftools/ffmpeg.h        |  4 ++++
 fftools/ffmpeg_filter.c |  2 +-
 fftools/ffmpeg_opt.c    |  8 ++++++++
 5 files changed, 27 insertions(+), 5 deletions(-)

Comments

Gyan July 20, 2019, 5:28 a.m.
On 19-07-2019 11:04 PM, Linjie Fu wrote:
> Currently, ffmpeg inserts scale filter by default in the filter graph
> to force the whole decoded stream to scale into the same size with the
> first frame. It's not quite make sense in resolution changing cases if
> user wants the rawvideo without any scale.
>
> Using autoscale/noautoscale to indicate whether auto inserting the scale
> filter in the filter graph:
>      -noautoscale or -autoscale 0:
>          disable the default auto scale filter inserting.
>
> Update docs.
>
> Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
> Signed-off-by: Linjie Fu <linjie.fu@intel.com>
> ---
>   doc/ffmpeg.texi         | 17 +++++++++++++----
>   fftools/ffmpeg.c        |  1 +
>   fftools/ffmpeg.h        |  4 ++++
>   fftools/ffmpeg_filter.c |  2 +-
>   fftools/ffmpeg_opt.c    |  8 ++++++++
>   5 files changed, 27 insertions(+), 5 deletions(-)
>
> diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> index cd35eb49c8..99121b6981 100644
> --- a/doc/ffmpeg.texi
> +++ b/doc/ffmpeg.texi
> @@ -734,10 +734,6 @@ ffmpeg -dump_attachment:t "" -i INPUT
>   Technical note -- attachments are implemented as codec extradata, so this
>   option can actually be used to extract extradata from any stream, not just
>   attachments.
> -
> -@item -noautorotate
> -Disable automatically rotating video based on file metadata.
> -
>   @end table
>   
>   @section Video Options
> @@ -819,6 +815,19 @@ Create the filtergraph specified by @var{filtergraph} and use it to
>   filter the stream.
>   
>   This is an alias for @code{-filter:v}, see the @ref{filter_option,,-filter option}.
> +
> +@item -autorotate
> +Automatically rotate the video according to file metadata. Enabled by
> +default, use @option{-noautorotate} to disable it.
> +
> +@item -autoscale
> +Automatically scale the video according to the resolution of first frame.
> +Enabled by default, use @option{-noautoscale} to disable it. When autoscale is
> +disabled, all output frames might not be in the same resolution and may require
> +some additional explicit processing according to your final rendering/output
> +destination. Disabling autoscale may not work in all situations. Therefore, it
> +is not recommended to disable it unless you really know what you are doing.
> +Disable autoscale at your own risk.

Since the auto scaling happens at the end of the graph, what may the 
"additional explicit processing" be?

>   @end table
>   
>   @section Advanced Video options
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index 01f04103cf..5d52430b1e 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -2133,6 +2133,7 @@ static int ifilter_send_frame(InputFilter *ifilter, AVFrame *frame)
>   
>       /* determine if the parameters for this input changed */
>       need_reinit = ifilter->format != frame->format;
> +    fg->autoscale = ifilter->ist->autoscale;
>   
>       switch (ifilter->ist->st->codecpar->codec_type) {
>       case AVMEDIA_TYPE_AUDIO:
> diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
> index 7b6f802082..1602406581 100644
> --- a/fftools/ffmpeg.h
> +++ b/fftools/ffmpeg.h
> @@ -133,6 +133,8 @@ typedef struct OptionsContext {
>       int        nb_hwaccel_output_formats;
>       SpecifierOpt *autorotate;
>       int        nb_autorotate;
> +    SpecifierOpt *autoscale;
> +    int        nb_autoscale;
>   
>       /* output options */
>       StreamMap *stream_maps;
> @@ -285,6 +287,7 @@ typedef struct FilterGraph {
>   
>       AVFilterGraph *graph;
>       int reconfiguration;
> +    int autoscale;
>   
>       InputFilter   **inputs;
>       int          nb_inputs;
> @@ -335,6 +338,7 @@ typedef struct InputStream {
>       int guess_layout_max;
>   
>       int autorotate;
> +    int autoscale;
>   
>       int fix_sub_duration;
>       struct { /* previous decoded subtitle and related variables */
> diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
> index 72838de1e2..2a2eb080eb 100644
> --- a/fftools/ffmpeg_filter.c
> +++ b/fftools/ffmpeg_filter.c
> @@ -469,7 +469,7 @@ static int configure_output_video_filter(FilterGraph *fg, OutputFilter *ofilter,
>       if (ret < 0)
>           return ret;
>   
> -    if (ofilter->width || ofilter->height) {
> +    if ((ofilter->width || ofilter->height) && fg->autoscale) {
>           char args[255];
>           AVFilterContext *filter;
>           AVDictionaryEntry *e = NULL;
> diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
> index f5ca18aa64..41cb676dad 100644
> --- a/fftools/ffmpeg_opt.c
> +++ b/fftools/ffmpeg_opt.c
> @@ -742,7 +742,9 @@ static void add_input_streams(OptionsContext *o, AVFormatContext *ic)
>           MATCH_PER_STREAM_OPT(ts_scale, dbl, ist->ts_scale, ic, st);
>   
>           ist->autorotate = 1;
> +        ist->autoscale  = 1;
>           MATCH_PER_STREAM_OPT(autorotate, i, ist->autorotate, ic, st);
> +        MATCH_PER_STREAM_OPT(autoscale, i, ist->autoscale, ic, st);
>   
>           MATCH_PER_STREAM_OPT(codec_tags, str, codec_tag, ic, st);
>           if (codec_tag) {
> @@ -3640,6 +3642,12 @@ const OptionDef options[] = {
>       { "autorotate",       HAS_ARG | OPT_BOOL | OPT_SPEC |
>                             OPT_EXPERT | OPT_INPUT,                                { .off = OFFSET(autorotate) },
>           "automatically insert correct rotate filters" },
> +    { "autoscale",        HAS_ARG | OPT_BOOL | OPT_SPEC |
> +                          OPT_EXPERT | OPT_INPUT,                                { .off = OFFSET(autoscale) },
> +        "automatically insert a scale filter at the end of the filter graph if a resolution"
> +        "change is detected. This ensures all frames are the same resolution as the first frame"
> +        "when they leave the filter chain (this option is enabled by default)."
> +        "If disabled, some encoders/muxers may not support this mode."},
Which muxers can detect or check for prop changes within coded 
bitstreams? Which encoders are known to be able to handle
changing resolution?

Gyan
Nicolas George July 20, 2019, 7:46 a.m.
Gyan (12019-07-20):
> Since the auto scaling happens at the end of the graph

Are you sure? IIRC, the scaling happens just after buffersrc.

Regards,
Gyan July 20, 2019, 7:54 a.m.
On 20-07-2019 01:16 PM, Nicolas George wrote:
> Gyan (12019-07-20):
>> Since the auto scaling happens at the end of the graph
> Are you sure? IIRC, the scaling happens just after buffersrc.

 From the patch,

1)

 >  @@ -469,7 +469,7 @@ static int 
configure_output_video_filter(FilterGraph *fg, OutputFilter *ofilter,
 >       if (ret < 0)
 >           return ret;
 >
 >  -    if (ofilter->width || ofilter->height) {
 >  +    if ((ofilter->width || ofilter->height) && fg->autoscale) {

and

2)

> +    { "autoscale",        HAS_ARG | OPT_BOOL | OPT_SPEC |
> +                          OPT_EXPERT | OPT_INPUT,                                { .off = OFFSET(autoscale) },
> +        "automatically insert a scale filter at the end of the filter graph if a resolution"



Gyan
Nicolas George July 20, 2019, 8:09 a.m.
Gyan (12019-07-20):
> From the patch,

After checking, you are right. When that option is enabled, the filter
graphs are still reinited. That makes it slightly less fragile than I
thought.

Regards,
Linjie Fu July 22, 2019, 8:10 a.m.
> -----Original Message-----

> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On Behalf

> Of Gyan

> Sent: Saturday, July 20, 2019 13:29

> To: ffmpeg-devel@ffmpeg.org

> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -

> autoscale to disable/enable the default scale


> > diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi

> > index cd35eb49c8..99121b6981 100644

> > --- a/doc/ffmpeg.texi

> > +++ b/doc/ffmpeg.texi

> > +@item -autoscale

> > +Automatically scale the video according to the resolution of first frame.

> > +Enabled by default, use @option{-noautoscale} to disable it. When

> autoscale is

> > +disabled, all output frames might not be in the same resolution and may

> require

> > +some additional explicit processing according to your final

> rendering/output

> > +destination. Disabling autoscale may not work in all situations. Therefore,

> it

> > +is not recommended to disable it unless you really know what you are

> doing.

> > +Disable autoscale at your own risk.

> 

> Since the auto scaling happens at the end of the graph, what may the

> "additional explicit processing" be?


Vpp processing may not be influenced,  a warning in transcode is needed.
The expression seems to be improper, how about:

"When autoscale is disabled, all output frames of filter graph might not be in the same
resolution and may be inadequate for encoder/muxer."

or other suggestions?

> > @@ -3640,6 +3642,12 @@ const OptionDef options[] = {

> >       { "autorotate",       HAS_ARG | OPT_BOOL | OPT_SPEC |

> >                             OPT_EXPERT | OPT_INPUT,                                { .off =

> OFFSET(autorotate) },

> >           "automatically insert correct rotate filters" },

> > +    { "autoscale",        HAS_ARG | OPT_BOOL | OPT_SPEC |

> > +                          OPT_EXPERT | OPT_INPUT,                                { .off =

> OFFSET(autoscale) },

> > +        "automatically insert a scale filter at the end of the filter graph if a

> resolution"

> > +        "change is detected. This ensures all frames are the same resolution

> as the first frame"

> > +        "when they leave the filter chain (this option is enabled by default)."

> > +        "If disabled, some encoders/muxers may not support this mode."},

> Which muxers can detect or check for prop changes within coded

> bitstreams? Which encoders are known to be able to handle

> changing resolution?


It's not supported currently (even in libvpx-vp9, since vp9 supports dynamic resolution in spec).

I don't intend to be so absolutely in doc,  will it be better for you to modify like:
"If disabled, encoders/muxers won't support this mode currently."

- linjie
Linjie Fu July 23, 2019, 4:36 p.m.
> -----Original Message-----

> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On Behalf

> Of Fu, Linjie

> Sent: Monday, July 22, 2019 16:11

> To: FFmpeg development discussions and patches <ffmpeg-

> devel@ffmpeg.org>

> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -

> autoscale to disable/enable the default scale

> 

> > -----Original Message-----

> > From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On

> Behalf

> > Of Gyan

> > Sent: Saturday, July 20, 2019 13:29

> > To: ffmpeg-devel@ffmpeg.org

> > Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -

> > autoscale to disable/enable the default scale

> 

> > > diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi

> > > index cd35eb49c8..99121b6981 100644

> > > --- a/doc/ffmpeg.texi

> > > +++ b/doc/ffmpeg.texi

> > > +@item -autoscale

> > > +Automatically scale the video according to the resolution of first frame.

> > > +Enabled by default, use @option{-noautoscale} to disable it. When

> > autoscale is

> > > +disabled, all output frames might not be in the same resolution and may

> > require

> > > +some additional explicit processing according to your final

> > rendering/output

> > > +destination. Disabling autoscale may not work in all situations. Therefore,

> > it

> > > +is not recommended to disable it unless you really know what you are

> > doing.

> > > +Disable autoscale at your own risk.

> >

> > Since the auto scaling happens at the end of the graph, what may the

> > "additional explicit processing" be?

> 

> Vpp processing may not be influenced,  a warning in transcode is needed.

> The expression seems to be improper, how about:

> 

> "When autoscale is disabled, all output frames of filter graph might not be in

> the same

> resolution and may be inadequate for encoder/muxer."

> 

> or other suggestions?

> 

> > > @@ -3640,6 +3642,12 @@ const OptionDef options[] = {

> > >       { "autorotate",       HAS_ARG | OPT_BOOL | OPT_SPEC |

> > >                             OPT_EXPERT | OPT_INPUT,                                { .off =

> > OFFSET(autorotate) },

> > >           "automatically insert correct rotate filters" },

> > > +    { "autoscale",        HAS_ARG | OPT_BOOL | OPT_SPEC |

> > > +                          OPT_EXPERT | OPT_INPUT,                                { .off =

> > OFFSET(autoscale) },

> > > +        "automatically insert a scale filter at the end of the filter graph if a

> > resolution"

> > > +        "change is detected. This ensures all frames are the same resolution

> > as the first frame"

> > > +        "when they leave the filter chain (this option is enabled by

> default)."

> > > +        "If disabled, some encoders/muxers may not support this mode."},

> > Which muxers can detect or check for prop changes within coded

> > bitstreams? Which encoders are known to be able to handle

> > changing resolution?

> 

> It's not supported currently (even in libvpx-vp9, since vp9 supports dynamic

> resolution in spec).

> 

> I don't intend to be so absolutely in doc,  will it be better for you to modify

> like:

> "If disabled, encoders/muxers won't support this mode currently."

> 

Are these modifications acceptable?
If no against, will update a new version. Thanks.

- linjie
Gyan July 23, 2019, 4:48 p.m.
On 22-07-2019 01:40 PM, Fu, Linjie wrote:
>> -----Original Message-----
>> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On Behalf
>> Of Gyan
>> Sent: Saturday, July 20, 2019 13:29
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
>> autoscale to disable/enable the default scale
>>> diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
>>> index cd35eb49c8..99121b6981 100644
>>> --- a/doc/ffmpeg.texi
>>> +++ b/doc/ffmpeg.texi
>>> +@item -autoscale
>>> +Automatically scale the video according to the resolution of first frame.
>>> +Enabled by default, use @option{-noautoscale} to disable it. When
>> autoscale is
>>> +disabled, all output frames might not be in the same resolution and may
>> require
>>> +some additional explicit processing according to your final
>> rendering/output
>>> +destination. Disabling autoscale may not work in all situations. Therefore,
>> it
>>> +is not recommended to disable it unless you really know what you are
>> doing.
>>> +Disable autoscale at your own risk.
>> Since the auto scaling happens at the end of the graph, what may the
>> "additional explicit processing" be?
> Vpp processing may not be influenced,  a warning in transcode is needed.
> The expression seems to be improper, how about:
>
> "When autoscale is disabled, all output frames of filter graph might not be in the same
> resolution and may be inadequate for encoder/muxer."
>
> or other suggestions?
>
>>> @@ -3640,6 +3642,12 @@ const OptionDef options[] = {
>>>        { "autorotate",       HAS_ARG | OPT_BOOL | OPT_SPEC |
>>>                              OPT_EXPERT | OPT_INPUT,                                { .off =
>> OFFSET(autorotate) },
>>>            "automatically insert correct rotate filters" },
>>> +    { "autoscale",        HAS_ARG | OPT_BOOL | OPT_SPEC |
>>> +                          OPT_EXPERT | OPT_INPUT,                                { .off =
>> OFFSET(autoscale) },
>>> +        "automatically insert a scale filter at the end of the filter graph if a
>> resolution"
>>> +        "change is detected. This ensures all frames are the same resolution
>> as the first frame"
>>> +        "when they leave the filter chain (this option is enabled by default)."
>>> +        "If disabled, some encoders/muxers may not support this mode."},
>> Which muxers can detect or check for prop changes within coded
>> bitstreams? Which encoders are known to be able to handle
>> changing resolution?
> It's not supported currently (even in libvpx-vp9, since vp9 supports dynamic resolution in spec).
>
> I don't intend to be so absolutely in doc,  will it be better for you to modify like:
> "If disabled, encoders/muxers won't support this mode currently."

So other than    `-c:v rawvideo -f rawvideo`, there is no combination 
that supports changing frame sizes?

Gyan
Linjie Fu July 24, 2019, 2:45 a.m.
> -----Original Message-----

> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On Behalf

> Of Gyan

> Sent: Wednesday, July 24, 2019 00:49

> To: ffmpeg-devel@ffmpeg.org

> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -

> autoscale to disable/enable the default scale

> 

> 

> 

> On 22-07-2019 01:40 PM, Fu, Linjie wrote:

> >> -----Original Message-----

> >> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On

> Behalf

> >> Of Gyan

> >> Sent: Saturday, July 20, 2019 13:29

> >> To: ffmpeg-devel@ffmpeg.org

> >> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -

> >> autoscale to disable/enable the default scale

> >>> diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi

> >>> index cd35eb49c8..99121b6981 100644

> >>> --- a/doc/ffmpeg.texi

> >>> +++ b/doc/ffmpeg.texi

> >>> +@item -autoscale

> >>> +Automatically scale the video according to the resolution of first frame.

> >>> +Enabled by default, use @option{-noautoscale} to disable it. When

> >> autoscale is

> >>> +disabled, all output frames might not be in the same resolution and

> may

> >> require

> >>> +some additional explicit processing according to your final

> >> rendering/output

> >>> +destination. Disabling autoscale may not work in all situations.

> Therefore,

> >> it

> >>> +is not recommended to disable it unless you really know what you are

> >> doing.

> >>> +Disable autoscale at your own risk.

> >> Since the auto scaling happens at the end of the graph, what may the

> >> "additional explicit processing" be?

> > Vpp processing may not be influenced,  a warning in transcode is needed.

> > The expression seems to be improper, how about:

> >

> > "When autoscale is disabled, all output frames of filter graph might not be

> in the same

> > resolution and may be inadequate for encoder/muxer."

> >

> > or other suggestions?

> >

> >>> @@ -3640,6 +3642,12 @@ const OptionDef options[] = {

> >>>        { "autorotate",       HAS_ARG | OPT_BOOL | OPT_SPEC |

> >>>                              OPT_EXPERT | OPT_INPUT,                                { .off =

> >> OFFSET(autorotate) },

> >>>            "automatically insert correct rotate filters" },

> >>> +    { "autoscale",        HAS_ARG | OPT_BOOL | OPT_SPEC |

> >>> +                          OPT_EXPERT | OPT_INPUT,                                { .off =

> >> OFFSET(autoscale) },

> >>> +        "automatically insert a scale filter at the end of the filter graph if a

> >> resolution"

> >>> +        "change is detected. This ensures all frames are the same

> resolution

> >> as the first frame"

> >>> +        "when they leave the filter chain (this option is enabled by

> default)."

> >>> +        "If disabled, some encoders/muxers may not support this mode."},

> >> Which muxers can detect or check for prop changes within coded

> >> bitstreams? Which encoders are known to be able to handle

> >> changing resolution?

> > It's not supported currently (even in libvpx-vp9, since vp9 supports

> dynamic resolution in spec).

> >

> > I don't intend to be so absolutely in doc,  will it be better for you to modify

> like:

> > "If disabled, encoders/muxers won't support this mode currently."

> 

> So other than    `-c:v rawvideo -f rawvideo`, there is no combination

> that supports changing frame sizes?


I didn't check all encoders.
But since the resolution changing is detectable, some additional reinit procedures
can be added to change resolution at IDR frame and make the encoder works.
Gyan July 24, 2019, 4:28 a.m.
On 24-07-2019 08:15 AM, Fu, Linjie wrote:
>> -----Original Message-----
>> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On Behalf
>> Of Gyan
>> Sent: Wednesday, July 24, 2019 00:49
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
>> autoscale to disable/enable the default scale
>>
>>
>>
>> On 22-07-2019 01:40 PM, Fu, Linjie wrote:
>>>> -----Original Message-----
>>>> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On
>> Behalf
>>>> Of Gyan
>>>> Sent: Saturday, July 20, 2019 13:29
>>>> To: ffmpeg-devel@ffmpeg.org
>>>> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
>>>> autoscale to disable/enable the default scale
>>>>> diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
>>>>> index cd35eb49c8..99121b6981 100644
>>>>> --- a/doc/ffmpeg.texi
>>>>> +++ b/doc/ffmpeg.texi
>>>>> +@item -autoscale
>>>>> +Automatically scale the video according to the resolution of first frame.
>>>>> +Enabled by default, use @option{-noautoscale} to disable it. When
>>>> autoscale is
>>>>> +disabled, all output frames might not be in the same resolution and
>> may
>>>> require
>>>>> +some additional explicit processing according to your final
>>>> rendering/output
>>>>> +destination. Disabling autoscale may not work in all situations.
>> Therefore,
>>>> it
>>>>> +is not recommended to disable it unless you really know what you are
>>>> doing.
>>>>> +Disable autoscale at your own risk.
>>>> Since the auto scaling happens at the end of the graph, what may the
>>>> "additional explicit processing" be?
>>> Vpp processing may not be influenced,  a warning in transcode is needed.
>>> The expression seems to be improper, how about:
>>>
>>> "When autoscale is disabled, all output frames of filter graph might not be
>> in the same
>>> resolution and may be inadequate for encoder/muxer."
>>>
>>> or other suggestions?
>>>
>>>>> @@ -3640,6 +3642,12 @@ const OptionDef options[] = {
>>>>>         { "autorotate",       HAS_ARG | OPT_BOOL | OPT_SPEC |
>>>>>                               OPT_EXPERT | OPT_INPUT,                                { .off =
>>>> OFFSET(autorotate) },
>>>>>             "automatically insert correct rotate filters" },
>>>>> +    { "autoscale",        HAS_ARG | OPT_BOOL | OPT_SPEC |
>>>>> +                          OPT_EXPERT | OPT_INPUT,                                { .off =
>>>> OFFSET(autoscale) },
>>>>> +        "automatically insert a scale filter at the end of the filter graph if a
>>>> resolution"
>>>>> +        "change is detected. This ensures all frames are the same
>> resolution
>>>> as the first frame"
>>>>> +        "when they leave the filter chain (this option is enabled by
>> default)."
>>>>> +        "If disabled, some encoders/muxers may not support this mode."},
>>>> Which muxers can detect or check for prop changes within coded
>>>> bitstreams? Which encoders are known to be able to handle
>>>> changing resolution?
>>> It's not supported currently (even in libvpx-vp9, since vp9 supports
>> dynamic resolution in spec).
>>> I don't intend to be so absolutely in doc,  will it be better for you to modify
>> like:
>>> "If disabled, encoders/muxers won't support this mode currently."
>> So other than    `-c:v rawvideo -f rawvideo`, there is no combination
>> that supports changing frame sizes?
> I didn't check all encoders.
> But since the resolution changing is detectable, some additional reinit procedures
> can be added to change resolution at IDR frame and make the encoder works.
>
They could, but as of now, which encoder + muxer combinations are 
**known** to work?

Gyan
Linjie Fu July 24, 2019, 9:30 a.m.
> -----Original Message-----

> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On Behalf

> Of Gyan

> Sent: Wednesday, July 24, 2019 12:28

> To: ffmpeg-devel@ffmpeg.org

> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -

> autoscale to disable/enable the default scale

> 

> 

> 

> On 24-07-2019 08:15 AM, Fu, Linjie wrote:

> >> -----Original Message-----

> >> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On

> Behalf

> >> Of Gyan

> >> Sent: Wednesday, July 24, 2019 00:49

> >> To: ffmpeg-devel@ffmpeg.org

> >> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -

> >> autoscale to disable/enable the default scale

> >>

> >>

> >>

> >> On 22-07-2019 01:40 PM, Fu, Linjie wrote:

> >>>> -----Original Message-----

> >>>> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On

> >> Behalf

> >>>> Of Gyan

> >>>> Sent: Saturday, July 20, 2019 13:29

> >>>> To: ffmpeg-devel@ffmpeg.org

> >>>> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -

> >>>> autoscale to disable/enable the default scale

> >>>>> diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi

> >>>>> index cd35eb49c8..99121b6981 100644

> >>>>> --- a/doc/ffmpeg.texi

> >>>>> +++ b/doc/ffmpeg.texi

> >>>>> +@item -autoscale

> >>>>> +Automatically scale the video according to the resolution of first

> frame.

> >>>>> +Enabled by default, use @option{-noautoscale} to disable it. When

> >>>> autoscale is

> >>>>> +disabled, all output frames might not be in the same resolution and

> >> may

> >>>> require

> >>>>> +some additional explicit processing according to your final

> >>>> rendering/output

> >>>>> +destination. Disabling autoscale may not work in all situations.

> >> Therefore,

> >>>> it

> >>>>> +is not recommended to disable it unless you really know what you

> are

> >>>> doing.

> >>>>> +Disable autoscale at your own risk.

> >>>> Since the auto scaling happens at the end of the graph, what may the

> >>>> "additional explicit processing" be?

> >>> Vpp processing may not be influenced,  a warning in transcode is needed.

> >>> The expression seems to be improper, how about:

> >>>

> >>> "When autoscale is disabled, all output frames of filter graph might not

> be

> >> in the same

> >>> resolution and may be inadequate for encoder/muxer."

> >>>

> >>> or other suggestions?

> >>>

> >>>>> @@ -3640,6 +3642,12 @@ const OptionDef options[] = {

> >>>>>         { "autorotate",       HAS_ARG | OPT_BOOL | OPT_SPEC |

> >>>>>                               OPT_EXPERT | OPT_INPUT,                                { .off =

> >>>> OFFSET(autorotate) },

> >>>>>             "automatically insert correct rotate filters" },

> >>>>> +    { "autoscale",        HAS_ARG | OPT_BOOL | OPT_SPEC |

> >>>>> +                          OPT_EXPERT | OPT_INPUT,                                { .off =

> >>>> OFFSET(autoscale) },

> >>>>> +        "automatically insert a scale filter at the end of the filter graph if

> a

> >>>> resolution"

> >>>>> +        "change is detected. This ensures all frames are the same

> >> resolution

> >>>> as the first frame"

> >>>>> +        "when they leave the filter chain (this option is enabled by

> >> default)."

> >>>>> +        "If disabled, some encoders/muxers may not support this

> mode."},

> >>>> Which muxers can detect or check for prop changes within coded

> >>>> bitstreams? Which encoders are known to be able to handle

> >>>> changing resolution?

> >>> It's not supported currently (even in libvpx-vp9, since vp9 supports

> >> dynamic resolution in spec).

> >>> I don't intend to be so absolutely in doc,  will it be better for you to

> modify

> >> like:

> >>> "If disabled, encoders/muxers won't support this mode currently."

> >> So other than    `-c:v rawvideo -f rawvideo`, there is no combination

> >> that supports changing frame sizes?

> > I didn't check all encoders.

> > But since the resolution changing is detectable, some additional reinit

> procedures

> > can be added to change resolution at IDR frame and make the encoder

> works.

> >

> They could, but as of now, which encoder + muxer combinations are

> **known** to work?

> 

As far as I tried, no.
(pipeline failed in libx264,  garbage exists in libx265 and libvpx-vp9 )
Paul B Mahol July 24, 2019, 9:42 a.m.
On 7/24/19, Fu, Linjie <linjie.fu@intel.com> wrote:
>> -----Original Message-----
>> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On Behalf
>> Of Gyan
>> Sent: Wednesday, July 24, 2019 12:28
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
>> autoscale to disable/enable the default scale
>>
>>
>>
>> On 24-07-2019 08:15 AM, Fu, Linjie wrote:
>> >> -----Original Message-----
>> >> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On
>> Behalf
>> >> Of Gyan
>> >> Sent: Wednesday, July 24, 2019 00:49
>> >> To: ffmpeg-devel@ffmpeg.org
>> >> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
>> >> autoscale to disable/enable the default scale
>> >>
>> >>
>> >>
>> >> On 22-07-2019 01:40 PM, Fu, Linjie wrote:
>> >>>> -----Original Message-----
>> >>>> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On
>> >> Behalf
>> >>>> Of Gyan
>> >>>> Sent: Saturday, July 20, 2019 13:29
>> >>>> To: ffmpeg-devel@ffmpeg.org
>> >>>> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
>> >>>> autoscale to disable/enable the default scale
>> >>>>> diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
>> >>>>> index cd35eb49c8..99121b6981 100644
>> >>>>> --- a/doc/ffmpeg.texi
>> >>>>> +++ b/doc/ffmpeg.texi
>> >>>>> +@item -autoscale
>> >>>>> +Automatically scale the video according to the resolution of first
>> frame.
>> >>>>> +Enabled by default, use @option{-noautoscale} to disable it. When
>> >>>> autoscale is
>> >>>>> +disabled, all output frames might not be in the same resolution
>> >>>>> and
>> >> may
>> >>>> require
>> >>>>> +some additional explicit processing according to your final
>> >>>> rendering/output
>> >>>>> +destination. Disabling autoscale may not work in all situations.
>> >> Therefore,
>> >>>> it
>> >>>>> +is not recommended to disable it unless you really know what you
>> are
>> >>>> doing.
>> >>>>> +Disable autoscale at your own risk.
>> >>>> Since the auto scaling happens at the end of the graph, what may the
>> >>>> "additional explicit processing" be?
>> >>> Vpp processing may not be influenced,  a warning in transcode is
>> >>> needed.
>> >>> The expression seems to be improper, how about:
>> >>>
>> >>> "When autoscale is disabled, all output frames of filter graph might
>> >>> not
>> be
>> >> in the same
>> >>> resolution and may be inadequate for encoder/muxer."
>> >>>
>> >>> or other suggestions?
>> >>>
>> >>>>> @@ -3640,6 +3642,12 @@ const OptionDef options[] = {
>> >>>>>         { "autorotate",       HAS_ARG | OPT_BOOL | OPT_SPEC |
>> >>>>>                               OPT_EXPERT | OPT_INPUT,
>> >>>>>                 { .off =
>> >>>> OFFSET(autorotate) },
>> >>>>>             "automatically insert correct rotate filters" },
>> >>>>> +    { "autoscale",        HAS_ARG | OPT_BOOL | OPT_SPEC |
>> >>>>> +                          OPT_EXPERT | OPT_INPUT,
>> >>>>>              { .off =
>> >>>> OFFSET(autoscale) },
>> >>>>> +        "automatically insert a scale filter at the end of the
>> >>>>> filter graph if
>> a
>> >>>> resolution"
>> >>>>> +        "change is detected. This ensures all frames are the same
>> >> resolution
>> >>>> as the first frame"
>> >>>>> +        "when they leave the filter chain (this option is enabled
>> >>>>> by
>> >> default)."
>> >>>>> +        "If disabled, some encoders/muxers may not support this
>> mode."},
>> >>>> Which muxers can detect or check for prop changes within coded
>> >>>> bitstreams? Which encoders are known to be able to handle
>> >>>> changing resolution?
>> >>> It's not supported currently (even in libvpx-vp9, since vp9 supports
>> >> dynamic resolution in spec).
>> >>> I don't intend to be so absolutely in doc,  will it be better for you
>> >>> to
>> modify
>> >> like:
>> >>> "If disabled, encoders/muxers won't support this mode currently."
>> >> So other than    `-c:v rawvideo -f rawvideo`, there is no combination
>> >> that supports changing frame sizes?
>> > I didn't check all encoders.
>> > But since the resolution changing is detectable, some additional reinit
>> procedures
>> > can be added to change resolution at IDR frame and make the encoder
>> works.
>> >
>> They could, but as of now, which encoder + muxer combinations are
>> **known** to work?
>>
> As far as I tried, no.
> (pipeline failed in libx264,  garbage exists in libx265 and libvpx-vp9 )

Than how this change can be useful to us?

It will just increase maintenance burden on other developers.
Linjie Fu July 24, 2019, 12:44 p.m.
> -----Original Message-----

> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On Behalf

> Of Paul B Mahol

> Sent: Wednesday, July 24, 2019 17:42

> To: FFmpeg development discussions and patches <ffmpeg-

> devel@ffmpeg.org>

> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -

> autoscale to disable/enable the default scale

> 

> On 7/24/19, Fu, Linjie <linjie.fu@intel.com> wrote:

> >> -----Original Message-----

> >> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On

> Behalf

> >> Of Gyan

> >> Sent: Wednesday, July 24, 2019 12:28

> >> To: ffmpeg-devel@ffmpeg.org

> >> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -

> >> autoscale to disable/enable the default scale

> >>

> >>

> >>

> >> On 24-07-2019 08:15 AM, Fu, Linjie wrote:

> >> >> -----Original Message-----

> >> >> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On

> >> Behalf

> >> >> Of Gyan

> >> >> Sent: Wednesday, July 24, 2019 00:49

> >> >> To: ffmpeg-devel@ffmpeg.org

> >> >> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -

> >> >> autoscale to disable/enable the default scale

> >> >>

> >> >>

> >> >>

> >> >> On 22-07-2019 01:40 PM, Fu, Linjie wrote:

> >> >>>> -----Original Message-----

> >> >>>> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org]

> On

> >> >> Behalf

> >> >>>> Of Gyan

> >> >>>> Sent: Saturday, July 20, 2019 13:29

> >> >>>> To: ffmpeg-devel@ffmpeg.org

> >> >>>> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add

> -

> >> >>>> autoscale to disable/enable the default scale

> >> >>>>> diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi

> >> >>>>> index cd35eb49c8..99121b6981 100644

> >> >>>>> --- a/doc/ffmpeg.texi

> >> >>>>> +++ b/doc/ffmpeg.texi

> >> >>>>> +@item -autoscale

> >> >>>>> +Automatically scale the video according to the resolution of first

> >> frame.

> >> >>>>> +Enabled by default, use @option{-noautoscale} to disable it.

> When

> >> >>>> autoscale is

> >> >>>>> +disabled, all output frames might not be in the same resolution

> >> >>>>> and

> >> >> may

> >> >>>> require

> >> >>>>> +some additional explicit processing according to your final

> >> >>>> rendering/output

> >> >>>>> +destination. Disabling autoscale may not work in all situations.

> >> >> Therefore,

> >> >>>> it

> >> >>>>> +is not recommended to disable it unless you really know what

> you

> >> are

> >> >>>> doing.

> >> >>>>> +Disable autoscale at your own risk.

> >> >>>> Since the auto scaling happens at the end of the graph, what may

> the

> >> >>>> "additional explicit processing" be?

> >> >>> Vpp processing may not be influenced,  a warning in transcode is

> >> >>> needed.

> >> >>> The expression seems to be improper, how about:

> >> >>>

> >> >>> "When autoscale is disabled, all output frames of filter graph might

> >> >>> not

> >> be

> >> >> in the same

> >> >>> resolution and may be inadequate for encoder/muxer."

> >> >>>

> >> >>> or other suggestions?

> >> >>>

> >> >>>>> @@ -3640,6 +3642,12 @@ const OptionDef options[] = {

> >> >>>>>         { "autorotate",       HAS_ARG | OPT_BOOL | OPT_SPEC |

> >> >>>>>                               OPT_EXPERT | OPT_INPUT,

> >> >>>>>                 { .off =

> >> >>>> OFFSET(autorotate) },

> >> >>>>>             "automatically insert correct rotate filters" },

> >> >>>>> +    { "autoscale",        HAS_ARG | OPT_BOOL | OPT_SPEC |

> >> >>>>> +                          OPT_EXPERT | OPT_INPUT,

> >> >>>>>              { .off =

> >> >>>> OFFSET(autoscale) },

> >> >>>>> +        "automatically insert a scale filter at the end of the

> >> >>>>> filter graph if

> >> a

> >> >>>> resolution"

> >> >>>>> +        "change is detected. This ensures all frames are the same

> >> >> resolution

> >> >>>> as the first frame"

> >> >>>>> +        "when they leave the filter chain (this option is enabled

> >> >>>>> by

> >> >> default)."

> >> >>>>> +        "If disabled, some encoders/muxers may not support this

> >> mode."},

> >> >>>> Which muxers can detect or check for prop changes within coded

> >> >>>> bitstreams? Which encoders are known to be able to handle

> >> >>>> changing resolution?

> >> >>> It's not supported currently (even in libvpx-vp9, since vp9 supports

> >> >> dynamic resolution in spec).

> >> >>> I don't intend to be so absolutely in doc,  will it be better for you

> >> >>> to

> >> modify

> >> >> like:

> >> >>> "If disabled, encoders/muxers won't support this mode currently."

> >> >> So other than    `-c:v rawvideo -f rawvideo`, there is no combination

> >> >> that supports changing frame sizes?

> >> > I didn't check all encoders.

> >> > But since the resolution changing is detectable, some additional reinit

> >> procedures

> >> > can be added to change resolution at IDR frame and make the encoder

> >> works.

> >> >

> >> They could, but as of now, which encoder + muxer combinations are

> >> **known** to work?

> >>

> > As far as I tried, no.

> > (pipeline failed in libx264,  garbage exists in libx265 and libvpx-vp9 )

> 

> Than how this change can be useful to us?

> 

> It will just increase maintenance burden on other developers.


Why? 
This option does no harm to current filter graph since auto scale is enabled by default,
and won't be disabled only if user really knows what he is doing.

It could be used  for raw video dump currently, and provided the possibility for dynamic
Resolution encoding as well. 

- linjie
Paul B Mahol July 24, 2019, 1:16 p.m.
On 7/24/19, Fu, Linjie <linjie.fu@intel.com> wrote:
>> -----Original Message-----
>> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On Behalf
>> Of Paul B Mahol
>> Sent: Wednesday, July 24, 2019 17:42
>> To: FFmpeg development discussions and patches <ffmpeg-
>> devel@ffmpeg.org>
>> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
>> autoscale to disable/enable the default scale
>>
>> On 7/24/19, Fu, Linjie <linjie.fu@intel.com> wrote:
>> >> -----Original Message-----
>> >> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On
>> Behalf
>> >> Of Gyan
>> >> Sent: Wednesday, July 24, 2019 12:28
>> >> To: ffmpeg-devel@ffmpeg.org
>> >> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
>> >> autoscale to disable/enable the default scale
>> >>
>> >>
>> >>
>> >> On 24-07-2019 08:15 AM, Fu, Linjie wrote:
>> >> >> -----Original Message-----
>> >> >> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On
>> >> Behalf
>> >> >> Of Gyan
>> >> >> Sent: Wednesday, July 24, 2019 00:49
>> >> >> To: ffmpeg-devel@ffmpeg.org
>> >> >> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add
>> >> >> -
>> >> >> autoscale to disable/enable the default scale
>> >> >>
>> >> >>
>> >> >>
>> >> >> On 22-07-2019 01:40 PM, Fu, Linjie wrote:
>> >> >>>> -----Original Message-----
>> >> >>>> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org]
>> On
>> >> >> Behalf
>> >> >>>> Of Gyan
>> >> >>>> Sent: Saturday, July 20, 2019 13:29
>> >> >>>> To: ffmpeg-devel@ffmpeg.org
>> >> >>>> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter:
>> >> >>>> add
>> -
>> >> >>>> autoscale to disable/enable the default scale
>> >> >>>>> diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
>> >> >>>>> index cd35eb49c8..99121b6981 100644
>> >> >>>>> --- a/doc/ffmpeg.texi
>> >> >>>>> +++ b/doc/ffmpeg.texi
>> >> >>>>> +@item -autoscale
>> >> >>>>> +Automatically scale the video according to the resolution of
>> >> >>>>> first
>> >> frame.
>> >> >>>>> +Enabled by default, use @option{-noautoscale} to disable it.
>> When
>> >> >>>> autoscale is
>> >> >>>>> +disabled, all output frames might not be in the same resolution
>> >> >>>>> and
>> >> >> may
>> >> >>>> require
>> >> >>>>> +some additional explicit processing according to your final
>> >> >>>> rendering/output
>> >> >>>>> +destination. Disabling autoscale may not work in all
>> >> >>>>> situations.
>> >> >> Therefore,
>> >> >>>> it
>> >> >>>>> +is not recommended to disable it unless you really know what
>> you
>> >> are
>> >> >>>> doing.
>> >> >>>>> +Disable autoscale at your own risk.
>> >> >>>> Since the auto scaling happens at the end of the graph, what may
>> the
>> >> >>>> "additional explicit processing" be?
>> >> >>> Vpp processing may not be influenced,  a warning in transcode is
>> >> >>> needed.
>> >> >>> The expression seems to be improper, how about:
>> >> >>>
>> >> >>> "When autoscale is disabled, all output frames of filter graph
>> >> >>> might
>> >> >>> not
>> >> be
>> >> >> in the same
>> >> >>> resolution and may be inadequate for encoder/muxer."
>> >> >>>
>> >> >>> or other suggestions?
>> >> >>>
>> >> >>>>> @@ -3640,6 +3642,12 @@ const OptionDef options[] = {
>> >> >>>>>         { "autorotate",       HAS_ARG | OPT_BOOL | OPT_SPEC |
>> >> >>>>>                               OPT_EXPERT | OPT_INPUT,
>> >> >>>>>                 { .off =
>> >> >>>> OFFSET(autorotate) },
>> >> >>>>>             "automatically insert correct rotate filters" },
>> >> >>>>> +    { "autoscale",        HAS_ARG | OPT_BOOL | OPT_SPEC |
>> >> >>>>> +                          OPT_EXPERT | OPT_INPUT,
>> >> >>>>>              { .off =
>> >> >>>> OFFSET(autoscale) },
>> >> >>>>> +        "automatically insert a scale filter at the end of the
>> >> >>>>> filter graph if
>> >> a
>> >> >>>> resolution"
>> >> >>>>> +        "change is detected. This ensures all frames are the
>> >> >>>>> same
>> >> >> resolution
>> >> >>>> as the first frame"
>> >> >>>>> +        "when they leave the filter chain (this option is
>> >> >>>>> enabled
>> >> >>>>> by
>> >> >> default)."
>> >> >>>>> +        "If disabled, some encoders/muxers may not support this
>> >> mode."},
>> >> >>>> Which muxers can detect or check for prop changes within coded
>> >> >>>> bitstreams? Which encoders are known to be able to handle
>> >> >>>> changing resolution?
>> >> >>> It's not supported currently (even in libvpx-vp9, since vp9
>> >> >>> supports
>> >> >> dynamic resolution in spec).
>> >> >>> I don't intend to be so absolutely in doc,  will it be better for
>> >> >>> you
>> >> >>> to
>> >> modify
>> >> >> like:
>> >> >>> "If disabled, encoders/muxers won't support this mode currently."
>> >> >> So other than    `-c:v rawvideo -f rawvideo`, there is no
>> >> >> combination
>> >> >> that supports changing frame sizes?
>> >> > I didn't check all encoders.
>> >> > But since the resolution changing is detectable, some additional
>> >> > reinit
>> >> procedures
>> >> > can be added to change resolution at IDR frame and make the encoder
>> >> works.
>> >> >
>> >> They could, but as of now, which encoder + muxer combinations are
>> >> **known** to work?
>> >>
>> > As far as I tried, no.
>> > (pipeline failed in libx264,  garbage exists in libx265 and libvpx-vp9
>> > )
>>
>> Than how this change can be useful to us?
>>
>> It will just increase maintenance burden on other developers.
>
> Why?
> This option does no harm to current filter graph since auto scale is enabled
> by default,
> and won't be disabled only if user really knows what he is doing.
>
> It could be used  for raw video dump currently, and provided the possibility
> for dynamic
> Resolution encoding as well.
>

It is incomplete functionality at best.
Linjie Fu July 28, 2019, 10:01 a.m.
> -----Original Message-----

> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On Behalf

> Of Paul B Mahol

> Sent: Wednesday, July 24, 2019 21:17

> To: FFmpeg development discussions and patches <ffmpeg-

> devel@ffmpeg.org>

> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -

> autoscale to disable/enable the default scale

> 

> On 7/24/19, Fu, Linjie <linjie.fu@intel.com> wrote:

> >> -----Original Message-----

> >> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On

> Behalf

> >> Of Paul B Mahol

> >> Sent: Wednesday, July 24, 2019 17:42

> >> To: FFmpeg development discussions and patches <ffmpeg-

> >> devel@ffmpeg.org>

> >> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -

> >> autoscale to disable/enable the default scale

> >>

> >> On 7/24/19, Fu, Linjie <linjie.fu@intel.com> wrote:

> >> >> -----Original Message-----

> >> >> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On

> >> Behalf

> >> >> Of Gyan

> >> >> Sent: Wednesday, July 24, 2019 12:28

> >> >> To: ffmpeg-devel@ffmpeg.org

> >> >> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -

> >> >> autoscale to disable/enable the default scale

> >> >>

> >> >>

> >> >>

> >> >> On 24-07-2019 08:15 AM, Fu, Linjie wrote:

> >> >> >> -----Original Message-----

> >> >> >> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org]

> On

> >> >> Behalf

> >> >> >> Of Gyan

> >> >> >> Sent: Wednesday, July 24, 2019 00:49

> >> >> >> To: ffmpeg-devel@ffmpeg.org

> >> >> >> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add

> >> >> >> -

> >> >> >> autoscale to disable/enable the default scale

> >> >> >>

> >> >> >>

> >> >> >>

> >> >> >> On 22-07-2019 01:40 PM, Fu, Linjie wrote:

> >> >> >>>> -----Original Message-----

> >> >> >>>> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org]

> >> On

> >> >> >> Behalf

> >> >> >>>> Of Gyan

> >> >> >>>> Sent: Saturday, July 20, 2019 13:29

> >> >> >>>> To: ffmpeg-devel@ffmpeg.org

> >> >> >>>> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter:

> >> >> >>>> add

> >> -

> >> >> >>>> autoscale to disable/enable the default scale

> >> >> >>>>> diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi

> >> >> >>>>> index cd35eb49c8..99121b6981 100644

> >> >> >>>>> --- a/doc/ffmpeg.texi

> >> >> >>>>> +++ b/doc/ffmpeg.texi

> >> >> >>>>> +@item -autoscale

> >> >> >>>>> +Automatically scale the video according to the resolution of

> >> >> >>>>> first

> >> >> frame.

> >> >> >>>>> +Enabled by default, use @option{-noautoscale} to disable it.

> >> When

> >> >> >>>> autoscale is

> >> >> >>>>> +disabled, all output frames might not be in the same

> resolution

> >> >> >>>>> and

> >> >> >> may

> >> >> >>>> require

> >> >> >>>>> +some additional explicit processing according to your final

> >> >> >>>> rendering/output

> >> >> >>>>> +destination. Disabling autoscale may not work in all

> >> >> >>>>> situations.

> >> >> >> Therefore,

> >> >> >>>> it

> >> >> >>>>> +is not recommended to disable it unless you really know what

> >> you

> >> >> are

> >> >> >>>> doing.

> >> >> >>>>> +Disable autoscale at your own risk.

> >> >> >>>> Since the auto scaling happens at the end of the graph, what may

> >> the

> >> >> >>>> "additional explicit processing" be?

> >> >> >>> Vpp processing may not be influenced,  a warning in transcode is

> >> >> >>> needed.

> >> >> >>> The expression seems to be improper, how about:

> >> >> >>>

> >> >> >>> "When autoscale is disabled, all output frames of filter graph

> >> >> >>> might

> >> >> >>> not

> >> >> be

> >> >> >> in the same

> >> >> >>> resolution and may be inadequate for encoder/muxer."

> >> >> >>>

> >> >> >>> or other suggestions?

> >> >> >>>

> >> >> >>>>> @@ -3640,6 +3642,12 @@ const OptionDef options[] = {

> >> >> >>>>>         { "autorotate",       HAS_ARG | OPT_BOOL | OPT_SPEC |

> >> >> >>>>>                               OPT_EXPERT | OPT_INPUT,

> >> >> >>>>>                 { .off =

> >> >> >>>> OFFSET(autorotate) },

> >> >> >>>>>             "automatically insert correct rotate filters" },

> >> >> >>>>> +    { "autoscale",        HAS_ARG | OPT_BOOL | OPT_SPEC |

> >> >> >>>>> +                          OPT_EXPERT | OPT_INPUT,

> >> >> >>>>>              { .off =

> >> >> >>>> OFFSET(autoscale) },

> >> >> >>>>> +        "automatically insert a scale filter at the end of the

> >> >> >>>>> filter graph if

> >> >> a

> >> >> >>>> resolution"

> >> >> >>>>> +        "change is detected. This ensures all frames are the

> >> >> >>>>> same

> >> >> >> resolution

> >> >> >>>> as the first frame"

> >> >> >>>>> +        "when they leave the filter chain (this option is

> >> >> >>>>> enabled

> >> >> >>>>> by

> >> >> >> default)."

> >> >> >>>>> +        "If disabled, some encoders/muxers may not support this

> >> >> mode."},

> >> >> >>>> Which muxers can detect or check for prop changes within coded

> >> >> >>>> bitstreams? Which encoders are known to be able to handle

> >> >> >>>> changing resolution?

> >> >> >>> It's not supported currently (even in libvpx-vp9, since vp9

> >> >> >>> supports

> >> >> >> dynamic resolution in spec).

> >> >> >>> I don't intend to be so absolutely in doc,  will it be better for

> >> >> >>> you

> >> >> >>> to

> >> >> modify

> >> >> >> like:

> >> >> >>> "If disabled, encoders/muxers won't support this mode

> currently."

> >> >> >> So other than    `-c:v rawvideo -f rawvideo`, there is no

> >> >> >> combination

> >> >> >> that supports changing frame sizes?

> >> >> > I didn't check all encoders.

> >> >> > But since the resolution changing is detectable, some additional

> >> >> > reinit

> >> >> procedures

> >> >> > can be added to change resolution at IDR frame and make the

> encoder

> >> >> works.

> >> >> >

> >> >> They could, but as of now, which encoder + muxer combinations are

> >> >> **known** to work?

> >> >>

> >> > As far as I tried, no.

> >> > (pipeline failed in libx264,  garbage exists in libx265 and libvpx-vp9

> >> > )

> >>

> >> Than how this change can be useful to us?

> >>

> >> It will just increase maintenance burden on other developers.

> >

> > Why?

> > This option does no harm to current filter graph since auto scale is enabled

> > by default,

> > and won't be disabled only if user really knows what he is doing.

> >

> > It could be used  for raw video dump currently, and provided the possibility

> > for dynamic

> > Resolution encoding as well.

> >

> 

> It is incomplete functionality at best.


Provided a patch to support dynamic resolution encode for libvpx-vp9.
Thus "noautoscale" option makes more sense in transcode.
Please help to review.

- linjie

Patch hide | download patch | download mbox

diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index cd35eb49c8..99121b6981 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -734,10 +734,6 @@  ffmpeg -dump_attachment:t "" -i INPUT
 Technical note -- attachments are implemented as codec extradata, so this
 option can actually be used to extract extradata from any stream, not just
 attachments.
-
-@item -noautorotate
-Disable automatically rotating video based on file metadata.
-
 @end table
 
 @section Video Options
@@ -819,6 +815,19 @@  Create the filtergraph specified by @var{filtergraph} and use it to
 filter the stream.
 
 This is an alias for @code{-filter:v}, see the @ref{filter_option,,-filter option}.
+
+@item -autorotate
+Automatically rotate the video according to file metadata. Enabled by
+default, use @option{-noautorotate} to disable it.
+
+@item -autoscale
+Automatically scale the video according to the resolution of first frame.
+Enabled by default, use @option{-noautoscale} to disable it. When autoscale is
+disabled, all output frames might not be in the same resolution and may require
+some additional explicit processing according to your final rendering/output
+destination. Disabling autoscale may not work in all situations. Therefore, it
+is not recommended to disable it unless you really know what you are doing.
+Disable autoscale at your own risk.
 @end table
 
 @section Advanced Video options
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 01f04103cf..5d52430b1e 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -2133,6 +2133,7 @@  static int ifilter_send_frame(InputFilter *ifilter, AVFrame *frame)
 
     /* determine if the parameters for this input changed */
     need_reinit = ifilter->format != frame->format;
+    fg->autoscale = ifilter->ist->autoscale;
 
     switch (ifilter->ist->st->codecpar->codec_type) {
     case AVMEDIA_TYPE_AUDIO:
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 7b6f802082..1602406581 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -133,6 +133,8 @@  typedef struct OptionsContext {
     int        nb_hwaccel_output_formats;
     SpecifierOpt *autorotate;
     int        nb_autorotate;
+    SpecifierOpt *autoscale;
+    int        nb_autoscale;
 
     /* output options */
     StreamMap *stream_maps;
@@ -285,6 +287,7 @@  typedef struct FilterGraph {
 
     AVFilterGraph *graph;
     int reconfiguration;
+    int autoscale;
 
     InputFilter   **inputs;
     int          nb_inputs;
@@ -335,6 +338,7 @@  typedef struct InputStream {
     int guess_layout_max;
 
     int autorotate;
+    int autoscale;
 
     int fix_sub_duration;
     struct { /* previous decoded subtitle and related variables */
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 72838de1e2..2a2eb080eb 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -469,7 +469,7 @@  static int configure_output_video_filter(FilterGraph *fg, OutputFilter *ofilter,
     if (ret < 0)
         return ret;
 
-    if (ofilter->width || ofilter->height) {
+    if ((ofilter->width || ofilter->height) && fg->autoscale) {
         char args[255];
         AVFilterContext *filter;
         AVDictionaryEntry *e = NULL;
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index f5ca18aa64..41cb676dad 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -742,7 +742,9 @@  static void add_input_streams(OptionsContext *o, AVFormatContext *ic)
         MATCH_PER_STREAM_OPT(ts_scale, dbl, ist->ts_scale, ic, st);
 
         ist->autorotate = 1;
+        ist->autoscale  = 1;
         MATCH_PER_STREAM_OPT(autorotate, i, ist->autorotate, ic, st);
+        MATCH_PER_STREAM_OPT(autoscale, i, ist->autoscale, ic, st);
 
         MATCH_PER_STREAM_OPT(codec_tags, str, codec_tag, ic, st);
         if (codec_tag) {
@@ -3640,6 +3642,12 @@  const OptionDef options[] = {
     { "autorotate",       HAS_ARG | OPT_BOOL | OPT_SPEC |
                           OPT_EXPERT | OPT_INPUT,                                { .off = OFFSET(autorotate) },
         "automatically insert correct rotate filters" },
+    { "autoscale",        HAS_ARG | OPT_BOOL | OPT_SPEC |
+                          OPT_EXPERT | OPT_INPUT,                                { .off = OFFSET(autoscale) },
+        "automatically insert a scale filter at the end of the filter graph if a resolution"
+        "change is detected. This ensures all frames are the same resolution as the first frame"
+        "when they leave the filter chain (this option is enabled by default)."
+        "If disabled, some encoders/muxers may not support this mode."},
 
     /* audio options */
     { "aframes",        OPT_AUDIO | HAS_ARG  | OPT_PERFILE | OPT_OUTPUT,           { .func_arg = opt_audio_frames },