On Sat, Sep 10, 2022 at 06:34:43PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Fri, Sep 09, 2022 at 08:15:22PM +0200, Andreas Rheinhardt wrote:
> >> Michael Niedermayer:
> >>> On Thu, Sep 08, 2022 at 11:44:51PM +0200, Andreas Rheinhardt wrote:
> >>>> Michael Niedermayer:
> >>>>> On Thu, Sep 08, 2022 at 09:38:51PM +0200, Andreas Rheinhardt wrote:
> >>>>>> Michael Niedermayer:
> >>> [...]
> >>>>> To me if i look at the evolution
> >>>>> of isBE() / code checking BE-ness it become more messy over time
> >>>>>
> >>>>> I think it would be interresting to think about if we can make
> >>>>> av_pix_fmt_desc_get(compile time constant) work at compile time.
> >>>>> or if we maybe can return to a simpler implementation
> >>>>>
> >>>>
> >>>> We could put the av_pix_fmt_descriptors array into an internal header
> >>>> and use something like
> >>>>
> >>>> static av_always_inline const AVPixFmtDescriptor
> >>>> *ff_pix_fmt_descriptor_get(enum AVPixelFormat fmt)
> >>>> {
> >>>>     if (av_builtin_constant_p(fmt))
> >>>>         return &av_pix_fmt_descriptors[fmt];
> >>>>     return av_pix_fmt_desc_get(fmt);
> >>>> }
> >>>
> >>> yes thats what i was thinking of too.
> >>>
> >>
> >> Seems like Anton is away for a week or so. I am sure he has an opinion
> >> on the above approach. I think we will wait for him or shall I apply the
> >> patches as they are given that they do not block any later alternative
> >> solution?
> > 
> > please dont apply code like "IS_BE(BE_LE)" 
> > iam sure it makes sense to you today but it requires an additional step
> > for the reader to understand
> > simplest is a seperate endianness and isbe variable. on the wrapper
> > that should be less code too but quite possibly you see a better and
> > cleaner way
> > 
> 
> I actually thought that my solution is superior to the one you seem to
> have in mind; after all, the parameter for isbe is redundant: It can
> also be derived from the pixfmt-name.

your solution is supperior in some sense. But iam concerned that it is
less readable for a small gain.
Maybe BE_LE and others can be renamed to make it immedeatly clear


> 
> > 
> >> (There is one thing I already don't like about the alternative solution:
> >> It relies on av_builtin_constant_p, which not every compiler supports.)
> > 
> > Thats why i didnt suggets to use av_builtin_constant_p() i was hoping you
> > saw a better way to achieve it.
> > 
> 
> Well, without av_builtin_constant_p() the only other way for this would
> be to add two systems to get the information, one for compile-time
> constants and one for not-constants. Ensuring that the former is only
> used for compile-time constants will be a challenge, to say the least.

I dont think its a challenge, but iam still quite unsure if this would
lead to other issues.

For example, if we add a constant lookup function that has direct access
to the table. We assue that will only be used where constants are the
arguzment. Now its easy to add a extra field to that table and then
grep the binary for that. If its found it was either used with a non
constant or the compiler failed to optimize it out.
This could be a fate test. If it works 100% thats simple but if it works
99% it will be a pain and is not a direction i would suggest, it would
be more pain than its worth.

So really this is just for discussion at this point, far from a plan
with understood consequences

thx
[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.