[FFmpeg-devel] PATCH rtsp/sdp/multicast

armand bendanan armand.bendanan
Sat Oct 24 20:41:20 CEST 2009


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.

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.

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

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.

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.


Here is the log from the FLIR camera.

[rtsp @ 0x8b41a80]Sending:
DESCRIBE rtsp://193.168.1.22/video0 RTSP/1.0
Accept: application/sdp
CSeq: 2

--
[rtsp @ 0x8b41a80]line='RTSP/1.0 200 OK'
[rtsp @ 0x8b41a80]line='CSeq: 2'
[rtsp @ 0x8b41a80]line='Date: Fri, Oct 23 2009 08:01:01 GMT'
[rtsp @ 0x8b41a80]line='Content-Base: rtsp://193.168.1.22/video0/'
[rtsp @ 0x8b41a80]line='Content-Type: application/sdp'
[rtsp @ 0x8b41a80]line='Content-Length: 358'
[rtsp @ 0x8b41a80]line=''
[rtsp @ 0x8b41a80]sdp: v='0'
[rtsp @ 0x8b41a80]sdp: o='- 1256232694373451 1 IN IP4 193.168.1.22'
[rtsp @ 0x8b41a80]sdp: s='Ifara Server'
[rtsp @ 0x8b41a80]sdp: i='Ifara Session'
[rtsp @ 0x8b41a80]sdp: t='0 0'
[rtsp @ 0x8b41a80]sdp: a='tool:Ifara Streaming Media'
[rtsp @ 0x8b41a80]sdp: a='type:broadcast'
[rtsp @ 0x8b41a80]sdp: a='control:*'
[rtsp @ 0x8b41a80]sdp: a='range:npt=0-'
[rtsp @ 0x8b41a80]sdp: a='x-qt-text-nam:Ifara Session'
[rtsp @ 0x8b41a80]sdp: a='x-qt-text-inf:Ifara Session'
[rtsp @ 0x8b41a80]sdp: m='video 11112 RTP/AVP 96'
[rtsp @ 0x8b41a80]sdp: c='IN IP4 224.1.1.22'
[rtsp @ 0x8b41a80]sdp: a='rtpmap:96 MP4V-ES/90000'
[NULL @ 0x8b3d880] video codec set to : mpeg4
[rtsp @ 0x8b41a80]sdp: a='fmtp:96 profile-level-id=3;config='
[rtsp @ 0x8b41a80]sdp: a='control:track1'
### rtsp_read_header: lower_transport:0
## make_setup_request: host:193.168.1.22, port:554, lower_transport:0
trans_pref:RTP/AVP
## url_open, call url_open_protocol, proto:rtp,
filename:rtp://193.168.1.22?localport=5000
## url_open, call url_open_protocol, proto:udp,
filename:udp://193.168.1.22:-1?localport=5000
## url_open, call url_open_protocol, proto:rtp,
filename:rtp://193.168.1.22?localport=5002
## url_open, call url_open_protocol, proto:udp,
filename:udp://193.168.1.22:-1?localport=5002
## url_open, call url_open_protocol, proto:udp,
filename:udp://193.168.1.22:0?localport=5003
[rtsp @ 0x8b41a80]Sending:
SETUP rtsp://193.168.1.22/video0/track1 RTSP/1.0
Transport: RTP/AVP/UDP;unicast;client_port=5002-5003
CSeq: 3

--
[rtsp @ 0x8b41a80]line='RTSP/1.0 200 OK'
[rtsp @ 0x8b41a80]line='CSeq: 3'
[rtsp @ 0x8b41a80]line='Date: Fri, Oct 23 2009 08:01:01 GMT'
[rtsp @ 0x8b41a80]line='Transport:
RTP/AVP;multicast;destination=224.1.1.22;port=11112-0;ttl=10'
## rtsp_parse_transport, transport_protocol:RTP
## rtsp_parse_transport, profile:AVP
## rtsp_parse_transport, lower_transport:
## rtsp_parse_transport, th->lower_transport:0
## rtsp_parse_transport, parameter:multicast
## rtsp_parse_transport, th->lower_transport:2
## rtsp_parse_transport, parameter:destination
## rtsp_parse_transport, th->destination:E0010116 (224.1.1.22)
## rtsp_parse_transport, parameter:port
## rtsp_parse_transport, th->port_min:11112, th->port_max:0
## rtsp_parse_transport, parameter:ttl
## rtsp_parse_transport, th->ttl:10
[rtsp @ 0x8b41a80]line='Session: 13'
[rtsp @ 0x8b41a80]line=''
## make_setup_request RTSP_LOWER_TRANSPORT_UDP_MULTICAST
destination:-536805098 servport min:0 max:0 sdp_ip:224.1.1.22
sdp_payload_type:96 sdp_port:11112 sdp_ttl:16
## make_setup_request RTSP_LOWER_TRANSPORT_UDP_MULTICAST call url_open,
url:rtp://224.1.1.22:11112?ttl=10
## url_open, call url_open_protocol, proto:rtp,
filename:rtp://224.1.1.22:11112?ttl=10
## url_open, call url_open_protocol, proto:udp,
filename:udp://224.1.1.22:11112?ttl=10
## url_open, call url_open_protocol, proto:udp,
filename:udp://224.1.1.22:11113?localport=11113&ttl=10


> 
> Something alike your patch will hit svn soon, please contact ATEME and
> ask about the c= line since at least from a cursory look at rfc 2327
> they are sending a broken sdp.
> 

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?



 

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4538 (20091024) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 




More information about the ffmpeg-devel mailing list