[FFmpeg-devel] [RFC] AVComponentDescriptor and bit-streamed formats

Michael Niedermayer michaelni
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
> pixdesc.
> 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
>   suffice)
>   *or*
>   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
> or
> * 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
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090330/97369119/attachment.pgp>

More information about the ffmpeg-devel mailing list