<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">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
cite="mid:CA+DpatiCHL17sSO7_L4i6Jgd7wH6e_jmXEY-JEx1i3b1sGASjw@mail.gmail.com"
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">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 class="im">
<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 class="im"><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 class="HOEnZb">
<div class="h5">
<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 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>