[FFmpeg-devel] [PATCH] Enable pixdesc.c compilation

[Stefano Sabatini]

On date Saturday 2009-11-07 23:44:00 +0100, Michael Niedermayer encoded:
> On Sat, Nov 07, 2009 at 10:48:38PM +0100, Stefano Sabatini wrote:
> > On date Saturday 2009-11-07 21:14:56 +0100, Michael Niedermayer encoded:
> > > On Sat, Nov 07, 2009 at 04:46:53PM +0100, Stefano Sabatini wrote:
> > > > On date Saturday 2009-11-07 13:42:50 +0100, Michael Niedermayer encoded:
> > > > > On Sat, Nov 07, 2009 at 12:40:29AM +0100, Stefano Sabatini wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > as in patch, I plan to use it for some incoming filter so I need it.
> > > > > 
> > > > > until the headers are installed and the API made public theres no way you
> > > > > can use this code from outside libavutil
> > > > 
> > > > Strictly speaking, no this isn't required since we can consider it
> > > > just a sort of an internal API, and use it from within FFmpeg as it's
> > > > done for many other modules.
> > > 
> > > any use of code outside libx is external to libx.
> > > If you dislike this talk with all the distro maintainers they will explain
> > > you with a pitchfork why
> > 
> > OK so we have a problem here, how am I supposed to replace PixFmtInfo
> > if I can't access pixdescs from libavcodec?
> > 
> > I'm even considering to move pixdesc back to libavcodec, then move it
> > again when PixFmtInfo will be removed.
> 
> You can move it around as much as you like, it needs to be reviewed and iam
> not the right person for it because i wrote it.
> 
> as i said, look at the API, think about it, review it
> is it understandable?
> is it simple?
> think about possible uses
> does it fullfill them?
> can it be extended? (obviously this is only relevant to real extensions
> not abstracted "i have no clue why we would want to do X but we cant so
> its a poor API")
> ...
> 
> As is it is pretty compact space wise and i like it but iam not sure if
> this might bite us in terms of extendability.
> 
> the problem ATM is no comments from anyone about it. I want to hear something
> from someone good or bad before it is made public API.

One of the requirement I have for pixdescs is that it should make
possible to avoid particular cases handling in the generic functions
which deal with pixel formats.

In other words the pixdesc definition should be expressive enough to
avoid case PIX_FMT_FOO: branches.

In order to prove that, my plan is to use it in imgconvert, as we
replace the old functions we should see if that's good enough, and
extend it in the meaningwhile.

According to this heuristic, once all the PixFmtInfo functionality
will be replaced then the API should be ready for public exposure.

Since this cannot be done having pixdescs in lavu, then I suggest to
move it again to lavc, and re-export them to lavu when publishing it.

There is one point which I don't like of the pixdescs, and which I
noticed when trying to replace ff_fill_linesize().

log2_chroma_w and log2_chroma_h refer to plane 1 and 2, this doesn't
work if the chroma shift is associated to a component rather than to a
plane, consider for example yuyv.

So my idea was to make log2_chroma_w and log2_chroma_h properties of
the *component* rather than properties of plane 1 and 2, which means
allocating 2 or 3 bits * 2 for each component.

Anyway I'll discuss this in another thread.

Resuming, my plan is:

1) move pixdescs back to lavc

2) change one by one the functions in imgconvert.c for making use it
rather than PixFmtInfo, extend pixdescs as it seems needed.

3) finally move them again to lavu and make them public.

In the meaningwhile we'll hear other people opinions about it.

Since this appears a long process, I'll avoid to use them in lavfi,
unfortunately because they would make lavfi (and maybe swscale as
well) better, and we'll need to change the filters code again when
pixdescs use will be available.

Regards.
-- 
FFmpeg = Fundamentalist and Fiendish Mega Power Efficient Gangster