[FFmpeg-devel] [PATCH]

[Michael Niedermayer]

On Wed, May 15, 2019 at 11:13:57PM +0200, Werner Robitza wrote:
> On Wed, May 15, 2019 at 4:55 PM Gyan <ffmpeg at gyani.pro> wrote:
> > On 15-05-2019 05:06 PM, Werner Robitza wrote:
> > > On Wed, May 15, 2019 at 11:36 AM Gyan <ffmpeg at gyani.pro> wrote:
> > >> Which lines in the CLI help?
> > > SWScaler AVOptions:
> > >    -sws_flags         <flags>      E..V..... scaler flags (default bicubic)
> > >     ...
> > >    -src_format        <pix_fmt>    E..V..... source format (default yuv420p)
> > >    -dst_format        <pix_fmt>    E..V..... destination format (default yuv420p)
> > >    -src_range         <boolean>    E..V..... source is full range (default false)
> > >    -dst_range         <boolean>    E..V..... destination is full range
> > > (default false)
> > >
> > >> I don't see any constants set in the AVOptions struct. Can you share a command line where you could set this option using a string?
> > > I was just going by the help printed above, including the default. If
> > > a string is not valid, which values are?
> > The help function fetches the string name for the default value but the
> > user has to input an integer.
> >
> > The pixel formats are declared in an enum in libavutil/pixfmt.h. The
> > integers correspond to their index in that list.
> 
> That seems very bad in terms of usability. Is there a particular
> reason why the "-pix_fmt" option can parse these values, but swscaler
> not? In fact, most (if not all) other options that accept a finite set
> of arguments don't use numbers in that way, but strings.
> I can add the integers to the documentation as a lookup table, but it
> feels weird doing so.

where exactly is a end user facing interface using integers for pix_fmt
in place of named identifers, can you show an example command line ?

Maybe there is some misunderstranding between end user facing interface
in API for lib users, interfacing with components through the C API would
use pixel format values which fundamentally are integers throughout the
various libs. But end user facing interface like what is accessed from
the command line should use human compatible string values

thx


> 
> > >>> +If set to 1, source range will be full range.
> > >> Mention the range of values possible and their meaning.
> > > I don't understand, as no other values are possible. Well, 0 is
> > > possible but meaningless since it's default; 1 indicates "true".
> > Sure, if the option name was is_src_range_full. But src_range allows you
> > to specify a range. So, even though there are only two, better to
> > mention the allowed values and their meaning.
> 
> Ok. Will send an update.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20190515/91360950/attachment.sig>