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

[Robert Krakora]

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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130809/9b475d6d/attachment.html>