[Bug 675444] New: UDP multicast packet loss

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=675444
  GStreamer | gst-plugins-good | 0.10.36

           Summary: UDP multicast packet loss
    Classification: Platform
           Product: GStreamer
           Version: 0.10.36
        OS/Version: Windows
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: mariagiovanna.chiossa at selexelsag.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


I have noticed that playing many instances of a rtsp/rtp multicast video from a
same source,
some streams lose packets that others receive.
This happens both playing from the same process or using separated processes,
so you can verify this behaviour starting this pipeline:

gst-launch-0.10 rtspsrc location=rtsp://... udp-buffer-size=524288 ! queue !
rtph264depay ! ffdec_h264 ! d3dvideosink

On average, playing 25 instances for 20’ I have 220 packets lost.

I attached a log with jitterbuffer and udpsrc debug enabled;
in gst_udpsrc_create I added the sequence number log after having performed the
recvfrom call, I added also a log when 
the ioctlsocket after the select fails (see the attached log for mode details).

You can see that sometime some udpsrc instances lose a packet that other udpsrc
instances receive.
For instance, at line 3059, udpsrc12 lost packet #294 that was received from
other udpsrc instances before that line and after that line
If we check the history of udpsrc12, we see that at line 3050 it received
packet #293 (it read all 1414 bytes available),
but the next recvfrom receives packet #295.
We can verify that between the two read it got error on ioctlsocket.

I guess that calling ioctlsocket after the select leads to some strange
behaviour on socket.
(indeed there are 2 calls of ioctlsocket, but seems that only the second, after
the select, give troubles)

I tried to remove it allocating a fixed 64k buffer: after the select I call
directly the recvfrom,
that sometimes fails with WSAEWOULDBLOCK error. I manage this error going to
"retry" and the next recvfrom succedes. 
This way, playing 25 instances for 50’ I've lost no packets.

Maybe it is not the better solution, but I'm attaching it anyway if you want to
take a look at it.
Thank you

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.