> -----Original Message----- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Paul B Mahol > Sent: Wednesday, July 24, 2019 21:17 > 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 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.
Provided a patch to support dynamic resolution encode for libvpx-vp9. Thus "noautoscale" option makes more sense in transcode. Please help to review. - 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".