[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