View Full Version : DMK27AUP031 streaming issue with gstreamer

October 25, 2016, 15:52:00
I have the following script:

/////For the DMK27AUP031 camera///// No error with the DMK 24UJ003 camera!?

v4l2-ctl --set-ctrl=brightness=168
v4l2-ctl --set-ctrl=gain=100
v4l2-ctl --set-ctrl=exposure_absolute=333
v4l2-ctl --set-parm=7


#How much time there should be between taking an image
ImageCaptureIntervalTime=5 #seconds

#How long the camera should take pictures
TimeToCapture=1 #minutes

#Show all properties and their settings on the terminal
v4l2-ctl --all -d 0

#set the number of buffers required based on the TimeToCapture variable
let numbuffers="TimeToCapture*180" #depends on the framerate of the camera. currently this is 3 fps -> 180 frames per minute!

gst-launch-0.10 -e v4l2src num-buffers=$numbuffers ! videorate ! video/x-raw-gray,width=$ImageWidth,height=$ImageHeight,framera te=1/$ImageCaptureIntervalTime ! queue ! pngenc snapshot=FALSE ! multifilesink post-messages=true location="/home/pi/Desktop/pishare/frame%04d.png"


For which I get this error:

ERROR: from element /GstPipeline:pipeline0/GstPngEnc:pngenc0: The stream is in the wrong format.
Additional debug info:
gstpngenc.c(280): gst_pngenc_chain (): /GstPipeline:pipeline0/GstPngEnc:pngenc0:
Provided input buffer is too small, caps problem?

I found this about this error:

xt/libpng/gstpngenc.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/ext/libpng/gstpngenc.c b/ext/libpng/gstpngenc.c
index 21ab564..e59da9b 100644
--- a/ext/libpng/gstpngenc.c
+++ b/ext/libpng/gstpngenc.c
@@ -271,6 +271,14 @@ gst_pngenc_chain (GstPad * pad, GstBuffer * buf)


+ if (G_UNLIKELY (GST_BUFFER_SIZE (buf) < pngenc->height * pngenc->stride)) {
+ gst_buffer_unref (buf);
+ ("Provided input buffer is too small, caps problem?"));
+ goto done;
+ }
/* initialize png struct stuff */
pngenc->png_struct_ptr = png_create_write_struct (PNG_LIBPNG_VER_STRING,
(png_voidp) NULL, user_error_fn, user_warning_fn);

If I use the jpegenc module instead of the pngenc, I get a few images with tearing (attached) followed by a crash (timing of crash varies each run):

Caught SIGSEGV accessing address 0x727dc000
#0 0x76bf2b80 in poll () at ../sysdeps/unix/syscall-template.S:81
#1 0x76cdd528 in g_main_context_poll (priority=<optimized out>, n_fds=1,
#2 g_main_context_iterate (context=0x631f08, block=block@entry=1,
#3 0x76cdd8ec in g_main_loop_run (loop=0x6279b0)
#4 0x76e1c948 in gst_bus_poll (bus=bus@entry=0x557a58,
#5 0x00014514 in event_loop (pipeline=0x11210, blocking=blocking@entry=1,
#6 0x00013708 in main (argc=1995354484, argv=0x0) at gst-launch.c:1157
Spinning. Please run 'gdb gst-launch 1020' to continue debugging, Ctrl-C to quit, or Ctrl-\ to dump core.

The odd thing is I have tested this script succesfully in the past using the DMK 24UJ003 camera

Any suggestions?

Many thanks in advance,
Geert Depuydt

Stefan Geissler
October 25, 2016, 16:42:34
Hello Geert

"Caught SIGSEGV accessing address 0x727dc000" can happen, if the image buffer is too small. This happens, if the image data transfer from USB into memory was interrupted. In order to avoid this, use the "tisvideobufferfilter" module, which drops the incomplete frames. BUT: this can result in getting less than "num-buffers=$numbuffers" images.
Maybe this works better, if the camera is connected via an USB 3.0 controller.

You also should lower the camera's frame rate:

gst-launch-0.10 -e v4l2src num-buffers=$numbuffers ! video/x-raw-gray,width=$ImageWidth,height=$ImageHeight,framera te=3/1! queue ! pngenc snapshot=FALSE ! multifilesink post-messages=true location="/home/pi/Desktop/pishare/frame%04d.png"

The "videorate" does not change the frame rate of the camera.

Using the "queue" is a good idea.

October 26, 2016, 13:09:16
Many thanks Stefan!

Your suggestions made me think that something is wrong by how I set the framerate.

For example:
v4l2-ctl --set-parm=3 //set camera framerate to 3fps
video/x-raw-gray,width=$ImageWidth,height=$ImageHeight,framera te=3/1 (I thought this only sets the frequency of grabbing frames from the stream, independent of the actual camera framerate?)

The problem disapears (and no tearing of images either)! (this problem did not occur with the higher resolution DMK 24UJ003 camera though).

this works for all combinations of 7 and 3 fps.
But not with any other framerate combinations as far as I can tell...

So transfer speed is not the issue since we actually only need like 1 fps max (0.2 fps otherwise)

If only I could set the camera framerate to 0.2 or 1 fps...

I have looked around and tried without succes so far. :/


Stefan Geissler
October 26, 2016, 13:21:57
Hi Geert

good to know, the problem is nearly solved. Extremely low frame rates are not supported by the sensor. You will get weird results, if the sensor runs too slow. The camera has no memory for images, therefore, the image is sent out right after exposure.

October 26, 2016, 13:49:38
Hi Stefan,

I think I found a solution in the following form:

gst-launch-0.10 -e v4l2src num-buffers=$numbuffers ! videorate ! video/x-raw-gray,width=$ImageWidth,height=$ImageHeight,framera te=3/1 ! queue ! videorate ! video/x-raw-gray,framerate=1/5 ! jpegenc ! multifilesink post-messages=true location="/home/pi/Desktop/pishare/frame%04d.jpg"

I respect the framerate the camera is able to provide, grabbing frames from the stream at the rate desired.
Will test for robustness, but seems to work in first testing.

Thanks again for the help!