[FFmpeg-devel] PATCH rtsp/sdp/multicast

[Luca Barbato]

armand bendanan wrote:
> Luca Barbato wrote:
>> armand bendanan wrote:
>>> OK, diego, I got also a reply from Stefano.
>>> Here a new patch.
>> The patch addresses at least two issues:
>>
>> - ATEME not putting "c=" line in certain cases (why?) [that's a quirk
> mode]
>> Looks like they got wrong the fact the "c=" line is non-optional
>> document wide but you can omit from the Session description IF you put
>> it in each media description and vice versa.
>>
>> this part being a quirk mode should be marked as is (with loud warnings)
> 
> You are right.
> But they omit the "c=" from the session and media descriptions when ATEME is
> configured in unicast.
> When it is configured in multicast, they put this line in the Session
> description, which is correct.
> 
>> - ffmpeg way to pass parameters in url is suboptimal and in rtsp wrongly
>> handled.
>>
>> That part is good, I wonder if there is interest in getting option
>> passing a bit more saner (since at least in rtsp and http you may have
>> url with params that may collide with ffmpeg internal ones...)
>>
>>
>> The initial email also point ffmpeg doesn't handle gracefully unexpected
>> responses and that will be investigated.
> 
> Yes. Bellow, you will find some more information on that.
> 
> The problem is when we ask ffplay with a URL like:
> rtsp://xx.xx.xx.xx/video1?multicast
> and ATEME is *not configured* to operate in multicast.

Then it should say it is not supported IMHO.

Still I _think_ the problem is due the fact we are parsing but not using
all the transport lines we receive.

> 
> We send:
> [rtsp @ 0x96a6780]Sending:
> SETUP rtsp://192.168.0.150:554/video2/video RTSP/1.0
> Transport: RTP/AVP/UDP;multicast
> CSeq: 3
> 
> ATEME will reply:
> [rtsp @ 0x96a6780]line='RTSP/1.0 200 OK'
> [rtsp @ 0x96a6780]line='CSeq: 3'
> [rtsp @ 0x96a6780]line='Session: 1110634900'
> [rtsp @ 0x96a6780]line='Transport:
> RTP/AVP;unicast;destination=192.168.0.93;client_port=0-1;server_port=49174-4
> 9175;ssrc=8021f6b8'
> 
> The reply lower_transport (unicast) is different from the one that we asked
> (multicast) and there is a core dump.

This is a bug indeed.

> The reverse is working; if ATEME is configured to work in multicast and I
> ask a unicast lower_transport, ATEME will reply with a unicast
> lower_transport. Meaning that If ATEME is configured to multicast, it is
> also able to send the stream in unicast. This is OK.

I see.

> I have another ENCODER embedded in a camera (FLIR) which does not behave
> like the ATEME encoder. If the FIR is configured in multicast and I ask a
> unicast lower_transport, the FLIR will reply with a *multicast*
> lower_transport.

That is curious as well.

> What is interessant is that here the rtsp stack works ... We ask a unicast
> transport, we get a multicast one, and it works without core dump.

Hmm

> To conclude:
> If I ask a multicast lower_transport and receive a unicast lower_transport :
> core dump.
> If I ask a unicast lower_transport and receive a multicast lower_transport :
> it works.
> The only case where ATEME does not send the c= line is when it is configured
> in unicast, but it works with FFMPEG.
> I can contact them, but what parameters they should send in this c= line?

It is just needed for compliance usually you get

 c= IN IP4 0.0.0.0

in order to stay compliant, sdp mandates the line but rtsp Transport:
takes priority.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero