[FFmpeg-devel] PATCH rtsp/sdp/multicast
armand bendanan
armand.bendanan
Wed Oct 21 22:03:03 CEST 2009
Hi,
You will find a patchable.diff which contain a patch that I needed to make
when using an ATEME video encoder (VSIP2) which operates in RTSP protocol.
Some log files and 2 SDP files are attached to illustrate my problem.
I am not sure *at all* that my understanding of FFMPEG / RTSP / SDP is
enough, but with this patch, I am almost ready to play video stream from
this encoder.
It is very probable that you *can* find other solutions.
Sorry for my level of English.
Armand Bendanan
NESLOG
PRESENTATION:
I am using an ATEME video encoder (VSIP2) which operates in RTSP protocol.
We can setup 2 streams; each of these 2 streams can be independently setup
using multicast or unicast.
The URLs to play the video has the form:
- For the first stream rtsp://XX.XX.XX.XX/video1
- For the second stream rtsp://XX.XX.XX.XX/video2
XX.XX.XX.XX is the Internet unicast address of the video encoder.
I am currently using FFPLAY in order to test FFMPEG and this video encoder.
The ATEME video encoder is setup to use multicast for the first stream.
The ATEME video encoder is setup to use unicast for the second stream.
It is possible to download the SDP file, we have to use the URLs:
http://XX.XX.XX.XX/stream1.sdp
http://XX.XX.XX.XX/stream2.sdp
The 2 streams are attached.
One important thing to notice in the strean1.sdp (multicast) is that there
is one line 'c=' which contains the default multicast group address for all
the media descriptions. And the media description 'm=' contains the port
20000 which is the multicast configured group. On the other hand, in the
stream2.sdp, there is no 'c=' line, and the port in the media description
'm=' is set to 0.
I have a little bit modified libavformat in order to print more information,
all lines beginning with '## ' are printed with dprintf.
1/ If I am using the first stream (video1) which is configured in multicast
a- ffplay_g rtsp://192.168.0.150:554/video1 2>/tmp/loga.txt
It works, and it is in UNICAST *even if* the 'c=' line in the SDP gives a
multicast default address ....
The SETUP command specify an unicast address, and the reply contains
'Transport: RTP/AVP;unicast ...'
What remains bizarre are the used ports (:-1 and :0) in the url_open calls
(lines 48-50 in the log file):
## url_open, call url_open_protocol, proto:rtp,
filename:rtp://192.168.0.150?localport=5000
## url_open, call url_open_protocol, proto:udp,
filename:udp://192.168.0.150:-1?localport=5000
## url_open, call url_open_protocol, proto:udp,
filename:udp://192.168.0.150:0?localport=5001
b- ffplay_g rtsp://192.168.0.150:554/video1?multicast 2>/tmp/logb.txt
I got from the video encoder a 404 error.
The log is in the file logb_1.txt
The point is that, this encoder seams to *dislike* to have the '?multicast'
option in the URL of the RTSP OPTIONS command.
I have modified the rtsp_read_headerto suppress the options from the
filename as:
else if (strcmp(option, "multicast") == 0)
lower_transport_mask = (1<<
RTSP_LOWER_TRANSPORT_UDP_MULTICAST);
else if (strcmp(option, "tcp") == 0)
lower_transport_mask = (1<< RTSP_LOWER_TRANSPORT_TCP);
}
+ // Suppress the options from the filename
+ option_list = strchr(s->filename, '?');
+ if (option_list) {
+ *option_list = 0;
+ }
}
After that corrected, the problem is in the make_setup_request function
which is not using properly the 'Transport' line in the reply of the SETUP
command and the 'c=' line in the SDP, the used IP address is 0.0.0.0.
The problem is showed in the log file logb_2.txt.
We can see that make_setup_request is using the
reply->transports[0].destination which is 0.
Instead, we should use the rtsp_st->sdp_ip / rtsp_st->sdp_port /
rtsp_st->sdp_ttl which came from the 'c=' line in the SDP.
I have modified the make_setup_request by using the rtsp_st->sdp_ip /
rtsp_st->sdp_port / rtsp_st->sdp_ttl if destination == 0.
Here, it works in multicast.
The log file is logb_3.txt
2/ If I am using the second stream (video2) which is configured in unicast
c- ffplay_g rtsp://192.168.0.150:554/video2 2>/tmp/logc.txt
It work OK and it is in UNICAST.
What remains bizarre are the used ports (:-1 and :0) in the url_open calls
(lines 47-49 in the log file):
## url_open, call url_open_protocol, proto:rtp,
filename:rtp://192.168.0.150?localport=5000
## url_open, call url_open_protocol, proto:udp,
filename:udp://192.168.0.150:-1?localport=5000
## url_open, call url_open_protocol, proto:udp,
filename:udp://192.168.0.150:0?localport=5001
The log file is logc.txt
d- ffplay_g rtsp://192.168.0.150:554/video2?multicast 2>/tmp/logd.txt
Here we ask to use a multicast connection but the encoder is not prepared to
that.
It failed (core dump)!.
The log file is logd.txt
The lower_transport (parameter of the function make_setup_request) = 2
because of the '?multicast' option in the URL.
The RTSP SETUP command contains a multicast attribute, we got in the reply:
'Transport:
RTP/AVP;unicast;destination=192.168.0.93;client_port=0-1;server_port=49174-4
9175;ssrc=8021f6b8'
The encoder cannot do multicast (it is configured as unicast) so it set a
unicast destination address, but the client_port numbers are wrong.
Furthermore, here the reply->transports[0].lower_transport is 0 (the reply
is unicast) and the rtsp_st pointer is not initialized.
This is because at the beginning of the for() loop we are using the
lower_transport parameter and in the switch we are using the
reply->transports[0].lower_transport, the 2 values are different.
I got a core dump in the rtp_set_remote_url call :
case RTSP_LOWER_TRANSPORT_UDP:
{
char url[1024];
/* XXX: also use address if specified */
snprintf(url, sizeof(url), "rtp://%s:%d",
host, reply->transports[0].server_port_min);
if (!(rt->server_type == RTSP_SERVER_WMS && i > 1) &&
rtp_set_remote_url(rtsp_st->rtp_handle, url) < 0) {
// core dump, here rtsp_st is NULL
err = AVERROR_INVALIDDATA;
goto fail;
}
}
break;
#0 rtp_set_remote_url (h=0x0, uri=0xb74d5bbe "rtp://192.168.0.150:49174")
at libavformat/rtpproto.c:59
59 RTPContext *s = h->priv_data;
(gdb) where
#0 rtp_set_remote_url (h=0x0, uri=0xb74d5bbe "rtp://192.168.0.150:49174")
at libavformat/rtpproto.c:59
#1 0x080c2bd0 in rtsp_read_header (s=0xa1da780, ap=0xb74d733c) at
libavformat/rtsp.c:1174
Here, I don't know how to deal with this core dump and how to *gracefully*
handle this error.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stream2.sdp
Type: application/octet-stream
Size: 282 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20091021/01f2d455/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stream1.sdp
Type: application/octet-stream
Size: 307 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20091021/01f2d455/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patchabe.diff
Type: application/octet-stream
Size: 1822 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20091021/01f2d455/attachment-0002.obj>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: logd.txt
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20091021/01f2d455/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: loga.txt
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20091021/01f2d455/attachment-0001.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: logb_1.txt
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20091021/01f2d455/attachment-0002.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: logb_2.txt
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20091021/01f2d455/attachment-0003.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: logc.txt
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20091021/01f2d455/attachment-0004.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: logb_3.txt
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20091021/01f2d455/attachment-0005.txt>
More information about the ffmpeg-devel
mailing list