<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">Good to know.<br>
<br>
I will let it run for some hours today, but I will have to restart
to give a presentation tomorrow. I will make some thorough test
after. I will not pull from the repository for the moment. If we
get different results, we have a starting point to look for. But
anyway I think I am quite close to the HEAD, as I pulled about two
weeks ago.<br>
<br>
Just for the record,<br>
<br>
I am working at the moment with (applies to the patch previously
posted):<br>
<br>
gstreamer:<br>
commit f8fdb61b02cbcfc6f6bbc136ada329db128dab3f<br>
Author: Sebastian Dröge <a class="moz-txt-link-rfc2396E" href="mailto:slomo@circular-chaos.org"><slomo@circular-chaos.org></a><br>
Date: Thu Jul 11 16:57:06 2013 +0200<br>
<br>
<br>
gst-plugins-base:<br>
commit 9ab6ab42572a28e447f761485c457f2a71eabb86<br>
Author: Sebastian Dröge <a class="moz-txt-link-rfc2396E" href="mailto:slomo@circular-chaos.org"><slomo@circular-chaos.org></a><br>
Date: Wed Jul 10 17:16:14 2013 +0200<br>
<br>
<br>
gst-plugins-good:<br>
commit d57ef52cadd51643dfc812779dac444bf3d9eaae<br>
Author: Andoni Morales Alastruey <a class="moz-txt-link-rfc2396E" href="mailto:ylatuya@gmail.com"><ylatuya@gmail.com></a><br>
Date: Tue Jul 9 15:34:04 2013 +0200<br>
<br>
<br>
gst-plugins-bad:<br>
commit f83e9405ded5b062841f5b6d83864d4221304866<br>
Author: Sebastian Dröge <a class="moz-txt-link-rfc2396E" href="mailto:slomo@circular-chaos.org"><slomo@circular-chaos.org></a><br>
Date: Wed Jul 10 12:28:38 2013 +0200<br>
<br>
<br>
<br>
<br>
On 07/29/2013 04:29 PM, Robert Krakora wrote:<br>
</div>
<blockquote
cite="mid:CA+Dpatgk2k5rMDG0GvbYrG=F1pXc1Mx4E7J2icgvhQdNT2TkXA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>Hi Peter,<br>
<br>
</div>
After 8-24 hours of continuous running I have noticed an error
indicating no "enough data to read auxiliary data" or
something to that effect. I was instructed to get the Git tip
of gstreamer and gst-plugins-base and re-run my test which I
am doing right now.<br>
<br>
</div>
Best Regards,<br>
<br>
Rob<br>
<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Mon, Jul 29, 2013 at 10:49 AM, 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">
<div bgcolor="#FFFFFF" text="#000000">
<div>Hi Rob,<br>
<br>
Brilliant stuff! I did not answer earlier, because I
wanted to test for a longer time. I tested it with the
pipeline<br>
<br>
gst-launch-1.0 --gst-debug=gstv4l2bufferpool:5
uvch264src device=/dev/video1 name=src auto-start=true
src.vfsrc ! queue ! fakesink src.vidsrc ! queue !
video/x-h264 ! fakesink<br>
<br>
and patch [1] and it run for 24h. There was no memory
leak as far as I can tell. I posted the patch because
additionally to your patch for gstuvch264_mjpgdemux.c, I
did not remove some changes I did (and forgot to remove)
in gstv4l2bufferpool.c. But I do not think that they
have an effect at all.<br>
<br>
I am now testing with the patch you proposed in
gstuvch264_mjpgdemux.c only, stashing all changes made
in gstv4l2bufferpool.c. It seems to run without memory
leak or other problems. I will report back about
stability at the end of the week.<br>
<br>
Thanks a lot for your effort!<br>
<br>
Peter<br>
<br>
[1]<br>
<br>
diff --git a/sys/uvch264/gstuvch264_mjpgdemux.c
b/sys/uvch264/gstuvch264_mjpgdemux.c<br>
index dfb0775..1b0e08e 100644<br>
--- a/sys/uvch264/gstuvch264_mjpgdemux.c<br>
+++ b/sys/uvch264/gstuvch264_mjpgdemux.c<br>
@@ -710,6 +710,8 @@ done:<br>
gst_buffer_unref (aux_buf);<br>
if (jpeg_buf)<br>
gst_buffer_unref (jpeg_buf);<br>
+ /* patch by Robert Krakora */<br>
+ gst_buffer_unmap(buf, &info);<br>
<br>
/* We must always unref the input buffer since we
never push it out */<br>
gst_buffer_unref (buf);<br>
<br>
<br>
<br>
diff --git a/sys/v4l2/gstv4l2bufferpool.c
b/sys/v4l2/gstv4l2bufferpool.c<br>
index 1e74fc7..3430b86 100644<br>
--- a/sys/v4l2/gstv4l2bufferpool.c<br>
+++ b/sys/v4l2/gstv4l2bufferpool.c<br>
@@ -52,6 +52,9 @@<br>
#define V4L2_FIELD_INTERLACED_BT 9<br>
#endif<br>
<br>
+#ifndef VIDIOC_CREATE_BUFS<br>
+#define VIDIOC_CREATE_BUFS<br>
+#endif<br>
<br>
GST_DEBUG_CATEGORY_EXTERN (v4l2_debug);<br>
#define GST_CAT_DEFAULT v4l2_debug<br>
@@ -411,11 +414,11 @@ 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 = num_buffers + 1;<br>
} else {<br>
/* we are certain that we have enough buffers
so we don't need to<br>
* copy */<br>
- copy_threshold = 0;<br>
+ copy_threshold = num_buffers + 1;<br>
}<br>
break;<br>
}<br>
diff --git a/sys/v4l2/gstv4l2src.c
b/sys/v4l2/gstv4l2src.c<br>
index 107ea21..581ce7d 100644<br>
--- a/sys/v4l2/gstv4l2src.c<br>
+++ b/sys/v4l2/gstv4l2src.c<br>
@@ -530,6 +530,7 @@ gst_v4l2src_decide_allocation
(GstBaseSrc * bsrc, GstQuery * query)<br>
} else {<br>
pool = NULL;<br>
min = max = 0;<br>
+// max = 100;<br>
size =
0;
<br>
update =
FALSE;
<br>
} <br>
<br>
<br>
<br>
<br>
On 07/26/2013 09:10 PM, Robert Krakora wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>Hi Peter,<br>
<br>
</div>
See <a moz-do-not-send="true"
href="https://bugzilla.gnome.org/show_bug.cgi?id=699517"
target="_blank">https://bugzilla.gnome.org/show_bug.cgi?id=699517</a>.<br>
<br>
</div>
Best Regards,<br>
<br>
Rob<br>
<br>
</div>
<div class="gmail_extra"> <br>
<br>
<div class="gmail_quote">On Fri, Jul 26, 2013 at 2: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>
It looks as though this patch fixes your error
and the memory leak as well. It is against
gst-plugins-bad-1.1.2.
<div> <br>
<br>
---
gst-plugins-bad-1.1.2/sys/uvch264/gstuvch264_mjpgdemux.c
2013-04-23 08:38:28.000000000 -0400<br>
</div>
+++
gst-plugins-bad-1.1.2.new/sys/uvch264/gstuvch264_mjpgdemux.c
2013-07-26 14:22:51.177762515 -0400
<div><br>
@@ -711,6 +711,8 @@<br>
if (jpeg_buf)<br>
gst_buffer_unref (jpeg_buf);<br>
<br>
+ gst_buffer_unmap(buf, &info);<br>
+<br>
/* We must always unref the input buffer
since we never push it out */<br>
gst_buffer_unref (buf);<br>
<br>
</div>
</div>
Best Regards,<br>
<br>
Rob Krakora<br>
<br>
</div>
<div>
<div>
<div class="gmail_extra"> <br>
<br>
<div class="gmail_quote"> On Fri, Jul 26,
2013 at 12:53 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">Making the change I just
posted and no other change I can run
indefinitely (no error parsing JPEG
container) although there still seems
to be a very, very slow memory leak in
uvch264src...NO CHANGES were made to
v4l2src at all to add back
"always-copy"...<br>
<br>
--- gst-plugins-bad-1.1.2/sys/
<div>
<div>uvch264/gstuvch264_mjpgdemux.c
2013-04-23 08:38:28.000000000
-0400<br>
</div>
+++ gst-plugins-bad-1.1.2.new/sys/
<div>uvch264/gstuvch264_mjpgdemux.c
2013-07-26 12:20:52.625791724
-0400<br>
@@ -711,6 +711,8 @@<br>
if (jpeg_buf)<br>
gst_buffer_unref (jpeg_buf);<br>
<br>
+ gst_buffer_unmap(buf,
&info);
<div><br>
+<br>
/* We must always unref the
input buffer since we never push
it out */<br>
gst_buffer_unref (buf);</div>
</div>
<br>
<br>
</div>
...<br>
</div>
<div>
<div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri,
Jul 26, 2013 at 12:44 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">Hi Peter,<br>
<div><br>
OK, I found a leak in
uvch264src...
<div><br>
<br>
---
gst-plugins-bad-1.1.2/sys/uvch264/gstuvch264_mjpgdemux.c
2013-04-23
08:38:28.000000000 -0400<br>
</div>
+++
gst-plugins-bad-1.1.2.new/sys/uvch264/gstuvch264_mjpgdemux.c
2013-07-26
12:20:52.625791724 -0400<br>
@@ -711,6 +711,8 @@<br>
if (jpeg_buf)<br>
gst_buffer_unref
(jpeg_buf);<br>
<br>
+ gst_buffer_unmap(buf,
&info);
<div><br>
+<br>
/* We must always
unref the input buffer
since we never push it
out */<br>
gst_buffer_unref
(buf);<br>
<br>
</div>
</div>
<div>There is still a very
slow leak may remain,
however...<br>
</div>
<div><br>
<br>
</div>
</div>
<div>
<div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On
Fri, Jul 26, 2013 at
10:32 AM, 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">Sorry,
I attached the
patch files and
they were scrubbed
off by the
forum...<br>
<br>
---
gst-plugins-good-1.1.2/sys/v4l2/gstv4l2bufferpool.c
2013-07-08
10:27:16.000000000
-0400<br>
+++
gst-plugins-good-1.1.2.new/sys/v4l2/gstv4l2bufferpool.c
2013-07-26
09:47:22.584092634
-0400<br>
@@ -375,6 +375,7
@@
<div><br>
{<br>
/*
request a
reasonable
number of
buffers when no
max specified.
We will<br>
* copy
when we run out
of buffers */<br>
</div>
+
//max_buffers =
100;<br>
if
(max_buffers == 0)<br>
num_buffers = 4;<br>
else<br>
@@ -411,11 +412,11
@@
<div><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>
</div>
+
copy_threshold =
num_buffers + 1;
<div><br>
} else {<br>
/* we
are certain that
we have enough
buffers so we
don't need to<br>
* copy
*/<br>
</div>
-
copy_threshold =
0;<br>
+
copy_threshold =
num_buffers + 1;<br>
}<br>
break;<br>
}<br>
<br>
---
gst-plugins-bad-1.1.2/sys/uvch264/gstuvch264_mjpgdemux.c
2013-04-23
08:38:28.000000000
-0400<br>
+++
gst-plugins-bad-1.1.2.new/sys/uvch264/gstuvch264_mjpgdemux.c
2013-07-26
10:07:18.232833437
-0400<br>
@@ -462,10 +462,10
@@<br>
{<br>
GstUvcH264MjpgDemux
*self;<br>
GstFlowReturn
ret = GST_FLOW_OK;<br>
- GstBuffer
*jpeg_buf =
gst_buffer_copy_region
(buf,
GST_BUFFER_COPY_METADATA,<br>
- 0, 0);<br>
- GstBuffer
*aux_buf = NULL;<br>
+ GstBufferList
*jpeg_buf =
gst_buffer_list_new
();<br>
+ GstBufferList
*aux_buf = NULL;<br>
AuxiliaryStreamHeader
aux_header = { 0
};<br>
+ GstBuffer
*sub_buffer =
NULL;<br>
guint32
aux_size = 0;<br>
GstPad *aux_pad
= NULL;<br>
GstCaps
**aux_caps = NULL;<br>
@@ -514,9 +514,8
@@<br>
<br>
/* Add JPEG
data between the
last offset and
this market */<br>
if (i -
last_offset >
0) {<br>
- GstMemory
*m =
gst_memory_copy
(info.memory,
last_offset,<br>
- i -
last_offset);<br>
-
gst_buffer_append_memory
(jpeg_buf, m);<br>
+
sub_buffer =
gst_buffer_copy_region
(buf,
GST_BUFFER_COPY_ALL,
last_offset, i -
last_offset);<br>
+
gst_buffer_copy_into
(sub_buffer, buf,
GST_BUFFER_COPY_METADATA,
0, -1);<br>
}<br>
last_offset
= i + 2 +
segment_size;<br>
<br>
@@ -624,7 +623,7
@@<br>
}<br>
<br>
/*
Create new
auxiliary buffer
list and adjust
i/segment size */<br>
- aux_buf
= gst_buffer_new
();<br>
+ aux_buf
=
gst_buffer_list_new
();<br>
}<br>
<br>
i +=
sizeof
(aux_header) +
sizeof (aux_size);<br>
@@ -640,15 +639,12
@@<br>
}<br>
<br>
if
(segment_size >
0) {<br>
- GstMemory
*m;<br>
- m =
gst_memory_copy
(info.memory, i,
segment_size);<br>
-<br>
-
GST_BUFFER_DURATION
(aux_buf) =<br>
+
sub_buffer =
gst_buffer_copy_region
(buf,
GST_BUFFER_COPY_ALL,
i, segment_size);<br>
+
GST_BUFFER_DURATION
(sub_buffer) =<br>
aux_header.frame_interval
* 100 *
GST_NSECOND;<br>
+
gst_buffer_copy_into
(sub_buffer, buf,
GST_BUFFER_COPY_TIMESTAMPS,
0, -1);<br>
<br>
-
_pts_to_timestamp
(self, aux_buf,
aux_header.pts);<br>
-<br>
-
gst_buffer_append_memory
(aux_buf, m);<br>
+
_pts_to_timestamp
(self, sub_buffer,
aux_header.pts);<br>
<br>
aux_size
-= segment_size;<br>
<br>
@@ -657,7 +653,7
@@<br>
GST_DEBUG_OBJECT
(self, "Pushing %"
GST_FOURCC_FORMAT<br>
"
auxiliary buffer
%" GST_PTR_FORMAT,<br>
GST_FOURCC_ARGS
(aux_header.type),
*aux_caps);<br>
- ret =
gst_pad_push
(aux_pad,
aux_buf);<br>
+ ret =
gst_pad_push_list
(aux_pad,
aux_buf);<br>
aux_buf
= NULL;<br>
if (ret
!= GST_FLOW_OK) {<br>
GST_WARNING_OBJECT
(self, "Error
pushing %"
GST_FOURCC_FORMAT<br>
@@ -669,13 +665,12
@@<br>
<br>
i +=
segment_size - 1;<br>
} else if
(data[i] == 0xff
&& data[i
+ 1] == 0xda) {<br>
- GstMemory
*m;<br>
<br>
/* The APP4
markers must be
before the SOS
marker, so this is
the end */<br>
GST_DEBUG_OBJECT
(self, "Found SOS
marker.");<br>
<br>
- m =
gst_memory_copy
(info.memory,
last_offset, size
- last_offset);<br>
-
gst_buffer_append_memory
(jpeg_buf, m);<br>
+ sub_buffer
=
gst_buffer_copy_region
(buf,
GST_BUFFER_COPY_ALL,
last_offset, size
- last_offset);<br>
+
gst_buffer_copy_into
(sub_buffer, buf,
GST_BUFFER_COPY_METADATA,
0, -1);<br>
last_offset
= size;<br>
break;<br>
}<br>
@@ -692,10 +687,10
@@<br>
/* this means
there was no SOS
marker in the jpg,
so we assume the
JPG was<br>
just a
container */<br>
GST_DEBUG_OBJECT
(self, "SOS marker
wasn't found. MJPG
is container
only");<br>
-
gst_buffer_unref
(jpeg_buf);<br>
+
gst_buffer_list_unref
(jpeg_buf);<br>
jpeg_buf =
NULL;<br>
} else {<br>
- ret =
gst_pad_push
(self->priv->jpeg_pad,
jpeg_buf);<br>
+ ret =
gst_pad_push_list
(self->priv->jpeg_pad,
jpeg_buf);<br>
jpeg_buf =
NULL;<br>
}<br>
<br>
@@ -707,9 +702,9
@@<br>
done:<br>
/* In case of
error, unref
whatever was left
*/<br>
if (aux_buf)<br>
-
gst_buffer_unref
(aux_buf);<br>
+
gst_buffer_list_unref
(aux_buf);<br>
if (jpeg_buf)<br>
-
gst_buffer_unref
(jpeg_buf);<br>
+
gst_buffer_list_unref
(jpeg_buf);<br>
<br>
/* We must
always unref the
input buffer since
we never push it
out */<br>
gst_buffer_unref
(buf);<br>
<br>
<br>
</div>
<div>
<div>
<div
class="gmail_extra"><br>
<br>
<div
class="gmail_quote">
On Fri, Jul
26, 2013 at
10:22 AM,
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>
Here is what I
am running
with
currently...still
has leak, but
no error on
JPEG
parsing...<br>
<br>
Best Regards,<br>
<br>
Rob<br>
<br>
</div>
<div>
<div>
<div
class="gmail_extra"><br>
<br>
<div
class="gmail_quote">
On Fri, Jul
26, 2013 at
9:45 AM, 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">
<div
bgcolor="#FFFFFF"
text="#000000">
<div>After
playing a bit
around it with
it, I think
the memory
leak arises if
you set
copy_threshold
too high (25
seems to be
still ok). In
my patch in
the previous
email I had it
set to 15
only, and
capped the
max_buffers to
100 in the
gstv4l2src.c<br>
<br>
Alternatively,
I can also set
<br>
<br>
diff --git
a/sys/v4l2/gstv4l2bufferpool.c
b/sys/v4l2/gstv4l2bufferpool.c
<br>
index
1e74fc7..90e8470
100644
<br>
---
a/sys/v4l2/gstv4l2bufferpool.c<br>
+++
b/sys/v4l2/gstv4l2bufferpool.c<br>
@@ -376,7
+376,7 @@
gst_v4l2_buffer_pool_set_config
(GstBufferPool
* bpool,
GstStructure *
config)<br>
/*
request a
reasonable
number of
buffers when
no max
specified. We
will<br>
* copy
when we run
out of buffers
*/<br>
if
(max_buffers
== 0)<br>
-
num_buffers =
4;<br>
+
num_buffers =
100;<br>
else<br>
num_buffers =
max_buffers;<br>
<br>
(using the
original
gstv4l2src.c)<br>
<br>
leaving<br>
<br>
copy_threshold
= 2;<br>
<br>
Intact. Now
the pipeline
runs without
memory leak
for 4.35min
and crashes
then. <br>
<br>
I get exactly
the same
behaviour if I
set
num_buffers =
100;
copy_threshold
= 25; or
num_buffers =
200;
copy_threshold
= 25;
<div>
<div><br>
<br>
On 07/26/2013
02:26 PM,
Robert Krakora
wrote:<br>
</div>
</div>
</div>
<div>
<div>
<blockquote
type="cite">
<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="gmail_extra"><br>
<br>
<div
class="gmail_quote">On
Fri, Jul 26,
2013 at 9:24
AM, 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">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
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">
<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
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> <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
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 <a
moz-do-not-send="true"
href="tel:2149480048" value="+12149480048" target="_blank">2149480048</a>
x2 <a
moz-do-not-send="true"
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
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></fieldset>
<br>
<pre>_______________________________________________
gstreamer-devel mailing list
<a moz-do-not-send="true" href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a>
<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>
</pre>
</blockquote>
<br>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
gstreamer-devel mailing list
<a moz-do-not-send="true" href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a>
<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>
</pre>
</blockquote>
<br>
</div>
</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>
<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
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></fieldset>
<br>
<pre>_______________________________________________
gstreamer-devel mailing list
<a moz-do-not-send="true" href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a>
<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>
</pre>
</blockquote>
<br>
</div>
</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>
<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
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>
</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></fieldset>
<br>
<pre>_______________________________________________
gstreamer-devel mailing list
<a moz-do-not-send="true" href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a>
<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>
</pre>
</blockquote>
<br>
</div>
<br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a moz-do-not-send="true"
href="mailto:gstreamer-devel@lists.freedesktop.org">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>
<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 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>