[FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -autoscale to disable/enable the default scale

[Gyan]

On 24-07-2019 08:15 AM, Fu, Linjie wrote:
>> -----Original Message-----
>> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On Behalf
>> Of Gyan
>> Sent: Wednesday, July 24, 2019 00:49
>> To: ffmpeg-devel at 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 at ffmpeg.org] On
>> Behalf
>>>> Of Gyan
>>>> Sent: Saturday, July 20, 2019 13:29
>>>> To: ffmpeg-devel at 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
>>>>> + at 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