[FFmpeg-devel] Adding 10-bit depth YUV

[Michael Niedermayer]

Hi

On Thu, May 10, 2007 at 03:28:25PM -0500, erik98 at sunflower.com wrote:
> Thanks for your reply. Some additional questions I have are as follows...
> 
> >> --> To accomplish phase one, it would seem that I need to make the following source code changes...
> >> libavcodec/imgconvert.c:
> >> Add 10-bit depth variants of PIX_FMT_YUV* (ie. PIX_FMT_YUV444D10, PIX_FMT_YUV444P10, etc.).
> >> Note, planar forms will likely be a packed format where 5 bytes are used for every 4 pixels, padded if necessary at the end of each plane.
> >i am against adding 10bit anything support before 16bit is supported and
> >a clear advantage is demonstrated why 10bit support would be needed in
> >addition to 8 and 16bit support, 
> What would you say to adding generic 16-bit support, where anything between 9-15bits gets promoted (padded) internally to 16-bit for internal storage? 

ok


> However, some 10-bit support (or at least _annotation_) would be helpful for compressors and for encoders/containers with 8+ bit support options (such as the Quicktime support for 10-bit YUV444 and YUV422, as well as YUV16). 
> If the plan is to re-write the pix_fmt (see below), one could explicitly separate out Storage class (5, 8 or 16-bits; Number of channels/planes) and Interpretation (or "valid bits") class (5,8,10,16), etc.
>  
> >>additionally i think a more generic pix_fmt
> >>system should be introduced before supporting bit depth between 8 and 16 bits
> >that is a system which specifies in a struct for each pix_fmt how it is
> >stored, so that a single simple generic (and slow) convertion routine can
> >convert any pix_fmt to any pix_fmt
> >this would greatly simplify things ...
> I am curious about this idea. Can you expand in more detail on what you envision? Would the "generic" conversion routine simple be a storage-class to storage-class coercer, ignoring such details as range changes (Y-crush, etc.)?

the idea is to have a table of pix_fmt_descriptors 
so that pix_fmt_descriptor[pix_fmt] would describe the current pix_fmt

so component c at position x,y could be addressed like

int plane= desc.plane_index[c];
uint8_t *ptr= data[plane] + linesize[plane]*y;
ptr += (x>>desc.mp_shift[c])*desc.mp_size;
if(desc.little_endian) pixel= AV_RL64(ptr);
else                   pixel= AV_RB64(ptr);
return (pixel>>desc.pos[c][x & 3]) & desc.mask[c];

for rgb15 the descriptor would look like
plane_index ={0,0,0};
mp_shift    ={0,0,0};
mp_size     = 2;
pos[0]      = {0,};
pos[1]      = {5,};
pos[2]      = {10,};
mask        = {31,31,31};

for uyvy it would look like
plane_index  ={0,0,0};
mp_shift     ={1,0,0};
mp_size      = 4;
little_endian= 0
pos[0]       = {16,0,};
pos[1]       = {24,};
pos[2]       = {8,};
mask         = {255,255,255};

for 10bit planar YUV it would look like
plane_index  ={0,1,2};
mp_shift     ={2,2,2};
mp_size      = 5;
little_endian= 0
pos[0]       = {30,20,10,0};
pos[1]       = {30,20,10,0};
pos[2]       = {30,20,10,0};
mask         = {1023,1023,1023};

with something like that it should be easy to add new formats by just
adding a new entry in the table ...


> 
> >> --> To accomplish phase two, it would seem that I need to make the following source code changes...
> >> libavcodec/ffv1.c:
> >> Bump the header version from 0 to 1
> >maybe
> >> change coder_type interpretation to be coder_flags. Default is 0
> >> Add new flag CODER_FLAG_D10
> >no
> Could you expand on your objection? 
> (Do you not like flag-type variables? Do you prefer increasing the size of the header with new, explicit variables? What?) I have no intention of breaking backward compatibility for streams <=8 bits/value...

coder is conceptiually different from the number of bits which are in the
pixel format so whereever the distinction is made between 8 and 10
coder is not the right place

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070511/a88774e5/attachment.pgp>