[Ffmpeg-cvslog] CVS: ffmpeg/libavcodec bmp.c, NONE, 1.1 allcodecs.c, 1.115, 1.116 Makefile, 1.212, 1.213 avcodec.h, 1.428, 1.429

[Rich Felker]

On Wed, Nov 30, 2005 at 09:10:38PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Wed, Nov 30, 2005 at 01:45:26PM -0500, Rich Felker wrote:
> > On Wed, Nov 30, 2005 at 09:49:39AM -0000, M?ns Rullg?rd wrote:
> > > > hmm, i love pixel format conversation code in codecs ...
> > > > please at least add a note to the source explaining that this is not the
> > > > way its supposed to be done but that instead a new PIX_FMT should be added
> > > > for each new pixel format,
> > > 
> > > That way we'll end up with a PIX_FMT for every permutation of component
> > > orders.  I agree that converting between "standard" formats in a codec
> > > shouldn't be done.  Dealing with arbitrary pixel layouts in every app is
> > > a nuisance.
> > 
> > This is a design problem in lavc. Ideally where would not be PIX_FMT
> > constants for different channel layouts, etc. but instead a format
> > descriptor structure that tells the bit offsets and sizes of each
> > channel, sample value ranges, etc.
> 
> well send patch to change all pix_fmt to pointers to PixFmtInfo 
> (see imgresample.c)
> but IMHO this is alot of work, a little bloat and a little improvement

well yes, especially when our target is just codecs which use a very
limited subset of possible buffer arrangements. but for the filter
stuff i was thinking about, it may help a lot to support arbitrary
arrangements. anyway it's not a big deal for lavc imo.

> > This is why a better architecture would not consider codecs and
> > filters as separate components, but both as a generic type of blackbox
> > that can convert one video/image format to another. In such an
> > architecture, factoring the 'decoding' components as much as possible
> > (as long as it doesn't hurt performance) is desirable.
> > 
> > Unfortunately we're not to that point yet..
> 
> hmm, lets see, we fail to design a video filter layer which can handle
> everything we want/need and now we are talking about a generic architecture
> which should support filters and codecs, hmm somehow i think thats not going
> to lead to anything working in the next few years ...
> but no doubt, such a generic archiecture would be nice if it is clean, simple
> efficient and fast

exactly. like i said it's not happening soon (or even ever?). in the
meantime we should make things as efficient and flexible as we can
with the architecture we have, like you said.

rich