[FFmpeg-devel] [PATCH] Enable RGB32 on video4linux2 devices

Jean Delvare khali
Thu Sep 4 15:50:20 CEST 2008

Hi Luca,

Thanks for your answer.

On Wed, 03 Sep 2008 22:16:33 +0200, Luca Abeni wrote:
> Hi Jean,
> Jean Delvare wrote:
> > Hi folks,
> > 
> > I am using ffmpeg to capture video streams from V4L2 devices (and it
> > works really well, so first of all I'd like to thank you a lot for the
> > excellent software!)
> Well, I'm happy to see people using the v4l2 input format without
> problems ;-)
> > For testing purposes, I need to get ffmpeg to put the devices in RGB32
> > or BGR32 pixel format.
> [...]
> > But I'm a bit skeptical because apparently the code was almost there
> > already but commented out. Was there a reason for that?
> I do not remember... Probably, I did not know the exact mapping, or I
> found some contradictory documentation about this format, and I've not
> been able to test it.
> Anyway, if you have a v4l2 card supporting V4L2_PIX_FMT_{BGR,RGB}32,
> you test the patch, and you confirm that it works, I'll commit it.

My original patch wasn't correct, I realized it only after testing,
sorry about that. There are two factors which make this specific format
difficult to deal with:

* The RGB4 format is apparently not totally specified in the V4L2
  standard. Some drivers think it means RGBA and others think it means

* The 32-bit RGB formats in ffmpeg depend on the host endianess. This
  means that PIX_FMT_RGB32 isn't the same the same if ffmpeg runs on a
  little-endian machine or a big-endian machine.

There seems to be an alias which resolves to the correct format based
on the endianess: PIX_FMT_BGRA. This works OK for me on a little-endian
machine where it resolves to PIX_FMT_RGB32. However I suspect it won't
work on big-endian machines, where it resolves to PIX_FMT_BGR32_1, due
to ffmpeg refusing to use PIX_FMT_BGR32_1 as an input pixel format:

swScaler: rgb32x is not supported as input pixel format

Not being familiar with the ffmpeg code, I don't know why this
limitation exists.

So, the following patch works for me on a little-endian machine:

 libavdevice/v4l2.c |   12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

--- ffmpeg.orig/libavdevice/v4l2.c	2008-09-02 21:35:20.000000000 +0200
+++ ffmpeg/libavdevice/v4l2.c	2008-09-04 15:14:58.000000000 +0200
@@ -99,6 +99,14 @@ static struct fmt_map fmt_conversion_tab
         .v4l2_fmt = V4L2_PIX_FMT_YUV410,
+        .ff_fmt = PIX_FMT_RGB555,
+        .v4l2_fmt = V4L2_PIX_FMT_RGB555,
+    },
+    {
+        .ff_fmt = PIX_FMT_RGB565,
+        .v4l2_fmt = V4L2_PIX_FMT_RGB565,
+    },
+    {
         .ff_fmt = PIX_FMT_BGR24,
         .v4l2_fmt = V4L2_PIX_FMT_BGR24,
@@ -106,12 +114,10 @@ static struct fmt_map fmt_conversion_tab
         .ff_fmt = PIX_FMT_RGB24,
         .v4l2_fmt = V4L2_PIX_FMT_RGB24,
-    /*
-        .ff_fmt = PIX_FMT_RGB32,
+        .ff_fmt = PIX_FMT_BGRA,
         .v4l2_fmt = V4L2_PIX_FMT_BGR32,
-    */
         .ff_fmt = PIX_FMT_GRAY8,
         .v4l2_fmt = V4L2_PIX_FMT_GREY,

I've added support for 15-bit and 16-bit RGB as well. I've tested all 3
formats on 3 different adapters (bttv, cx88 and zr36067) so I am
confident that this is correct for little-endian machines. I suspect
this won't work on big-endian machines without some additional work
(but there is no regression - it isn't working without my patch
either.) So maybe we can commit this patch for now, and if someone is
interested in getting these formats to work on big-endian machines this
can be added later.

Jean Delvare

More information about the ffmpeg-devel mailing list