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