[Ffmpeg-devel] [PATCH/RFC] 1-7 and 9-15 bits per pixel PGM files

Rich Felker dalias
Sun Apr 8 01:43:10 CEST 2007


On Sat, Apr 07, 2007 at 11:45:00PM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Sat, Apr 07, 2007 at 11:17:43PM +0200, Ivo wrote:
> > On Saturday 07 April 2007 16:27, Michael Niedermayer wrote:
> > > On Sat, Apr 07, 2007 at 03:43:40PM +0200, Ivo wrote:
> > > > I see. I have thought about it and I think the shift/or "upgrading" to
> > > > 8/16-bits per component is better than multiply/division, even in this
> > >
> > > division is too slow, always mupltply by the reciprocal and shift
> > >
> > > > case, because it won't introduce rounding errors and can be downgraded
> > > > losslessly (simple shift).
> > >
> > > hmm
> > 
> > Do you disagree here and should I support all non-power-of-two maxvals 
> > exactly, despite the rounding errors they will introduce, or are you ok 
> > with treating non-power-of-two maxvals like they had a maxval of the 
> > nearest power of two above that? (which is what the current patch does)
> 
> i dunno :)

This is where the distinction between "decoder" and "filter" muddles.
Maybe someday we'll have a framework where everything (decoders
included) is just a "filter" converting between different picture or
picture-sequence formats, and the appropriate ones are loaded for
converting to your output format (possibly display).

Even without going that far, programs wanting to keep the strange
non-power-of-two data could keep it, and swScale could convert.. :)

Rich




More information about the ffmpeg-devel mailing list