Driver Question

[nickneubrand]

Has there been any new developments in divers to use raspberry pi camera directly in a python program.

I've been trying to use it in pygame by using:
cam = pygame.camera.Camera("/dev/video2", (640,480))
cam.start()
which hasn't worked.

I also tried using a subprocess call:
cam = pygame.camera.Camera( call (["raspivid -o video.h264"], shell=True), 640,480))
I've messed around with it in a few other ways with no success.

Has any one come up with a successful way of doing this? It's clear that I don't understand "piping" into python so I'm looking for a substitute for "/dev/video2".

Im looking to bring in the video at a resolution larger than the application window and move it around with the arrow keys, if the description of my goal jogs someones memory on how to do something like this. I got it to work with a regular webcam, but I cant with the Pi camera.

Any help would be appreciate, thanks

[ghans]

Yeah , your use of "call" seems wrong.
Learn some basics of the shell/Linux commands
(really , this comes usuful later)
and play with the preview option.


ghans

[alexeames]

Yeah , your use of "call" seems wrong.
Learn some basics of the shell/Linux commands
(really , this comes usuful later)
and play with the preview option.


ghans

It is wrong, but you haven't done much more than put the OP down Ghans.

The whole of the called command must be within the quotes. I'm not an expert on this, but that may help a bit. I have no idea if you can call the camera from pygame or not.

[texy]

This thread may help, not pygame, but python with PIL :
http://www.raspberrypi.org/phpBB3/viewt ... 43&t=45235

Texy

[ghans]

The point i was trying to make is that i seriously doubt
that you can call the camera via pyGame.

I'm pretty confident that pyGame expects V4L devices only.

So , what you could do is using Pythons in-built System and
Subprocess modules , call raspistill and with some magic
sprinkle have the result loaded into a Python variable instead of
a file.

This could be passed to pyGame instead , i would dare to
guess.

And to get there , CLI knowledge is a big help IMHO.

ghans

[ghans]

Actually , just use files on a ramdisk.
Much easier , it seems.

ghans

[drhastings]

I'm working on a v4l2 driver for the camera.

Progress has been slow but steady, as I have never written a kernel module before. It will work in two parts, one being the kernel module which creates and manages the /dev/videoX node, the other being a userspace daemon based heavily (HEAVILY) on raspivid which will feed the frames into the driver as they become available.

The driver is based on the v4l2-mem2mem test device which is included with more recent kernels but there has been some modification to get it to support read() syscalls as well as mmap(). I'm still working out how to appropriately track context given different use cases and how the v4l2 events work to allow the driver to post info back to the userspace daemon.

I will post more as things progress.

[towolf]

... the other being a userspace daemon based heavily (HEAVILY) on raspivid which will feed the frames into the driver as they become available..

I thought the video4linux driver would be more low-level? Can this ensure that actual, precise time-of-capture timestamps will be available? I've seen mention of raw timestamps in the mmal headers. Are you going to leverage these?

[ghans]

Good news !
Is this of any interest for you ?

https://github.com/umlaeute/v4l2loopback


ghans

[drhastings]

... the other being a userspace daemon based heavily (HEAVILY) on raspivid which will feed the frames into the driver as they become available..

I thought the video4linux driver would be more low-level? Can this ensure that actual, precise time-of-capture timestamps will be available? I've seen mention of raw timestamps in the mmal headers. Are you going to leverage these?

Low level in what sense? With appropriate message passing between the kernel and the userspace portions, it should work transparently as far as video applications are concerned. It currently presents as a v4l2 video capture device and the plan is your application sets the capture settings via the normal ioctl's which will pass an event to the userspace portion adjusting the parameters there. On first open the driver will alert the userspace portion which will initialize the camera with the supplied settings and upon a read call (or activating the v4l2 streaming interface) the driver will alert the userspace portion which will start streaming in frames to be passed back out by the driver.

To be honest I haven't made it as far as timestamps but I don't see why they can't be used. The v4l2 buffer struct also has a timestamp field. I'll have to see if the framework currently just copies the time stamps over from the "output" queue to the "input" queue or if it reassigns them to what time the framework thinks the frames were generated but I'm sure that can be overridden if I need to.

So I think this should present as low-level as you would need for anything, and I'm not sure how I'd get access to the video data other than through the mmal interface. If you know how I could use the mmal headers in kernel code I'd be interested to hear it, like I said this is the first kernel module I've worked on so I'm sure things are far from optimal.

Good news !
Is this of any interest for you ?

https://github.com/umlaeute/v4l2loopback


ghans

Thanks ghans,

That is one of the many things I've referenced so far!

[jamesh]

Probably worth knowing that the Foundation is funding a V4L2 driver from a specialist Linux software company. In my discussions with them, there is some pretty low level stuff to take care of (I don't know much about this level of driver).

[ghans]

Perhaps a bit OT : What was the company which worked on
X acceleration ? Did Liz mean Collabra and their work
on Wayland ?

ghans

[jamesh]

Perhaps a bit OT : What was the company which worked on
X acceleration ? Did Liz mean Collabra and their work
on Wayland ?

ghans

Probably.

[drhastings]

Probably worth knowing that the Foundation is funding a V4L2 driver from a specialist Linux software company. In my discussions with them, there is some pretty low level stuff to take care of (I don't know much about this level of driver).

That is good to know. I wonder how much more time I should spend on this then. I've got it so I can open the device and read the same video stream from multiple processes from the same device node at the same time but I doubt I'd ever get anything as polished as what is likely to come from that.

Still very interesting stuff. I've taken a look at kernel code several times over the past ten years or so and this is the first time I could make heads or tails of it.

[towolf]

Don't feel discouraged. Who knows how long that rumoured driver will take to finally appear.

Release early, release often. And many things can't be done currently because there no device node support at all.

[nickneubrand]

After working on this for a while I finally got Python to run raspivid, but I hit a bit of a wall if anyone could make some suggestions where to go next.

screen = pygame.display.set_mode([640,480])
cam = pygame.camera.Camera(subprocess.call(["raspivid -9999 -p video.h264"], shell=True,(640,480))
cam.start()
x =0
y=0
while1:
screen.blit(cam, (x,y))

Whenever I run this, the camera does turn on and runs exactly how it should through the terminal, but then when I check the shell it says:
"Type Error: must be string, not int"
Which I assume means that pygame.camera.Camera is reading my first argument as an int rather than a string. But if that were true, then why does it still execute the raspivid command? And because pygame.camera.Camera is returning an int to my "cam" (that I am trying to blit at the bottom of the code) is not technically a Surface which it needs to be.

Im not saying any of the above is true, but that is what I am thinking is happening. Can anyone confirm this? If so do you have any solutions on how to get the video that is being called into the display window that I have set up?

Thanks, also I have no idea how to make the elegant little code blocks that others do on posts so, sorry if this takes up a lot of the forum page.

[ghans]

To make code blocks use

Code: Select all

 [code] 

[/code]

You can either select your Code and then click on the button
"Code" or write those tags yourself (around the code) .

On your Problem : That what you want to do simply won't work.
You will have to settle for image files (snapshots ) , which you
manipulate in fast succession via PyGame. Research how
PyGame handles Image files , or wait until drhastings or
the Raspberry Pi foundation has finished the V4L2 driver.

ghans

[jamesh]

Don't feel discouraged. Who knows how long that rumoured driver will take to finally appear.

Release early, release often. And many things can't be done currently because there no device node support at all.

Well, before a community run effort I would think due to the support being given to the development by the Foundation and Broadcom which is not available to community efforts, and the fact it being worked on as a paid job full time. Not that I want to disparage such community efforts, but some pragmatism is needed.

Not sure what 'release early release often' has to do with this - problem with projects such as this is that there is a lot of boiler plate code required up front which you cannot release 'often' as its doesn't yet work, so there really is no point in releasing it. Once the framework is in place it might be feasible to release, but until the majority of work is actually done, it's rather a waste since it won't work for most requirements, and it's unlikely any community stuff pushed would be useful.

[towolf]

What I meant was: There's a proper driver in the making where we don't know how long it will be until it is available.

Dr Hastings has a stop-gap driver that is more or less working and now in light of the news he is wondering how much more work he should put into it.

I was suggesting to drhastings to release what he's got now so that people needing V4L device node have something to play with until the proper driver appears.

[jamesh]

What I meant was: There's a proper driver in the making where we don't know how long it will be until it is available.

Dr Hastings has a stop-gap driver that is more or less working and now in light of the news he is wondering how much more work he should put into it.

I was suggesting to drhastings to release what he's got now so that people needing V4L device node have something to play with until the proper driver appears.

More or less working? Are you sure? As far as I can tell (and I did look in to it) for someone with V4L experience, it's still a multiple man week job to get something like this in a usable state. Would be interesting to know how far DrHasting has got, i.e. can it be installed and recover a video or stills to a userland app, if so that very prompt good work indeed.

[drhastings]

What I meant was: There's a proper driver in the making where we don't know how long it will be until it is available.

Dr Hastings has a stop-gap driver that is more or less working and now in light of the news he is wondering how much more work he should put into it.

I was suggesting to drhastings to release what he's got now so that people needing V4L device node have something to play with until the proper driver appears.

More or less working? Are you sure? As far as I can tell (and I did look in to it) for someone with V4L experience, it's still a multiple man week job to get something like this in a usable state. Would be interesting to know how far DrHasting has got, i.e. can it be installed and recover a video or stills to a userland app, if so that very prompt good work indeed.

Its definitely on the lesser end of working at the moment. I've had enough success with reading streams to think its possible to get it to the state I hope. The streams come out with some weird padding, but right now that is more based on how the userland tool feeds them in than anything else, and so far I've only implemented read and not mmap for getting data out although it is in the plan. So far I have nothing done as far as changing formats, which includes reading jpegs, and I'm trying to track down a null dereference which brings the whole thing down occasionally. Part of the reason this started with the userspace tool is because I don't have the information needed to activate and initialize the device from the kernel. So all in all it doesn't quite work yet for anything but there is a light at the end of the tunnel.

I'll probably look at it a bit this weekend, and I'll put it out there if I can stop if from crashing on occasion. The one advantage from keeping the video capture in a userland program is that it remove much of the complexity from the driver. There are no hardware events to respond to and much of the complexity gets pushed into the event passing and the userspace portion.

Oh by the way, I'm no Dr, I just put my initials there to look smart.

[towolf]

More or less working? Are you sure?

Well, it sounded like that?