<div dir="ltr"><div>Thanks Nicolas for your reply.<br></div>I will take a look at your suggestions.<br><br>Thanks again!!!!<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 8, 2014 at 5:31 PM, Nicolas Dufresne <span dir="ltr"><<a href="mailto:nicolas.dufresne@collabora.com" target="_blank">nicolas.dufresne@collabora.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le vendredi 08 août 2014 à 17:22 +0100, anno domini a écrit :<br>
<div class="">> gst-launch v4l2src device=/dev/video1 norm=PAL ! ffmpegcolorspace !<br>
> pngenc snapshot=true ! filesink location=screenshot.png; shotwell<br>
> screenshot.png<br>
><br>
><br>
> I've also tried:<br>
><br>
> gst-launch v4l2src device=/dev/video1 norm=PAL num-buffers=1 !<br>
> ffmpegcolorspace ! jpegenc ! filesink location=screenshot.jpeg<br>
<br>
</div>Can't offer you a "this is the answer", but I have a guess, that would<br>
imply a buggy driver. It is likely that the driver miss-behave if you<br>
are not reading frames fast enough (hence the visual corruption). Try<br>
for this adding a queue after the v4l2src. It may improve, but it won't<br>
fix the problem entirely. My recommendation would be, make sure your<br>
kernel and driver is up to date, switch to GStreamer 1.4, and add debug<br>
traces if not already in the kernel driver to figure-out what is being<br>
triggered when the corruption is visible. Finally, you can enabled<br>
traces in GStreamer with environment GST_DEBUG="v4l2*:7".<br>
<span class="HOEnZb"><font color="#888888"><br>
Nicolas<br>
<br>
</font></span><br>_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
<br></blockquote></div><br></div>