> -----Original Message----- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Gyan > Sent: Wednesday, July 24, 2019 00:49 > To: ffmpeg-devel@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-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." > > 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. _______________________________________________ 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".
