[MPlayer-dev-eng] quicktime 'raw ' format files not handled properly

[chas williams - CONTRACTOR]

sorry it took so long for me to reply.  i guess your message got lost
in my inbox somewhere.

In message <475928CD.9020100 at ag.or.at>,"Carl Eugen Hoyos" writes:
>Hi!
>
>On 2007-12-07 03:43, chas williams - CONTRACTOR wrote:
>> quicktime 'raw ' format video codec should be give the format tag
>> IMGFMT_RGB.
>
>Are you sure? I thought, IMGFMT_RGB_1 would be needed which isn't
>implemented because it is not supported by swscaler.

i dont know what IMGFMT_RGB_1 is.  i am reasonably certain that you
cant just set fourcc to be the value of 'raw '.  the other layers
of mplayer dont know what this means.  from the quicktime specs:

http://developer.apple.com/documentation/QuickTime/QTFF/QTFFChap3/chapter_4_section_2.html#//apple_ref/doc/uid/TP40000939-CH205-74522

    Uncompressed RGB

    Uncompressed RGB data is stored in a variety of different
    formats. The format used depends on the depth field of the video sample
    description. For all depths, the image data is padded on each scan line
    to ensure that each scan line begins on an even byte boundary.

    * For depths of 1, 2, 4, and 8, the values stored are indexes into
    the color table specified in the color table ID field.

    * For a depth of 16, the pixels are stored as 5-5-5 RGB values with
    the high bit of each 16-bit integer set to 0.

    * For a depth of 24, the pixels are stored packed together in
    RGB order.

    * For a depth of 32, the pixels are stored with an 8-bit alpha
    channel, followed by 8-bit RGB components.

    RGB data can be stored in composite or planar format. Composite format
    stores the RGB data for each pixel contiguously, while planar format
    stores the R, G, and B data separately, so the RGB information for a given
    pixel is found using the same offset into multiple tables. For example,
    the data for two pixels could be represented in composite format as
    RGB-RGB or in planar format as RR-GG-BB.

so my patch is only correct for composite format.  i have never seen
a planar quicktime file but its a possiblity.  does anyone have an 
example?

>Could you upload a sample to incoming?

most of my samples are pretty big.  the smallest is a ~200MB.  if
that's ok with you, i could upload it.

>Here is a sample that is not shown correctly (should be brown), no
>difference with or without your patch:
>https://live.polito.it/roundup/ffmpeg/issue248

all my samples are 24.  the sample file attached to issue248 is 32-bit and
thereofre has an alpha channel.  so i guess IMGFMT_RGB32 isnt quite right,
but perhaps IMGFMT_ARGB is a better match for 32-bit files.