[FFmpeg-devel] Uncompressed pixel format handling clarifications

[Michael Niedermayer]

On Fri, May 15, 2009 at 03:28:18PM -0700, Baptiste Coudurier wrote:
> 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 ?

-pix_fmt rgb555
would be the native endian variant

BE arch and LE arch are different
equality of formats depends on which way you compare (uint16_t vs. uint8_t)


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

what we want to achive:
* make it work :)
* simplicity
* speed probably doesnt matter because anti native rgb555&565 is a rather
  obscure thing IMHO

A-> the decoder could do bswap
B-> sws could do a bswap pass
C-> sws could truly support it

IMHO C is not worth it in terms of amount of code for this rare thing
A will require some changes at the encoder/muxer side too
so at a first look B seems the way to go

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
-------------- 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/20090516/27476a39/attachment.pgp>