[FFmpeg-devel] [PATCH] Enable pixdesc.c compilation
Sun Nov 8 04:24:33 CET 2009
On Sun, Nov 08, 2009 at 01:01:55AM +0100, Stefano Sabatini wrote:
> 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.
just keep in mind that i will reject every hunk that makes code more
(thats especially true for any attempt to replace a 2 line switch/case
by 2 pages of obfuscated code)
also i still insist on some comments on pixdescs from someone
hmm reimar maybe? :)
before its made public API
> 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.
well, if you have nothing better to do than move pixdescs between the
2 libs, then i dont mind
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 1
"Used only once" - "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel