On Wed, May 15, 2019 at 11:13:57PM +0200, Werner Robitza wrote:
> On Wed, May 15, 2019 at 4:55 PM Gyan <ffm...@gyani.pro> wrote:
> > On 15-05-2019 05:06 PM, Werner Robitza wrote:
> > > On Wed, May 15, 2019 at 11:36 AM Gyan <ffm...@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@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@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

Attachment: signature.asc
Description: PGP signature

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

Reply via email to