[uvch264src in 1.1.1.1] "Got data flow before segment event" warnings until crash
Peter Rennert
p.rennert at cs.ucl.ac.uk
Mon Jul 29 07:49:24 PDT 2013
Hi Rob,
Brilliant stuff! I did not answer earlier, because I wanted to test for
a longer time. I tested it with the pipeline
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
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.
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.
Thanks a lot for your effort!
Peter
[1]
diff --git a/sys/uvch264/gstuvch264_mjpgdemux.c
b/sys/uvch264/gstuvch264_mjpgdemux.c
index dfb0775..1b0e08e 100644
--- a/sys/uvch264/gstuvch264_mjpgdemux.c
+++ b/sys/uvch264/gstuvch264_mjpgdemux.c
@@ -710,6 +710,8 @@ done:
gst_buffer_unref (aux_buf);
if (jpeg_buf)
gst_buffer_unref (jpeg_buf);
+ /* patch by Robert Krakora */
+ gst_buffer_unmap(buf, &info);
/* We must always unref the input buffer since we never push it out */
gst_buffer_unref (buf);
diff --git a/sys/v4l2/gstv4l2bufferpool.c b/sys/v4l2/gstv4l2bufferpool.c
index 1e74fc7..3430b86 100644
--- a/sys/v4l2/gstv4l2bufferpool.c
+++ b/sys/v4l2/gstv4l2bufferpool.c
@@ -52,6 +52,9 @@
#define V4L2_FIELD_INTERLACED_BT 9
#endif
+#ifndef VIDIOC_CREATE_BUFS
+#define VIDIOC_CREATE_BUFS
+#endif
GST_DEBUG_CATEGORY_EXTERN (v4l2_debug);
#define GST_CAT_DEFAULT v4l2_debug
@@ -411,11 +414,11 @@ gst_v4l2_buffer_pool_set_config (GstBufferPool *
bpool, GstStructure * config)
if (max_buffers == 0 || num_buffers < max_buffers) {
/* if we are asked to provide more buffers than we have
allocated, start
* copying buffers when we only have 2 buffers left in the pool */
- copy_threshold = 2;
+ copy_threshold = num_buffers + 1;
} else {
/* we are certain that we have enough buffers so we don't need to
* copy */
- copy_threshold = 0;
+ copy_threshold = num_buffers + 1;
}
break;
}
diff --git a/sys/v4l2/gstv4l2src.c b/sys/v4l2/gstv4l2src.c
index 107ea21..581ce7d 100644
--- a/sys/v4l2/gstv4l2src.c
+++ b/sys/v4l2/gstv4l2src.c
@@ -530,6 +530,7 @@ gst_v4l2src_decide_allocation (GstBaseSrc * bsrc,
GstQuery * query)
} else {
pool = NULL;
min = max = 0;
+// max = 100;
size = 0;
update = FALSE;
}
On 07/26/2013 09:10 PM, Robert Krakora wrote:
> Hi Peter,
>
> See https://bugzilla.gnome.org/show_bug.cgi?id=699517.
>
> Best Regards,
>
> Rob
>
>
>
> On Fri, Jul 26, 2013 at 2:27 PM, Robert Krakora
> <rob.krakora at messagenetsystems.com
> <mailto:rob.krakora at messagenetsystems.com>> wrote:
>
> Hi Peter,
>
> It looks as though this patch fixes your error and the memory leak
> as well. It is against gst-plugins-bad-1.1.2.
>
>
> --- gst-plugins-bad-1.1.2/sys/uvch264/gstuvch264_mjpgdemux.c
> 2013-04-23 08:38:28.000000000 -0400
> +++ gst-plugins-bad-1.1.2.new/sys/uvch264/gstuvch264_mjpgdemux.c
> 2013-07-26 14:22:51.177762515 -0400
>
> @@ -711,6 +711,8 @@
> if (jpeg_buf)
> gst_buffer_unref (jpeg_buf);
>
> + gst_buffer_unmap(buf, &info);
> +
> /* We must always unref the input buffer since we never push it
> out */
> gst_buffer_unref (buf);
>
> Best Regards,
>
> Rob Krakora
>
>
>
> On Fri, Jul 26, 2013 at 12:53 PM, Robert Krakora
> <rob.krakora at messagenetsystems.com
> <mailto:rob.krakora at messagenetsystems.com>> wrote:
>
> 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"...
>
> --- gst-plugins-bad-1.1.2/sys/
> uvch264/gstuvch264_mjpgdemux.c 2013-04-23 08:38:28.000000000 -0400
> +++ gst-plugins-bad-1.1.2.new/sys/
> uvch264/gstuvch264_mjpgdemux.c 2013-07-26 12:20:52.625791724 -0400
> @@ -711,6 +711,8 @@
> if (jpeg_buf)
> gst_buffer_unref (jpeg_buf);
>
> + gst_buffer_unmap(buf, &info);
>
> +
> /* We must always unref the input buffer since we never
> push it out */
> gst_buffer_unref (buf);
>
>
> ...
>
>
> On Fri, Jul 26, 2013 at 12:44 PM, Robert Krakora
> <rob.krakora at messagenetsystems.com
> <mailto:rob.krakora at messagenetsystems.com>> wrote:
>
> Hi Peter,
>
> OK, I found a leak in uvch264src...
>
>
> ---
> gst-plugins-bad-1.1.2/sys/uvch264/gstuvch264_mjpgdemux.c
> 2013-04-23 08:38:28.000000000 -0400
> +++
> gst-plugins-bad-1.1.2.new/sys/uvch264/gstuvch264_mjpgdemux.c
> 2013-07-26 12:20:52.625791724 -0400
> @@ -711,6 +711,8 @@
> if (jpeg_buf)
> gst_buffer_unref (jpeg_buf);
>
> + gst_buffer_unmap(buf, &info);
>
> +
> /* We must always unref the input buffer since we never
> push it out */
> gst_buffer_unref (buf);
>
> There is still a very slow leak may remain, however...
>
>
>
>
> On Fri, Jul 26, 2013 at 10:32 AM, Robert Krakora
> <rob.krakora at messagenetsystems.com
> <mailto:rob.krakora at messagenetsystems.com>> wrote:
>
> Sorry, I attached the patch files and they were
> scrubbed off by the forum...
>
> ---
> gst-plugins-good-1.1.2/sys/v4l2/gstv4l2bufferpool.c
> 2013-07-08 10:27:16.000000000 -0400
> +++
> gst-plugins-good-1.1.2.new/sys/v4l2/gstv4l2bufferpool.c 2013-07-26
> 09:47:22.584092634 -0400
> @@ -375,6 +375,7 @@
>
> {
> /* request a reasonable number of buffers when
> no max specified. We will
> * copy when we run out of buffers */
> + //max_buffers = 100;
> if (max_buffers == 0)
> num_buffers = 4;
> else
> @@ -411,11 +412,11 @@
>
> if (max_buffers == 0 || num_buffers <
> max_buffers) {
> /* if we are asked to provide more buffers
> than we have allocated, start
> * copying buffers when we only have 2
> buffers left in the pool */
> - copy_threshold = 2;
> + copy_threshold = num_buffers + 1;
>
> } else {
> /* we are certain that we have enough buffers
> so we don't need to
> * copy */
> - copy_threshold = 0;
> + copy_threshold = num_buffers + 1;
> }
> break;
> }
>
> ---
> gst-plugins-bad-1.1.2/sys/uvch264/gstuvch264_mjpgdemux.c
> 2013-04-23 08:38:28.000000000 -0400
> +++
> gst-plugins-bad-1.1.2.new/sys/uvch264/gstuvch264_mjpgdemux.c
> 2013-07-26 10:07:18.232833437 -0400
> @@ -462,10 +462,10 @@
> {
> GstUvcH264MjpgDemux *self;
> GstFlowReturn ret = GST_FLOW_OK;
> - GstBuffer *jpeg_buf = gst_buffer_copy_region (buf,
> GST_BUFFER_COPY_METADATA,
> - 0, 0);
> - GstBuffer *aux_buf = NULL;
> + GstBufferList *jpeg_buf = gst_buffer_list_new ();
> + GstBufferList *aux_buf = NULL;
> AuxiliaryStreamHeader aux_header = { 0 };
> + GstBuffer *sub_buffer = NULL;
> guint32 aux_size = 0;
> GstPad *aux_pad = NULL;
> GstCaps **aux_caps = NULL;
> @@ -514,9 +514,8 @@
>
> /* Add JPEG data between the last offset and
> this market */
> if (i - last_offset > 0) {
> - GstMemory *m = gst_memory_copy (info.memory,
> last_offset,
> - i - last_offset);
> - gst_buffer_append_memory (jpeg_buf, m);
> + sub_buffer = gst_buffer_copy_region (buf,
> GST_BUFFER_COPY_ALL, last_offset, i - last_offset);
> + gst_buffer_copy_into (sub_buffer, buf,
> GST_BUFFER_COPY_METADATA, 0, -1);
> }
> last_offset = i + 2 + segment_size;
>
> @@ -624,7 +623,7 @@
> }
>
> /* Create new auxiliary buffer list and
> adjust i/segment size */
> - aux_buf = gst_buffer_new ();
> + aux_buf = gst_buffer_list_new ();
> }
>
> i += sizeof (aux_header) + sizeof (aux_size);
> @@ -640,15 +639,12 @@
> }
>
> if (segment_size > 0) {
> - GstMemory *m;
> - m = gst_memory_copy (info.memory, i,
> segment_size);
> -
> - GST_BUFFER_DURATION (aux_buf) =
> + sub_buffer = gst_buffer_copy_region (buf,
> GST_BUFFER_COPY_ALL, i, segment_size);
> + GST_BUFFER_DURATION (sub_buffer) =
> aux_header.frame_interval * 100 * GST_NSECOND;
> + gst_buffer_copy_into (sub_buffer, buf,
> GST_BUFFER_COPY_TIMESTAMPS, 0, -1);
>
> - _pts_to_timestamp (self, aux_buf,
> aux_header.pts);
> -
> - gst_buffer_append_memory (aux_buf, m);
> + _pts_to_timestamp (self, sub_buffer,
> aux_header.pts);
>
> aux_size -= segment_size;
>
> @@ -657,7 +653,7 @@
> GST_DEBUG_OBJECT (self, "Pushing %"
> GST_FOURCC_FORMAT
> " auxiliary buffer %" GST_PTR_FORMAT,
> GST_FOURCC_ARGS (aux_header.type), *aux_caps);
> - ret = gst_pad_push (aux_pad, aux_buf);
> + ret = gst_pad_push_list (aux_pad, aux_buf);
> aux_buf = NULL;
> if (ret != GST_FLOW_OK) {
> GST_WARNING_OBJECT (self, "Error pushing %"
> GST_FOURCC_FORMAT
> @@ -669,13 +665,12 @@
>
> i += segment_size - 1;
> } else if (data[i] == 0xff && data[i + 1] == 0xda) {
> - GstMemory *m;
>
> /* The APP4 markers must be before the SOS
> marker, so this is the end */
> GST_DEBUG_OBJECT (self, "Found SOS marker.");
>
> - m = gst_memory_copy (info.memory, last_offset,
> size - last_offset);
> - gst_buffer_append_memory (jpeg_buf, m);
> + sub_buffer = gst_buffer_copy_region (buf,
> GST_BUFFER_COPY_ALL, last_offset, size - last_offset);
> + gst_buffer_copy_into (sub_buffer, buf,
> GST_BUFFER_COPY_METADATA, 0, -1);
> last_offset = size;
> break;
> }
> @@ -692,10 +687,10 @@
> /* this means there was no SOS marker in the jpg,
> so we assume the JPG was
> just a container */
> GST_DEBUG_OBJECT (self, "SOS marker wasn't found.
> MJPG is container only");
> - gst_buffer_unref (jpeg_buf);
> + gst_buffer_list_unref (jpeg_buf);
> jpeg_buf = NULL;
> } else {
> - ret = gst_pad_push (self->priv->jpeg_pad, jpeg_buf);
> + ret = gst_pad_push_list (self->priv->jpeg_pad,
> jpeg_buf);
> jpeg_buf = NULL;
> }
>
> @@ -707,9 +702,9 @@
> done:
> /* In case of error, unref whatever was left */
> if (aux_buf)
> - gst_buffer_unref (aux_buf);
> + gst_buffer_list_unref (aux_buf);
> if (jpeg_buf)
> - gst_buffer_unref (jpeg_buf);
> + gst_buffer_list_unref (jpeg_buf);
>
> /* We must always unref the input buffer since we
> never push it out */
> gst_buffer_unref (buf);
>
>
>
>
> On Fri, Jul 26, 2013 at 10:22 AM, Robert Krakora
> <rob.krakora at messagenetsystems.com
> <mailto:rob.krakora at messagenetsystems.com>> wrote:
>
> Hi Peter,
>
> Here is what I am running with currently...still
> has leak, but no error on JPEG parsing...
>
> Best Regards,
>
> Rob
>
>
>
> On Fri, Jul 26, 2013 at 9:45 AM, Peter Rennert
> <p.rennert at cs.ucl.ac.uk
> <mailto:p.rennert at cs.ucl.ac.uk>> wrote:
>
> 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
>
> Alternatively, I can also set
>
> diff --git a/sys/v4l2/gstv4l2bufferpool.c
> b/sys/v4l2/gstv4l2bufferpool.c
> index 1e74fc7..90e8470 100644
> --- a/sys/v4l2/gstv4l2bufferpool.c
> +++ b/sys/v4l2/gstv4l2bufferpool.c
> @@ -376,7 +376,7 @@
> gst_v4l2_buffer_pool_set_config (GstBufferPool
> * bpool, GstStructure * config)
> /* request a reasonable number of
> buffers when no max specified. We will
> * copy when we run out of buffers */
> if (max_buffers == 0)
> - num_buffers = 4;
> + num_buffers = 100;
> else
> num_buffers = max_buffers;
>
> (using the original gstv4l2src.c)
>
> leaving
>
> copy_threshold = 2;
>
> Intact. Now the pipeline runs without memory
> leak for 4.35min and crashes then.
>
> I get exactly the same behaviour if I set
> num_buffers = 100; copy_threshold = 25; or
> num_buffers = 200; copy_threshold = 25;
>
>
> On 07/26/2013 02:26 PM, Robert Krakora wrote:
>> 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.
>>
>>
>> On Fri, Jul 26, 2013 at 9:24 AM, Robert
>> Krakora <rob.krakora at messagenetsystems.com
>> <mailto:rob.krakora at messagenetsystems.com>>
>> wrote:
>>
>> 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...
>>
>>
>> On Fri, Jul 26, 2013 at 9:03 AM, Peter
>> Rennert <p.rennert at cs.ucl.ac.uk
>> <mailto:p.rennert at cs.ucl.ac.uk>> wrote:
>>
>> 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.
>>
>>
>>
>> On 07/26/2013 01:13 PM, Peter Rennert
>> wrote:
>>> Rob,
>>>
>>> Well spotted!
>>>
>>> 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.
>>>
>>> Try this patch to get rid of the
>>> memory leak:
>>>
>>> diff --git
>>> a/sys/v4l2/gstv4l2bufferpool.c
>>> b/sys/v4l2/gstv4l2bufferpool.c
>>> index 1e74fc7..282ac2b 100644
>>> --- a/sys/v4l2/gstv4l2bufferpool.c
>>> +++ b/sys/v4l2/gstv4l2bufferpool.c
>>> @@ -411,7 +411,7 @@
>>> gst_v4l2_buffer_pool_set_config
>>> (GstBufferPool * bpool, GstStructure
>>> * config)
>>> if (max_buffers == 0 ||
>>> num_buffers < max_buffers) {
>>> /* if we are asked to
>>> provide more buffers than we have
>>> allocated, start
>>> * copying buffers when we
>>> only have 2 buffers left in the pool */
>>> - copy_threshold = 2;
>>> + copy_threshold = 15;// 2;
>>> } else {
>>> /* we are certain that we
>>> have enough buffers so we don't need to
>>> * copy */
>>> diff --git a/sys/v4l2/gstv4l2src.c
>>> b/sys/v4l2/gstv4l2src.c
>>> index 107ea21..0c5d91a 100644
>>> --- a/sys/v4l2/gstv4l2src.c
>>> +++ b/sys/v4l2/gstv4l2src.c
>>> @@ -529,7 +529,8 @@
>>> gst_v4l2src_decide_allocation
>>> (GstBaseSrc * bsrc, GstQuery * query)
>>> update = TRUE;
>>> } else {
>>> pool = NULL;
>>> - min = max = 0;
>>> + min = 0;
>>> + max = 100;
>>> size = 0;
>>> update = FALSE;
>>> }
>>>
>>>
>>> On 07/25/2013 09:52 PM, Robert
>>> Krakora wrote:
>>>> Hi Peter,
>>>>
>>>> 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).
>>>>
>>>> gst-launch-1.0 uvch264src
>>>> device=/dev/video0 name=src
>>>> auto-start=true src.vfsrc ! queue !
>>>> fakesink src.vidsrc ! queue !
>>>> video/x-h264 ! fakesink
>>>>
>>>> Best Regards,
>>>>
>>>> Rob Krakora
>>>>
>>>>
>>>>
>>>> On Thu, Jul 25, 2013 at 4:27 PM,
>>>> Robert Krakora
>>>> <rob.krakora at messagenetsystems.com
>>>> <mailto:rob.krakora at messagenetsystems.com>>
>>>> wrote:
>>>>
>>>> Hi Peter,
>>>>
>>>> I forgot to mention that the
>>>> file that needs modification is
>>>> named gstv4l2bufferpool.c and
>>>> is under sys/v4l2 under
>>>> plugins-good.
>>>>
>>>>
>>>> if (max_buffers == 0 ||
>>>> num_buffers < max_buffers) {
>>>> /* if we are asked to
>>>> provide more buffers than we
>>>> have allocated, start
>>>> * copying buffers when
>>>> we only have 2 buffers left in
>>>> the pool */
>>>> copy_threshold = 100; //2;
>>>> } else {
>>>> /* we are certain that
>>>> we have enough buffers so we
>>>> don't need to
>>>> * copy */
>>>> copy_threshold = 0;
>>>> }
>>>>
>>>>
>>>> On Thu, Jul 25, 2013 at 4:21
>>>> PM, Robert Krakora
>>>> <rob.krakora at messagenetsystems.com
>>>> <mailto:rob.krakora at messagenetsystems.com>>
>>>> wrote:
>>>>
>>>> Hi Peter,
>>>>
>>>> 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.
>>>>
>>>> if (max_buffers == 0
>>>> || num_buffers < max_buffers) {
>>>> /* if we are asked
>>>> to provide more buffers
>>>> than we have allocated, start
>>>> * copying buffers
>>>> when we only have 2 buffers
>>>> left in the pool */
>>>> copy_threshold = 100; //2;
>>>> } else {
>>>> /* we are certain
>>>> that we have enough buffers
>>>> so we don't need to
>>>> * copy */
>>>> copy_threshold = 0;
>>>> }
>>>>
>>>> Best Regards,
>>>>
>>>> Rob Krakora
>>>>
>>>>
>>>>
>>>> On Thu, Jul 25, 2013 at
>>>> 1:06 PM, Robert Krakora
>>>> <rob.krakora at messagenetsystems.com
>>>> <mailto:rob.krakora at messagenetsystems.com>>
>>>> wrote:
>>>>
>>>> Hi Peter,
>>>>
>>>> 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.
>>>> Below 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.
>>>>
>>>> uvcvideo: Frame
>>>> complete (EOF found).
>>>> uvcvideo: EOF in empty
>>>> payload.
>>>> uvcvideo: uvc_v4l2_poll
>>>> uvcvideo:
>>>> uvc_v4l2_ioctl(VIDIOC_DQBUF)
>>>> uvcvideo: HD Pro Webcam
>>>> C920: PTS 1029592232 y
>>>> 2948.098587 SOF
>>>> 2948.098587 (x1
>>>> 2149480048
>>>> <tel:2149480048> x2
>>>> 2179588048
>>>> <tel:2179588048> y1
>>>> 193593344 y2 199426048
>>>> SOF offset 39)
>>>> 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)
>>>> uvcvideo:
>>>> uvc_dequeue_buffer -
>>>> buf->bytesused = 220410
>>>> uvcvideo:
>>>> uvc_v4l2_ioctl(VIDIOC_QBUF)
>>>>
>>>> Best Regards,
>>>>
>>>> Rob
>>>>
>>>>
>>>> On Thu, Jul 25, 2013 at
>>>> 12:22 PM, Peter Rennert
>>>> <p.rennert at cs.ucl.ac.uk
>>>> <mailto:p.rennert at cs.ucl.ac.uk>>
>>>> wrote:
>>>>
>>>> A bit of an update
>>>> today.
>>>>
>>>> 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:
>>>>
>>>> GST_DEBUG_OBJECT (self,
>>>> "Found APP4 marker
>>>> (%d). JPG: %d-%d -
>>>> APP4: %d - %d",
>>>> segment_size,
>>>> last_offset, i, i,
>>>> i + 2 + segment_size);
>>>>
>>>> I print for each
>>>> time in the loop
>>>> (before the sanity
>>>> test that will fail
>>>> finally):
>>>>
>>>> printf("Found APP4
>>>> marker (%d). JPG:
>>>> %d-%d - APP4: %d -
>>>> %d - size: %d\n",
>>>> segment_size,
>>>> last_offset, i, i,
>>>> i + 2 +
>>>> segment_size,
>>>> (int)size);
>>>>
>>>> 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:
>>>>
>>>> Found APP4 marker
>>>> (13010). JPG: 0-8 -
>>>> APP4: 8 - 13020 -
>>>> size: 166660
>>>>
>>>> Found APP4 marker
>>>> (65533). JPG:
>>>> 13020-13020 - APP4:
>>>> 13020 - 78555 -
>>>> size: 166660
>>>>
>>>> Found APP4 marker
>>>> (65533). JPG:
>>>> 78555-78555
>>>> <tel:78555-78555> -
>>>> APP4: 78555 -
>>>> 144090 - size: 166660
>>>>
>>>> Found APP4 marker
>>>> (22566). JPG:
>>>> 144090-144090 -
>>>> APP4: 144090 -
>>>> 166658 - size: 166660
>>>>
>>>>
>>>> The frame that
>>>> causes the failure
>>>> of the system has
>>>> the following output:
>>>>
>>>> Found APP4 marker
>>>> (12084). JPG: 0-8 -
>>>> APP4: 8 - 12094 -
>>>> size: 165485
>>>>
>>>> Found APP4 marker
>>>> (65533). JPG:
>>>> 12094-12094 - APP4:
>>>> 12094 - 77629 -
>>>> size: 165485
>>>>
>>>> Found APP4 marker
>>>> (65533). JPG:
>>>> 77629-77629 - APP4:
>>>> 77629 - 143164 -
>>>> size: 165485
>>>>
>>>> Found APP4 marker
>>>> (22566). JPG:
>>>> 143164-143164 -
>>>> APP4: 143164 -
>>>> 165732 - size: 165485
>>>>
>>>>
>>>> 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.
>>>>
>>>> The number of bytes
>>>> getting lost is not
>>>> the same for
>>>> different trials,
>>>> neither is the
>>>> cut-off. For my
>>>> second trial I got:
>>>>
>>>> Found APP4 marker
>>>> (22566). JPG:
>>>> 144796-144796 -
>>>> APP4: 144796 -
>>>> 167364 - size: 165815
>>>>
>>>> So where are these
>>>> bytes? And why are
>>>> they missing so
>>>> regularly?
>>>>
>>>> _______________________________________________
>>>> gstreamer-devel
>>>> mailing list
>>>> gstreamer-devel at lists.freedesktop.org
>>>> <mailto:gstreamer-devel at lists.freedesktop.org>
>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Rob Krakora
>>>> MessageNet Systems
>>>> 101 East Carmel Dr.
>>>> Suite 105
>>>> Carmel, IN 46032
>>>> (317)566-1677Ext 212
>>>> (317)663-0808 Fax
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Rob Krakora
>>>> MessageNet Systems
>>>> 101 East Carmel Dr. Suite 105
>>>> Carmel, IN 46032
>>>> (317)566-1677Ext 212
>>>> (317)663-0808 Fax
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Rob Krakora
>>>> MessageNet Systems
>>>> 101 East Carmel Dr. Suite 105
>>>> Carmel, IN 46032
>>>> (317)566-1677Ext 212
>>>> (317)663-0808 Fax
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Rob Krakora
>>>> MessageNet Systems
>>>> 101 East Carmel Dr. Suite 105
>>>> Carmel, IN 46032
>>>> (317)566-1677Ext 212
>>>> (317)663-0808 Fax
>>>>
>>>>
>>>> _______________________________________________
>>>> gstreamer-devel mailing list
>>>> gstreamer-devel at lists.freedesktop.org <mailto:gstreamer-devel at lists.freedesktop.org>
>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>
>>>
>>>
>>> _______________________________________________
>>> gstreamer-devel mailing list
>>> gstreamer-devel at lists.freedesktop.org <mailto:gstreamer-devel at lists.freedesktop.org>
>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> <mailto:gstreamer-devel at lists.freedesktop.org>
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>>
>>
>>
>> --
>> Rob Krakora
>> MessageNet Systems
>> 101 East Carmel Dr. Suite 105
>> Carmel, IN 46032
>> (317)566-1677Ext 212
>> (317)663-0808 Fax
>>
>>
>>
>>
>> --
>> Rob Krakora
>> MessageNet Systems
>> 101 East Carmel Dr. Suite 105
>> Carmel, IN 46032
>> (317)566-1677Ext 212
>> (317)663-0808 Fax
>>
>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org <mailto:gstreamer-devel at lists.freedesktop.org>
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> <mailto:gstreamer-devel at lists.freedesktop.org>
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
>
>
> --
> Rob Krakora
> MessageNet Systems
> 101 East Carmel Dr. Suite 105
> Carmel, IN 46032
> (317)566-1677Ext 212
> (317)663-0808 Fax
>
>
>
>
> --
> Rob Krakora
> MessageNet Systems
> 101 East Carmel Dr. Suite 105
> Carmel, IN 46032
> (317)566-1677Ext 212
> (317)663-0808 Fax
>
>
>
>
> --
> Rob Krakora
> MessageNet Systems
> 101 East Carmel Dr. Suite 105
> Carmel, IN 46032
> (317)566-1677Ext 212
> (317)663-0808 Fax
>
>
>
>
> --
> Rob Krakora
> MessageNet Systems
> 101 East Carmel Dr. Suite 105
> Carmel, IN 46032
> (317)566-1677Ext 212
> (317)663-0808 Fax
>
>
>
>
> --
> Rob Krakora
> MessageNet Systems
> 101 East Carmel Dr. Suite 105
> Carmel, IN 46032
> (317)566-1677Ext 212
> (317)663-0808 Fax
>
>
>
>
> --
> Rob Krakora
> MessageNet Systems
> 101 East Carmel Dr. Suite 105
> Carmel, IN 46032
> (317)566-1677Ext 212
> (317)663-0808 Fax
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130729/18b3c477/attachment-0001.html>
More information about the gstreamer-devel
mailing list