| Message ID | 20190719173439.25077-1-linjie.fu@intel.com |
|---|---|
| State | Superseded |
| Headers | show |
On 19-07-2019 11:04 PM, Linjie Fu wrote: > Currently, ffmpeg inserts scale filter by default in the filter graph > to force the whole decoded stream to scale into the same size with the > first frame. It's not quite make sense in resolution changing cases if > user wants the rawvideo without any scale. > > Using autoscale/noautoscale to indicate whether auto inserting the scale > filter in the filter graph: > -noautoscale or -autoscale 0: > disable the default auto scale filter inserting. > > Update docs. > > Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com> > Signed-off-by: Linjie Fu <linjie.fu@intel.com> > --- > doc/ffmpeg.texi | 17 +++++++++++++---- > fftools/ffmpeg.c | 1 + > fftools/ffmpeg.h | 4 ++++ > fftools/ffmpeg_filter.c | 2 +- > fftools/ffmpeg_opt.c | 8 ++++++++ > 5 files changed, 27 insertions(+), 5 deletions(-) > > diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi > index cd35eb49c8..99121b6981 100644 > --- a/doc/ffmpeg.texi > +++ b/doc/ffmpeg.texi > @@ -734,10 +734,6 @@ ffmpeg -dump_attachment:t "" -i INPUT > Technical note -- attachments are implemented as codec extradata, so this > option can actually be used to extract extradata from any stream, not just > attachments. > - > -@item -noautorotate > -Disable automatically rotating video based on file metadata. > - > @end table > > @section Video Options > @@ -819,6 +815,19 @@ Create the filtergraph specified by @var{filtergraph} and use it to > filter the stream. > > This is an alias for @code{-filter:v}, see the @ref{filter_option,,-filter option}. > + > +@item -autorotate > +Automatically rotate the video according to file metadata. Enabled by > +default, use @option{-noautorotate} to disable it. > + > +@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? > @end table > > @section Advanced Video options > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c > index 01f04103cf..5d52430b1e 100644 > --- a/fftools/ffmpeg.c > +++ b/fftools/ffmpeg.c > @@ -2133,6 +2133,7 @@ static int ifilter_send_frame(InputFilter *ifilter, AVFrame *frame) > > /* determine if the parameters for this input changed */ > need_reinit = ifilter->format != frame->format; > + fg->autoscale = ifilter->ist->autoscale; > > switch (ifilter->ist->st->codecpar->codec_type) { > case AVMEDIA_TYPE_AUDIO: > diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h > index 7b6f802082..1602406581 100644 > --- a/fftools/ffmpeg.h > +++ b/fftools/ffmpeg.h > @@ -133,6 +133,8 @@ typedef struct OptionsContext { > int nb_hwaccel_output_formats; > SpecifierOpt *autorotate; > int nb_autorotate; > + SpecifierOpt *autoscale; > + int nb_autoscale; > > /* output options */ > StreamMap *stream_maps; > @@ -285,6 +287,7 @@ typedef struct FilterGraph { > > AVFilterGraph *graph; > int reconfiguration; > + int autoscale; > > InputFilter **inputs; > int nb_inputs; > @@ -335,6 +338,7 @@ typedef struct InputStream { > int guess_layout_max; > > int autorotate; > + int autoscale; > > int fix_sub_duration; > struct { /* previous decoded subtitle and related variables */ > diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c > index 72838de1e2..2a2eb080eb 100644 > --- a/fftools/ffmpeg_filter.c > +++ b/fftools/ffmpeg_filter.c > @@ -469,7 +469,7 @@ static int configure_output_video_filter(FilterGraph *fg, OutputFilter *ofilter, > if (ret < 0) > return ret; > > - if (ofilter->width || ofilter->height) { > + if ((ofilter->width || ofilter->height) && fg->autoscale) { > char args[255]; > AVFilterContext *filter; > AVDictionaryEntry *e = NULL; > diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c > index f5ca18aa64..41cb676dad 100644 > --- a/fftools/ffmpeg_opt.c > +++ b/fftools/ffmpeg_opt.c > @@ -742,7 +742,9 @@ static void add_input_streams(OptionsContext *o, AVFormatContext *ic) > MATCH_PER_STREAM_OPT(ts_scale, dbl, ist->ts_scale, ic, st); > > ist->autorotate = 1; > + ist->autoscale = 1; > MATCH_PER_STREAM_OPT(autorotate, i, ist->autorotate, ic, st); > + MATCH_PER_STREAM_OPT(autoscale, i, ist->autoscale, ic, st); > > MATCH_PER_STREAM_OPT(codec_tags, str, codec_tag, ic, st); > if (codec_tag) { > @@ -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? Gyan
Gyan (12019-07-20):
> Since the auto scaling happens at the end of the graph
Are you sure? IIRC, the scaling happens just after buffersrc.
Regards,
On 20-07-2019 01:16 PM, Nicolas George wrote: > Gyan (12019-07-20): >> Since the auto scaling happens at the end of the graph > Are you sure? IIRC, the scaling happens just after buffersrc. From the patch, 1) > @@ -469,7 +469,7 @@ static int configure_output_video_filter(FilterGraph *fg, OutputFilter *ofilter, > if (ret < 0) > return ret; > > - if (ofilter->width || ofilter->height) { > + if ((ofilter->width || ofilter->height) && fg->autoscale) { and 2) > + { "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" Gyan
Gyan (12019-07-20):
> From the patch,
After checking, you are right. When that option is enabled, the filter
graphs are still reinited. That makes it slightly less fragile than I
thought.
Regards,
> -----Original Message----- > From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@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
> -----Original Message----- > From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On Behalf > Of Fu, Linjie > Sent: Monday, July 22, 2019 16:11 > To: FFmpeg development discussions and patches <ffmpeg- > devel@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add - > autoscale to disable/enable the default scale > > > -----Original Message----- > > From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@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." > Are these modifications acceptable? If no against, will update a new version. Thanks. - linjie
On 22-07-2019 01:40 PM, Fu, Linjie wrote: >> -----Original Message----- >> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@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? Gyan
> -----Original Message----- > From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@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-bounces@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.
On 24-07-2019 08:15 AM, Fu, Linjie wrote: >> -----Original Message----- >> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@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-bounces@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? Gyan
> -----Original Message----- > From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@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-bounces@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-bounces@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 )
On 7/24/19, Fu, Linjie <linjie.fu@intel.com> wrote: >> -----Original Message----- >> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@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-bounces@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-bounces@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.
> -----Original Message----- > From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On Behalf > Of Paul B Mahol > Sent: Wednesday, July 24, 2019 17:42 > To: FFmpeg development discussions and patches <ffmpeg- > devel@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.fu@intel.com> wrote: > >> -----Original Message----- > >> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@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-bounces@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-bounces@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. - linjie
On 7/24/19, Fu, Linjie <linjie.fu@intel.com> wrote: >> -----Original Message----- >> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On Behalf >> Of Paul B Mahol >> Sent: Wednesday, July 24, 2019 17:42 >> To: FFmpeg development discussions and patches <ffmpeg- >> devel@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.fu@intel.com> wrote: >> >> -----Original Message----- >> >> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@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-bounces@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-bounces@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.
> -----Original Message----- > From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On Behalf > Of Paul B Mahol > Sent: Wednesday, July 24, 2019 21:17 > To: FFmpeg development discussions and patches <ffmpeg- > devel@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.fu@intel.com> wrote: > >> -----Original Message----- > >> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On > Behalf > >> Of Paul B Mahol > >> Sent: Wednesday, July 24, 2019 17:42 > >> To: FFmpeg development discussions and patches <ffmpeg- > >> devel@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.fu@intel.com> wrote: > >> >> -----Original Message----- > >> >> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@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-bounces@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-bounces@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
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi index cd35eb49c8..99121b6981 100644 --- a/doc/ffmpeg.texi +++ b/doc/ffmpeg.texi @@ -734,10 +734,6 @@ ffmpeg -dump_attachment:t "" -i INPUT Technical note -- attachments are implemented as codec extradata, so this option can actually be used to extract extradata from any stream, not just attachments. - -@item -noautorotate -Disable automatically rotating video based on file metadata. - @end table @section Video Options @@ -819,6 +815,19 @@ Create the filtergraph specified by @var{filtergraph} and use it to filter the stream. This is an alias for @code{-filter:v}, see the @ref{filter_option,,-filter option}. + +@item -autorotate +Automatically rotate the video according to file metadata. Enabled by +default, use @option{-noautorotate} to disable it. + +@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. @end table @section Advanced Video options diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c index 01f04103cf..5d52430b1e 100644 --- a/fftools/ffmpeg.c +++ b/fftools/ffmpeg.c @@ -2133,6 +2133,7 @@ static int ifilter_send_frame(InputFilter *ifilter, AVFrame *frame) /* determine if the parameters for this input changed */ need_reinit = ifilter->format != frame->format; + fg->autoscale = ifilter->ist->autoscale; switch (ifilter->ist->st->codecpar->codec_type) { case AVMEDIA_TYPE_AUDIO: diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h index 7b6f802082..1602406581 100644 --- a/fftools/ffmpeg.h +++ b/fftools/ffmpeg.h @@ -133,6 +133,8 @@ typedef struct OptionsContext { int nb_hwaccel_output_formats; SpecifierOpt *autorotate; int nb_autorotate; + SpecifierOpt *autoscale; + int nb_autoscale; /* output options */ StreamMap *stream_maps; @@ -285,6 +287,7 @@ typedef struct FilterGraph { AVFilterGraph *graph; int reconfiguration; + int autoscale; InputFilter **inputs; int nb_inputs; @@ -335,6 +338,7 @@ typedef struct InputStream { int guess_layout_max; int autorotate; + int autoscale; int fix_sub_duration; struct { /* previous decoded subtitle and related variables */ diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c index 72838de1e2..2a2eb080eb 100644 --- a/fftools/ffmpeg_filter.c +++ b/fftools/ffmpeg_filter.c @@ -469,7 +469,7 @@ static int configure_output_video_filter(FilterGraph *fg, OutputFilter *ofilter, if (ret < 0) return ret; - if (ofilter->width || ofilter->height) { + if ((ofilter->width || ofilter->height) && fg->autoscale) { char args[255]; AVFilterContext *filter; AVDictionaryEntry *e = NULL; diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c index f5ca18aa64..41cb676dad 100644 --- a/fftools/ffmpeg_opt.c +++ b/fftools/ffmpeg_opt.c @@ -742,7 +742,9 @@ static void add_input_streams(OptionsContext *o, AVFormatContext *ic) MATCH_PER_STREAM_OPT(ts_scale, dbl, ist->ts_scale, ic, st); ist->autorotate = 1; + ist->autoscale = 1; MATCH_PER_STREAM_OPT(autorotate, i, ist->autorotate, ic, st); + MATCH_PER_STREAM_OPT(autoscale, i, ist->autoscale, ic, st); MATCH_PER_STREAM_OPT(codec_tags, str, codec_tag, ic, st); if (codec_tag) { @@ -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."}, /* audio options */ { "aframes", OPT_AUDIO | HAS_ARG | OPT_PERFILE | OPT_OUTPUT, { .func_arg = opt_audio_frames },
Currently, ffmpeg inserts scale filter by default in the filter graph to force the whole decoded stream to scale into the same size with the first frame. It's not quite make sense in resolution changing cases if user wants the rawvideo without any scale. Using autoscale/noautoscale to indicate whether auto inserting the scale filter in the filter graph: -noautoscale or -autoscale 0: disable the default auto scale filter inserting. Update docs. Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com> Signed-off-by: Linjie Fu <linjie.fu@intel.com> --- doc/ffmpeg.texi | 17 +++++++++++++---- fftools/ffmpeg.c | 1 + fftools/ffmpeg.h | 4 ++++ fftools/ffmpeg_filter.c | 2 +- fftools/ffmpeg_opt.c | 8 ++++++++ 5 files changed, 27 insertions(+), 5 deletions(-)