| Message ID | 20191018165944.29832-1-haupt.wolfgang@gmail.com |
|---|---|
| State | New |
| Headers | show |
On 2019-10-18 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; > + > err = ff_rtsp_make_setup_request(s, host, port, lower_transport, > rt->server_type == RTSP_SERVER_REAL ? > real_challenge : NULL); Did anybody have the chance/interest to review this patch, yet? Best Regards, Wolfgang
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; > + > err = ff_rtsp_make_setup_request(s, host, port, lower_transport, > rt->server_type == RTSP_SERVER_REAL ? > real_challenge : NULL);
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; >> + >> err = ff_rtsp_make_setup_request(s, host, port, >> lower_transport, >> rt->server_type == RTSP_SERVER_REAL ? >> real_challenge : NULL); > >
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? 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@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
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. > > 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@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
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. 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@ffmpeg.org >>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> >>> To unsubscribe, visit link above, or email >>> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". >> _______________________________________________ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". > > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
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. 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. 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. > > 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@ffmpeg.org >>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>>> >>>> To unsubscribe, visit link above, or email >>>> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". >>> _______________________________________________ >>> ffmpeg-devel mailing list >>> ffmpeg-devel@ffmpeg.org >>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> >>> To unsubscribe, visit link above, or email >>> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". >> >> >> _______________________________________________ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
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@ffmpeg.org >>>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>>>> >>>>> To unsubscribe, visit link above, or email >>>>> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". >>>> _______________________________________________ >>>> ffmpeg-devel mailing list >>>> ffmpeg-devel@ffmpeg.org >>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>>> >>>> To unsubscribe, visit link above, or email >>>> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". >>> >>> >>> _______________________________________________ >>> ffmpeg-devel mailing list >>> ffmpeg-devel@ffmpeg.org >>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> >>> To unsubscribe, visit link above, or email >>> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". >> _______________________________________________ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". > > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
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. > >> 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@ffmpeg.org >>>>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>>>>> >>>>>> To unsubscribe, visit link above, or email >>>>>> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". >>>>> _______________________________________________ >>>>> ffmpeg-devel mailing list >>>>> ffmpeg-devel@ffmpeg.org >>>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>>>> >>>>> To unsubscribe, visit link above, or email >>>>> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". >>>> >>>> >>>> _______________________________________________ >>>> ffmpeg-devel mailing list >>>> ffmpeg-devel@ffmpeg.org >>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>>> >>>> To unsubscribe, visit link above, or email >>>> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". >>> _______________________________________________ >>> ffmpeg-devel mailing list >>> ffmpeg-devel@ffmpeg.org >>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> >>> To unsubscribe, visit link above, or email >>> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". >> >> >> _______________________________________________ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
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@ffmpeg.org >>>>>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>>>>>> >>>>>>> To unsubscribe, visit link above, or email >>>>>>> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". >>>>>> _______________________________________________ >>>>>> ffmpeg-devel mailing list >>>>>> ffmpeg-devel@ffmpeg.org >>>>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>>>>> >>>>>> To unsubscribe, visit link above, or email >>>>>> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". >>>>> >>>>> >>>>> _______________________________________________ >>>>> ffmpeg-devel mailing list >>>>> ffmpeg-devel@ffmpeg.org >>>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>>>> >>>>> To unsubscribe, visit link above, or email >>>>> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". >>>> _______________________________________________ >>>> ffmpeg-devel mailing list >>>> ffmpeg-devel@ffmpeg.org >>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>>> >>>> To unsubscribe, visit link above, or email >>>> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". >>> >>> >>> _______________________________________________ >>> ffmpeg-devel mailing list >>> ffmpeg-devel@ffmpeg.org >>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> >>> To unsubscribe, visit link above, or email >>> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". >> _______________________________________________ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". > >
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; + err = ff_rtsp_make_setup_request(s, host, port, lower_transport, rt->server_type == RTSP_SERVER_REAL ? real_challenge : NULL);