[FFmpeg-devel] [RFC] Request for pixdesc API review

[Stefano Sabatini]

On date Sunday 2009-11-22 00:05:59 +0100, Michael Niedermayer encoded:
> On Sat, Nov 21, 2009 at 04:43:10PM +0100, Stefano Sabatini wrote:
> > On date Wednesday 2009-11-18 06:41:50 +0100, Olivier Galibert encoded:
> > [...]
> > > Also, I notice you can't handle 32-bits component values (I'm thinking
> > > floating point here).  Intentional?
> > 
> > We have a current limit of 16 bits per value.
> > 
> > We currently don't support pixel formats which require more than 16 bits
> > per component values, this would require more space but then we'll be
> > more future proof.
> > 
> > Michael?
> 
> which codecs in practice use >16bit ? (and no i dont care about computer
> rendered anything)
> 
> I would like to avoid overshooting the goal and over abstracting things
> pixdesc should be useable, i dont want a get_line return double precission
> floats or some arbitrary precission stuff and thats where you end when you
> try to support everything.
> 
> And yes i know linear 16bit and probably 32bit too arent enough to cover
> the human eyes dynamic range. I just think that going beyond 16bit is
> a too big step. i would suggest we try it with 16bit first (>8bit is still
> pretty new stuff) we can always increase it and introduce a pix desc2.
> But doing it now means additional weight on every piece of code that accesses
> pixels through this system because it all must handle the larger range.
> 
> But iam open to reconsider this if there actually is a real usecase for
> >16bit. Allowing 32bit int would probably not be that much of an issue
> 32bit float though would be a big issue.

I would mildly prefer to use 32 bit int but then I have no usecase for
it, so I'm pretty happy with the current 16 bits.

Regards.
-- 
FFmpeg = Fiendish and Faithful Mere Peaceless Ecumenical Gymnast