[FFmpeg-devel] Uncompressed pixel format handling clarifications
Fri May 15 23:41:23 CEST 2009
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
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel