python-video4linux2 fails with 04f2:b018 Chicony Electronics Co., Ltd

[GoogleCodeExporter]

I'm using svn python-v4l2 on Ubuntu on x86_64.

My System76 laptop's built-in video camera doesn't work with python-v4l2. 
When I run recordpics (after I fix #11), I get:

Exception: Could not set standard NTSC:       22: Invalid argument

OK, so maybe my camera isn't a NTSC camera.  So I tried it with all the
other standards, and none of them work.  My camera does support v4l2 --
luvcview works fine, and captures images at 320x240.  

I also tried sticking in a GetStandard call (using VIDIOC_G_STD), and that
also said Invalid argument.  I did not try VIDIOC_ENUMSTD, because it
looked like a hassle.

I tried commenting out the call to SetStandard, but then I got No such
device in Read() (well, I did once I added error detection -- you should
really catch errors in Read())

P.S.  Why do your function names not follow the Python coding standard?

Original issue reported on code.google.com by david.no...@gmail.com on 1 Feb 2009 at 4:46

[GoogleCodeExporter]

P.S.  Give me SVN commit access, and I'll start working on at least the error
detection bit. 

Original comment by david.no...@gmail.com on 1 Feb 2009 at 4:48

[GoogleCodeExporter]

Oops, I also had to change the pixel format to YUYV before I got the No such 
device
message.

Original comment by david.no...@gmail.com on 1 Feb 2009 at 5:05

[GoogleCodeExporter]

I also tried streampics, which does not work.  Part of the problem is that 
SetupStreaming calls StreamOn before it queues any buffers.  <a
href="http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec/r13478.htm"
>Don't
do that</a>. 

Then PIL cannot decode YUYV.  

Original comment by david.no...@gmail.com on 1 Feb 2009 at 10:54

[GoogleCodeExporter]

http://mail.python.org/pipermail/image-sig/2009-February/005404.html <-- This 
is my
patch to PIL which adds support for YUYV.

Original comment by david.no...@gmail.com on 2 Feb 2009 at 1:30

[GoogleCodeExporter]

I also tried implementing it in Python, but even at 320x240, I could only get 
like
4fps.  So instead, since PIL takes a very long time between releases, I just 
hacked
it your code.  My patch includes this and some other minor cleanups (including
removing the spurious call to StreamOn).  

Original comment by david.no...@gmail.com on 2 Feb 2009 at 3:27

Attachments:

• YUYV_and_more.patch

[GoogleCodeExporter]

If I'd known someone else was hacking on this..... I could have paid attention 
to the
movie last night, rather than banging my head on this. ;-)

Good job,
Mungewell.

Original comment by mungew...@gmail.com on 2 Feb 2009 at 7:14

[GoogleCodeExporter]

Well, recordpics is still broken, unfortunately.  streampics is sufficient for 
my
needs, but if you have ideas about recordpics, I am happy to test for you.

Original comment by nova...@gnu.org on 2 Feb 2009 at 7:54

[GoogleCodeExporter]

I note that you have added a hard coded frame rate with "int SetFPS(int fd)".

Would it be better to:
1) Enable user to set this with streampic.py, a '-f/--fps' option would be good.
2) Auto detect this (if not supplied) according to Standard PAL/NTSC.

I can test PAL if no-one else here has capability.
Mungewell.

Original comment by mungew...@gmail.com on 2 Feb 2009 at 8:06

[GoogleCodeExporter]

Actually, there is no need for SetFPS -- I was cargo culting from luvcview, and
forgot to remove it before I sent in the diff.  I just tested without it, and it
works fine.

Original comment by david.no...@gmail.com on 2 Feb 2009 at 8:26

[GoogleCodeExporter]

I meant an option so that a user can set it too a lower value should they wish. 
My
current project would work just fine with a feed of 4 fps, so why load the 
processor
with anything more?

Original comment by mungew...@gmail.com on 2 Feb 2009 at 9:02

[GoogleCodeExporter]

Yes, that would be a good idea.

Original comment by david.no...@gmail.com on 2 Feb 2009 at 9:07

[GoogleCodeExporter]

Patch to do FPS stuff against your YUYV stuff, does affect the frame rate but 
isn't
very accurate. I suspect other factors are coming into play.

Original comment by mungew...@gmail.com on 3 Feb 2009 at 4:25

Attachments:

• FPS_YUYV.patch

[GoogleCodeExporter]

This looks good.  I think the framerate is probably limited by hardware 
limitations.  

There is one issue even with the revised code: the first frame captured is 
garbage. 
This doesn't matter for my application, but it could be annoying for some.  I 
think
it should probably be skipped.

Original comment by AlysonCo...@gmail.com on 3 Feb 2009 at 4:38

[GoogleCodeExporter]

better patch for setting the framerate, doesn't adjust it if not specified and 
allows
setting one of either/both the numerator/denominator.

Mungewell.

Original comment by mungew...@gmail.com on 4 Feb 2009 at 1:36

Attachments:

• 20090203_fps.patch

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

With a non-zero default value for the options it does not know whether you have
spec'ed numerator or not.

At present it copes with
'no fps spec' - does not set framerate, just leaves at whatever it is/default 
value
'-f' - sets a frame rate (1/s)
'-t' - sets a frame interval (s) 
'-f and -t' - sets a fractional frame rate.

Original comment by mungew...@gmail.com on 4 Feb 2009 at 2:58

[GoogleCodeExporter]

Sorry, previous message was from wrong account.

Original comment by david.no...@gmail.com on 4 Feb 2009 at 3:14