Re: [FFmpeg-devel] Please, clarify -r/-fps_mode usage for YUV encoding

[Timo Rothenpieler <timo@rothenpieler.org>]

On 15.03.2023 21:36, Rogozhkin, Dmitry V wrote:
> Hi,
> 
> Can someone, please, help to clarify ffmpeg behavior after one of the
> recent changes [1]. This commit turns warning into error to prevent
> usage of conflicting options. Error printed out is:
> “One of -r/-fpsmax was specified together a non-CFR -vsync/-fps_mode.
> This is contradictory.”
> 
> In our command lines [2] we were using -fps_mode passthrough to make
> sure that there is no frame rate conversion/frame dropping which is
> desirable for quality benchmarking use case. We did not use -r option
> for any transcoding use cases. However, we did use -r for YUV encoding
> use cases along with -fps_mode passthrough, i.e. command lines were
> looking like:
> 
> ffmpeg <...>  \
>    -f rawvideo -pix_fmt yuv420p -s:v ${w}x${h} -r $framerate -i $yuv \
>    -c:v h264_qsv <...> -fps_mode passthrough -y $output
> 
> Above YUV encoding command line continues to work after [1] without
> warnings or errors. My understanding is that in case of YUV -r
> specifies a framerate of the input YUV file while for transcoding case
> -r actually overrides framerate of the input bitstream and causes frame
> rate conversion per se which clearly conflicts with intend of -fps_mode
> passthrough which specifies that the frame rate is “passing through”
> without conversion. Thus, using -r along with -fps_mode passthrough is
> a valid for YUV encoding (since fps_mode will be the only frame rate
> conversion being requested), but that’s not a valid combination for
> transcoding use cases. Is this interpretation correct?
> 
> [1]
> https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/260f3918937463f1b90e1b77cba80b917f3cb8c1
> [2] https://github.com/intel/media-delivery/blob/master/doc/quality.rst
> 
> Regards,
> Dmitry.

The option to specify the framerate of a rawvideo input is -framerate:
https://ffmpeg.org/ffmpeg-formats.html#rawvideo

With -r you're telling ffmpeg to overwrite the framerate of the input, 
which probably defaults to 24 or something.
And then you also tell it to not mess with the framerate which, as it 
correctly points, out is contradictory.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".