On 7/24/19, Fu, Linjie <linjie...@intel.com> wrote: >> -----Original Message----- >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf >> Of Paul B Mahol >> Sent: Wednesday, July 24, 2019 17:42 >> To: FFmpeg development discussions and patches <ffmpeg- >> de...@ffmpeg.org> >> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add - >> autoscale to disable/enable the default scale >> >> 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. > > Why? > This option does no harm to current filter graph since auto scale is enabled > by default, > and won't be disabled only if user really knows what he is doing. > > It could be used for raw video dump currently, and provided the possibility > for dynamic > Resolution encoding as well. >
It is incomplete functionality at best. _______________________________________________ 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".
