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

[Fu, Linjie]

> -----Original Message-----
> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On Behalf
> Of Paul B Mahol
> Sent: Wednesday, July 24, 2019 17:42
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at 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 at intel.com> wrote:
> >> -----Original Message-----
> >> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On
> Behalf
> >> Of Gyan
> >> Sent: Wednesday, July 24, 2019 12:28
> >> To: ffmpeg-devel at 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 at ffmpeg.org] On
> >> Behalf
> >> >> Of Gyan
> >> >> Sent: Wednesday, July 24, 2019 00:49
> >> >> To: ffmpeg-devel at 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 at ffmpeg.org]
> On
> >> >> Behalf
> >> >>>> Of Gyan
> >> >>>> Sent: Saturday, July 20, 2019 13:29
> >> >>>> To: ffmpeg-devel at 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
> >> >>>>> + at 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