Format of /dev/video0 data for HVR-4000 frame grabber

Format of /dev/video0 data for HVR-4000 frame grabber

[Michael PARKER]

All,

I'm attempting to capture a single frame from the /dev/video0 output of my HVR-4000 card's analogue tuner as a JPEG.

Whilst several resources exist for capturing the output of a card with h/w MPEG compression, I'm unable to determine the format of the /dev/video0 data for a frame grabber such as the HVR-4000.

Can anyone suggest a means by which I can capture a single frame from a frame grabber card? Can I just use "dd if=/dev/video0 of=image.jpg bs=64K" or similar or do I have to access the card via the V4L2 drivers?

Many thanks in advance,

Mike

Re: Format of /dev/video0 data for HVR-4000 frame grabber

[Daniel Glöckner]

On Tue, Nov 09, 2010 at 09:43:29AM +0100, Michael PARKER wrote:
> I'm attempting to capture a single frame from the /dev/video0 output of
> my HVR-4000 card's analogue tuner as a JPEG.
> 
> Whilst several resources exist for capturing the output of a card with
> h/w MPEG compression, I'm unable to determine the format of the
> /dev/video0 data for a frame grabber such as the HVR-4000.

According to the sourcecode the cx88 chip can do 8 bit grayscale,
15/16/24/32 bit RGB/BGR, and two variants of 4:2:2 YCbCr.
 
> Can anyone suggest a means by which I can capture a single frame from a
> frame grabber card? Can I just use "dd if=/dev/video0 of=image.jpg bs=64K"
> or similar or do I have to access the card via the V4L2 drivers?

Yes, dd should work but you need to use a blocksize that can hold a
complete frame and count=1 if you want a single frame. JPEG, as
mentioned above, is not possible with this board.

The resolution and data format can be selected with V4L2 ioctls.

  Daniel

RE: Format of /dev/video0 data for HVR-4000 frame grabber

[Michael PARKER]

Daniel,

Many thanks for your mail. Please excuse the naivety of my questions - I'm a h/w guy and a nube to the s/w world.

> -----Original Message-----
> From: Daniel Glöckner [mailto:daniel-gl@gmx.net]
> Sent: 09 November 2010 09:10
> To: Michael PARKER
> Cc: linux-media@vger.kernel.org
> Subject: Re: Format of /dev/video0 data for HVR-4000 frame grabber
> 
> On Tue, Nov 09, 2010 at 09:43:29AM +0100, Michael PARKER wrote:
> > I'm attempting to capture a single frame from the /dev/video0 output of
> > my HVR-4000 card's analogue tuner as a JPEG.
> >
> > Whilst several resources exist for capturing the output of a card with
> > h/w MPEG compression, I'm unable to determine the format of the
> > /dev/video0 data for a frame grabber such as the HVR-4000.
> 
> According to the sourcecode the cx88 chip can do 8 bit grayscale,
> 15/16/24/32 bit RGB/BGR, and two variants of 4:2:2 YCbCr.

Do you know which of these is the default format or how to determine the format I'm seeing coming out of /dev/video0? 

Do you have a suggestion for how data captured from /dev/video0 can be converted into a recognisable image format (JPEG, GIF, PNG etc.)?

I'm keen, if possible, to grab the single frame image using just command line tools and without recourse to ioctls, compiled code etc.

> > Can anyone suggest a means by which I can capture a single frame from a
> > frame grabber card? Can I just use "dd if=/dev/video0 of=image.jpg bs=64K"
> > or similar or do I have to access the card via the V4L2 drivers?
> 
> Yes, dd should work but you need to use a blocksize that can hold a
> complete frame and count=1 if you want a single frame. JPEG, as
> mentioned above, is not possible with this board.

Presumably blocksize is just x * y * depth? Do you happen to know the default x/y for the cx88 output? 

I assume that x/y can be set via ioctls but, as stated earlier, I'm keen to avoid writing/compiling code if I can. 

Do I need to make any allowance for any form of header within the blocksize?

Also, how do I synchronise dd to the beginning of a new frame (and thus avoid capturing sections of two frames)?

Thanks again,

Mike

RE: Format of /dev/video0 data for HVR-4000 frame grabber

[Andy Walls]

On Tue, 2010-11-09 at 10:34 +0100, Michael PARKER wrote:
> Daniel,
> 
> Many thanks for your mail. Please excuse the naivety of my questions -
> I'm a h/w guy and a nube to the s/w world.


> Do you know which of these is the default format or how to determine
> the format I'm seeing coming out of /dev/video0? 

$ v4l2-ctl -d /dev/video0 --list-formats
$ v4l2-ctl -d /dev/video0 --get-fmt-video
$ v4l2-ctl --help

> Do you have a suggestion for how data captured from /dev/video0 can be
> converted into a recognisable image format (JPEG, GIF, PNG etc.)?
> 
> I'm keen, if possible, to grab the single frame image using just
> command line tools and without recourse to ioctls, compiled code etc.

v4l2-ctl can set up the device.  As you and Daniel mentioned, dd can
read off a frame given the proper parameters.


> Also, how do I synchronise dd to the beginning of a new frame (and
> thus avoid capturing sections of two frames)?

When dd open()s the device and does a read() it should start a capture.
When dd close()s the device and exits, it should stop the capture.  I'm
fairly certain stopping and restarting a capture should resynchronize
things, but I'm not sure.  The overhead of stopping and starting a
capture may cause you some noticeable delays, but again, I'm not sure.

I think the answer is to write some code and use the Streaming I/O
ioctl()s interface to get frame based data. I know you were hoping to
avoid that.

Regards,
Andy

> Thanks again,
> 
> Mike

RE: Format of /dev/video0 data for HVR-4000 frame grabber

[Michael PARKER]

Andy,

Thanks - I'm looking over the source code for the V4L2 sample capture application (http://v4l2spec.bytesex.org/v4l2spec/capture.c) for inspiration.

I'm still more than a little unclear how I go about transforming my captured frame into an image file. 

Can you point me in the direction of a utility/methodology that I can use to transform RGB/BGR/YCbCr/greyscale into JPEG/PNG/GIF or similar?

Cheers,

Mike

> -----Original Message-----
> From: Andy Walls [mailto:awalls@md.metrocast.net]
> Sent: 09 November 2010 12:29
> To: Michael PARKER
> Cc: Daniel Glöckner; linux-media@vger.kernel.org
> Subject: RE: Format of /dev/video0 data for HVR-4000 frame grabber
> 
> On Tue, 2010-11-09 at 10:34 +0100, Michael PARKER wrote:
> > Daniel,
> >
> > Many thanks for your mail. Please excuse the naivety of my questions -
> > I'm a h/w guy and a nube to the s/w world.
> 
> 
> > Do you know which of these is the default format or how to determine
> > the format I'm seeing coming out of /dev/video0?
> 
> $ v4l2-ctl -d /dev/video0 --list-formats
> $ v4l2-ctl -d /dev/video0 --get-fmt-video
> $ v4l2-ctl --help
> 
> > Do you have a suggestion for how data captured from /dev/video0 can be
> > converted into a recognisable image format (JPEG, GIF, PNG etc.)?
> >
> > I'm keen, if possible, to grab the single frame image using just
> > command line tools and without recourse to ioctls, compiled code etc.
> 
> v4l2-ctl can set up the device.  As you and Daniel mentioned, dd can
> read off a frame given the proper parameters.
> 
> 
> > Also, how do I synchronise dd to the beginning of a new frame (and
> > thus avoid capturing sections of two frames)?
> 
> When dd open()s the device and does a read() it should start a capture.
> When dd close()s the device and exits, it should stop the capture.  I'm
> fairly certain stopping and restarting a capture should resynchronize
> things, but I'm not sure.  The overhead of stopping and starting a
> capture may cause you some noticeable delays, but again, I'm not sure.
> 
> I think the answer is to write some code and use the Streaming I/O
> ioctl()s interface to get frame based data. I know you were hoping to
> avoid that.
> 
> Regards,
> Andy
> 
> > Thanks again,
> >
> > Mike
> 

RE: Format of /dev/video0 data for HVR-4000 frame grabber

[Andy Walls]

Mike,

1. For a utility look at what ffmpeg has to offer.  Id wager it can be employed to do what ever you want.  (Although single JPEG image creation might have nonobvious command line arguments compared to MJPEG)

2. If you are writing code, you may want to link with libv4l2, libv4l, and/or libv4lconvert to have the library to transparent format conversion in userspace.  Search the list archives for announcement by Hans de Goede.

Regards,
Andy

Michael PARKER <michael.parker@st.com> wrote:

>Andy,
>
>Thanks - I'm looking over the source code for the V4L2 sample capture application (http://v4l2spec.bytesex.org/v4l2spec/capture.c) for inspiration.
>
>I'm still more than a little unclear how I go about transforming my captured frame into an image file. 
>
>Can you point me in the direction of a utility/methodology that I can use to transform RGB/BGR/YCbCr/greyscale into JPEG/PNG/GIF or similar?
>
>Cheers,
>
>Mike
>
>> -----Original Message-----
>> From: Andy Walls [mailto:awalls@md.metrocast.net]
>> Sent: 09 November 2010 12:29
>> To: Michael PARKER
>> Cc: Daniel Glöckner; linux-media@vger.kernel.org
>> Subject: RE: Format of /dev/video0 data for HVR-4000 frame grabber
>> 
>> On Tue, 2010-11-09 at 10:34 +0100, Michael PARKER wrote:
>> > Daniel,
>> >
>> > Many thanks for your mail. Please excuse the naivety of my questions -
>> > I'm a h/w guy and a nube to the s/w world.
>> 
>> 
>> > Do you know which of these is the default format or how to determine
>> > the format I'm seeing coming out of /dev/video0?
>> 
>> $ v4l2-ctl -d /dev/video0 --list-formats
>> $ v4l2-ctl -d /dev/video0 --get-fmt-video
>> $ v4l2-ctl --help
>> 
>> > Do you have a suggestion for how data captured from /dev/video0 can be
>> > converted into a recognisable image format (JPEG, GIF, PNG etc.)?
>> >
>> > I'm keen, if possible, to grab the single frame image using just
>> > command line tools and without recourse to ioctls, compiled code etc.
>> 
>> v4l2-ctl can set up the device.  As you and Daniel mentioned, dd can
>> read off a frame given the proper parameters.
>> 
>> 
>> > Also, how do I synchronise dd to the beginning of a new frame (and
>> > thus avoid capturing sections of two frames)?
>> 
>> When dd open()s the device and does a read() it should start a capture.
>> When dd close()s the device and exits, it should stop the capture.  I'm
>> fairly certain stopping and restarting a capture should resynchronize
>> things, but I'm not sure.  The overhead of stopping and starting a
>> capture may cause you some noticeable delays, but again, I'm not sure.
>> 
>> I think the answer is to write some code and use the Streaming I/O
>> ioctl()s interface to get frame based data. I know you were hoping to
>> avoid that.
>> 
>> Regards,
>> Andy
>> 
>> > Thanks again,
>> >
>> > Mike
>> 
>