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

[Michael Niedermayer]

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.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20091122/26fb3039/attachment.pgp>