[uvch264src in 1.1.1.1] "Got data flow before segment event" warnings until crash

Fri Aug 9 12:03:13 PDT 2013

Hi Peter,

I further modified v4l2src to pass a static dummy array (instead of the
real memory) wrapped in the GstBuffer with a pointer to the real memory (as
usual) in the meta data of the GstBuffer.  When the GstBuffer arrived at
uvch264src I pluck the real pointer out of the meta data in the chain
function and the JPEG parsing is not failing.  I really, really think that
there is an issue with GstBuffer and/or GstMemory corrupting memory.

Best Regards,

Rob

On Fri, Aug 9, 2013 at 9:15 AM, Robert Krakora <
rob.krakora at messagenetsystems.com> wrote:

> Hi Peter,
>
> I placed the JPEG parse code in the UVC driver, v4l2src and uvch264src
> plugins.  The JPEG parse code did not fail in the UVC driver but it did in
> the v4l2src and uvch264src plugins.  In the v4l2src plugin I noticed that a
> pointer to the memory mapped form kernel space was not only wrapped in a
> GstBuffer but also placed in it's meta data.  I then used the pointer that
> was placed in the meta data as the pointer acted on by the JPEG parse code
> and then the JPEG parse code in the v4l2src plugin no longer failed (i.e. I
> removed the gst_buffer_map() and gst_buffer_unmap() calls from around the
> JPEG parse code in v4l2src and just used the pointer from the meta data of
> the GstBuffer).  I am thinking that there is a bug or bugs in the GstMemory
> class where memory is being merged, moved and replaced that results in
> memory corruption.  I compared UVC driver logs from the JPEG parse code and
> uvch264src plugin logs from the JPEG parse code and everything jives
> segment size wise in regard to the first segment encountered in the buffer
> until the failure where the sizes of the first segments in both logs do not
> match each other.
>
> Best Regards,
>
> Rob
>
>
>
> On Fri, Aug 9, 2013 at 7:45 AM, Peter Rennert <p.rennert at cs.ucl.ac.uk>wrote:
>
>> Hi Rob,
>>
>> Is there a way for you to print both buffers (uvch264src and UVC Driver)
>> out and compare them?
>>
>> Maybe the v4l2src inserts some kind of metadata in the buffer at some
>> time stamps. Or maybe just modifies somehow the two bytes after the first
>> 0xff 0xe4.
>>
>> If that is the case then this line (gst_uvc_h264_mjpg_demux_**chain:
>> 498):
>>
>>       segment_size = GUINT16_FROM_BE (*((guint16 *) (info.data + i + 2)));
>>
>>
>> will set the segment_size wrong.
>>
>> However, I compared your first segment size with the one I've got earlier
>> (email from the 25/07). They are different. So whatever those bytes are
>> they are not static. It just pops into my mind that perhaps the v4l2
>> swallows first bytes of the stream. In this case the 0xff 0xe4 that the
>> uvch264src detects are actually image data rather than part of the metadata.
>>
>> What puzzles me as well is that the first segment size is parsed wrong
>> and still it fails at the last segment. Which is weird. I would expect that
>> if it gets a too large first segment it will parse/copy too much of the
>> buffer as the first segment. The result should be that it would not be able
>> to find (i.e. skip) the second APP4 marker, including its segment size tag
>> and continue with the third one. This is because i in the loop is
>> incremented with the segment_size to avoid looping through the entire
>> buffer in order to find the APP4 markers (line 648).
>>
>> Peter
>>
>> ______________________________**_________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.**freedesktop.org<gstreamer-devel at lists.freedesktop.org>
>> http://lists.freedesktop.org/**mailman/listinfo/gstreamer-**devel<http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel>
>>
>
>
>
> --
>
> 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>
>

-- 

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/20130809/4f8f97dd/attachment.html>