[FFmpeg-devel] [RFC] AVComponentDescriptor and bit-streamed formats
Mon Mar 30 10:25:40 CEST 2009
On Mon, Mar 30, 2009 at 12:26:10AM +0200, Stefano Sabatini wrote:
> Hi all,
> I'm trying to figure out how to manage the bit-streamed formats using
> I'll use the term "bit-streamed format" and "byte-streamead format" to
> distinguish between the two types of formats.
> These are the concepts used for describing a component:
> * plane: this applies perfectly well to both bit-streamed and
> byte-streamed formats
> * step (range: 1 - 8): it's the number of bytes between 2 horizontally
> consecutive pixels (byte-streamed formats).
> For bit-streamed formats it may be both the number of *bits* between
> two consecutive pixels (only problem is that the range may not
> the number of bytes between the pixels, if the number of bytes
> between two pixels is not an integer then we need to add to this
> value another value.
> * offset (range: -1 - 6): number of bytes before the component of the
> first pixel, same consideration as for the step field applies.
> * shift (range: 0 - 7): it's the number of least significant bits that
> must be shifted away to get the value.
> This doesn't make sense for bit-streamed filters, but may be used in
> combination with step or offset.
> * depth: number of bits in the component, works fine with both bit and
> byte-streamed formats.
> So the problem I'm having is with step+offset+shift.
> The variables I need for describing a bit-streamed format are:
> * plane
> * step (bits or bytes+remaining bits)
> * offset (bits or bytes+remaining bits)
> * depth
> Currently the only bit-streamed formats supported in FFmpeg are:
> BGR4, RGB4, MONOWHITE, MONOBLACK, and for these the ranges used for
> step and offset may suffice for interpreting those values as a number
> of *bits*, but for extensibility sake I think we should:
> * extend the range of the step and offset fields
> * introduce new fields to express the step/offset remaining bits
> (maybe reusing shift)
> Once this is clear it should be fairly easy to complete the
so you want to extend things to support non existent cases?
no interest until you can provide a real and used pix format that needs
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you really think that XML is the answer, then you definitly missunderstood
the question -- Attila Kinali
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel