<div dir="ltr"><div>I tried v4l2src once again with rtpjitterbuffer and it seems to work better now. I'm not sure why it wasn't working before. But the problem<br></div> with playing sdp file using sdpdemux still persists. Video tearing and packet loss is still happening when playing using sdpdemux for a v4l2src. <br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 11, 2016 at 2:44 PM, Anuj Pahuja <span dir="ltr"><<a href="mailto:kamikazeanuj@gmail.com" target="_blank">kamikazeanuj@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"><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Wed, May 11, 2016 at 1:54 PM, Sebastian Dröge <span dir="ltr"><<a href="mailto:sebastian@centricular.com" target="_blank">sebastian@centricular.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On Mi, 2016-05-11 at 13:09 +0530, Anuj Pahuja wrote:<br>
> I tried using a V4L2 stream instead of a custom appsrc. I'm still<br>
> facing the same issue (frame drop/video tearing) while using sdpdemux<br>
> or rtpjitterbuffer with my receiver's pipeline. No issue when<br>
> rtpjitterbuffer is not there. Here are the pipelines I'm using:<br>
><br>
> Sender side:<br>
> gst-launch-1.0 v4l2src device=/dev/video0 ! videoscale ! videoconvert<br>
> ! video/x-raw, width=720, height=576, format=UYVY ! rtpvrawpay !<br>
> udpsink host=239.192.1.6 port=5004 -v<br>
><br>
> Receiver's side:<br>
</span>> gst-launch-1.0 udpsrc address=239.192.1.6 port=5004 ! "application/x-<br>
> rtp, media=(string)video, clock-rate=(int)90000, encoding-<br>
<span>> name=(string)RAW, sampling=(string)YCbCr-4:2:2, depth=(string)8,<br>
> width=(string)720, height=(string)576, colorimetry=(string)BT601-5,<br>
> payload=(int)96" ! rtpjitterbuffer ! rtpvrawdepay ! videoconvert !<br>
> autovideosink<br>
><br>
> As you said, there must be a problem in the stream if it isn't<br>
> working with rtpjitterbuffer. Could you suggest what might be the<br>
> possible issues on the sender's side here?<br>
<br>
</span>Can you also reproduce it with a videotestsrc, e.g. when using<br>
  videotestsrc ! "video/x-raw,width=720,height=576" ! ...<br>
?<br></blockquote><div><br></div></span><div>Yes, I can reproduce it with videotestsrc also.<br> </div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The logs you get with GST_DEBUG=3,rtpjitterbufer:6 might also be<br>
useful.<br></blockquote><div><br></div></span><div>I got a lot of debug messages after enabling that. Here's a bit of that:<br><br>0:00:05.729438230  6615      0x1f8e0a0 DEBUG        rtpjitterbuffer gstrtpjitterbuffer.c:3425:wait_next_timeout:<rtpjitterbuffer0> 357, 1, 33662, 0:00:01.626756110<br>0:00:05.729438230  6615      0x1f8e0a0 DEBUG        rtpjitterbuffer gstrtpjitterbuffer.c:3425:wait_next_timeout:<rtpjitterbuffer0> 358, 1, 33663, 0:00:01.626756357<br>0:00:05.729446434  6615      0x1f8e0a0 DEBUG        rtpjitterbuffer gstrtpjitterbuffer.c:3425:wait_next_timeout:<rtpjitterbuffer0> 359, 1, 33664, 0:00:01.626756604<br>0:00:05.729454907  6615      0x1f8e0a0 DEBUG        rtpjitterbuffer gstrtpjitterbuffer.c:3425:wait_next_timeout:<rtpjitterbuffer0> 360, 1, 33665, 0:00:01.626756851<br>0:00:05.729463187  6615      0x1f8e0a0 DEBUG        rtpjitterbuffer gstrtpjitterbuffer.c:3425:wait_next_timeout:<rtpjitterbuffer0> 361, 1, 33666, 0:00:01.626757098<br>0:00:05.729471554  6615      0x1f8e0a0 DEBUG        rtpjitterbuffer gstrtpjitterbuffer.c:3425:wait_next_timeout:<rtpjitterbuffer0> 362, 1, 33667, 0:00:01.626757345<br>0:00:05.729479770  6615      0x1f8e0a0 DEBUG        rtpjitterbuffer gstrtpjitterbuffer.c:3425:wait_next_timeout:<rtpjitterbuffer0> 363, 1, 33668, 0:00:01.626757592<br>0:00:05.729488141  6615      0x1f8e0a0 DEBUG        rtpjitterbuffer gstrtpjitterbuffer.c:3294:do_lost_timeout:<rtpjitterbuffer0> Packet #33656 lost<br>0:00:05.729500432  6615      0x1f8e0a0 DEBUG        rtpjitterbuffer gstrtpjitterbuffer.c:1948:remove_timer:<rtpjitterbuffer0> removed index 351<br>0:00:05.729509156  6615      0x1f8e0a0 DEBUG        rtpjitterbuffer gstrtpjitterbuffer.c:3416:wait_next_timeout:<rtpjitterbuffer0> now 0:00:05.702634355<br>0:00:05.729517244  6615      0x1f8e0a0 DEBUG        rtpjitterbuffer gstrtpjitterbuffer.c:3425:wait_next_timeout:<rtpjitterbuffer0> 0, 1, 34019, 0:00:01.626844289<br>0:00:05.729525904  6615      0x1f8e0a0 DEBUG        rtpjitterbuffer gstrtpjitterbuffer.c:3450:wait_next_timeout:<rtpjitterbuffer0> new best 0<br>0:00:05.729532770  6615      0x1f8e0a0 DEBUG        rtpjitterbuffer gstrtpjitterbuffer.c:3425:wait_next_timeout:<rtpjitterbuffer0> 1, 1, 34018, 0:00:01.626844042<br>0:00:05.729541166  6615      0x1f8e0a0 DEBUG        rtpjitterbuffer gstrtpjitterbuffer.c:3450:wait_next_timeout:<rtpjitterbuffer0> new best 1<br>0:00:05.729547959  6615      0x1f8e0a0 DEBUG        rtpjitterbuffer gstrtpjitterbuffer.c:3425:wait_next_timeout:<rtpjitterbuffer0> 2, 1, 34017, 0:00:01.626843795<br>0:00:05.729556229  6615      0x1f8e0a0 DEBUG        rtpjitterbuffer gstrtpjitterbuffer.c:3450:wait_next_timeout:<rtpjitterbuffer0> new best 2<br>0:00:05.729563019  6615      0x1f8e0a0 DEBUG        rtpjitterbuffer gstrtpjitterbuffer.c:3425:wait_next_timeout:<rtpjitterbuffer0> 3, 1, 34016, 0:00:01.626843548<br><br></div><div>I'm assuming it's losing some packets. Can some more sense be made out of the logs? <br></div></div><br></div></div>
</blockquote></div><br></div>