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