image goes black after a couple of minutes

[jamesh]

Doesn't matter if X is running for the preview. But not sure why others haven't seen this issue so will have to pass on to the V4L experts.

[flok]

Ok, I'll see how can I enable this preview (not sure yet).

In the mean time: I did some more experimenting: if I disable auto exposure and set it to e.g. 1500 I get an image but it flickers. Every couple of frames the image gets totally black for a while, then displays the scenery again and then goes black again.

[ethanol100]

Ok, I'll see how can I enable this preview (not sure yet).

v4l2-ctl --overlay=1 # enable viewfinder
v4l2-ctl --overlay=0 # disable viewfinder

[flok]

Hi,

Regarding the problem with exposure going wrong (e.g. image going black), it looks like this code:

Code: Select all

        if (rpi_workaround)
        {
                int sw = 1;
                if (ioctl(fd, VIDIOC_OVERLAY, &sw) == -1)
                        error_exit(true, "ioctl(VIDIOC_OVERLAY) failed");
        }

indeed (as you suggested) solves the problem.
I've been streaming jpeg data for > 10 minutes now and still an image (640x480).

(I enhanced koudevoeten so that it correctly handles video sources that can compress jpeg data by themselves: with 2 clients it is now streaming MJPEG (to both of them) with only 14% cpu usage (with 1 client +/- 11%) and the SOC only 45 degrees celsius (the jpeg-on-cpu version did 50 degrees celsius).

[flok]

Koudevoeten (http://www.vanheusden.com/koudevoeten/) 0.5 was released to the web! It now retrieves JPEG encoded images directly from the camera/GPU dramatically reducing the CPU load.

It has been streaming MJPEG data for a couple of days now from the birdhouse in my garden without any crashes and such: this data is then retrieved by "motion" on an other system where it is checked for any movements.

[leol]

Koudevoeten (http://www.vanheusden.com/koudevoeten/) 0.5 was released to the web! It now retrieves JPEG encoded images directly from the camera/GPU dramatically reducing the CPU load.

It has been streaming MJPEG data for a couple of days now from the birdhouse in my garden without any crashes and such: this data is then retrieved by "motion" on an other system where it is checked for any movements.

I'm unable to get this to run. I get "failed creating socket errno: 97 (Address family not supported by protocol)"
Looking at the code, I think this might have someting to do with IP6.

Anyone had any luck?

[flok]

Ah yes, that looks indeed like an ipv6 problem.

sudo modprobe ipv6

or
echo ipv6 >> /etc/modules
(and reboot)

should fix it.

[leol]

Ah yes, that looks indeed like an ipv6 problem.

sudo modprobe ipv6

or
echo ipv6 >> /etc/modules
(and reboot)

should fix it.

Fantastic. Thanks that works.

[M_P]

I'm not sure if this is the best place to post this (and I apologize if it's a repeat of other work), but I found something interesting about the picture going dark when running Motion.

If I run it with resolution 1280x800, it goes dark within about five minutes. If I run it with resolution 1280x720, it seems to stay the correct brightness and changes appropriately with the ambient light. I can reliably reproduce both situations with two different NoIR camera modules after reboots and/or power cycles.

Some details:
- Pi Model B
- Fresh build from yesterday using the 2014-01-07 Raspbian image.
- Kernel #640 from Friday Feb 14 19:09GMT.
- I am using the official V4L2 driver.
- Memory split is set to 128MB
- The standard Motion build that comes from running apt-get (3.2.12).
- Motion is configured to use the YU12 palette.
- Motion is configured to grab images at 2FPS.
- Everything has been apt-get updated, apt-get upgraded, and rpi-updated.

I'm perfectly happy with 1280x720, just thought it might help pin down a problem (if there actually is one - I've no doubt that I could well be causing the problem).

[6by9]

I'm not sure if this is the best place to post this (and I apologize if it's a repeat of other work), but I found something interesting about the picture going dark when running Motion.

If I run it with resolution 1280x800, it goes dark within about five minutes. If I run it with resolution 1280x720, it seems to stay the correct brightness and changes appropriately with the ambient light. I can reliably reproduce both situations with two different NoIR camera modules after reboots and/or power cycles.

Some details:
- Pi Model B
- Fresh build from yesterday using the 2014-01-07 Raspbian image.
- Kernel #640 from Friday Feb 14 19:09GMT.
- I am using the official V4L2 driver.
- Memory split is set to 128MB
- The standard Motion build that comes from running apt-get (3.2.12).
- Motion is configured to use the YU12 palette.
- Motion is configured to grab images at 2FPS.
- Everything has been apt-get updated, apt-get upgraded, and rpi-updated.

I'm perfectly happy with 1280x720, just thought it might help pin down a problem (if there actually is one - I've no doubt that I could well be causing the problem).

Totally expected as you've told Motion to capture YU12 images.

With any of the raw pixel formats (YUV or RGB) the driver makes a guess as to what you're using it for based on resolution. If <= 1280x720, then it assumes it is video mode and effectively runs it as preview/video encode at whatever frame rate is requested. If > 1280x720, then it guesses you're doing a stills capture and switches the pipe into that mode. JPEG always assumes stills, H264 or MJPEG assumes video.

The issue is with the stills mode auto exposure calcs (or lack thereof), hence <=1280x720 is OK, but > isn't.
Having preview running means that it reverts to video mode between captures, and hence AE can run on those frames quite happily and hence adapts to changes in light level.

[M_P]

Totally expected as you've told Motion to capture YU12 images.

With any of the raw pixel formats (YUV or RGB) the driver makes a guess as to what you're using it for based on resolution. If <= 1280x720, then it assumes it is video mode and effectively runs it as preview/video encode at whatever frame rate is requested. If > 1280x720, then it guesses you're doing a stills capture and switches the pipe into that mode. JPEG always assumes stills, H264 or MJPEG assumes video.

The issue is with the stills mode auto exposure calcs (or lack thereof), hence <=1280x720 is OK, but > isn't.
Having preview running means that it reverts to video mode between captures, and hence AE can run on those frames quite happily and hence adapts to changes in light level.

Ah - that makes perfect sense. Very interesting, too - I didn't know there was a fixed cutoff between video and still image.

Thank you for the explanation and for all your hard work!

[6by9]

Ah - that makes perfect sense. Very interesting, too - I didn't know there was a fixed cutoff between video and still image.

There isn't in standard V4L2 terms, but there is on the GPU (it does a load of slightly different AE and AWB calcs, and may choose a higher quality image off the sensor to improve the image quality to the detriment of framerate).
It's a fairly arbitrary value set in https://github.com/raspberrypi/linux/bl ... 5-camera.c line 44/45

Code: Select all

#define MAX_VIDEO_MODE_WIDTH 1280
#define MAX_VIDEO_MODE_HEIGHT 720

720P is about the limit we can sensibly do at a reasonable framerate (should do 30fps if YUV, prob not if RGB) passing the full pixel buffers around through V4L2. If doing H264 encoding on the GPU, then the resultant frames are so much smaller that it isn't an issue.
We could try and base it on framerate/resolution combination, but it just adds complication, and it wouldn't help you anyway as Motion doesn't set the V4L2 framerate, it just adjusts the rate at which it processes the output buffers.