Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: "Rogozhkin, Dmitry V" <dmitry.v.rogozhkin-at-intel.com@ffmpeg.org>
To: "ffmpeg-devel@ffmpeg.org" <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] Please, clarify -r/-fps_mode usage for YUV encoding
Date: Sat, 18 Mar 2023 00:39:55 +0000
Message-ID: <2e0209ed0c4353f8cc99b7c991b77edcbc35f503.camel@intel.com> (raw)
In-Reply-To: <658b84d0-99ff-151f-6ac9-746f051a34b4@rothenpieler.org>

On Wed, 2023-03-15 at 21:52 +0100, Timo Rothenpieler wrote:
> 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.

Thank you for quick reply. This makes sense now. We will make a fix on
our side.

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

      reply	other threads:[~2023-03-18  0:40 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-15 20:36 Rogozhkin, Dmitry V
2023-03-15 20:52 ` Timo Rothenpieler
2023-03-18  0:39   ` Rogozhkin, Dmitry V [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2e0209ed0c4353f8cc99b7c991b77edcbc35f503.camel@intel.com \
    --to=dmitry.v.rogozhkin-at-intel.com@ffmpeg.org \
    --cc=ffmpeg-devel@ffmpeg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git