> -----Original Message----- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Gyan > Sent: Saturday, July 20, 2019 13:29 > To: ffmpeg-devel@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 > > +@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." - linjie _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".