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

[Paul B Mahol]

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 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.
>

It is incomplete functionality at best.