<div dir="ltr">You want the copy threshold to ALWAYS be bigger then the number of buffers queued so that the copy ALWAYS happens... :-) To do this, make "copy_threshold" bigger than "max_buffers"...<br>
<br><br> if (pool->num_queued < pool->copy_threshold) {<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 26, 2013 at 9:26 AM, Robert Krakora <span dir="ltr"><<a 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">Basically, you want to set up v4l2src so that it ALWAYS copies it's buffer pool buffers to freshly allocated buffers...this was it's default behaviour in 0.10.<br>
</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br>
<div class="gmail_quote">On Fri, Jul 26, 2013 at 9:24 AM, Robert Krakora <span dir="ltr"><<a 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">If the only thing that I do is set the copy threshold to 100 I can run until the memory leak that I mentioned before invokes the OS to kill gst-launch...I don't see the error reported...<br></div><div>
<div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Fri, Jul 26, 2013 at 9:03 AM, Peter Rennert <span dir="ltr"><<a 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">
<div bgcolor="#FFFFFF" text="#000000">
<div>Hmm that is not the solution. It still
fails after some minutes, reporting the same error as before. I am
trying to find the right way to manipulate the buffer numbers now.<div><div><br>
<br>
<br>
On 07/26/2013 01:13 PM, Peter Rennert wrote:<br>
</div></div></div><div><div>
<blockquote type="cite">
<div>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 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 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> <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>
<div>
<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 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 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
<a href="tel:2179588048" value="+12179588048" target="_blank">2179588048</a> 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 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 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 href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
<a 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 value="+13175661677">(317)566-1677</a></font></font><font color="#888888"><font color="blue"> Ext 212<br>
<a 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 value="+13175661677">(317)566-1677</a></font></font><font color="#888888"><font color="blue"> Ext
212<br>
<a 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 value="+13175661677">(317)566-1677</a></font></font><font color="#888888"><font color="blue"> Ext 212<br>
<a 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 value="+13175661677">(317)566-1677</a></font></font><font color="#888888"><font color="blue"> Ext 212<br>
<a value="+13176630808">(317)663-0808</a>
Fax </font></font> </div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
gstreamer-devel mailing list
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a>
</pre>
</blockquote>
<br>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
gstreamer-devel mailing list
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
<br></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 value="+13175661677">(317)566-1677</a></font></font><font color="#888888"><font color="blue"> Ext 212<br>
<a 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 value="+13175661677">(317)566-1677</a></font></font><font color="#888888"><font color="blue"> Ext 212<br>
<a 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 value="+13175661677">(317)566-1677</a></font></font><font color="#888888"><font color="blue"> Ext 212<br>
<a value="+13176630808">(317)663-0808</a> Fax
</font></font>
</div>