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

Peter Rennert p.rennert at cs.ucl.ac.uk
Fri Aug 9 12:34:00 PDT 2013 

Hi Rob,

I think GstBuffers and GstMemory goes far beyond my knowledge about 
gstreamer. But if it would be a general error related to GstBuffer and 
GstMemory, would that not lead to other applications fail as well after 
some time?

But what you were saying is that you can insert as often as you want 
"fake" (but still valid) JPEG data into v4l2src and it will not crash? I 
did not even try yet to capture from the cam with v4l2. Did you try that?

I was also thinking to try to stream a video with v4l2sink and capture 
it using uvch264src (not sure if they are compatitble). Do you think 
that should crash as well? I am sorry its getting late here. I will try 
and do some experiments tomorrow on that.



On 08/09/2013 08:03 PM, Robert Krakora wrote:
> 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 
> <mailto: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 <mailto: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
>         <mailto:gstreamer-devel at lists.freedesktop.org>
>         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
>     <mailto: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 
> <mailto: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>
>
>
>
> _______________________________________________
> 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/20130809/dadb057c/attachment-0001.html>

More information about the gstreamer-devel mailing list