[FFmpeg-devel] Uncompressed pixel format handling clarifications

[Michael Niedermayer]

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.
> 
> >>> 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.

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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- 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/20090515/81b067a2/attachment.pgp>