Occasional problems include udpsink returns a wrong source port and udpsrc receives no packets

[OUWenjun]

Hello everyone, I try to use MCU(MultiPoint Control Unit) architecture to
build a RTC(Real-Time Communication) system including client and server. The
pipeline design is like this:

1. *【PIPE-Push】* sending pipeline from client-side of Android:
my_ahcsrc(replace 'ahcsrc' from 'androidmedia')-> capsfilter -> videoconvert
-> my_h264_enc(replace 'x264enc') -> h264parse -> rtph264pay -> udpsink

2. *【PIPE-Pull】* receiving pipeline from client-side of Android:
udpsrc -> rtpbin -> ["pad-added"] -> rtph264depay -> h264parse ->
my_h264_dec(replace 'avdec_h264') -> glimagesink

3. *【PIPE-Forwarding】* forwarding pipeline from server-side
udpsrc -> [get udpsrc's source port from probe] -> udpsink -> [forwarding to
client]

Among them, 【PIPE-Push】 and 【PIPE-Pull】 are two independent pipelines, which
run in the same Android APP.
The flow of data can be simply understood as follows: 【PIPE-Push】->
【PIPE-Forwarding】-> 【PIPE-Pull】

Currently I have encountered two *occasional *problems related to the udp
plugin:

*Problem 1: The source port extracted from udpsink is not the same as the
port that tcpdump actually sends packets from.* The reproduction steps are
as follows:
    a. After I started the 【PIPE-Push】pipeline, I extracted GSocket of
udpsink through g_object_get ("used-socket")
    b. Call g_socket_get_local_address() to extract the GSocketAddress
object
    c. Call the macro G_INET_SOCKET_ADDRESS() to convert GSocketAddress to
GInetSocketAddress
    d. Call g_inet_socket_address_get_port() to get the source port of
udpsink
OK, now the problem comes: I rooted an Android machine, tried to use tcpdump
to capture packets, and found that the actual source port of tcpdump was not
the same port that udpsink told me.
I have to get the correct source port of udpsink from 【PIPE-Push】, and then
set the port number into udpsrc of 【PIPE-Pull】; otherwise 【PIPE-Forwarding】
would forward on a wrong port number.
Actually, udpsink provides "bind-port" capability, but the same problem
exists. The binding port is not consistent with what tcpdump sees.
This problem was found in the latest 1.16.0 Android Package on the GStreamer
official website. The probability of recurrence is about 10%.
    
*Problem 2: udpsrc cannot receive packets but tcpdump shows me that packets
has arrived.*
    a. Register a probe with type "ALL-BOTH" into the udpsrc of
【PIPE-Forward】, and check if packets arrived through log printing
    b. Start 【PIPE-Forwarding】 on server-side
    c. Start 【PIPE-Push】 on client-side, it would send RTP packets carrying
H.264 to 【PIPE-Forwarding】
    d. On the server-side, start tcpdump to capture packets; find that RTP
packets have been received from the client
    e. However, on the server-side，udpsrc's probe of 【PIPE-Forwarding】 don't
respond, which means that it pick up nothing.    
What puzzles me is: is udpsrc not receiving any packets at all? Or does it
receive packets but discard them




--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/