[FFmpeg-user] FFv1: Encode rgb48le?
Peter B.
pb at das-werkstatt.com
Wed Jun 13 15:58:01 CEST 2012
On 06/09/2012 07:52 AM, Carl Eugen Hoyos wrote:
> Peter B. <pb <at> das-werkstatt.com> writes:
>
>> On 06/06/2012 08:39 PM, Carl Eugen Hoyos wrote:
>>> Peter B. <pb <at> das-werkstatt.com> writes:
>>>
>>>> "Incompatible pixel format 'rgb48le' for codec 'ffv1',
>>>> auto-selecting format 'yuv420p16le'"
>>> I consider it a bug that FFmpeg does not auto-select yuv444p16
> Ticket #1426
>
> [...]
>
>> I must admit, that I don't understand the "0" in RGB
>> colorspaces (0RGB, RGB0)...
> RGB24 is RGB with 8bit colour information per pixel,
> RGBA (and friends) is RGB24 plus eight bit transparency
> information. RGB0 is a 32bit representation of RGB24,
> there is no transparency information hidden there.
> There are two reasons for RGB0's existence:
> ffv1 (and other encoders) in the past claimed to support
> RGBA but actually supported only RGB0
> It might be faster to process RGB0 than RGB24 (for
> some encoders)
Thanks for clearing that up!
So, I presume that the 32bit representation of 24bit information can be
processed faster because of it's a more "native" word size (16, 32, 64
bits)?
However, I'm still confused about the following piece of code, taking
from the previously mentioned diff:
//------------
+ [PIX_FMT_0RGB] = {
+ .name = "0rgb",
+ .nb_components= 3,
+ .log2_chroma_w= 0,
+ .log2_chroma_h= 0,
+ .comp = {
+ {0,3,2,0,7}, /* R */
+ {0,3,3,0,7}, /* G */
+ {0,3,4,0,7}, /* B */
+ },
+ .flags = PIX_FMT_RGB,
+ },
+ [PIX_FMT_RGB0] = {
+ .name = "rgb0",
+ .nb_components= 3,
+ .log2_chroma_w= 0,
+ .log2_chroma_h= 0,
+ .comp = {
+ {0,3,1,0,7}, /* R */
+ {0,3,2,0,7}, /* G */
+ {0,3,3,0,7}, /* B */
+ {0,3,4,0,7}, /* A */
+ },
+ .flags = PIX_FMT_RGB,
+ },
//-------------
This looks to me as if PIX_FMT_0RGB is a 32bit representation of RGB24,
whereas PIX_FMT_RGB0 contains an alpha channel?
> (The naming is FFmpeg-specific afaik.)
I see.
btw: How are the 3x8bit (RGB24) stored in a 32bit word?
>>> 16bit rgb encoding is not as trivial as I hoped but certainly
>>> possible.
>> Interesting to hear that.
>> What is necessary in order to support it?
> encode_rgb_frame() needs to support bits_per_raw_sample>8
> similar to encode_plane()
I see...
I'll take a look at the code - maybe I'll understand it :)
Thanks a lot!
Pb
More information about the ffmpeg-user
mailing list