[FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -autoscale to disable/enable the default scale
Fu, Linjie
linjie.fu at intel.com
Wed Jul 24 05:45:12 EEST 2019
> -----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.
More information about the ffmpeg-devel
mailing list