<div dir="ltr"><div><div>Hi Peter,<br><br></div>See <a 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 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 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 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 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 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 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 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 <a href="tel:2149480048" value="+12149480048" target="_blank">2149480048</a>
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>
<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>
</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>