[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
    
        - Previous message: [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
 
        - Next message: [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
 
         -  Messages sorted by: 
              [ date ]
              [ thread ]
              [ subject ]
              [ author ]
         
 
       
    
  
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
    
    
        
	- Previous message: [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
 
	- Next message: [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
 
         -  Messages sorted by: 
              [ date ]
              [ thread ]
              [ subject ]
              [ author ]
         
 
       
More information about the ffmpeg-cvslog
mailing list