[Live-devel] ffprobe over UDP gets 461 from testOnDemandRTSPServer (2026.10.29)

[MANDJUKOWSKI Esteban]

Hello Paul,

I can not stream RTSP over UDP using ffplay as a client either. I had tested a month ago, did not manage to make it work and assumed it was an issue from ffmpeg's RTSP client.
Now, I am not so sure. The issue indeed seems to come from Live555 source code.

According to https://www.rfc-editor.org/rfc/rfc2326.html#page-58 , 

> The syntax for the transport specifier is

>       transport/profile/lower-transport.

> The default value for the "lower-transport" parameters is specific to the profile. For RTP/AVP, the default is UDP.


In ffmpeg's source code, they always send the transport-spec as defined by RFC 2326 : 

> transport-spec      =    transport-protocol/profile[/lower-transport]

and ffmpeg does (if I did not get lost in their code) https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/rtspdec.c#L352C1-L357C33 :  

>         snprintf(responseheaders, sizeof(responseheaders), "Transport: "
> 		 "RTP/AVP/UDP;unicast;mode=record;source=%s;"
                 "client_port=%d-%d;server_port=%d-%d\r\n",
                 host, request.transports[0].client_port_min,
                 request.transports[0].client_port_max, localport,
                 localport + 1);

So the "/UDP" part is always sent by ffmpeg, which should not be a problem because it seems allowed (and I do not see any reason why it would not, unless I misunderstood the RFC).

But in Live555, again if I am not mistaken, in "RTSPServer::parseTransportHeader()", in the while loop : 

> else if (strcmp(field, "RTP/AVP") == 0 || strcmp(field, "RTP/SAVP") == 0) {
>      if (streamingMode != UNKNOWN) break; // more than one 'streaming mode' is not allowed
>	}

It looks like "RTP/AVP/UDP" can NOT be accepted, even though it should.

I added "|| strcmp(field, "RTP/AVP/UDP") == 0" in the "if" block to test it, and adding this simple addition makes ffplay play the file without any issue.

As it is a modification of Live555's library source code, if what I said is true, we would need a new release in order to fix this issue. (or you could subclass the RTSPServer, but this issue seems to arise from an oversight in the library code, so I would wait on Ross's input to get more informations)

Best regards, 
MANDJUKOWSKI Esteban