Testing Requested: Python Bindings for Video4linux2

Testing Requested: Python Bindings for Video4linux2

[Jackson Yee]

For anyone who is a fellow python fan and has a video4linux2 capture
card, please try out

http://code.google.com/p/python-video4linux2/

and let me know if the samples work out for you. I'd like to see how
this performs on cards other than my Happugage ImpactVCB.

--
Regards,
Jackson Yee
The Possum Company
540-818-4079
me@gotpossum.com

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: Testing Requested: Python Bindings for Video4linux2

[Laurent Pinchart]

Hi,

first of all, sorry for the late reply.

On Tuesday 28 October 2008, Jackson Yee wrote:
> For anyone who is a fellow python fan and has a video4linux2 capture
> card, please try out
>
> http://code.google.com/p/python-video4linux2/
>
> and let me know if the samples work out for you. I'd like to see how
> this performs on cards other than my Happugage ImpactVCB.

I'm testing your bindings with a Quickcam Pro for Notebooks (using the 
uvcvideo driver).

$ ./pyv4l2.py
Available devices:  ['/dev/video0', '/dev/video1394-0']
        /dev/video0
Capabilities:
        Capture
        Streaming
Input 0:
                Name:   Camera 1
                Type:   camera
                Standards: []
Traceback (most recent call last):
  File "./pyv4l2.py", line 755, in <module>
    d.SetStandard(d.standards['NTSC'])
  File "./pyv4l2.py", line 456, in SetStandard
    (FindKey(self.standards, std, 'Unknown'),
NameError: global name 'FindKey' is not defined

The uvcvideo driver doesn't implement the standard ioctls. This should not be 
fatal (and you probably want to define FindKeyas well).

$ ./streampics.py /dev/video0 0 MJPG 640 480 testpics
Traceback (most recent call last):
  File "./streampics.py", line 94, in <module>
    Run()
  File "./streampics.py", line 59, in Run
    d.SetResolution( int(options.width), int(options.height) )
  File "/home/laurent/src/kernel/uvc/python-v4l2/pyv4l2.py", line 551, in 
SetResolution
    self.SetFormat()
  File "/home/laurent/src/kernel/uvc/python-v4l2/pyv4l2.py", line 492, in 
SetFormat
    lib.Error()
Exception: Could not set format:        22: Invalid argument

The problem comes from a bad alignment in the PixFormat structure. At least on 
my architecture (x86) the type field is 32 bits wide.

Best regards,

Laurent Pinchart

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: Testing Requested: Python Bindings for Video4linux2

[Jackson Yee]

Lauren,

On Wed, Nov 5, 2008 at 7:42 PM, Laurent Pinchart
<laurent.pinchart@skynet.be> wrote:
> The uvcvideo driver doesn't implement the standard ioctls. This should not be
> fatal (and you probably want to define FindKeyas well).

The standard ioctls are, unfortunately, all I have to go by since I'm
testing on my amd64 box with a bttv card. If a function does not
succeed though, it should throw an exception and let the user code
sort things out. Do you have a link for the uncvideo driver so I could
add support for it?

FindKey looks to be Carl's code. ;-) I've added the function now.

> The problem comes from a bad alignment in the PixFormat structure. At least on
> my architecture (x86) the type field is 32 bits wide.

I've updated the type field on PixFormat to c_long, which should come
out to be the right size on both x86 and amd64 platforms now.

Thanks for the test. I'm working on adding libavcodec/libavformat
support so that we can capture straight to video instead of jpegs like
we're doing now. Please let me know if we have any other issues.

-- 
Regards,
Jackson Yee
The Possum Company
540-818-4079
me@gotpossum.com

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: Testing Requested: Python Bindings for Video4linux2

[Carl Karsten]

Jackson Yee wrote:
> Lauren,
> 
> On Wed, Nov 5, 2008 at 7:42 PM, Laurent Pinchart
> <laurent.pinchart@skynet.be> wrote:
>> The uvcvideo driver doesn't implement the standard ioctls. This should not be
>> fatal (and you probably want to define FindKeyas well).
> 
> The standard ioctls are, unfortunately, all I have to go by since I'm
> testing on my amd64 box with a bttv card.

and vivi.  I wish more people would test against vivi.  although right now I
would hold off, cuz there is a nasty memory leak in one of vivi.c, capture.c or
the newer capture_example.c - details:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/294951 - I am guessing vivi.

> If a function does not
> succeed though, it should throw an exception and let the user code
> sort things out. Do you have a link for the uncvideo driver so I could
> add support for it?
> 
> FindKey looks to be Carl's code. ;-) I've added the function now.

I'll take responsibility for that, cuz it make it look like I am doing something
 kinda useful :)

Carl K

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: Testing Requested: Python Bindings for Video4linux2

[Laurent Pinchart]

Hi,

On Friday 07 November 2008, Jackson Yee wrote:
> Lauren,
>
> On Wed, Nov 5, 2008 at 7:42 PM, Laurent Pinchart
>
> <laurent.pinchart@skynet.be> wrote:
> > The uvcvideo driver doesn't implement the standard ioctls. This should
> > not be fatal (and you probably want to define FindKeyas well).
>
> The standard ioctls are, unfortunately, all I have to go by since I'm
> testing on my amd64 box with a bttv card. If a function does not
> succeed though, it should throw an exception and let the user code
> sort things out.

That's right. But your sample application should handle that.

> Do you have a link for the uncvideo driver so I could add support for it?

Sure. http://linux-uvc.berlios.de/

> FindKey looks to be Carl's code. ;-) I've added the function now.
>
> > The problem comes from a bad alignment in the PixFormat structure. At
> > least on my architecture (x86) the type field is 32 bits wide.
>
> I've updated the type field on PixFormat to c_long, which should come
> out to be the right size on both x86 and amd64 platforms now.
>
> Thanks for the test. I'm working on adding libavcodec/libavformat
> support so that we can capture straight to video instead of jpegs like
> we're doing now. Please let me know if we have any other issues.

Best regards,

Laurent Pinchart

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: Testing Requested: Python Bindings for Video4linux2

[Jens Bongartz]

Hi Jackson, Laurent and Carl,

I would appreciate the uvcvideo supprt of the Python bindings for
Video4Linux2 a lot.
Could you send a message on this list, when its done?

Thanks a lot,
Jens


Lauren,

On Wed, Nov 5, 2008 at 7:42 PM, Laurent Pinchart
<laurent.pinchart@xxxxxxxxx> wrote:
> The uvcvideo driver doesn't implement the standard ioctls. This should not be
> fatal (and you probably want to define FindKeyas well).

The standard ioctls are, unfortunately, all I have to go by since I'm
testing on my amd64 box with a bttv card. If a function does not
succeed though, it should throw an exception and let the user code
sort things out. Do you have a link for the uncvideo driver so I could
add support for it?

FindKey looks to be Carl's code. ;-) I've added the function now.

> The problem comes from a bad alignment in the PixFormat structure. At least on
> my architecture (x86) the type field is 32 bits wide.

I've updated the type field on PixFormat to c_long, which should come
out to be the right size on both x86 and amd64 platforms now.

Thanks for the test. I'm working on adding libavcodec/libavformat
support so that we can capture straight to video instead of jpegs like
we're doing now. Please let me know if we have any other issues.

-- 
Regards,
Jackson Yee
The Possum Company
540-818-4079
me@xxxxxxxxxxxxx

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: Testing Requested: Python Bindings for Video4linux2

[Jackson Yee]

I'm going to be getting one of these webcams to test with after the
new year, so I'll try to add support for it then.

My earlier approach of trying to integrate libavcodec/libavformat in
Python has been a huge headache, to be blunt, so I'm currently trying
to move more into the C layer and use Python for only the high-level
system calls which determine the video devices, sets the formats, and
so forth. Eventually, you'll be able to set everything up, start the
capturing loop in C, and just sit back and check on it every once in a
while from Python code (This approach might be better for
cross-platform compatibility anyways...)

Thanks for trying the library out. I'll do a major merge soon once I
have some working code instead of debugging code.

Regards,
Jackson Yee
The Possum Company
540-818-4079
me@gotpossum.com

On Wed, Dec 31, 2008 at 11:17 AM, Jens Bongartz <bongartz@gmail.com> wrote:
> Hi everybody,
>
> I saw this thread recently and I am interested in this topic too.
> I am using a Logitech Quickcam 9000 Pro with the uvcvideo driver. The
> camera works properly with the uvccapture application.
> I did some experiment with the python-video4linux2 bindings using the
> python interactive mode. To be honest I am not really familiar with
> v4l2.
> Here are my results:
>
>>>> import pyv4l2
>>>> cam = pyv4l2.Device('dev/video0')
>>>> cam.EnumInput(0)
> ['Camera 1', 'camera', 0L, 0L, [], []]
>>>> cam.EnumFormats(1)
> [('MJPG', 'MJPEG'), ('YUYV', 'YUV 4 :2 :2 (YUYV)')]
>>>> cam.GetResolutions()
> [(320L, 240L), (640L, 480L), (800L, 600L)]
>>>> cam.QueryCaps()
>>>> cam.driver
> 'uvcvideo'
>>>> cam.businfo
> '0000:00:10.1'
>>>> cam.card
> 'UVC Camera (046d:0990)'
>>>> cam.GetFormat()
>>>> cam.format.width
> 800L
>>>> cam.format.height
> 600L
>>>> cam.format.pixelformat
> 'MJPEG'
>>>> cam.SetFormat()
>
> The Read() method works without an error message and the buffer is created.
>>>> cam.Read()
>>>> cam.buffer
> <ctypes.c_char_Array_62933 object at 0xb7e5053c>
>
> But the camera seems not to react to the Read() call. The camera's LED
> does not flash like using the uvccapture application and the buffer is
> filled just with '\x00'. Am I doing something wrong?
>
> As Laurent already mentioned the "d.SetStandard( d.standards['NTSC']
> )" call creates an exception.
> Any suggestions? I would be happy to this webcam work with python.
>
> Wish you all the best for 2009.
>
> Best regards,
> Jens
>
>
>>From: Laurent Pinchart <laurent.pinchart <at> skynet.be>
>>Subject: Re: Testing Requested: Python Bindings for Video4linux2
>>Date: 2008-11-09 22:07:20 GMT (7 weeks, 2 days, 18 hours and 5 minutes ago)
>
>>Hi,
>
>>On Friday 07 November 2008, Jackson Yee wrote:
>>> Lauren,
>>>
>>> On Wed, Nov 5, 2008 at 7:42 PM, Laurent Pinchart
>>>
>>> <laurent.pinchart <at> skynet.be> wrote:
>>> > The uvcvideo driver doesn't implement the standard ioctls. This should
>>> > not be fatal (and you probably want to define FindKeyas well).
>>>
>>> The standard ioctls are, unfortunately, all I have to go by since I'm
>>> testing on my amd64 box with a bttv card. If a function does not
>>> succeed though, it should throw an exception and let the user code
>>> sort things out.
>
>>That's right. But your sample application should handle that.
>
>>> Do you have a link for the uncvideo driver so I could add support for it?
>
>>Sure. http://linux-uvc.berlios.de/
>
>>> FindKey looks to be Carl's code. ;-) I've added the function now.
>>>
>>>> > The problem comes from a bad alignment in the PixFormat structure. At
>>> > least on my architecture (x86) the type field is 32 bits wide.
>>>
>>> I've updated the type field on PixFormat to c_long, which should come
>>> out to be the right size on both x86 and amd64 platforms now.
>>>
>>> Thanks for the test. I'm working on adding libavcodec/libavformat
>>> support so that we can capture straight to video instead of jpegs like
>>> we're doing now. Please let me know if we have any other issues.
>
>>Best regards,
>
>>Laurent Pinchart
>

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: Testing Requested: Python Bindings for Video4linux2

[Laurent Pinchart]

HI Jens,

On Wednesday 31 December 2008, Jens Bongartz wrote:
> Hi everybody,
>
> I saw this thread recently and I am interested in this topic too.
> I am using a Logitech Quickcam 9000 Pro with the uvcvideo driver. The
> camera works properly with the uvccapture application.
> I did some experiment with the python-video4linux2 bindings using the
> python interactive mode. To be honest I am not really familiar with
> v4l2.
>
> Here are my results:
> >>> import pyv4l2
> >>> cam = pyv4l2.Device('dev/video0')
> >>> cam.EnumInput(0)
>
> ['Camera 1', 'camera', 0L, 0L, [], []]
>
> >>> cam.EnumFormats(1)
>
> [('MJPG', 'MJPEG'), ('YUYV', 'YUV 4 :2 :2 (YUYV)')]
>
> >>> cam.GetResolutions()
>
> [(320L, 240L), (640L, 480L), (800L, 600L)]
>
> >>> cam.QueryCaps()
> >>> cam.driver
>
> 'uvcvideo'
>
> >>> cam.businfo
>
> '0000:00:10.1'
>
> >>> cam.card
>
> 'UVC Camera (046d:0990)'
>
> >>> cam.GetFormat()
> >>> cam.format.width
>
> 800L
>
> >>> cam.format.height
>
> 600L
>
> >>> cam.format.pixelformat
>
> 'MJPEG'
>
> >>> cam.SetFormat()
>
> The Read() method works without an error message and the buffer is created.
>
> >>> cam.Read()
> >>> cam.buffer
>
> <ctypes.c_char_Array_62933 object at 0xb7e5053c>
>
> But the camera seems not to react to the Read() call. The camera's LED
> does not flash like using the uvccapture application and the buffer is
> filled just with '\x00'. Am I doing something wrong?

The read method is not supported by the uvcvideo driver. You should use the 
mmap video capture method.

> As Laurent already mentioned the "d.SetStandard( d.standards['NTSC']
> )" call creates an exception.
> Any suggestions? I would be happy to this webcam work with python.

Don't use the SetStandard function with UVC cameras :-). Or handle the 
exception and recover gracefully.

Best regards,

Laurent Pinchart

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: Testing Requested: Python Bindings for Video4linux2

[Jens Bongartz]

[-- Attachment #1: Type: text/plain, Size: 4115 bytes --]

Dear Laurent, dear Jackson,

thanks for your reply to my request.
I don't want to impose on you but maybe you are interested in my
findings. To get a better impression of my intention I attached a
brief description of my just started "FB-Py-Vision" project.

Form the source-code of uvccapture-0.5 I derived a shared library to
get access to the webcam from python using ctypes (file attached
"pycapture_03.c"). Please show mercy to me, I am not a C-expert. To
get continous grabbing I seperated init_videoIn(), uvcGrab() and
close() in different functions. I discovered that init_videoIn() /
free(videoIn) on every uvcGrab() is very time consuming and not
suitable for high framerates.
The functions I wrote are quite fixed and unflexible because right now
I am only interested in luminance/YUV with 640 by 480. The
corresponding python-program is also attached. ('python_capture.py')

Now something interesting appears: Grabbing the luminance images works
without problems (high frame rate). When I switch to the contour-mode
the python image processing workload is higher and the uvcGrab() calls
are fewer. For a short period the framerate slows down but after a few
seconds recovers but now with a delay between captured and displayed
images of around 4 seconds. Very curious! When I switch back to
"normal mode" the framerate speeds up (!) a short time and then
recovers again without a delay.

I suppose this effect is a result of the weak VIA-CPU I use (see my
project-description). In general I don't mind if the framerate drops
when the image processing load rises but the problem is that I want to
process an actual image and not an image which is a few seconds old.
(I hope you understand what I mean).

Furthermore I assume that the uvcvideo streaming mode plays also a
role. I suppose that the 16 v4l2_buffer becomes unsynchronised. But
when I decrease the NB_BUFFER constant of "v4l2uvc.h" everything
compiles flawless but on excecution I get a Segmentation fault with a
fatal error. Only NB_BUFEER = 16 works. Is this correct?

What do you think? Do you have any hints for me, why I get this delay?

Many thanks in advance.
Jens


2009/1/4 Laurent Pinchart <laurent.pinchart@skynet.be>:
> HI Jens,
>
> On Wednesday 31 December 2008, Jens Bongartz wrote:
>> Hi everybody,
>>
>> I saw this thread recently and I am interested in this topic too.
>> I am using a Logitech Quickcam 9000 Pro with the uvcvideo driver. The
>> camera works properly with the uvccapture application.
>> I did some experiment with the python-video4linux2 bindings using the
>> python interactive mode. To be honest I am not really familiar with
>> v4l2.
>>
>> Here are my results:
>> >>> import pyv4l2
>> >>> cam = pyv4l2.Device('dev/video0')
>> >>> cam.EnumInput(0)
>>
>> ['Camera 1', 'camera', 0L, 0L, [], []]
>>
>> >>> cam.EnumFormats(1)
>>
>> [('MJPG', 'MJPEG'), ('YUYV', 'YUV 4 :2 :2 (YUYV)')]
>>
>> >>> cam.GetResolutions()
>>
>> [(320L, 240L), (640L, 480L), (800L, 600L)]
>>
>> >>> cam.QueryCaps()
>> >>> cam.driver
>>
>> 'uvcvideo'
>>
>> >>> cam.businfo
>>
>> '0000:00:10.1'
>>
>> >>> cam.card
>>
>> 'UVC Camera (046d:0990)'
>>
>> >>> cam.GetFormat()
>> >>> cam.format.width
>>
>> 800L
>>
>> >>> cam.format.height
>>
>> 600L
>>
>> >>> cam.format.pixelformat
>>
>> 'MJPEG'
>>
>> >>> cam.SetFormat()
>>
>> The Read() method works without an error message and the buffer is created.
>>
>> >>> cam.Read()
>> >>> cam.buffer
>>
>> <ctypes.c_char_Array_62933 object at 0xb7e5053c>
>>
>> But the camera seems not to react to the Read() call. The camera's LED
>> does not flash like using the uvccapture application and the buffer is
>> filled just with '\x00'. Am I doing something wrong?
>
> The read method is not supported by the uvcvideo driver. You should use the
> mmap video capture method.
>
>> As Laurent already mentioned the "d.SetStandard( d.standards['NTSC']
>> )" call creates an exception.
>> Any suggestions? I would be happy to this webcam work with python.
>
> Don't use the SetStandard function with UVC cameras :-). Or handle the
> exception and recover gracefully.
>
> Best regards,
>
> Laurent Pinchart
>

[-- Attachment #2: FB-py-Vision-Project.pdf --]
[-- Type: application/pdf, Size: 286512 bytes --]

[-- Attachment #3: pyuvccapture_3.c --]
[-- Type: text/plain, Size: 3212 bytes --]


/*******************************************************************************
#                        pyuvccapture basing on                                #
#             uvccapture: USB UVC Video Class Snapshot Software                #
#This package work with the Logitech UVC based webcams with the mjpeg feature  #
#.                                                                             #
# 	Orginally Copyright (C) 2005 2006 Laurent Pinchart &&  Michel Xhaard   #
#       Modifications Copyright (C) 2006  Gabriel A. Devenyi                   #
#       Modifications to pyuvccapture (c) 2009 Jens Bongartz                   #
#							                       #
# This program is free software; you can redistribute it and/or modify         #
# it under the terms of the GNU General Public License as published by         #
# the Free Software Foundation; either version 2 of the License, or            #
# (at your option) any later version.                                          #
#                                                                              #
# This program is distributed in the hope that it will be useful,              #
# but WITHOUT ANY WARRANTY; without even the implied warranty of               #
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the                #
# GNU General Public License for more details.                                 #
#                                                                              #
# You should have received a copy of the GNU General Public License            #
# along with this program; if not, write to the Free Software                  #
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA    #
#                                                                              #
*******************************************************************************/

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <signal.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>
#include <jpeglib.h>
#include <time.h>
#include <linux/videodev.h>

#include "v4l2uvc.h"

struct vdIn *videoIn;

int 
cam_init (int width, int height)
{
  char *videodevice = "/dev/video0";
  char *post_capture_command[3];
  int format = V4L2_PIX_FMT_YUYV;
  int grabmethod = 1;
  int brightness = 0, contrast = 0, saturation = 0, gain = 0;
  int verbose = 0;
  int delay = 0;
  int quality = 100;

  videoIn = (struct vdIn *) calloc (1, sizeof (struct vdIn));

  if (init_videoIn(videoIn, (char *) videodevice, width, height, format, grabmethod) < 0)
    exit (1);

  return 0;

}

int
cam_capture (char *array, int len)
{

  if (uvcGrab (videoIn) < 0) {
      fprintf (stderr, "Error grabbing\n");
      close_v4l2 (videoIn);
      free (videoIn);
      exit (1);
  }

  len = videoIn->buf.bytesused;  
  //fprintf (stdout, "buf.index (%d).\n", videoIn->buf.index);
  //fprintf (stdout, "buf.timestamp (%d).\n", videoIn->buf.timestamp);

  int i;

  for(i = 0; i < len; i++){
      array[i] = videoIn->framebuffer[i];
  }
  
  videoIn->getPict = 0;

  return len;
}

int 
cam_close ()
{

  videoIn->getPict = 0;
  close_v4l2 (videoIn);
  free (videoIn);
   
  return 0;
}


[-- Attachment #4: python_capture.py --]
[-- Type: text/plain, Size: 1725 bytes --]

import ctypes, os
import pygame, sys
import ImageFilter
import time
from PIL import Image
from pygame.locals import *

str_buffer = ctypes.create_string_buffer(614400)
buffersize = 614400

size = (640, 480)
white = (255, 255, 255)

os.environ["SDL_VIDEODRIVER"] = "fbcon"

pygame.init()
screen = pygame.display.set_mode(size,0,32)
pygame.mouse.set_visible(False)

print pygame.version.ver
print pygame.get_sdl_version()

print pygame.display.Info()
print "Driver:",pygame.display.get_driver()

cam=ctypes.CDLL('/root/python-v4l2/libpyuvc_3.so.1.0')

palette = tuple([(i, i, i) for i in range(256)])

modes = pygame.display.list_modes()
print "Display Modes:",modes
depth = pygame.display.mode_ok(size)
print "Best Mode:",depth

print cam.cam_init(640, 480)

#start = time.time()

outlined = False
done = False

while not done:
      
   cam.cam_capture(str_buffer, buffersize)
   bild = str_buffer[:]
   Y_value = bild[::2]
   #print time.time()-start
   #start = time.time()

   if outlined:
      im = Image.fromstring('L',size,Y_value)
      im = im.filter(ImageFilter.CONTOUR)
      im = im.convert('RGBA')
      data = im.tostring()
      surf = pygame.image.fromstring(data,size,im.mode).convert()
   else:
      surf = pygame.image.fromstring(Y_value,size,'P')
      surf.set_palette(palette)
      surf = pygame.Surface.convert(surf,32)
      
   screen.blit(surf,(0,0))
   pygame.display.update()

   for e in pygame.event.get():
      if e.type == pygame.KEYDOWN:
         pygame.event.pump()
         keystate = pygame.key.get_pressed()
         
         if keystate[K_ESCAPE]:
            done = True

         if keystate[K_o]:
            outlined = not outlined
            
print cam.cam_close()
sys.exit(0)

[-- Attachment #5: Type: text/plain, Size: 164 bytes --]

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: Testing Requested: Python Bindings for Video4linux2

[Paul Thomas]

Jens,

I'd give it a try. Can you include a make file or tell me compile command?

thanks,
Paul

2009/1/4 Jens Bongartz <bongartz@gmail.com>:
> Dear Laurent, dear Jackson,
>
> thanks for your reply to my request.
> I don't want to impose on you but maybe you are interested in my
> findings. To get a better impression of my intention I attached a
> brief description of my just started "FB-Py-Vision" project.
>
> Form the source-code of uvccapture-0.5 I derived a shared library to
> get access to the webcam from python using ctypes (file attached
> "pycapture_03.c"). Please show mercy to me, I am not a C-expert. To
> get continous grabbing I seperated init_videoIn(), uvcGrab() and
> close() in different functions. I discovered that init_videoIn() /
> free(videoIn) on every uvcGrab() is very time consuming and not
> suitable for high framerates.
> The functions I wrote are quite fixed and unflexible because right now
> I am only interested in luminance/YUV with 640 by 480. The
> corresponding python-program is also attached. ('python_capture.py')
>
> Now something interesting appears: Grabbing the luminance images works
> without problems (high frame rate). When I switch to the contour-mode
> the python image processing workload is higher and the uvcGrab() calls
> are fewer. For a short period the framerate slows down but after a few
> seconds recovers but now with a delay between captured and displayed
> images of around 4 seconds. Very curious! When I switch back to
> "normal mode" the framerate speeds up (!) a short time and then
> recovers again without a delay.
>
> I suppose this effect is a result of the weak VIA-CPU I use (see my
> project-description). In general I don't mind if the framerate drops
> when the image processing load rises but the problem is that I want to
> process an actual image and not an image which is a few seconds old.
> (I hope you understand what I mean).
>
> Furthermore I assume that the uvcvideo streaming mode plays also a
> role. I suppose that the 16 v4l2_buffer becomes unsynchronised. But
> when I decrease the NB_BUFFER constant of "v4l2uvc.h" everything
> compiles flawless but on excecution I get a Segmentation fault with a
> fatal error. Only NB_BUFEER = 16 works. Is this correct?
>
> What do you think? Do you have any hints for me, why I get this delay?
>
> Many thanks in advance.
> Jens
>
>
> 2009/1/4 Laurent Pinchart <laurent.pinchart@skynet.be>:
>> HI Jens,
>>
>> On Wednesday 31 December 2008, Jens Bongartz wrote:
>>> Hi everybody,
>>>
>>> I saw this thread recently and I am interested in this topic too.
>>> I am using a Logitech Quickcam 9000 Pro with the uvcvideo driver. The
>>> camera works properly with the uvccapture application.
>>> I did some experiment with the python-video4linux2 bindings using the
>>> python interactive mode. To be honest I am not really familiar with
>>> v4l2.
>>>
>>> Here are my results:
>>> >>> import pyv4l2
>>> >>> cam = pyv4l2.Device('dev/video0')
>>> >>> cam.EnumInput(0)
>>>
>>> ['Camera 1', 'camera', 0L, 0L, [], []]
>>>
>>> >>> cam.EnumFormats(1)
>>>
>>> [('MJPG', 'MJPEG'), ('YUYV', 'YUV 4 :2 :2 (YUYV)')]
>>>
>>> >>> cam.GetResolutions()
>>>
>>> [(320L, 240L), (640L, 480L), (800L, 600L)]
>>>
>>> >>> cam.QueryCaps()
>>> >>> cam.driver
>>>
>>> 'uvcvideo'
>>>
>>> >>> cam.businfo
>>>
>>> '0000:00:10.1'
>>>
>>> >>> cam.card
>>>
>>> 'UVC Camera (046d:0990)'
>>>
>>> >>> cam.GetFormat()
>>> >>> cam.format.width
>>>
>>> 800L
>>>
>>> >>> cam.format.height
>>>
>>> 600L
>>>
>>> >>> cam.format.pixelformat
>>>
>>> 'MJPEG'
>>>
>>> >>> cam.SetFormat()
>>>
>>> The Read() method works without an error message and the buffer is created.
>>>
>>> >>> cam.Read()
>>> >>> cam.buffer
>>>
>>> <ctypes.c_char_Array_62933 object at 0xb7e5053c>
>>>
>>> But the camera seems not to react to the Read() call. The camera's LED
>>> does not flash like using the uvccapture application and the buffer is
>>> filled just with '\x00'. Am I doing something wrong?
>>
>> The read method is not supported by the uvcvideo driver. You should use the
>> mmap video capture method.
>>
>>> As Laurent already mentioned the "d.SetStandard( d.standards['NTSC']
>>> )" call creates an exception.
>>> Any suggestions? I would be happy to this webcam work with python.
>>
>> Don't use the SetStandard function with UVC cameras :-). Or handle the
>> exception and recover gracefully.
>>
>> Best regards,
>>
>> Laurent Pinchart
>>
>
> --
> video4linux-list mailing list
> Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/video4linux-list
>

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: Testing Requested: Python Bindings for Video4linux2

[Jens Bongartz]

Hi Paul,

thanks for your help.
I am quite new to gcc compiling. I just used the commands I found in
the internet for compiling shared libraries.

First I compile my shared library:

gcc -fPIC -DPIC -c pyuvccapture_3.c

then the modified v4l2uvc.c:

gcc -fPIC -DPIC -c v4l2uvc.c

to create pyuvccapture_3.o and v4l2uvc.o

Then I link it togehter:

gcc -shared -o libpyuvc_3.so.1.0 -Wl, -soname, libpyuvc_3.s.o.1
pyuvccapture_3.o v4l2uvc.o

Did I used wrong compiler options for v4l2.c? For NB_BUFEER = 16 it
works this way.

I appreciate your help.

Thanks,
Jens



2009/1/5 Paul Thomas <pthomas8589@gmail.com>:
> Jens,
>
> I'd give it a try. Can you include a make file or tell me compile command?
>
> thanks,
> Paul
>
> 2009/1/4 Jens Bongartz <bongartz@gmail.com>:
>> Dear Laurent, dear Jackson,
>>
>> thanks for your reply to my request.
>> I don't want to impose on you but maybe you are interested in my
>> findings. To get a better impression of my intention I attached a
>> brief description of my just started "FB-Py-Vision" project.
>>
>> Form the source-code of uvccapture-0.5 I derived a shared library to
>> get access to the webcam from python using ctypes (file attached
>> "pycapture_03.c"). Please show mercy to me, I am not a C-expert. To
>> get continous grabbing I seperated init_videoIn(), uvcGrab() and
>> close() in different functions. I discovered that init_videoIn() /
>> free(videoIn) on every uvcGrab() is very time consuming and not
>> suitable for high framerates.
>> The functions I wrote are quite fixed and unflexible because right now
>> I am only interested in luminance/YUV with 640 by 480. The
>> corresponding python-program is also attached. ('python_capture.py')
>>
>> Now something interesting appears: Grabbing the luminance images works
>> without problems (high frame rate). When I switch to the contour-mode
>> the python image processing workload is higher and the uvcGrab() calls
>> are fewer. For a short period the framerate slows down but after a few
>> seconds recovers but now with a delay between captured and displayed
>> images of around 4 seconds. Very curious! When I switch back to
>> "normal mode" the framerate speeds up (!) a short time and then
>> recovers again without a delay.
>>
>> I suppose this effect is a result of the weak VIA-CPU I use (see my
>> project-description). In general I don't mind if the framerate drops
>> when the image processing load rises but the problem is that I want to
>> process an actual image and not an image which is a few seconds old.
>> (I hope you understand what I mean).
>>
>> Furthermore I assume that the uvcvideo streaming mode plays also a
>> role. I suppose that the 16 v4l2_buffer becomes unsynchronised. But
>> when I decrease the NB_BUFFER constant of "v4l2uvc.h" everything
>> compiles flawless but on excecution I get a Segmentation fault with a
>> fatal error. Only NB_BUFEER = 16 works. Is this correct?
>>
>> What do you think? Do you have any hints for me, why I get this delay?
>>
>> Many thanks in advance.
>> Jens
>>
>>
>> 2009/1/4 Laurent Pinchart <laurent.pinchart@skynet.be>:
>>> HI Jens,
>>>
>>> On Wednesday 31 December 2008, Jens Bongartz wrote:
>>>> Hi everybody,
>>>>
>>>> I saw this thread recently and I am interested in this topic too.
>>>> I am using a Logitech Quickcam 9000 Pro with the uvcvideo driver. The
>>>> camera works properly with the uvccapture application.
>>>> I did some experiment with the python-video4linux2 bindings using the
>>>> python interactive mode. To be honest I am not really familiar with
>>>> v4l2.
>>>>
>>>> Here are my results:
>>>> >>> import pyv4l2
>>>> >>> cam = pyv4l2.Device('dev/video0')
>>>> >>> cam.EnumInput(0)
>>>>
>>>> ['Camera 1', 'camera', 0L, 0L, [], []]
>>>>
>>>> >>> cam.EnumFormats(1)
>>>>
>>>> [('MJPG', 'MJPEG'), ('YUYV', 'YUV 4 :2 :2 (YUYV)')]
>>>>
>>>> >>> cam.GetResolutions()
>>>>
>>>> [(320L, 240L), (640L, 480L), (800L, 600L)]
>>>>
>>>> >>> cam.QueryCaps()
>>>> >>> cam.driver
>>>>
>>>> 'uvcvideo'
>>>>
>>>> >>> cam.businfo
>>>>
>>>> '0000:00:10.1'
>>>>
>>>> >>> cam.card
>>>>
>>>> 'UVC Camera (046d:0990)'
>>>>
>>>> >>> cam.GetFormat()
>>>> >>> cam.format.width
>>>>
>>>> 800L
>>>>
>>>> >>> cam.format.height
>>>>
>>>> 600L
>>>>
>>>> >>> cam.format.pixelformat
>>>>
>>>> 'MJPEG'
>>>>
>>>> >>> cam.SetFormat()
>>>>
>>>> The Read() method works without an error message and the buffer is created.
>>>>
>>>> >>> cam.Read()
>>>> >>> cam.buffer
>>>>
>>>> <ctypes.c_char_Array_62933 object at 0xb7e5053c>
>>>>
>>>> But the camera seems not to react to the Read() call. The camera's LED
>>>> does not flash like using the uvccapture application and the buffer is
>>>> filled just with '\x00'. Am I doing something wrong?
>>>
>>> The read method is not supported by the uvcvideo driver. You should use the
>>> mmap video capture method.
>>>
>>>> As Laurent already mentioned the "d.SetStandard( d.standards['NTSC']
>>>> )" call creates an exception.
>>>> Any suggestions? I would be happy to this webcam work with python.
>>>
>>> Don't use the SetStandard function with UVC cameras :-). Or handle the
>>> exception and recover gracefully.
>>>
>>> Best regards,
>>>
>>> Laurent Pinchart
>>>
>>
>> --
>> video4linux-list mailing list
>> Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
>> https://www.redhat.com/mailman/listinfo/video4linux-list
>>
>

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: Testing Requested: Python Bindings for Video4linux2

[Laurent Pinchart]

Hi Jens,

On Monday 05 January 2009, Jens Bongartz wrote:
> Dear Laurent, dear Jackson,
>
> thanks for your reply to my request.
> I don't want to impose on you but maybe you are interested in my
> findings. To get a better impression of my intention I attached a
> brief description of my just started "FB-Py-Vision" project.
>
> Form the source-code of uvccapture-0.5 I derived a shared library to
> get access to the webcam from python using ctypes (file attached
> "pycapture_03.c"). Please show mercy to me, I am not a C-expert. To
> get continous grabbing I seperated init_videoIn(), uvcGrab() and
> close() in different functions. I discovered that init_videoIn() /
> free(videoIn) on every uvcGrab() is very time consuming and not
> suitable for high framerates.
> The functions I wrote are quite fixed and unflexible because right now
> I am only interested in luminance/YUV with 640 by 480. The
> corresponding python-program is also attached. ('python_capture.py')
>
> Now something interesting appears: Grabbing the luminance images works
> without problems (high frame rate). When I switch to the contour-mode
> the python image processing workload is higher and the uvcGrab() calls
> are fewer. For a short period the framerate slows down but after a few
> seconds recovers but now with a delay between captured and displayed
> images of around 4 seconds. Very curious! When I switch back to
> "normal mode" the framerate speeds up (!) a short time and then
> recovers again without a delay.
>
> I suppose this effect is a result of the weak VIA-CPU I use (see my
> project-description). In general I don't mind if the framerate drops
> when the image processing load rises but the problem is that I want to
> process an actual image and not an image which is a few seconds old.
> (I hope you understand what I mean).
>
> Furthermore I assume that the uvcvideo streaming mode plays also a
> role. I suppose that the 16 v4l2_buffer becomes unsynchronised.

The buffers can indeed contain old data. An easy way to flush them would be to 
dequeue all buffers without processing the data and requeue them.

> But when I decrease the NB_BUFFER constant of "v4l2uvc.h" everything
> compiles flawless but on excecution I get a Segmentation fault with a
> fatal error. Only NB_BUFEER = 16 works. Is this correct?

The uvcvideo driver doesn't require to number of buffers to be exactly 16. To 
debug your problem, when your application segfaults, check the kernel log 
(with dmesg). If the log shows a kernel crash (called an 'oops') please 
report it with the complete oops report. If it doesn't, you probably have a 
bug in your application, either in the code you wrote or in the uvccapture 
sources. gdb is your friend.

> What do you think? Do you have any hints for me, why I get this delay?

Best regards,

Laurent Pinchart

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: Testing Requested: Python Bindings for Video4linux2

[Jens Bongartz]

Hi Laurent, hi Paul!

Paul was right, I used the wrong compiler options.
After compiling the modified v4l2uvc code (NB=1) with uvccapture's
makefile and using the v4l2uvc.o for linking my shared library
everything works fine without Segmentation Fault.
And best of all: The delay is now gone!

Thank you all!

Regards,
Jens

P.S. I should learn more about gcc compiling!


2009/1/6 Laurent Pinchart <laurent.pinchart@skynet.be>:
> Hi Jens,
>
> On Monday 05 January 2009, Jens Bongartz wrote:
>> Dear Laurent, dear Jackson,
>>
>> thanks for your reply to my request.
>> I don't want to impose on you but maybe you are interested in my
>> findings. To get a better impression of my intention I attached a
>> brief description of my just started "FB-Py-Vision" project.
>>
>> Form the source-code of uvccapture-0.5 I derived a shared library to
>> get access to the webcam from python using ctypes (file attached
>> "pycapture_03.c"). Please show mercy to me, I am not a C-expert. To
>> get continous grabbing I seperated init_videoIn(), uvcGrab() and
>> close() in different functions. I discovered that init_videoIn() /
>> free(videoIn) on every uvcGrab() is very time consuming and not
>> suitable for high framerates.
>> The functions I wrote are quite fixed and unflexible because right now
>> I am only interested in luminance/YUV with 640 by 480. The
>> corresponding python-program is also attached. ('python_capture.py')
>>
>> Now something interesting appears: Grabbing the luminance images works
>> without problems (high frame rate). When I switch to the contour-mode
>> the python image processing workload is higher and the uvcGrab() calls
>> are fewer. For a short period the framerate slows down but after a few
>> seconds recovers but now with a delay between captured and displayed
>> images of around 4 seconds. Very curious! When I switch back to
>> "normal mode" the framerate speeds up (!) a short time and then
>> recovers again without a delay.
>>
>> I suppose this effect is a result of the weak VIA-CPU I use (see my
>> project-description). In general I don't mind if the framerate drops
>> when the image processing load rises but the problem is that I want to
>> process an actual image and not an image which is a few seconds old.
>> (I hope you understand what I mean).
>>
>> Furthermore I assume that the uvcvideo streaming mode plays also a
>> role. I suppose that the 16 v4l2_buffer becomes unsynchronised.
>
> The buffers can indeed contain old data. An easy way to flush them would be to
> dequeue all buffers without processing the data and requeue them.
>
>> But when I decrease the NB_BUFFER constant of "v4l2uvc.h" everything
>> compiles flawless but on excecution I get a Segmentation fault with a
>> fatal error. Only NB_BUFEER = 16 works. Is this correct?
>
> The uvcvideo driver doesn't require to number of buffers to be exactly 16. To
> debug your problem, when your application segfaults, check the kernel log
> (with dmesg). If the log shows a kernel crash (called an 'oops') please
> report it with the complete oops report. If it doesn't, you probably have a
> bug in your application, either in the code you wrote or in the uvccapture
> sources. gdb is your friend.
>
>> What do you think? Do you have any hints for me, why I get this delay?
>
> Best regards,
>
> Laurent Pinchart
>

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list