Frame drop when playing RTP stream using SDP file

[Nicolas Dufresne]

I've looked into the payloader/depayload code, I'm not sure this is
done correctly. First part is on the payloader, my quick read tells me
it's splitting frames in 10 chunks rather then calculating the
appropriate divider from the MTU size. This means the sender may endup
producing large UDP packets that get split by the protocol. It also
produce burst. On the receiver side, the depayloader does not expose
it's latency. Unless the video frame fit into a single UDP packet, it's
impossible to reconstruct that frame without inducing latency. The
latency the number of chunk per frame - 1 (we usually round up to the
number of chunk so we give the display a little more time to react).
For the tearing and green bar at start, that would seem the result of
missing packets at start and drops. I think the depayloader should just
drop the packet until it gets the first line of the following frame. I
doubt it's doing that atm. You will still get green lines whenever a
packet was dropped, though drops should be rate if you get the burst
part fixed.
Please, file those bugs to bugs.gnome.org on GStreamer product and gst-
plugins-good component. Feel free to offer you own pathes by attaching
them to the created bugs.
regards,
Nicolas
Le mercredi 18 mai 2016 à 11:51 +0530, Anuj Pahuja a écrit :
> > 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
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160518/918a9da3/attachment-0001.html>