[FFmpeg-devel] Uncompressed pixel format handling clarifications
Fri May 15 21:24:20 CEST 2009
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 ?
I find weird to have different commandlines on different 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 ?
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.
It seems for uncompressed decoders, we would have to #define cases for
BE/LE, what do you guys think ?
> For muxing it should be either BE (can be added to regtests, native for
> QT since it originated on Motorola/PPC) or native endian (to avoid
> byteswapping on LE CPUs).
Well, data passed to the muxer is in particular format.
Again should we #define for BE/LE in the muxer ?
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer http://www.ffmpeg.org
More information about the ffmpeg-devel