[FFmpeg-devel] dcp encoding + new pixel format request/sponsorship
michaelni at gmx.at
Tue Jan 22 20:45:57 CET 2013
On Tue, Jan 22, 2013 at 05:02:18PM +0100, Michael Niedermayer wrote:
> On Tue, Jan 22, 2013 at 02:57:38PM +0000, Carl Eugen Hoyos wrote:
> > Michael Bradshaw <mjbshaw <at> gmail.com> writes:
> > > > Is there any reason to add a 12 bit per component format
> > > > instead of using the 16 bit one and telling the encoder
> > > > it should discard 4 bit?
> > >
> > > Out of curiosity, how would that work? Which 4 bits do you discard?
> > I believe when we "scale" from 16 to 8 bits, we simply discard
> > the 8 least significant bit, the same can be done for the
> > 16 -> 12 case.
> There are 2 different cases here
> 12bit stored in 16bit and true 16bit
> while they are very similar, converting to 12bit can be done in 2
> A shift by 4
> B more or less exact rescaling
> The difference is quite small but for true 16bit rescaling should
> and i hope is used.
> for 12bit stored in 16bit both the shift and the rescaling gives the
> same result as long as the 12bit are reasonably correctly stored into
> 16bit, for example (i<<4) + (i>>8) will work
> A encoder that wished to support 12bit in 16bit would thus be fine
> with just using a >>4 and wouldnt need to care about the rest
also we do have AV_PIX_FMT_GBRP12BE, AV_PIX_FMT_GBRP12LE and
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel