[FFmpeg-devel] [PATCH] libavformat/rtsp: fix rtsp multicasts

Wolfgang Haupt haupt.wolfgang at gmail.com
Mon Apr 20 14:39:50 EEST 2020 

On 20.04.20 10:52, Wolfgang Haupt wrote:
> On 20.04.20 10:08, Marton Balint wrote:
>>
>>
>> On Mon, 20 Apr 2020, Wolfgang Haupt wrote:
>>
>>> On 19.04.20 23:43, Marton Balint wrote:
>>>>
>>>>
>>>> On Sun, 19 Apr 2020, Wolfgang Haupt wrote:
>>>>
>>>>> On 19.04.20 14:53, Marton Balint wrote:
>>>>>>
>>>>>>
>>>>>> On Sun, 19 Apr 2020, Wolfgang Haupt wrote:
>>>>>>
>>>>>>> ping
>>>>>>>
>>>>>>> On 03.04.20 08:42, Wolfgang Haupt wrote:
>>>>>>>> Hey,
>>>>>>>>
>>>>>>>> is someone up to review this patch?
>>>>>>>>
>>>>>>>> It's an attempt to fix rtsp streams that use udp multicasts as 
>>>>>>>> the underlying
>>>>>>>> transmission protocol.
>>>>>>>> The idea was taken from live555 as the said stream worked in VLC.
>>>>>>>>
>>>>>>>> It still applies cleanly on current master.
>>>>>>>>
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>> Wolfgang
>>>>>>>>
>>>>>>>> On 18.10.19 18:59, Wolfgang Haupt wrote:
>>>>>>>>> If an rtsp server offers a udp multicast
>>>>>>>>> address as response of a DESCRIBE command
>>>>>>>>> the rtsp client is expected to issue
>>>>>>>>> SETUP with "Transport: RTP/AVP/UDP;multicast".
>>>>>>>>> Some rtsp servers bail out otherwise.
>>>>>>>>> ---
>>>>>>>>>   libavformat/rtsp.c | 3 +++
>>>>>>>>>   1 file changed, 3 insertions(+)
>>>>>>>>>
>>>>>>>>> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
>>>>>>>>> index 859defa592..3f0cbfc98b 100644
>>>>>>>>> --- a/libavformat/rtsp.c
>>>>>>>>> +++ b/libavformat/rtsp.c
>>>>>>>>> @@ -1913,6 +1913,9 @@ redirect:
>>>>>>>>>                   && (rt->rtsp_flags & RTSP_FLAG_PREFER_TCP))
>>>>>>>>>               lower_transport = RTSP_LOWER_TRANSPORT_TCP;
>>>>>>>>>   +        if (ff_is_multicast_address((struct 
>>>>>>>>> sockaddr*)&rt->rtsp_streams[rt->nb_rtsp_streams-1]->sdp_ip))
>>>>>>>>> +            lower_transport = 
>>>>>>>>> RTSP_LOWER_TRANSPORT_UDP_MULTICAST;
>>>>>>>>> +
>>>>>>
>>>>>> Shouldn't this take into account lower_transport_mask? E.g. it 
>>>>>> should only prefer multicast if it is allowed in the mask?
>>>>>
>>>>> Can you explain what the lower_transport_mask is about?
>>>>> I cannot think of any case where you wouldn't want use udp 
>>>>> multicast when the rtsp server gives you a mutlicast-ip
>>>>> in response to a DESCRIBE request.
>>>>
>>>> I am not familiar with the code, but it looks like it is used to 
>>>> control the allowed (tried) transport methods. The rtsp protocol 
>>>> has an rtsp_transport option, that is the source of the mask:
>>>> https://www.ffmpeg.org/ffmpeg-all.html#rtsp
>>>> If UDP multicast transport is disallowed because it is not in the 
>>>> mask then you should not set it as far as I see.
>>>
>>> Mhm, yeah that's actually the problem I tried to fix.
>>> Reading the docs again, I'm not sure if I missed it before, but the 
>>> docs are stating:
>>> Multiple lower transport protocols may be specified, in that case 
>>> they are tried one at a time (if the setup of one fails, the next 
>>> one is tried). For the muxer, only the ‘tcp’ and ‘udp’ options are 
>>> supported.
>>
>> Are you fixing the muxer or the demuxer? So are you reading via 
>> multicast or generating multicast?
> I'm trying to fix the demuxer, so I'm reading a multicast udp stream 
> from an IP camera.
>>
>>> However I still cannot manage to get udp + udp_multicast into the 
>>> lower_transport_mask on the commandline, so I'm still not sure 
>>> how/if it's possible to really set multiple protocols.
>>
>> Why not? Isn't it just specifying -rtsp_transport +udp+udp_multicast ?
> I tried various separators like blank, comma, colon - now I gave your 
> version a try, but it still fails.
>
> ./ffprobe -rtsp_transport +udp+udp_multicast -i 
> rtsp://172.17.1.131/stream1m
>
> [rtsp @ 0x55be51d7c600] Nonmatching transport in server reply
> rtsp://172.17.1.131/stream1m: Invalid data found when processing input
>
> While writing this reply, I did some more debugging:
> Your version of the commandline successfully changes the value of the 
> lower_transport_mask but it still just fails to probe - I'll dig into 
> why it's not working as expected and come back with
> my conclusions.
Alright, thanks to your comments I think I now fully understand the code.
All of your remarks are right, I printed the value of 
lower_transport_mask and see that it's 7 by default and 5 for 
udp+udp_multicast, etc.

The RTSP-Server of that camera, does never return "status_code == 461", 
instead it just answers with
"[rtsp @ 0x55971cf77e80] line='Transport: 
RTP/AVP;multicast;source=172.17.1.131;destination=239.17.1.131;port=6780-6781;ttl=10;'"
no matter what protocol I request.

This results in ff_rtsp_make_setup_request returning AVERROR_INVALIDDATA 
instead of 1 and the mechanism to retry the next protocol doesn't get 
fired, instead ffmpeg bails out immediately.
Probably the camera is violating the RFC (honestly I don't know the RFC 
good enough) and I cannot upstream this patch :(
Big thanks for the review, though.

>
>>
>>> Therefore my patch always adds "udp_multicast" as lower_transport no 
>>> matter what the lower_transport_mask is as soon as the DESCRIBE 
>>> response returns a multicast IP, because
>>> clients don't know when to set udp vs. udp_multicast as you can't 
>>> know which stream you get.
>>
>> That is why lower_transport is a mask, a combination of the possible 
>> values. And it looks like by default everything _is_ allowed.
> My stream always fails until I specify exactly: ./ffprobe 
> -rtsp_transport udp_multicast -i rtsp://172.17.1.131/stream1m
>>
>> Regards,
>> Marton
>>
>>>
>>>>
>>>> Regards,
>>>> Marton
>>>>
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Marton
>>>>>>
>>>>>>>>>           err = ff_rtsp_make_setup_request(s, host, port, 
>>>>>>>>> lower_transport,
>>>>>>>>> rt->server_type == RTSP_SERVER_REAL ?
>>>>>>>>> real_challenge : NULL);
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> ffmpeg-devel mailing list
>>>>>>> ffmpeg-devel at ffmpeg.org
>>>>>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>>>>>
>>>>>>> To unsubscribe, visit link above, or email
>>>>>>> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>>>>>> _______________________________________________
>>>>>> ffmpeg-devel mailing list
>>>>>> ffmpeg-devel at ffmpeg.org
>>>>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>>>>
>>>>>> To unsubscribe, visit link above, or email
>>>>>> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> ffmpeg-devel mailing list
>>>>> ffmpeg-devel at ffmpeg.org
>>>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>>>
>>>>> To unsubscribe, visit link above, or email
>>>>> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>>>> _______________________________________________
>>>> ffmpeg-devel mailing list
>>>> ffmpeg-devel at ffmpeg.org
>>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>>
>>>> To unsubscribe, visit link above, or email
>>>> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>>>
>>>
>>> _______________________________________________
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel at ffmpeg.org
>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>> To unsubscribe, visit link above, or email
>>> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>> _______________________________________________
>> ffmpeg-devel mailing list
>> ffmpeg-devel at ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>
>

More information about the ffmpeg-devel mailing list