[uvch264src in 1.1.1.1] "Got data flow before segment event" warnings until crash
Robert Krakora
rob.krakora at messagenetsystems.com
Fri Jul 26 13:10:11 PDT 2013
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> 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> 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> 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> 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> 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
>>>>> > 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> 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> 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> 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> 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> 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 x2 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> 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 - 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
>>>>>>>>>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Rob Krakora
>>>>>>>>>>> MessageNet Systems
>>>>>>>>>>> 101 East Carmel Dr. Suite 105
>>>>>>>>>>> Carmel, IN 46032
>>>>>>>>>>> (317)566-1677 Ext 212
>>>>>>>>>>> (317)663-0808 Fax
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Rob Krakora
>>>>>>>>>> MessageNet Systems
>>>>>>>>>> 101 East Carmel Dr. Suite 105
>>>>>>>>>> Carmel, IN 46032
>>>>>>>>>> (317)566-1677 Ext 212
>>>>>>>>>> (317)663-0808 Fax
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Rob Krakora
>>>>>>>>> MessageNet Systems
>>>>>>>>> 101 East Carmel Dr. Suite 105
>>>>>>>>> Carmel, IN 46032
>>>>>>>>> (317)566-1677 Ext 212
>>>>>>>>> (317)663-0808 Fax
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Rob Krakora
>>>>>>>> MessageNet Systems
>>>>>>>> 101 East Carmel Dr. Suite 105
>>>>>>>> Carmel, IN 46032
>>>>>>>> (317)566-1677 Ext 212
>>>>>>>> (317)663-0808 Fax
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> gstreamer-devel mailing listgstreamer-devel at lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> gstreamer-devel mailing listgstreamer-devel at lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> gstreamer-devel mailing list
>>>>>>>> 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-1677 Ext 212
>>>>>>> (317)663-0808 Fax
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Rob Krakora
>>>>>> MessageNet Systems
>>>>>> 101 East Carmel Dr. Suite 105
>>>>>> Carmel, IN 46032
>>>>>> (317)566-1677 Ext 212
>>>>>> (317)663-0808 Fax
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> gstreamer-devel mailing listgstreamer-devel at lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> gstreamer-devel mailing list
>>>>>> 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-1677 Ext 212
>>>>> (317)663-0808 Fax
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Rob Krakora
>>>> MessageNet Systems
>>>> 101 East Carmel Dr. Suite 105
>>>> Carmel, IN 46032
>>>> (317)566-1677 Ext 212
>>>> (317)663-0808 Fax
>>>>
>>>
>>>
>>>
>>> --
>>> Rob Krakora
>>> MessageNet Systems
>>> 101 East Carmel Dr. Suite 105
>>> Carmel, IN 46032
>>> (317)566-1677 Ext 212
>>> (317)663-0808 Fax
>>>
>>
>>
>>
>> --
>> Rob Krakora
>> MessageNet Systems
>> 101 East Carmel Dr. Suite 105
>> Carmel, IN 46032
>> (317)566-1677 Ext 212
>> (317)663-0808 Fax
>>
>
>
>
> --
> Rob Krakora
> MessageNet Systems
> 101 East Carmel Dr. Suite 105
> Carmel, IN 46032
> (317)566-1677 Ext 212
> (317)663-0808 Fax
>
--
Rob Krakora
MessageNet Systems
101 East Carmel Dr. Suite 105
Carmel, IN 46032
(317)566-1677 Ext 212
(317)663-0808 Fax
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130726/3bfbb4cd/attachment-0001.html>
More information about the gstreamer-devel
mailing list