Opened 4 years ago

Closed 3 years ago

#2171 closed defect (fixed)

Joining a SSM multicast group using an SDP

Reported by: dbrb2 Owned by:
Priority: normal Component: avformat
Version: git-master Keywords: sdp rtp rtsp
Cc: ben@bbarker.co.uk Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description (last modified by cehoyos)

Hi, first bug report so apologies if format not quite correct.

When attempting to join a multicast group using SSM by providing ffmpeg with an sdp file as input, a tshark trace seems to show that the IGMPv3 requests issued do not in fact include the SSM addresses provided within the SDP, and hence the stream is not joined.

The original issue was raised here:

http://ffmpeg.gusari.org/viewtopic.php?f=12&t=766&p=1482#p1482

The command to replicate can be as simple as:

ffmpeg -i file.sdp

Where "file.sdp" is of the form:

v=0
m=video <multicast_port> RTP/AVP 96
c=IN IP4 <multicast_ip>
a=rtpmap:96 RTP/AVP
a=source-filter: incl IN IP4 <multicast_ip> <unicast_ip>

An example output for this would be:

ffmpeg version 1.1.1 Copyright (c) 2000-2013 the FFmpeg developers
  built on Jan 22 2013 14:35:01 with gcc 4.1.2 (GCC) 20080704 (Red Hat 4.1.2-52)
  configuration: --enable-gpl --enable-libvorbis --enable-x11grab --enable-libx264 --enable-nonfree --enable-version3
  libavutil      52. 13.100 / 52. 13.100
  libavcodec     54. 86.100 / 54. 86.100
  libavformat    54. 59.106 / 54. 59.106
  libavdevice    54.  3.102 / 54.  3.102
  libavfilter     3. 32.100 /  3. 32.100
  libswscale      2.  1.103 /  2.  1.103
  libswresample   0. 17.102 /  0. 17.102
  libpostproc    52.  2.100 / 52.  2.100
[sdp @ 0x1ba57500] Could not find codec parameters for stream 0 (Video: mpeg4, yuv420p): unspecified size
Consider increasing the value for the 'analyzeduration' and 'probesize' options
[sdp @ 0x1ba57500] Estimating duration from bitrate, this may be inaccurate
file.sdp: could not find codec parameters

If tshark is run on the machine making this request, it can be seen that no source is specified in the IGMPv3 requests

456.597623 <local_ip> -> 224.0.0.22 IGMP V3 Membership Report / Join group <multicast_video_address> for any sources
458.410757 <local_ip> -> 224.0.0.22 IGMP V3 Membership Report / Join group <multicast_video_address> for any sources
466.613846 <local_ip> -> 224.0.0.22 IGMP V3 Membership Report / Leave group <multicast_video_address>

Whereas a successful join of this group (using another media player, for instance VLC) would yeild something similar to:

146.777143 <local_ip> -> 224.0.0.22 IGMP V3 Membership Report / Join group <multicast_video_address> for any sources
146.785156 <local_ip> -> 224.0.0.22 IGMP V3 Membership Report / Join group <multicast_video_address> for source {<unicast_video_address>}

Change History (10)

comment:1 Changed 4 years ago by dbrb2

  • Version changed from unspecified to 1.1.1

comment:2 Changed 4 years ago by dbrb2

  • Cc ben@bbarker.co.uk added

comment:3 Changed 4 years ago by cehoyos

  • Keywords sdp added; IGMP SSM Multicast removed

Is this reproducible with current git head?

Do you have a suggestion on how this can be tested / reproduced on a local network?
Or do you have a public address (sdp file) that allows testing?

comment:4 Changed 4 years ago by cehoyos

  • Description modified (diff)

comment:5 Changed 4 years ago by dbrb2

Hi,

Yes, I have tried it on the latest from git:
FFmpeg version git-b319052
With the same results.

Testing / replicating is tricky, not only because the streams tend to be quite large, but more because the ability to work with multicast is so much a feature of the switches on the network as well as the video stream itself.

I imagine this is a massive oversimplification, but presumably the problem is either in the parsing of the sdp file, and detecting that SSM is required, or detecting SSM is required, but not issuing the correct IGMPv3 messages.

To check for the first problem, is there an alternate syntax I can use to join the ssm multicast stream?
Something along the lines of:

ffmpeg -i udp://<multicast_ip>:<multicast_port> <rtp type> <ssm address>

Ben

comment:6 Changed 4 years ago by cehoyos

  • Version changed from 1.1.1 to git-master

comment:7 Changed 4 years ago by dbrb2

Hi,
Just a note:

I'm really not qualified to attempt to fix this, but as far as I can tell, "libavformat/rtsp.c" deals with parsing an input sdp file, and as far as I can tell seems to have regex to parse most of the standard sdp lines, and the various lines of the sdp are parsed by a case/switch, but in the section for line type 'a' nothing to extract the:

a=source-filter: incl IN IP4 <multicast_ip> <unicast_ip>

i.e the line that specifies the SSM address.

I guess something similar to:

else if (av_strstart(p, "source-filter:", &p)
     <code to parse the line here>

Is required?

Calling ffmpeg with the stream parameters passed in thus:

ffmpeg -i udp://<multicast_ip>:<multicast_port>?sources=<ssm_address>

Seems to work, sending out the appropriate IGMPv3 message, so it seems under the bonnet ffmpeg is working fine, and it is just a problem parsing the SDP

Version 3, edited 4 years ago by dbrb2 (previous) (next) (diff)

comment:8 Changed 3 years ago by EdTorbett

Hi,

I have submitted a patch for this (plus additional checking for the source IP in rtpproto.c as it turns out to be necessary when running multiple instances of ffmpeg) to ffmpeg-devel.

Patch is here if you want to test it: http://ffmpeg.org/pipermail/ffmpeg-devel/2013-June/145105.html

comment:9 Changed 3 years ago by EdTorbett

Further to this, the additional errors mentioned in the original support thread you created are resolved by this; these are due to the stream being rtp rather than just plain udp. with this patch applied an alternate url to access the stream without an SDP file would be ffmpeg -i rtp://<multicast_ip>:<multicast_port>?ssm=<ssm_address>.

comment:10 Changed 3 years ago by cehoyos

  • Component changed from undetermined to avformat
  • Keywords rtp rtsp added
  • Resolution set to fixed
  • Status changed from new to closed

The patch was applied in 7203dbd.

Note: See TracTickets for help on using tickets.