[FFmpeg-devel] [PATCH] Create a libavutil/pix_fmt.h with the pixel format stuff

Michael Niedermayer michaelni
Sat Feb 21 18:10:25 CET 2009


On Sat, Feb 21, 2009 at 05:57:01PM +0100, Stefano Sabatini wrote:
> On date Saturday 2009-02-21 16:41:24 +0100, Michael Niedermayer encoded:
> > On Sat, Feb 21, 2009 at 04:32:47PM +0100, Stefano Sabatini wrote:
> > > On date Saturday 2009-02-21 15:34:50 +0100, Michael Niedermayer encoded:
> > > > On Sat, Feb 21, 2009 at 03:28:18PM +0100, Stefano Sabatini wrote:
> > > > > On date Friday 2009-02-20 21:08:55 +0100, Michael Niedermayer encoded:
> > > > > > On Thu, Feb 19, 2009 at 11:29:45PM +0100, Stefano Sabatini wrote:
> > > > > > > On date Thursday 2009-02-19 22:00:59 +0100, Stefano Sabatini encoded:
> > > > > > > > > > First step creates a pix_fmt.h header (PixFmtInfo would then be added
> > > > > > > > > > to libavutil/pix_fmt.c)
> > > > > > > > > 
> > > > > > > > > PixFmtInfo as is is too bloated, it requires cleanup _first_
> > > > > > > > > also your patch misses installing the new header while a installed header
> > > > > > > > > depends on it
> > > > > > > > 
> > > > > > > > Yes.
> > > > > > > > 
> > > > > > > > Also I'm not sure if pixfmt.h (no underscore) is a better name.
> > > > > > > 
> > > > > > > Uh, patch missing...
> > > > > > 
> > > > > > probably ok
> > > > > 
> > > > > This changes the public interface,
> > > > 
> > > > how so?
> > > 
> > > She (the user) was used to do:
> > > #include <libavutil/avutil.h>
> > > 
> > > while after the change she will do:
> > > #include <libavutil/pix_fmt.h>
> > 
> > She still can and should do #include <libavutil/avutil.h>
> > 
> > 
> > > 
> > > and get done with the pix fmt stuff inclusion, so she may do:
> > > #if (LIBAVUTIL_VERSION_MINOR < X)
> > > #include <libavutil/avutil.h>
> > > #else
> > > #include <libavutil/pix_fmt.h>
> > > #endif
> > 
> > well ...
> > 
> > > 
> > > Note that this currently doesn't make sense, since
> > 
> > great one line summary ...
> > ive not seen pix_fmt as a header the end user would want to include directly
> > rather as "internal but installed" header to factorize our code.
> > thus IMHO it wouldnt need a bump ...
> > also fewer headers -> less compexity
> > i know its trivial for us now but each additional (and useless so) header
> > makes it more complex for the user ...
> 
> I see your point, but how the user is supposed to understand if an
> header has to be considered "internal but installed"?

normally
* user reads docs
* docs say which header for which function

we have no docs except the headers ....

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090221/2d07a93f/attachment.pgp>



More information about the ffmpeg-devel mailing list