[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

Michael Niedermayer michaelni
Wed Nov 30 21:10:38 CET 2005


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


> 
> > Even though it's not compressed, it can still be considered
> > an encoded format that needs to be decoded into a normal format.
> 
> 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

[...]

-- 
Michael





More information about the ffmpeg-cvslog mailing list