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

[Marton Balint]

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?

> 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 ?

> 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.

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".