[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