Hello, I have a webcam running the zc0301 driver. On the VIDIOC_S_FMT ioctl call, it always sets the pixel format to V4L2_PIX_FMT_JPEG. The current code doesn't take into account when the pixel format is changed on that call. Also, it doesn't support the compressed JPEG stream even if the pixel format is changed according to the result of the ioctl. What's the best way to make it support compressed JPEG? Just check for compressed and set appropriate codec_id? Ramiro Polla
Hi Ramiro, On Mon, 2007-02-05 at 22:32 -0200, ramiro at lisha.ufsc.br wrote:
Hello,
I have a webcam running the zc0301 driver. On the VIDIOC_S_FMT ioctl call, it always sets the pixel format to V4L2_PIX_FMT_JPEG. Good! Someone with similar hardware can help in testing and implementing support for compressed v4l2 formats ;-)
The current code doesn't take into account when the pixel format is changed on that call. Also, it doesn't support the compressed JPEG stream even if the pixel format is changed according to the result of the ioctl. Well, since I had no access to hardware generating compressed v4l2 streams, I decided to postpone the support for such feature
What's the best way to make it support compressed JPEG?
Just check for compressed and set appropriate codec_id? I have a dirty and half-working patch (at least, I had report of some kind of "half-success" with it) at home. I think it can be a good starting point... I'll post it this evening.
Thanks, Luca -- _____________________________________________________________________________ Copy this in your signature, if you think it is important: N O W A R ! ! !
Hi, On Tue, 2007-02-06 at 08:57 +0100, Luca Abeni wrote: [...]
I have a dirty and half-working patch (at least, I had report of some kind of "half-success" with it) at home. I think it can be a good starting point... I'll post it this evening. Here it is...
Luca
Luca Abeni wrote:
Hi,
On Tue, 2007-02-06 at 08:57 +0100, Luca Abeni wrote: [...]
I have a dirty and half-working patch (at least, I had report of some kind of "half-success" with it) at home. I think it can be a good starting point... I'll post it this evening.
Here it is...
Had to make some modifications for it to work. - Change int64_t_C to INT64_C - Move setting pkt->pts to after av_new_packet - Set st->codec->{width,height,time_base} after compressed_device_init works - Make device_init return an error when the device changes the pixelformat I think that's it... (altough the code could use some cleanup =) Attached new patch. Just ignore the change of video_device to s1->filename. It's part of the new grabbing interface. Ramiro Polla
Hi On Wed, Feb 07, 2007 at 11:18:33PM -0200, Ramiro Polla wrote:
Luca Abeni wrote:
Hi,
On Tue, 2007-02-06 at 08:57 +0100, Luca Abeni wrote: [...]
I have a dirty and half-working patch (at least, I had report of some kind of "half-success" with it) at home. I think it can be a good starting point... I'll post it this evening.
Here it is...
Had to make some modifications for it to work.
- Change int64_t_C to INT64_C - Move setting pkt->pts to after av_new_packet - Set st->codec->{width,height,time_base} after compressed_device_init works - Make device_init return an error when the device changes the pixelformat
I think that's it... (altough the code could use some cleanup =)
Attached new patch. Just ignore the change of video_device to s1->filename. It's part of the new grabbing interface. [...] +static int compressed_device_init(int fd, int *width, int *height) +{ + struct v4l2_format fmt; + int res; + + memset(&fmt, 0, sizeof(struct v4l2_format)); + fmt.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + fmt.fmt.pix.width = *width; + fmt.fmt.pix.height = *height; + fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_MJPEG; + res = ioctl(fd, VIDIOC_S_FMT, &fmt); + if ((*width != fmt.fmt.pix.width) || (*height != fmt.fmt.pix.height)) { + av_log(NULL, AV_LOG_INFO, "The V4L2 driver changed the video from %dx%d to %dx%d\n", *width, *height, fmt.fmt.pix.width, fmt.fmt.pix.height);
please provide a context to av_log (AVFormatContxt will do), i dont want to see to many new av_log(NULL, ...) they cause problems in multithreded apps [...]
+static int compressed_read_frame(struct video_data *s, AVPacket *pkt) +{ + struct v4l2_buffer buf; + int res; + + memset(&buf, 0, sizeof(struct v4l2_buffer)); + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + buf.memory = V4L2_MEMORY_MMAP; + + /* FIXME: Some special treatment might be needed in case of loss of signal... */ + while ((res = ioctl(s->fd, VIDIOC_DQBUF, &buf)) < 0 && + ((errno == EAGAIN) || (errno == EINTR))); + if (res < 0) { + av_log(NULL, AV_LOG_ERROR, "ioctl(VIDIOC_DQBUF): %s\n", strerror(errno)); + + return -1; + } + assert (buf.index < s->buffers); + if (av_new_packet(pkt, buf.bytesused) < 0) { + return -1; + } + pkt->pts = buf.timestamp.tv_sec * INT64_C(1000000) + buf.timestamp.tv_usec; + + /* Image is at s->buff_start[buf.index] */ + memcpy(pkt->data, s->buf_start[buf.index], buf.bytesused);
can that memcpy be avoided? (directly grabing into AVPacket.data)? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus
+ if ((*width != fmt.fmt.pix.width) || (*height != fmt.fmt.pix.height)) { + av_log(NULL, AV_LOG_INFO, "The V4L2 driver changed the video from %dx%d to %dx%d\n", *width, *height, fmt.fmt.pix.width, fmt.fmt.pix.height);
please provide a context to av_log (AVFormatContxt will do), i dont want to see to many new av_log(NULL, ...) they cause problems in multithreded apps Tomorrow I'll fix v4l2.c to pass proper contexts to av_log() as much as
+ /* Image is at s->buff_start[buf.index] */ + memcpy(pkt->data, s->buf_start[buf.index], buf.bytesused);
can that memcpy be avoided? (directly grabing into AVPacket.data)? I had a patch for doing something similar, but the patch had some
Hi Michael, On Sat, 2007-02-10 at 17:23 +0100, Michael Niedermayer wrote: [...] possibile, and I'll update this patch in a similar way. [...] problems (I do not remember right now). I'll search for it in the next days. Luca
Hi, On Wed, 2007-02-07 at 23:18 -0200, Ramiro Polla wrote: [...]
Here it is...
Had to make some modifications for it to work.
- Change int64_t_C to INT64_C - Move setting pkt->pts to after av_new_packet - Set st->codec->{width,height,time_base} after compressed_device_init works - Make device_init return an error when the device changes the pixelformat
I think that's it... (altough the code could use some cleanup =) Thanks. I'll try to cleanup the code, and I'll generate a new patch for you to test. After having it cleaned up and tested, I'll commit it.
Thanks, Luca
Hi, On Wed, 2007-02-07 at 23:18 -0200, Ramiro Polla wrote: [...]
Had to make some modifications for it to work.
- Change int64_t_C to INT64_C - Move setting pkt->pts to after av_new_packet - Set st->codec->{width,height,time_base} after compressed_device_init works - Make device_init return an error when the device changes the pixelformat
I think that's it... (altough the code could use some cleanup =) Ok; I think I did that cleanup... ;-)
Can you please try if the attached patch still works for you? (sorry to ask you to test again, but I have no way to check if I simplified too much ;-) If it works (as I hope), I'll committ it after testing that it does not break uncompressed grabbing (I have no computers with video capture cards right now, so I'll have to wait the end of next week... - So, you can take your time for your testing) Thanks, Luca
Hi, Luca Abeni wrote:
On Wed, 2007-02-07 at 23:18 -0200, Ramiro Polla wrote: [...]
Had to make some modifications for it to work.
- Change int64_t_C to INT64_C - Move setting pkt->pts to after av_new_packet - Set st->codec->{width,height,time_base} after compressed_device_init works - Make device_init return an error when the device changes the pixelformat
I think that's it... (altough the code could use some cleanup =) Ok; I think I did that cleanup... ;-)
Can you please try if the attached patch still works for you? (sorry to ask you to test again, but I have no way to check if I simplified too much ;-)
If it works (as I hope), I'll committ it after testing that it does not break uncompressed grabbing (I have no computers with video capture cards right now, so I'll have to wait the end of next week... - So, you can take your time for your testing)
Sorry for the ridiculously late reply but I lost track of this thread about 2 years ago. Now someone contacted me and tested a few patches up to the point where we got it working again. I no longer have the webcam to test, but I tried it earlier this year and always got stuck in an error where capturing stops at the 15th frame. Apparently it's because it should use V4L2_PIX_FMT_JPEG instead of V4L2_PIX_FMT_MJPEG. But I also remember I got it working 2 years ago with V4L2_PIX_FMT_MJPEG, so I don't know if something changed in the kernel or it's a regression there or these cameras just plain suck... Does anyone else have a camera to test this? Here's an updated patch. I can't test it myself but I can relay the patch to the tester. Ramiro Polla
Ramiro Polla <ramiro <at> lisha.ufsc.br> writes:
I no longer have the webcam to test, but I tried it earlier this year and always got stuck in an error where capturing stops at the 15th frame.
This sounds like issue 507. Did you only test with ffplay? Carl Eugen
On Sun, Sep 6, 2009 at 6:52 AM, Carl Eugen Hoyos<cehoyos at ag.or.at> wrote:
Ramiro Polla <ramiro <at> lisha.ufsc.br> writes:
I no longer have the webcam to test, but I tried it earlier this year and always got stuck in an error where capturing stops at the 15th frame.
This sounds like issue 507. Did you only test with ffplay?
I had only tested with ffmpeg. I'll see if I can get the tester to check if munmap is being called. Ramiro Polla
Carl Eugen Hoyos wrote:
Ramiro Polla <ramiro <at> lisha.ufsc.br> writes:
I no longer have the webcam to test, but I tried it earlier this year and always got stuck in an error where capturing stops at the 15th frame.
This sounds like issue 507. Did you only test with ffplay? Is that bug still around? I think I fixed it (in a different way respect to the one mentioned on roundup) when playing with some different issue... If I remember correctly, I asked someone for testing but I received no feedback (or I lost the answer, I am not sure)...
Luca
Ramiro Polla wrote: [...]
If it works (as I hope), I'll committ it after testing that it does not break uncompressed grabbing (I have no computers with video capture cards right now, so I'll have to wait the end of next week... - So, you can take your time for your testing)
Sorry for the ridiculously late reply but I lost track of this thread about 2 years ago. Now someone contacted me and tested a few patches up to the point where we got it working again. Ugh... Very old thread, indeed. I completely forgot it :)
But I now have (somewhere in one of my local trees) a patch that should add support for compressed v4l2 (only JPEG, for now).... I tested it with a "logitech something" webcam (providing MJPEG compressed video), and I have some reports that it works with other v4l2 compressed sources (but I have no details about them). I'll search for such patch and post it (it might be just a forward port of the patch you are posting), after re-testing (just to make sure that some recent change did not break it). Luca
Luca Abeni wrote: [...]
Sorry for the ridiculously late reply but I lost track of this thread about 2 years ago. Now someone contacted me and tested a few patches up to the point where we got it working again. Ugh... Very old thread, indeed. I completely forgot it :)
But I now have (somewhere in one of my local trees) a patch that should add support for compressed v4l2 (only JPEG, for now).... I tested it with a "logitech something" webcam (providing MJPEG compressed video), and I have some reports that it works with other v4l2 compressed sources (but I have no details about them).
I'll search for such patch and post it (it might be just a forward port of the patch you are posting), after re-testing (just to make sure that some recent change did not break it).
Sorry for the delay... I attach my patch (a little bit old, but it still applies). I think it's just a different version of the patch just re-posted by Ramiro. I just tested this patch with a logitech something webcam (which produces MJPEG video), and it works wonderfully with both ffmpeg and ffplay (I cannot use "-vcodec copy" in ffmpeg, because I get the "non-monotone timestamp" error, but I think this is an unrelated issue). More testing (and/or feedback) is welcome. Luca
Hi, On Fri, Sep 11, 2009 at 6:27 AM, Luca Abeni <lucabe72 at email.it> wrote:
Luca Abeni wrote: [...]
Sorry for the ridiculously late reply but I lost track of this thread about 2 years ago. Now someone contacted me and tested a few patches up to the point where we got it working again.
Ugh... Very old thread, indeed. I completely forgot it :)
But I now have (somewhere in one of my local trees) a patch that should add support for compressed v4l2 (only JPEG, for now).... I tested it with a "logitech something" webcam (providing MJPEG compressed video), and I have some reports that it works with other v4l2 compressed sources (but I have no details about them).
I'll search for such patch and post it (it might be just a forward port of the patch you are posting), after re-testing (just to make sure that some recent change did not break it).
Sorry for the delay... I attach my patch (a little bit old, but it still applies). I think it's just a different version of the patch just re-posted by Ramiro.
I just tested this patch with a logitech something webcam (which produces MJPEG video), and it works wonderfully with both ffmpeg and ffplay (I cannot use "-vcodec copy" in ffmpeg, because I get the "non-monotone timestamp" error, but I think this is an unrelated issue).
More testing (and/or feedback) is welcome.
I found the old webcam and tested again, and your patch worked. I send here an updated version with proper indentation and a few cosmetic changes (a comma after io_compressed in io_method, removed empty lines before return AVERROR(EIO);). A couple of differences from my patch were that I had av_free(st) which IIRC really isn't necessary even if the function fails, and I set st->codec->width/height. Ramiro Polla
Hi Ramiro, Ramiro Polla wrote: [...]
Sorry for the delay... I attach my patch (a little bit old, but it still applies). I think it's just a different version of the patch just re-posted by Ramiro.
I just tested this patch with a logitech something webcam (which produces MJPEG video), and it works wonderfully with both ffmpeg and ffplay (I cannot use "-vcodec copy" in ffmpeg, because I get the "non-monotone timestamp" error, but I think this is an unrelated issue).
More testing (and/or feedback) is welcome.
I found the old webcam and tested again, and your patch worked. I send here an updated version with proper indentation and a few cosmetic changes [...]
Thanks for testing the patch and fixing the cosmetic issues. If noone complains or has additional comments, I think the patch should be committed. In this week, I'll have a bad internet connection, so I think I'll commit this patch on Friday. Thanks, Luca
Hi Ramiro, On Sat, 2009-12-05 at 08:17 -0200, Ramiro Polla wrote: [...]
I just tested this patch with a logitech something webcam (which produces MJPEG video), and it works wonderfully with both ffmpeg and ffplay (I cannot use "-vcodec copy" in ffmpeg, because I get the "non-monotone timestamp" error, but I think this is an unrelated issue).
More testing (and/or feedback) is welcome.
I found the old webcam and tested again, and your patch worked. I send here an updated version [...]
Sorry for this never-ending story, but... A new patch implementing this kind of functionalities has just been posted by "klchxbec". Can you test it (the latest version, the one with the table-driven codec selection)? Thanks, Luca
participants (6)
-
angustia＠arrozcru.no-ip.org -
cehoyos＠ag.or.at -
lucabe72＠email.it -
michaelni＠gmx.at -
ramiro.polla＠gmail.com -
ramiro＠lisha.ufsc.br