Frame drop when playing RTP stream using SDP file

[Anuj Pahuja]

>
> A plausible cause is that your sockets (udpsrc) have to small buffers
> to be able to hold on a frame, while this frame is being processed. You
> could try and increase the buffer-size property (it's by default 0,
> which is system default, you can also increase you system default if
> you prefer).
>
> For the non-v4l2src case, you probably have timestamp issues.
>

So I've tried most of the combinations now. I used a different machine as
the client this time, earlier I was streaming out and in from the same
machine, which doesn't work out correctly in case of multicast. I connected
just two of them to a Gigabit router via GIgabit ethernet cables to ensure
there's no packet loss due to network traffic. I used these pipelines on
the source machine -



*gst-launch-1.0 v4l2src device=/dev/video0 ! videoscale ! videoconvert !
video/x-raw, height=576, width=720, format=UYVY ! rtpvrawpay ! udpsink
host=224.1.1.1 port=5004*

*gst-launch-1.0 filesrc location=test_video.mp4 ! decodebin !  videoconvert
! videoscale ! video/x-raw, height=576, width=720, format=UYVY ! rtpvrawpay
! udpsink host=224.1.1.1 port=5004*
On the client machine, I played them using:



*gst-launch-1.0 udpsrc address=224.1.1.1 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" !
rtpvrawdepay ! videoconvert ! autovideosink*
(using rtpjitterbuffer also)


*gst-launch-1.0 udpsrc address=224.1.1.1 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*

*Results:*
1. When I don't use rtpjitterbuffer, there are no lacerations in the video
or video tearing, but the sink displays a still frame in 70% of the window,
and a continuous video stream on 30% of the sink window. I thought that was
a sink issue and tested it out on a custom appsink, which converts it to
RGB and renders it onto a Qt display. This improved the video a lot. I got
a continuous stream with minor data loss which is tolerable I think in case
of RTP/UDP, but I'm not entirely sure if even that should be there. This
was the best result that I got.

2. There is a lot of video tearing (maybe because of data loss) using
rtpjitterbuffer. It plays for some time but eventually stops the stream
completely.

3. Then I tried increasing buffer-size of udpsrc to 100, 1000, 50000 but
I'm getting green lines on most of the video.

Is there anything wrong in the pipelines I'm using? Is there a working
example of multicast send and receive using rtpvrawpay/depay or using sdp
file? Appreciate any help on this!

Thanks,
Anuj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160518/b0dd3ab2/attachment-0001.html>