[FFmpeg-devel] Uncompressed pixel format handling clarifications

[Baptiste Coudurier]

Michael,

On 5/15/2009 2:41 PM, Michael Niedermayer wrote:
> On Fri, May 15, 2009 at 12:24:20PM -0700, Baptiste Coudurier wrote:
>> Hi Kostya,
>>
>> On 5/15/2009 12:44 AM, Kostya wrote:
>>> On Thu, May 14, 2009 at 10:59:17PM -0700, Baptiste Coudurier wrote:
>>>> On Sun, May 10, 2009 at 01:34:30PM -0700, Baptiste Coudurier wrote:
>>>>> Hi guys,
>>>>>
>>>>> I'm quite confused regarding pixel format handling with uncompressed
>>>>> video currently.
>>>>>
>>>>> Quicktime supports almost every variant, be/le 565, 555, argb, rgba, bgra.
>>>>>
>>>>> I'd like to understand which pixfmt can be invoked from commandline.
>>>>> For example, on le arch I can request rgb565le, but not rgb565be,
>>>>> however both can be stored in .mov.
>> Any comment on this ? Can we clarify what can be invoked from
>> commandline and what is not possible ?
> 
> that what is supported can be invoked, that what is not can too but will
> fail one way or another.
> 
> 
>> I find weird to have different commandlines on different archs.

Of course. I'm just trying to clarify the intended behaviour ?
IE, should -pix_fmt rgb555 commandline be different on BE than on LE archs ?

>>>>> When decompressing (rawdec.c) which pix_fmt should be used ? Considering
>>>>> avpicture_layout (memcpy then) is used, LE/BE ones or NE one ?
>>>>>
>>>>> When muxing ? LE/BE ones ?
>>>>>
>>>>> Thanks for the clarification.
>>>> Sorry to insist, but is it really dumb to ask this ? :/
>>> I've asked a question like this looooooong time ago. 
>>> Operating non-native endian packed bits (i.e. 15/16) is silly.
>>> (the rest is IMO)
>> Of course, I'm trying to clarify the usage here :)
>>
>>> Thus, for decoding it should be NE which may require swapping in a form
>>> of hack in demuxer or bitstream filter or elsewhere.
> 
>> Even for uncompressed ?
> 
> i dont know
> 
> 
>> For "decoders" it's easy to use NE.
>> When memcpy/layout is used, it is less convenient, and I tend to think
>> that avoiding swapping treatment if more efficient therefore better.
> 
> id suspect that memcpy is limited by memory speed and the bswap would be
> free. Given that accessing anti-native rgb565 starts with a bswap, doing
> it during copy should be more efficient, thats just speed, iam not saying
> its cleaner or that i would recommand it.

Ok. It seems rawdec.c, currently, use avpicture_fill which do not even
memcpy. What should we do in this case ? Either #define for different
archs or use LE/BE ?

> If you want to add anti-native rgb565 support to sws, _clean_ patch welcome.

Of I certainly want to keep things clear and simple, and first trying to
determine what we'd like to achieve and have clear ideas.

After this, we can decide wether it's worth to add anti-native support
IMHO :)

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org