<div dir="ltr">I'm hoping someone has some thoughts on the code in my last post. Is there a better way to get the data from the buffer, and then pass it along? Inside the function called when the identity's handoff signal is fired I added the following lines of code to rule out the possibility that the data I'm reading is being partially overwritten while trying to read it:<div><br></div><div>newBuf = Gst.Buffer.copy_deep(buf)</div><div>memory = Gst.Buffer.get_all_memory(newBuf)</div><div><br></div><div>Then I send the data over a socket in the same way as in my last post.</div><div><br></div><div>Is it possible I'm reading data from memory I shouldn't? By which I mean should I be using the identity plugin's drop-buffer-flags property, and dropping buffers with the CORRUPTED flags, for example? Or would I be better off using a tee and then an appsink plugin, as was recommended as an alternative solution in a different post? Would that give me markedly different results?</div><div><br></div><div>Thanks!</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 6, 2017 at 12:48 PM, yun bao <span dir="ltr"><<a href="mailto:dayunbao@gmail.com" target="_blank">dayunbao@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks for the prompt reply! The jpegs that are saved to disk further down the pipeline are all fine. Would that indicate a problem somewhere in my code outside of Gstreamer?<div><br></div><div>Here's what I'm doing inside the function that's called when the identity's handoff signal is fired (keep in mind this is Python):</div><div><br></div><div>memory = Gst.Buffer.get_all_memory(buf)</div><div>(result, info) = Gst.memory.map(memory, Gst.MapFlahs.READ)</div><div>if result:</div><div> set up sockets...</div><div> sentTotal = 0</div><div> while sentTotal < info.size:</div><div> sent = self.connection.send(info.<wbr>data)</div><div> sentTotal += sent</div><div> Gst.Memory.unmap(memory, info)</div><div> close socket...</div><div><br></div><div>The process that's receiving the data, which is written in C++, is displaying the data as images with the following code:</div><div><br></div><div>read data over socket into buffer called data...</div><div>Mat bayer(720, 1280, CV_16U, data);</div><div>Mat converted;</div><div>cvtColor(bayer, converted, COLOR_BayerRG2RGB);</div><div>imshow("Socket Image", converted);</div><div>waitKey(0);</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Tue, Jun 6, 2017 at 11:46 AM, Nicolas Dufresne <span dir="ltr"><<a href="mailto:nicolas@ndufresne.ca" target="_blank">nicolas@ndufresne.ca</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><span>Le mardi 06 juin 2017 à 10:28 -0700, dayunbao a écrit :<br> > Here's the pipeline I'm using:<br> ><br> > v4l2src -> videorate -> queue -> identity -> jpegenc -> queue -> jifmux -><br> > multifilesink<br> ><br> > The pipeline is taking a picture once a second, and then does the following<br> > two things:<br> ><br> > 1) when the identity's handoff signal fires, it sends the data to another<br> > process (via a socket) for some processing of the image, and <br> ><br> > 2) also writes the images to disk as jpegs. <br> ><br> > The images that are written to disk are fine, but there seems to be an issue<br> > with the data being sent over the socket. I get images like the one below<br> > quite often. It seems that I'm not always getting all the data from the<br> > buffer (even though I'm verifying that the proper amount of data is being<br> > sent and received on both ends of the socket), although I'm not totally sure<br> > that's the issue. I'm using OpenCV to display the data sent over the socket<br> > as an image, by the way. In case you're wondering, what you're seeing in<br> > the top of the picture are two comics tacked to a wall. The colors are all<br> > out of wack, but I'm not too worried about that right now.<br> ><br> > I realize there are a lot of places where things could go wrong in my<br> > program, but I'm trying to narrow them down. Is there something I can do<br> > with my pipeline to make sure I'm getting all the data, and that it isn't<br> > being overwritten as I'm trying to read it? I recently added the first<br> <br> </span>To be honest, drivers should never produce a frame like this, or at<br> least should mark it as corrupted. Unless of course it's a bug in<br> libv4l2 (that you can try by rebuilding without that).<br> <br> As of today, you only last option would be to add a tee between v4l2src<br> and the queue. This will break the allocation query, and will ensure<br> v4l2src keep a certain amount of buffers in the driver and copy as<br> needed.<br> <span class="m_1062678796970808330HOEnZb"><font color="#888888"><br> Nicolas</font></span><br></div></div><span class="">______________________________<wbr>_________________<br> gstreamer-devel mailing list<br> <a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesk<wbr>top.org</a><br> <a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/gstreamer-dev<wbr>el</a><br> <br></span></blockquote></div><br></div> </blockquote></div><br></div>