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