[FFmpeg-trac] #916(avformat:new): ffmpeg doen't check that udp port which it selects for incoming rtp already receives packets
FFmpeg
trac at avcodec.org
Fri Jan 13 11:17:44 CET 2012
#916: ffmpeg doen't check that udp port which it selects for incoming rtp already
receives packets
-----------------------------------+--------------------------------------
Reporter: xeioex | Type: defect
Status: new | Priority: normal
Component: avformat | Version: git-master
Keywords: rtsp, rtp | Blocked By:
Blocking: | Reproduced by developer: 1
Analyzed by developer: 1 |
-----------------------------------+--------------------------------------
RTSP session brakes some times and rstp server doesn't receive any
notification about it and still sends packet in rtp session. new ffmpeg
instance request the same port for incoming streams and doesn't detect it
receives two stream simultaneously but tries constantly re-synchronize
with two interleaved streams.
Actually, the real case occurred very rarely (4 times per one day).But
steps below help to reproduce it in stable manner (using iptables drops)
Steps to reproducing:
Remote side: AXIS 211W Network Camera
Command line:
1) ffmpeg -v 10 -an -i rtsp://<login>:<passwd>@<ip-addr>/mpeg4/media.amp
-vcodec mpeg1video -r 25 -sameq -acodec mp2 -strict experimental -y -f
mpegts ts.ts -debug 99
2) sudo iptables -I OUTPUT -p tcp -d <ip-addr> -s <local-ip> --source-port
<local-port-for-rtp> -j DROP
3) killall ffmpeg
3) ffmpeg -v 10 -an -i rtsp://<login>:<passwd>@<ip-addr>/mpeg4/media.amp
-vcodec mpeg1video -r 25 -sameq -acodec mp2 -strict experimental -y -f
mpegts ts.ts -debug 99
ffmpeg version: ffmpeg -v
ffmpeg version git-2011-12-30-9896d9e
OS: Linux 3.0.0-14-generic, ubuntu 11.10, 64-bit
wireshark log analysis:
1) packet 60 - first ffmpeg instance
first ffmpeg instance setups 5000-5001 ports for rtp and rtsp
2) packet 9029 - icmp due to iptables drops
3) packet 9321 - second ffmpeg instance
4) packet 9357 - first ffmpeg instance setups 5000-5001 ports for rtp and
rtsp -AGAIN!
But it brakes RFC http://www.ietf.org/rfc/rfc3550.txt:
5.2 Multiplexing RTP Sessions
Separate audio and video streams SHOULD NOT be carried in a single
RTP session and demultiplexed based on the payload type or SSRC
fields.
Proposed solution 1: (before sending to remote side local ports during
session negotiation ffmpeg should check there are incoming packets on this
port or not):
@@ -205,6 +221,9 @@ static int rtp_open(URLContext *h, const char *uri,
int flags)
s->rtp_fd = ffurl_get_file_handle(s->rtp_hd);
s->rtcp_fd = ffurl_get_file_handle(s->rtcp_hd);
+ if(!rtp_validate_udp_port(s->rtp_fd))
+ goto fail;
+
h->max_packet_size = s->rtp_hd->max_packet_size;
h->is_streamed = 1;
return 0;
Proposed solution 2: (ffmpeg should verify incoming packets on remote
ports it should be (rtsp_port-1) and rejects other packets):
I still working on it. I'm newby in ffmpeg internal and I wish know how to
get udp data of incoming RTP packet here: libavformat/rtpdec.c:
rtp_valid_packet_in_sequence() without braking framework encapsulation of
modules
--
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/916>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list