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