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?
Gyan
_______________________________________________
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".
