<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Rob,<br>
<br>
Well spotted!<br>
<br>
It works for me. I am monitoring the memory only with htop at the
moment, but it seems to be stable. I think the memory leak stems
from the fact that max_buffers is set to 0, so it will always make
the buffer bigger and bigger. I think that is generally a bad
idea. This might affect also plain v4l2src applications.<br>
<br>
Try this patch to get rid of the memory leak:<br>
<br>
diff --git a/sys/v4l2/gstv4l2bufferpool.c
b/sys/v4l2/gstv4l2bufferpool.c
<br>
index 1e74fc7..282ac2b
100644
<br>
--- a/sys/v4l2/gstv4l2bufferpool.c<br>
+++ b/sys/v4l2/gstv4l2bufferpool.c<br>
@@ -411,7 +411,7 @@ gst_v4l2_buffer_pool_set_config (GstBufferPool
* bpool, GstStructure * config)<br>
if (max_buffers == 0 || num_buffers < max_buffers) {<br>
/* if we are asked to provide more buffers than we have
allocated, start<br>
* copying buffers when we only have 2 buffers left in
the pool */<br>
- copy_threshold = 2;<br>
+ copy_threshold = 15;// 2;<br>
} else {<br>
/* we are certain that we have enough buffers so we don't
need to<br>
* copy */<br>
diff --git a/sys/v4l2/gstv4l2src.c b/sys/v4l2/gstv4l2src.c<br>
index 107ea21..0c5d91a 100644<br>
--- a/sys/v4l2/gstv4l2src.c<br>
+++ b/sys/v4l2/gstv4l2src.c<br>
@@ -529,7 +529,8 @@ gst_v4l2src_decide_allocation (GstBaseSrc *
bsrc, GstQuery * query)<br>
update = TRUE;<br>
} else {<br>
pool = NULL;<br>
- min = max = 0;<br>
+ min = 0;<br>
+ max = 100;<br>
size = 0;<br>
update = FALSE;<br>
}<br>
<br>
<br>
On 07/25/2013 09:52 PM, Robert Krakora wrote:<br>
</div>
<blockquote
cite="mid:CA+DpathKMXgiFwMmzdbQLjoj6w-PC27NUw8AVk2bq5Wc9g9G1A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Hi Peter,<br>
<br>
I also wanted to note that when you apply the aforementioned
"hack" to emulate the default operation of v4l2src in version
0.10 ("always-copy=true") with the pipeline below, your system
will run out of memory due to a memory leak. It will then
kill off the gst-launch process instantiated to run your
pipeline. However, your pipeline will run for quite a bit (a
lot longer than the previous 36 seconds noted by Yusuf a
couple of months ago).<br>
<br>
gst-launch-1.0 uvch264src device=/dev/video0 name=src
auto-start=true src.vfsrc ! queue ! fakesink src.vidsrc !
queue ! video/x-h264 ! fakesink<br>
<br>
</div>
Best Regards,<br>
<br>
Rob Krakora<br>
<br>
</div>
<div class="gmail_extra">
<br>
<br>
<div class="gmail_quote">On Thu, Jul 25, 2013 at 4:27 PM, Robert
Krakora <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:rob.krakora@messagenetsystems.com"
target="_blank">rob.krakora@messagenetsystems.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>Hi Peter,<br>
<br>
</div>
I forgot to mention that the file that needs modification
is named gstv4l2bufferpool.c and is under sys/v4l2 under
plugins-good.
<div class="im">
<br>
<br>
if (max_buffers == 0 || num_buffers <
max_buffers) {<br>
/* if we are asked to provide more buffers than
we have allocated, start<br>
* copying buffers when we only have 2 buffers
left in the pool */<br>
copy_threshold = 100; //2;<br>
} else {<br>
/* we are certain that we have enough buffers so
we don't need to<br>
* copy */<br>
copy_threshold = 0;<br>
}<br>
</div>
</div>
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, Jul 25, 2013 at 4:21
PM, Robert Krakora <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:rob.krakora@messagenetsystems.com"
target="_blank">rob.krakora@messagenetsystems.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>Hi Peter,<br>
<br>
</div>
In version 0.10 v4l2src used to have a
property to force buffers from it's pool to
always be copied prior to being pushed out.
This property was called "always-copy" and
defaulted to "true". It seems that this was
removed in version 1.x. If you go to version
1.x good plugins and change "copy_threadhold"
from 2 to 100 you effectively get the same
behaviour with 1.x in this regard (same as
"always-copy=true" default in 0.10 v4l2src)
and there is no error after 30 some odd
seconds that causes the stream to abort.<br>
<br>
if (max_buffers == 0 || num_buffers <
max_buffers) {<br>
/* if we are asked to provide more
buffers than we have allocated, start<br>
* copying buffers when we only have 2
buffers left in the pool */<br>
copy_threshold = 100; //2;<br>
} else {<br>
/* we are certain that we have enough
buffers so we don't need to<br>
* copy */<br>
copy_threshold = 0;<br>
}<br>
<br>
</div>
Best Regards,<br>
<br>
Rob Krakora<br>
<br>
</div>
<div>
<div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, Jul 25,
2013 at 1:06 PM, Robert Krakora <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:rob.krakora@messagenetsystems.com" target="_blank">rob.krakora@messagenetsystems.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>
<div>Hi Peter,<br>
<br>
</div>
I did some work yesterday on this
and enabled logging on uvcvideo.ko
and was able to correlate the
buffer sizes reported by it and by
the uvch264src plugin. <span
style="background-color:rgb(255,255,0)">Below</span>
is the frame that failed...the
size in the kernel module was the
same as the size of the buffer
once it got back up to the
application to v4l2src and
uvch264src.<br>
<br>
uvcvideo: Frame complete (EOF
found).<br>
uvcvideo: EOF in empty payload.<br>
uvcvideo: uvc_v4l2_poll<br>
uvcvideo:
uvc_v4l2_ioctl(VIDIOC_DQBUF)<br>
uvcvideo: HD Pro Webcam C920: PTS
1029592232 y 2948.098587 SOF
2948.098587 (x1 2149480048 x2
2179588048 y1 193593344 y2
199426048 SOF offset 39)<br>
uvcvideo: HD Pro Webcam C920: SOF
2948.098587 y 927116325 ts
589.071670 buf ts 589.232519 (x1
197984256/205/906 x2
204537856/49/995 y1 1000000000 y2
1099975668)<br>
<span
style="background-color:rgb(255,255,0)"><span>uvcvideo:
uvc_dequeue_buffer -
buf->bytesused = 220410</span></span><br>
uvcvideo:
uvc_v4l2_ioctl(VIDIOC_QBUF)<br>
<br>
</div>
Best Regards,<br>
<br>
</div>
Rob<br>
</div>
<div class="gmail_extra">
<div>
<div><br>
<br>
<div class="gmail_quote">On Thu,
Jul 25, 2013 at 12:22 PM, Peter
Rennert <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:p.rennert@cs.ucl.ac.uk"
target="_blank">p.rennert@cs.ucl.ac.uk</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">A bit
of an update today.<br>
<br>
To figure out what is going on
normally and what is different
in the diseased frame I
printed out the debug line
[line 508] that was already in
the code, augmented with the
total size of the buffer. The
original line was:<br>
<br>
GST_DEBUG_OBJECT (self,<br>
"Found APP4 marker
(%d). JPG: %d-%d - APP4: %d -
%d", segment_size,<br>
last_offset, i, i, i
+ 2 + segment_size);<br>
<br>
I print for each time in the
loop (before the sanity test
that will fail finally):<br>
<br>
printf("Found APP4 marker
(%d). JPG: %d-%d - APP4: %d -
%d - size: %d\n",
segment_size,<br>
last_offset, i, i, i
+ 2 + segment_size,
(int)size);<br>
<br>
What I get for a normal frame
is about this. The total
buffer size changes and also
the size of the first APP4
chunk, however, I always seem
to get 4 blocks for each
frame. The segment size of the
first marker differs between
the individual frames, while
the 2nd, 3rd and 4th markers
are the same size all the time
as far as I can tell:<br>
<br>
Found APP4 marker (13010).
JPG: 0-8 - APP4: 8 - 13020 -
size: 166660<br>
<br>
Found APP4 marker (65533).
JPG: 13020-13020 - APP4: 13020
- 78555 - size: 166660<br>
<br>
Found APP4 marker (65533).
JPG: <a
moz-do-not-send="true"
href="tel:78555-78555"
value="+17855578555"
target="_blank">78555-78555</a>
- APP4: 78555 - 144090 - size:
166660<br>
<br>
Found APP4 marker (22566).
JPG: 144090-144090 - APP4:
144090 - 166658 - size: 166660<br>
<br>
<br>
The frame that causes the
failure of the system has the
following output:<br>
<br>
Found APP4 marker (12084).
JPG: 0-8 - APP4: 8 - 12094 -
size: 165485<br>
<br>
Found APP4 marker (65533).
JPG: 12094-12094 - APP4: 12094
- 77629 - size: 165485<br>
<br>
Found APP4 marker (65533).
JPG: 77629-77629 - APP4: 77629
- 143164 - size: 165485<br>
<br>
Found APP4 marker (22566).
JPG: 143164-143164 - APP4:
143164 - 165732 - size: 165485<br>
<br>
<br>
As you can see it seems as the
last segment reaches out of
the total size of the buffer.
As the last segment seems to
be always of a length 22566, I
think for some reason (that
does not happen in gstreamer
0.10) a piece of the h264
stream is missing in this
particular buffer.<br>
<br>
The number of bytes getting
lost is not the same for
different trials, neither is
the cut-off. For my second
trial I got:<br>
<br>
Found APP4 marker (22566).
JPG: 144796-144796 - APP4:
144796 - 167364 - size: 165815<br>
<br>
So where are these bytes? And
why are they missing so
regularly?
<div>
<div><br>
_______________________________________________<br>
gstreamer-devel mailing
list<br>
<a moz-do-not-send="true"
href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
<a moz-do-not-send="true"
href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel"
target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
</div>
</div>
<div>-- <br>
<font color="#888888"><font
color="blue">Rob Krakora<br>
MessageNet Systems
<br>
101 East Carmel Dr. Suite 105
<br>
Carmel, IN 46032
<br>
<a moz-do-not-send="true"
value="+13175661677">(317)566-1677</a></font></font><font
color="#888888"><font color="blue">
Ext 212<br>
<a moz-do-not-send="true"
value="+13176630808">(317)663-0808</a>
Fax
</font></font>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<font color="#888888"><font color="blue">Rob
Krakora<br>
MessageNet Systems
<br>
101 East Carmel Dr. Suite 105
<br>
Carmel, IN 46032
<br>
<a moz-do-not-send="true"
value="+13175661677">(317)566-1677</a></font></font><font
color="#888888"><font color="blue"> Ext
212<br>
<a moz-do-not-send="true"
value="+13176630808">(317)663-0808</a>
Fax
</font></font>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<font color="#888888"><font color="blue">Rob Krakora<br>
MessageNet Systems
<br>
101 East Carmel Dr. Suite 105
<br>
Carmel, IN 46032
<br>
<a moz-do-not-send="true" value="+13175661677">(317)566-1677</a></font></font><font
color="#888888"><font color="blue"> Ext 212<br>
<a moz-do-not-send="true" value="+13176630808">(317)663-0808</a>
Fax
</font></font>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<font color="#888888"><font color="blue">Rob Krakora<br>
MessageNet Systems
<br>
101 East Carmel Dr. Suite 105
<br>
Carmel, IN 46032
<br>
<a moz-do-not-send="true" value="+13175661677">(317)566-1677</a></font></font><font
color="#888888"><font color="blue"> Ext 212<br>
<a moz-do-not-send="true" value="+13176630808">(317)663-0808</a>
Fax
</font></font>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
gstreamer-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a>
<a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a>
</pre>
</blockquote>
<br>
</body>
</html>