Hi, NACK The byte ordering in v4l1's VIDEO_PALETTE_RGB24 was never really clear, but the kernel v4l1 compatibility ioctl handling has been mapping VIDEO_PALETTE_RGB24 <-> V4L2_PIX_FMT_BGR24 for ever and many v4l1 apps actually expect VIDEO_PALETTE_RGB24 to be BGR24. The only one I know of to get this wrong is camorama and the solution there is to: 1) not use camorama 2) if you use camorama anyway, fix it, there is a list of patches fixing various issues available here: http://pkgs.fedoraproject.org/gitweb/?p=camorama.git;a=tree Regards, Hans On 10/18/2010 02:44 PM, Marc Deslauriers wrote:
libv4l1: When asked for RGB, return RGB and not BGR Signed-off-by: Marc Deslauriers<marc.deslauriers@xxxxxxxxxx> --- lib/libv4l1/libv4l1.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/lib/libv4l1/libv4l1.c b/lib/libv4l1/libv4l1.c index cb53899..202f020 100644 --- a/lib/libv4l1/libv4l1.c +++ b/lib/libv4l1/libv4l1.c @@ -87,9 +87,9 @@ static unsigned int palette_to_pixelformat(unsigned int palette) case VIDEO_PALETTE_RGB565: return V4L2_PIX_FMT_RGB565; case VIDEO_PALETTE_RGB24: - return V4L2_PIX_FMT_BGR24; + return V4L2_PIX_FMT_RGB24; case VIDEO_PALETTE_RGB32: - return V4L2_PIX_FMT_BGR32; + return V4L2_PIX_FMT_RGB32; case VIDEO_PALETTE_YUYV: return V4L2_PIX_FMT_YUYV; case VIDEO_PALETTE_YUV422: @@ -118,9 +118,9 @@ static unsigned int pixelformat_to_palette(unsigned int pixelformat) return VIDEO_PALETTE_RGB555; case V4L2_PIX_FMT_RGB565: return VIDEO_PALETTE_RGB565; - case V4L2_PIX_FMT_BGR24: + case V4L2_PIX_FMT_RGB24: return VIDEO_PALETTE_RGB24; - case V4L2_PIX_FMT_BGR32: + case V4L2_PIX_FMT_RGB32: return VIDEO_PALETTE_RGB32; case V4L2_PIX_FMT_YUYV: return VIDEO_PALETTE_YUYV;
-- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
