Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Anton Khirnov <anton@khirnov.net>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 25/33] fftools/ffmpeg_filter: stop disregarding user-specified pixel format
Date: Fri, 14 Jul 2023 11:44:07 +0200
Message-ID: <168932784788.27367.2505386604250052570@lain.khirnov.net> (raw)
In-Reply-To: <20230713231107.GK1093384@pb2>

Quoting Michael Niedermayer (2023-07-14 01:11:07)
> On Thu, Jul 13, 2023 at 12:55:45PM +0200, Anton Khirnov wrote:
> > When the user explicitly specifies a pixel format that is not supported
> > by the encoder, ffmpeg CLI will currently use some heuristics to pick
> > another supported format. This is wrong and the correct action here is
> > to fail.
> > 
> > Surprisingly, a number of FATE tests are affected by this and actually
> > use a different pixel format than is specified in the makefiles.
> > ---
> >  doc/ffmpeg.texi                               |  3 +-
> >  fftools/ffmpeg_filter.c                       | 35 +------------------
> >  tests/fate/fits.mak                           |  6 ++--
> >  tests/fate/lavf-video.mak                     |  2 +-
> >  tests/fate/vcodec.mak                         |  4 +--
> >  .../{fitsdec-gbrap16le => fitsdec-gbrap16be}  |  4 +--
> >  .../fate/{fitsdec-gbrp16 => fitsdec-gbrp16be} |  4 +--
> >  tests/ref/lavf/gif                            |  2 +-
> >  8 files changed, 13 insertions(+), 47 deletions(-)
> >  rename tests/ref/fate/{fitsdec-gbrap16le => fitsdec-gbrap16be} (79%)
> >  rename tests/ref/fate/{fitsdec-gbrp16 => fitsdec-gbrp16be} (79%)
> > 
> > diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> > index 6769f8d305..08b11097b7 100644
> > --- a/doc/ffmpeg.texi
> > +++ b/doc/ffmpeg.texi
> > @@ -1014,8 +1014,7 @@ Disable autoscale at your own risk.
> >  @item -pix_fmt[:@var{stream_specifier}] @var{format} (@emph{input/output,per-stream})
> >  Set pixel format. Use @code{-pix_fmts} to show all the supported
> >  pixel formats.
> > -If the selected pixel format can not be selected, ffmpeg will print a
> > -warning and select the best pixel format supported by the encoder.
> > +
> >  If @var{pix_fmt} is prefixed by a @code{+}, ffmpeg will exit with an error
> >  if the requested pixel format can not be selected, and automatic conversions
> >  inside filtergraphs are disabled.
> 
> The commit message makes this sound like a bugfix, while really this is
> removing a documented feature.

It is a bugfix in my eyes. When you explicitly tell a program to perform
a specific action, and the program just decides to do something else,
then that program is broken.

As far as I can tell, this "feature" was added by you in 89f86379797
with no explanation or documentation beyond 'fix regression with png'.
It was later documented in a largely-unrelated commit that added
something else.

I see no argument whatsoever for why we should have such a "smart"
selection for pixel formats, but nothing else. It goes entirely against
the way any other option works.

> It also breaks some scripts (fate is an example as it requires changes)

No, its removal reveals already broken FATE tests, as I see no
indication that those tests intended to use a different format than
indicated on the commandline. It seems far more likely that this
misfeature confused the tests' authors as to what format is actually
used. That is IMO yet another argument for removing this.

> If the removial of that feature is intended, it should be argued somewhere
> that this feature is never usefull.

https://xkcd.com/1172/

> To me as a lazy person it surely feels usefull to be able to ask for
> both "exactly rgb" as well as something close to rgb (like bgr or gbrp)
> without needing to know what each individual codec uses to return R,G,B

1) This code does not give you the ability to specify "something close to rgb".
   You specify a precise pixel format, and this code gives you
   something. That something might be what you asked for, or something
   close to it, or something completely unrelated.
   E.g.
     ffmpeg -i in.mkv -map 0:v -c:v libx264 -pix_fmt pal8 -t 1 out.mkv
   produces yuv444p. How is it close to pal8?
2) If you want syntax for fuzzy format specification, patches are
   welcome. But it should not interfere with specifying an exact format.
3) No other option in ffmpeg CLI works like this. If you specify
   something, you get that or an error.

-- 
Anton Khirnov
_______________________________________________
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-07-14  9:44 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-13 10:55 [FFmpeg-devel] [PATCH 01/33] fftools/ffmpeg_mux_init: return errors from of_open() instead of aborting Anton Khirnov
2023-07-13 10:55 ` [FFmpeg-devel] [PATCH 02/33] fftools/ffmpeg_demux: return errors from ifile_open() " Anton Khirnov
2023-07-13 10:55 ` [FFmpeg-devel] [PATCH 03/33] fftools/ffmpeg_demux: drop a redundant avio_flush() Anton Khirnov
2023-07-13 10:55 ` [FFmpeg-devel] [PATCH 04/33] fftools/ffmpeg_demux: forward errors from dump_attachment() instead of aborting Anton Khirnov
2023-07-13 10:55 ` [FFmpeg-devel] [PATCH 05/33] fftools/ffmpeg_demux: add logging for -dump_attachment Anton Khirnov
2023-07-13 10:55 ` [FFmpeg-devel] [PATCH 06/33] fftools/ffmpeg: return errors from assert_file_overwrite() instead of aborting Anton Khirnov
2023-07-13 10:55 ` [FFmpeg-devel] [PATCH 07/33] fftools/ffmpeg_demux: return errors from ist_add() " Anton Khirnov
2023-07-13 10:55 ` [FFmpeg-devel] [PATCH 08/33] fftools/ffmpeg_mux_init: return errors from create_streams() " Anton Khirnov
2023-07-13 10:55 ` [FFmpeg-devel] [PATCH 09/33] fftools/ffmpeg_mux_init: improve error handling in of_add_attachments() Anton Khirnov
2023-07-13 10:55 ` [FFmpeg-devel] [PATCH 10/33] fftools/ffmpeg_mux_init: return error codes from map_*() instead of aborting Anton Khirnov
2023-07-13 10:55 ` [FFmpeg-devel] [PATCH 11/33] fftools/ffmpeg_mux_init: move allocation out of prologue Anton Khirnov
2023-07-13 10:55 ` [FFmpeg-devel] [PATCH 12/33] fftools/ffmpeg_mux_init: return error codes from ost_add() instead of aborting Anton Khirnov
2023-07-13 10:55 ` [FFmpeg-devel] [PATCH 13/33] fftools/ffmpeg_mux_init: return error codes from copy_meta() " Anton Khirnov
2023-07-13 10:55 ` [FFmpeg-devel] [PATCH 14/33] fftools/ffmpeg_mux_init: return error codes from parse_forced_key_frames() " Anton Khirnov
2023-07-13 10:55 ` [FFmpeg-devel] [PATCH 15/33] fftools/ffmpeg_mux_init: return error codes from validate_enc_avopt() " Anton Khirnov
2023-07-13 10:55 ` [FFmpeg-devel] [PATCH 16/33] fftools/ffmpeg_mux_init: improve of_add_programs() Anton Khirnov
2023-07-13 23:30   ` Michael Niedermayer
2023-07-14  9:07     ` Anton Khirnov
2023-07-14 18:12       ` Michael Niedermayer
2023-07-13 10:55 ` [FFmpeg-devel] [PATCH 17/33] fftools/ffmpeg_mux_init: return error codes from metadata processing instead of aborting Anton Khirnov
2023-07-13 10:55 ` [FFmpeg-devel] [PATCH 18/33] fftools/ffmpeg_mux_init: replace all remaining aborts with returning error codes Anton Khirnov
2023-07-13 10:55 ` [FFmpeg-devel] [PATCH 19/33] fftools/ffmpeg: return an error instead of aborting Anton Khirnov
2023-07-13 10:55 ` [FFmpeg-devel] [PATCH 20/33] fftools/ffmpeg: handle error codes from process_input_packet() Anton Khirnov
2023-07-13 10:55 ` [FFmpeg-devel] [PATCH 21/33] fftools/ffmpeg_mux: return errors from of_streamcopy() instead of aborting Anton Khirnov
2023-07-13 10:55 ` [FFmpeg-devel] [PATCH 22/33] fftools/ffmpeg_enc: return errors from enc_subtitle() " Anton Khirnov
2023-07-13 10:55 ` [FFmpeg-devel] [PATCH 23/33] fftools/ffmpeg_mux_init: drop an obsolete assignment Anton Khirnov
2023-07-13 10:55 ` [FFmpeg-devel] [PATCH 24/33] fftools/ffmpeg_mux_init: handle pixel format endianness Anton Khirnov
2023-07-13 10:55 ` [FFmpeg-devel] [PATCH 25/33] fftools/ffmpeg_filter: stop disregarding user-specified pixel format Anton Khirnov
2023-07-13 23:11   ` Michael Niedermayer
2023-07-14  9:44     ` Anton Khirnov [this message]
2023-07-14 10:20       ` Timo Rothenpieler
2023-07-14 15:47       ` Michael Niedermayer
2023-07-14 17:06         ` Anton Khirnov
2023-07-15  8:59           ` Paul B Mahol
2023-07-15 20:01           ` Michael Niedermayer
2023-07-13 10:55 ` [FFmpeg-devel] [PATCH 26/33] fftools/ffmpeg_filter: stop accessing encoder from pixfmt selection Anton Khirnov
2023-07-13 10:55 ` [FFmpeg-devel] [PATCH 27/33] fftools/ffmpeg: rework initializing encoders with no frames Anton Khirnov
2023-07-13 10:55 ` [FFmpeg-devel] [PATCH 28/33] fftools/ffmpeg_filter: only flush vsync code if encoding actually started Anton Khirnov
2023-07-13 10:55 ` [FFmpeg-devel] [PATCH 29/33] fftools/ffmpeg_enc: initialize audio/video encoders from frame parameters Anton Khirnov
2023-07-13 10:55 ` [FFmpeg-devel] [PATCH 30/33] fftools/ffmpeg_filter: make OutputFilter.filter private Anton Khirnov
2023-07-13 10:55 ` [FFmpeg-devel] [PATCH 31/33] fftools/ffmpeg: add more structure to FrameData Anton Khirnov
2023-07-13 10:55 ` [FFmpeg-devel] [PATCH 32/33] fftools/ffmpeg: rework -enc_time_base handling Anton Khirnov
2023-07-13 10:55 ` [FFmpeg-devel] [PATCH 33/33] doc/ffmpeg: fix -enc_time_base documentation Anton Khirnov
2023-07-13 12:01 ` [FFmpeg-devel] [PATCH 01/33] fftools/ffmpeg_mux_init: return errors from of_open() instead of aborting "zhilizhao(赵志立)"
2023-07-13 13:01   ` Anton Khirnov

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=168932784788.27367.2505386604250052570@lain.khirnov.net \
    --to=anton@khirnov.net \
    --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