[vlc-devel] [PATCH] live555: fix the subtitles issue
gilles.chanteperdrix at xenomai.org
Mon Dec 30 15:55:21 CET 2013
On 12/30/2013 03:48 PM, Rémi Denis-Courmont wrote:
> Le lundi 30 décembre 2013, 15:17:59 Gilles Chanteperdrix a écrit :
>>> RTP is completely different.
>> Well, if the client sends a packet on the server RTP port before the
>> server starts sending packet from its RTP port to the firewall port
>> where the original packet seemed to come from, the firewall will "see"
>> the RTP stream as an answer to this original packet. So, it is the same
>> thing. At least, for the first RTP packet.
> As a matter of facts, no.
> You will establish a NAT binding between a NAT port and the server RTP port of
> the server. The client does not know the NAT port, so it cannot put it into
> the SETUP request. In other words, this is nonsense.
> Unless of course, *both* the server and the client are extended in proprietary
> manner such that the server parses the incoming RTP packets and communicates
> the NAT port back to the client. But that would not fly; the VideoLAN and
> live555 projects do not command a large enough market share of RTSP servers.
I am going to try and explain again.
The client sends "dummy" packets after the SETUP and before the PLAY to
the server RTP ports. I mean right now. vlc does this, at least since
2.0 from Debian stable (you see, I am not even talking about bleeding
edge stuff). ffmpeg does this. The NAT port is simply the source port of
these packets when they are received on the server. What I do in my
server is, under special conditions, use this port instead of the
clients ports negotiated in the RTSP.
It is really not complicated, and it works, because it uses the way the
classical UDP NAT works.
More information about the vlc-devel