[FFmpeg-devel] FFMPEG video4linux2: is read() still supported?

[frank at frankvh.com]

> -------- Original Message --------
> Subject: Re: [FFmpeg-devel] FFMPEG video4linux2: is read() still
> supported?
> From: Luca Abeni <lucabe72 at email.it>
> Date: Mon, March 10, 2008 1:03 am
> To: FFmpeg development discussions and patches
> <ffmpeg-devel at mplayerhq.hu>
> 
> Hi Frank,
> 
> frank at frankvh.com wrote:
> > I'm writing a simple V4L2 driver, very loosely based on an existing V4L1
> > driver:
> > 
> > http://www.kevinboone.com/README_dummy-camera.html
> > 
> > The V4L1 driver is very simple; it does *not* support mmap; it only
> > supports read() for obtaining video data. FFMPEG works fine with the
> > V4L1 driver. 
> > 
> > Moving this same functionality to a V4L2 driver, FFMPEG no longer works.
> [...]
> 
> The "read()" access to video frames is currently not implemented in
> libavformat/v4l2.c. I never found a v4l2 driver that does not support
> mmap(), so I've been lazy and I did not implement the methods using
> read().
> See libavformat/v4l2.c::read_frame().
> 
> Everything you need to do is to implement read_frame() (which currently
> returns -1), and everything should work.
> 
> 
> > I'm wondering if the FFMPEG V4L2 code requires the use of mmap, and
> > simply shuts down if its not available.
> 
> As you can see, this is the current behaviour. Patches are welcome ;-)
> 

Hi Luca,

Thanks very much for your very helpful reply. I took a look at the
v4l2.c file, and
also the v4l.c file. I have one other, related, question that perhaps
you know the answer
to. 

I have seen with ffmpeg and a v4l (video4linux 1) driver, that even if I
specify rgb24 on 
the ffmpeg command line, and even if the v4l driver only supports rgb24,
ffmpeg actually uses
bgr24. Looking in v4l.c I see this:


struct {
    int palette;
    int depth;
    enum PixelFormat pix_fmt;
} video_formats [] = {
    {.palette = VIDEO_PALETTE_YUV420P, .depth = 12, .pix_fmt =
PIX_FMT_YUV420P },
    {.palette = VIDEO_PALETTE_YUV422,  .depth = 16, .pix_fmt =
PIX_FMT_YUYV422 },
    {.palette = VIDEO_PALETTE_UYVY,    .depth = 16, .pix_fmt =
PIX_FMT_UYVY422 },
    {.palette = VIDEO_PALETTE_YUYV,    .depth = 16, .pix_fmt =
PIX_FMT_YUYV422 },
    /* NOTE: v4l uses BGR24, not RGB24 */
    {.palette = VIDEO_PALETTE_RGB24,   .depth = 24, .pix_fmt =
PIX_FMT_BGR24   },
    {.palette = VIDEO_PALETTE_RGB565,  .depth = 16, .pix_fmt =
PIX_FMT_BGR565  },
    {.palette = VIDEO_PALETTE_GREY,    .depth = 8,  .pix_fmt =
PIX_FMT_GRAY8   },
};


Do you know the origins of that comment: 
/* NOTE: v4l uses BGR24, not RGB24 */      ?

Searching the web, I have not seen reference to anything like this
before.

I am happy to accept this behaviour, now that I see it's expected
programmed behaviour and 
not a bug, as such. But it is a little puzzling to me why we would
deliberately reverse
the rgb byte order in a v4l case, but not in a v4l2 case.

Thanks again.

Frank.



> 				Luca
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel