Frame drop when playing RTP stream using SDP file

[Anuj Pahuja]

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
 with playing sdp file using sdpdemux still persists. Video tearing and
packet loss is still happening when playing using sdpdemux for a v4l2src.

On Wed, May 11, 2016 at 2:44 PM, Anuj Pahuja <kamikazeanuj at gmail.com> wrote:

>
> On Wed, May 11, 2016 at 1:54 PM, Sebastian Dröge <
> sebastian at centricular.com> wrote:
>
>> On Mi, 2016-05-11 at 13:09 +0530, Anuj Pahuja wrote:
>> > I tried using a V4L2 stream instead of a custom appsrc. I'm still
>> > facing the same issue (frame drop/video tearing) while using sdpdemux
>> > or rtpjitterbuffer with my receiver's pipeline. No issue when
>> > rtpjitterbuffer is not there. Here are the pipelines I'm using:
>> >
>> > Sender side:
>> > gst-launch-1.0 v4l2src device=/dev/video0 ! videoscale ! videoconvert
>> > ! video/x-raw, width=720, height=576, format=UYVY ! rtpvrawpay !
>> > udpsink host=239.192.1.6 port=5004 -v
>> >
>> > Receiver's side:
>> > gst-launch-1.0 udpsrc address=239.192.1.6 port=5004 ! "application/x-
>> > rtp, media=(string)video, clock-rate=(int)90000, encoding-
>> > name=(string)RAW, sampling=(string)YCbCr-4:2:2, depth=(string)8,
>> > width=(string)720, height=(string)576, colorimetry=(string)BT601-5,
>> > payload=(int)96" ! rtpjitterbuffer ! rtpvrawdepay ! videoconvert !
>> > autovideosink
>> >
>> > As you said, there must be a problem in the stream if it isn't
>> > working with rtpjitterbuffer. Could you suggest what might be the
>> > possible issues on the sender's side here?
>>
>> Can you also reproduce it with a videotestsrc, e.g. when using
>>   videotestsrc ! "video/x-raw,width=720,height=576" ! ...
>> ?
>>
>
> Yes, I can reproduce it with videotestsrc also.
>
>
>>
>> The logs you get with GST_DEBUG=3,rtpjitterbufer:6 might also be
>> useful.
>>
>
> I got a lot of debug messages after enabling that. Here's a bit of that:
>
> 0:00:05.729438230  6615      0x1f8e0a0 DEBUG        rtpjitterbuffer
> gstrtpjitterbuffer.c:3425:wait_next_timeout:<rtpjitterbuffer0> 357, 1,
> 33662, 0:00:01.626756110
> 0:00:05.729438230  6615      0x1f8e0a0 DEBUG        rtpjitterbuffer
> gstrtpjitterbuffer.c:3425:wait_next_timeout:<rtpjitterbuffer0> 358, 1,
> 33663, 0:00:01.626756357
> 0:00:05.729446434  6615      0x1f8e0a0 DEBUG        rtpjitterbuffer
> gstrtpjitterbuffer.c:3425:wait_next_timeout:<rtpjitterbuffer0> 359, 1,
> 33664, 0:00:01.626756604
> 0:00:05.729454907  6615      0x1f8e0a0 DEBUG        rtpjitterbuffer
> gstrtpjitterbuffer.c:3425:wait_next_timeout:<rtpjitterbuffer0> 360, 1,
> 33665, 0:00:01.626756851
> 0:00:05.729463187  6615      0x1f8e0a0 DEBUG        rtpjitterbuffer
> gstrtpjitterbuffer.c:3425:wait_next_timeout:<rtpjitterbuffer0> 361, 1,
> 33666, 0:00:01.626757098
> 0:00:05.729471554  6615      0x1f8e0a0 DEBUG        rtpjitterbuffer
> gstrtpjitterbuffer.c:3425:wait_next_timeout:<rtpjitterbuffer0> 362, 1,
> 33667, 0:00:01.626757345
> 0:00:05.729479770  6615      0x1f8e0a0 DEBUG        rtpjitterbuffer
> gstrtpjitterbuffer.c:3425:wait_next_timeout:<rtpjitterbuffer0> 363, 1,
> 33668, 0:00:01.626757592
> 0:00:05.729488141  6615      0x1f8e0a0 DEBUG        rtpjitterbuffer
> gstrtpjitterbuffer.c:3294:do_lost_timeout:<rtpjitterbuffer0> Packet #33656
> lost
> 0:00:05.729500432  6615      0x1f8e0a0 DEBUG        rtpjitterbuffer
> gstrtpjitterbuffer.c:1948:remove_timer:<rtpjitterbuffer0> removed index 351
> 0:00:05.729509156  6615      0x1f8e0a0 DEBUG        rtpjitterbuffer
> gstrtpjitterbuffer.c:3416:wait_next_timeout:<rtpjitterbuffer0> now
> 0:00:05.702634355
> 0:00:05.729517244  6615      0x1f8e0a0 DEBUG        rtpjitterbuffer
> gstrtpjitterbuffer.c:3425:wait_next_timeout:<rtpjitterbuffer0> 0, 1, 34019,
> 0:00:01.626844289
> 0:00:05.729525904  6615      0x1f8e0a0 DEBUG        rtpjitterbuffer
> gstrtpjitterbuffer.c:3450:wait_next_timeout:<rtpjitterbuffer0> new best 0
> 0:00:05.729532770  6615      0x1f8e0a0 DEBUG        rtpjitterbuffer
> gstrtpjitterbuffer.c:3425:wait_next_timeout:<rtpjitterbuffer0> 1, 1, 34018,
> 0:00:01.626844042
> 0:00:05.729541166  6615      0x1f8e0a0 DEBUG        rtpjitterbuffer
> gstrtpjitterbuffer.c:3450:wait_next_timeout:<rtpjitterbuffer0> new best 1
> 0:00:05.729547959  6615      0x1f8e0a0 DEBUG        rtpjitterbuffer
> gstrtpjitterbuffer.c:3425:wait_next_timeout:<rtpjitterbuffer0> 2, 1, 34017,
> 0:00:01.626843795
> 0:00:05.729556229  6615      0x1f8e0a0 DEBUG        rtpjitterbuffer
> gstrtpjitterbuffer.c:3450:wait_next_timeout:<rtpjitterbuffer0> new best 2
> 0:00:05.729563019  6615      0x1f8e0a0 DEBUG        rtpjitterbuffer
> gstrtpjitterbuffer.c:3425:wait_next_timeout:<rtpjitterbuffer0> 3, 1, 34016,
> 0:00:01.626843548
>
> I'm assuming it's losing some packets. Can some more sense be made out of
> the logs?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160511/efc7652f/attachment-0001.html>