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@xxxxxx> 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@xxxxxxxxxxxxxxxx] >> Sent: 09 November 2010 12:29 >> To: Michael PARKER >> Cc: Daniel GlÃckner; linux-media@xxxxxxxxxxxxxxx >> 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 >> > ÿô.nlj·Ÿ®‰†+%ŠË±é¥Šwÿº{.nlj·¥Š{±þg‰¯â^n‡r¡öë¨è&£ûz¹Þúzf£¢·hšˆ§~††Ûÿÿïÿ‘ê_èæ+v‰¨þ)ßø
