On 7/24/19, Fu, Linjie <linjie...@intel.com> wrote: >> -----Original Message----- >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf >> Of Gyan >> Sent: Wednesday, July 24, 2019 12:28 >> To: ffmpeg-devel@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-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. >> > >> 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 )
Than how this change can be useful to us? It will just increase maintenance burden on other developers. _______________________________________________ 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".
