[uvch264src in 1.1.1.1] "Got data flow before segment event" warnings until crash
Robert Krakora
rob.krakora at messagenetsystems.com
Wed Aug 7 13:18:39 PDT 2013
Hi Peter,
I put the JPEG parse code that is in uvch264src in to v4l2src dequeue
buffer routine and it flagged the same error there parsing the data from
the freshly dequeued buffer.
0:00:34.776916339 9598 0xb4d540 LOG v4l2
gstv4l2bufferpool.c:621:gst_v4l2_object_poll:<v4l2src0> polling device
0:00:34.801286611 9598 0xb4d540 LOG v4l2
gstv4l2bufferpool.c:733:gst_v4l2_buffer_pool_dqbuf:<v4l2bufferpool0> doing
DQBUF
0:00:34.801318859 9598 0xb4d540 LOG v4l2
gstv4l2bufferpool.c:754:gst_v4l2_buffer_pool_dqbuf:<v4l2bufferpool0>
dequeued buffer 0x7fe93c008280 seq:1031 (ix=2), used 219467, flags
00000005, ts 0:54:59.618217000, pool-queued=3, buffer=0x7fe93c008280
0:00:34.801340586 9598 0xb4d540 DEBUG v4l2
gstv4l2bufferpool.c:797:gst_v4l2_buffer_pool_dqbuf:<v4l2bufferpool0> Found
APP4 marker (12766). JPG: 0-8 - APP4: 8 - 12776
0:00:34.801349031 9598 0xb4d540 DEBUG v4l2
gstv4l2bufferpool.c:837:gst_v4l2_buffer_pool_dqbuf:<v4l2bufferpool0> New
auxiliary stream : v1 - 22 bytes - H264 1920x1080 -- 333333 *100ns -- 27 ms
-- -716306112
0:00:34.801360256 9598 0xb4d540 DEBUG v4l2
gstv4l2bufferpool.c:839:gst_v4l2_buffer_pool_dqbuf:<v4l2bufferpool0>
Auxiliary stream size : 12738 bytes
0:00:34.801366732 9598 0xb4d540 DEBUG v4l2
gstv4l2bufferpool.c:797:gst_v4l2_buffer_pool_dqbuf:<v4l2bufferpool0> Found
APP4 marker (65533). JPG: 12776-12776 - APP4: 12776 - 78311
0:00:34.801378826 9598 0xb4d540 DEBUG v4l2
gstv4l2bufferpool.c:837:gst_v4l2_buffer_pool_dqbuf:<v4l2bufferpool0> New
auxiliary stream : v1 - 22 bytes - YUY2 432x240 -- 333333 *100ns -- 27 ms
-- -716306112
0:00:34.801388493 9598 0xb4d540 DEBUG v4l2
gstv4l2bufferpool.c:839:gst_v4l2_buffer_pool_dqbuf:<v4l2bufferpool0>
Auxiliary stream size : 207360 bytes
0:00:34.801394528 9598 0xb4d540 DEBUG v4l2
gstv4l2bufferpool.c:797:gst_v4l2_buffer_pool_dqbuf:<v4l2bufferpool0> Found
APP4 marker (65533). JPG: 78311-78311 - APP4: 78311 - 143846
0:00:34.801402057 9598 0xb4d540 DEBUG v4l2
gstv4l2bufferpool.c:797:gst_v4l2_buffer_pool_dqbuf:<v4l2bufferpool0> Found
APP4 marker (65533). JPG: 143846-143846 - APP4: 143846 - 209381
0:00:34.801409449 9598 0xb4d540 DEBUG v4l2
gstv4l2bufferpool.c:797:gst_v4l2_buffer_pool_dqbuf:<v4l2bufferpool0> Found
APP4 marker (10795). JPG: 209381-209381 - APP4: 209381 - 220178
0:00:34.801418067 9598 0xb4d540 WARN v4l2
gstv4l2bufferpool.c:801:gst_v4l2_buffer_pool_dqbuf:<v4l2bufferpool0> error:
Not enough data to read marker content
Best Regards,
Rob
On Thu, Aug 1, 2013 at 10:42 AM, Robert Krakora <
rob.krakora at messagenetsystems.com> wrote:
> Hi Peter,
>
> The HEAD failed after a few hours of continuous running, so it is no
> better. Running the same test with the HEAD of GSteamer 0.10 does not
> yield this error and can run indefinitely.
>
> Best Regards,
>
> Rob
>
>
>
> On Thu, Aug 1, 2013 at 10:24 AM, Peter Rennert <p.rennert at cs.ucl.ac.uk>wrote:
>
>> Hi Rob,
>>
>> I did not have time to run it before yesterday. Now I tried it last night
>> and it crashed after about 12.5h with the error you reported as well
>> (Incomplete auxiliary stream).
>>
>> How is it going with the git HEAD?
>>
>> ERROR: from element
>> /GstPipeline:pipeline0/GstUvcH264Src:src/GstUvcH264MjpgDemux:uvch264mjpgdemux0:
>> Incomplete auxiliary stream. 65531 bytes missing
>> Additional debug info:
>> gstuvch264_mjpgdemux.c(686): gst_uvc_h264_mjpg_demux_chain ():
>> /GstPipeline:pipeline0/GstUvcH264Src:src/GstUvcH264MjpgDemux:uvch264mjpgdemux0
>> Execution ended after 12:32:37.319528506
>>
>>
>>
>> On 07/29/2013 05:22 PM, Robert Krakora wrote:
>>
>> Hi Peter,
>>
>> Sounds good. I will check in tomorrow morning with results.
>>
>> Best Regards,
>>
>> Rob
>>
>>
>>
>> On Mon, Jul 29, 2013 at 11:51 AM, Peter Rennert <p.rennert at cs.ucl.ac.uk>wrote:
>>
>>> Good to know.
>>>
>>> I will let it run for some hours today, but I will have to restart to
>>> give a presentation tomorrow. I will make some thorough test after. I will
>>> not pull from the repository for the moment. If we get different results,
>>> we have a starting point to look for. But anyway I think I am quite close
>>> to the HEAD, as I pulled about two weeks ago.
>>>
>>> Just for the record,
>>>
>>> I am working at the moment with (applies to the patch previously posted):
>>>
>>> gstreamer:
>>> commit f8fdb61b02cbcfc6f6bbc136ada329db128dab3f
>>> Author: Sebastian Dröge <slomo at circular-chaos.org><slomo at circular-chaos.org>
>>> Date: Thu Jul 11 16:57:06 2013 +0200
>>>
>>>
>>> gst-plugins-base:
>>> commit 9ab6ab42572a28e447f761485c457f2a71eabb86
>>> Author: Sebastian Dröge <slomo at circular-chaos.org><slomo at circular-chaos.org>
>>> Date: Wed Jul 10 17:16:14 2013 +0200
>>>
>>>
>>> gst-plugins-good:
>>> commit d57ef52cadd51643dfc812779dac444bf3d9eaae
>>> Author: Andoni Morales Alastruey <ylatuya at gmail.com> <ylatuya at gmail.com>
>>> Date: Tue Jul 9 15:34:04 2013 +0200
>>>
>>>
>>> gst-plugins-bad:
>>> commit f83e9405ded5b062841f5b6d83864d4221304866
>>> Author: Sebastian Dröge <slomo at circular-chaos.org><slomo at circular-chaos.org>
>>> Date: Wed Jul 10 12:28:38 2013 +0200
>>>
>>>
>>>
>>>
>>> On 07/29/2013 04:29 PM, Robert Krakora wrote:
>>>
>>> Hi Peter,
>>>
>>> After 8-24 hours of continuous running I have noticed an error
>>> indicating no "enough data to read auxiliary data" or something to that
>>> effect. I was instructed to get the Git tip of gstreamer and
>>> gst-plugins-base and re-run my test which I am doing right now.
>>>
>>> Best Regards,
>>>
>>> Rob
>>>
>>>
>>>
>>> On Mon, Jul 29, 2013 at 10:49 AM, Peter Rennert <p.rennert at cs.ucl.ac.uk>wrote:
>>>
>>>> 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> 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
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>> _______________________________________________
>> 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,
Senior Software Engineer
MessageNet Systems
101 E Carmel Dr, Suite 105
Carmel, IN 46032
MessageNetSystems.com<http://www.messagenetcommunicationsystems.com/?utm_source=email+signature&utm_medium=email&utm_campaign=email+signature+to+homepage>
Rob.Krakora at MessageNetSystems.com <rob.krakora at messagenetsystems.com>
P: 317.566.1677, 212
F: 317.663.0808
For the latest news, information, and blogs, please be sure to visit,
follow, and like us...
<http://www.messagenetcommunicationsystems.com/get-the-message-out-blog/?utm_source=email+signature&utm_medium=email&utm_campaign=gmail+signature+to+blog>
<http://www.youtube.com/user/MessageNetConnection/feed>
<http://www.linkedin.com/company/messagenet-systems>
<http://twitter.com/MessageNet> <http://www.facebook.com/MessageNetsystems>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130807/7dab608f/attachment-0001.html>
More information about the gstreamer-devel
mailing list