[FFmpeg-devel] [PATCH] SAP muxer/demuxer

[Martin Storsjö]

On Thu, 7 Oct 2010, Luca Abeni wrote:

> On 10/06/2010 07:45 PM, Martin Storsj? wrote:
> > Hi,
> > 
> > As mentioned in another thread, I've been working on a SAP (RFC 2974)
> > muxer and demuxer. SAP is a very simple protocol for announcing the SDP
> > info for a RTP broadcast, and is most often sent over multicast (but there
> > are usecases where one could want to send it over normal unicast, too).
> 
> Quick question: by looking at the patches (patch 0005, in particular),
> it seems to me that you send SAP announcements to the RTP destination
> (at least, I get this impression when reading how sap->ann_fd is initialised).
> What am I missing? As far as I remember, SAP used a well known multicast
> address for announcements, and the RTP destination address could be a
> different multicast address (this is what I've always seen) or an unicast
> address...

You're absolutely right. Changed it to send the announcement to the fixed 
destination IP now, unless a specific one is set on the url via 
?announce_addr=<ip>.

> [...]
> > The content of this patch series is:
> > - Add a "connect" option to the udp protocol. In the SAP announcement, we
> > need to send the local IP address we're sending the packets from, and
> > that's not available on a normal UDP socket, only on a connected one. When
> > connected, one has to use send() instead of sendto(), and if you receive
> > "destination unreachable" ICMP packets, sends will return ECONNREFUSED.
> > Is this OK for Luca A/Ronald?
> 
> So, you use connect() in order to obtain the source address of your RTP
> packets? I am not sure if this is the best solution... Anyway, if other
> people feel that this is ok I will not object.

Do you have any other suggestion for finding out the address? Enumerating 
the local interface addresses and trying to guess which one the OS will 
use to send packets to this destination is way more error prone and 
clumsier IMO.

> > - Factorizing out a shared function from the RTSP muxer, that sets up a
> > chained RTP muxer given an AVStream.
> 
> I might be misunderstanding something, here... But, as far as I understand
> rtpenc_chain.o is needed by the RTSP muxer (and by the SAP muxer).

Yes, that's right.

> And it seems to me that your patch compiles it when the SDP demuxer is 
> enabled?

Yes - this code is called from the codepaths that is shared between the 
SDP demuxer, RTSP demuxer and RTSP muxer. So even if it actually is used 
only by the RTSP muxer, it is needed to avoid linking failures when 
compiling any of the other, too. And both the RTSP demuxer and muxer 
declare the SDP demuxer as one of its dependencies, so this way, there 
should be no linking error regardless of which of them is 
enabled/disabled.

> > - One patch for adding the muxer, and one for adding the demuxer.
> 
> See my first comment: is it possiblke to specify different destination
> addresses for announcement packets and RTP packets?

Not in the previous patch set, but in the one I attach now.

> [...]
> > Or to test with VLC:
> > 
> > ffmpeg -re -i<input>  -vcodec mpeg4 -acodec libfaac -f sap
> > sap://244.0.0.255?same_port=1
> > 
> > (VLC/Live555 requires all RTP streams to be received on the same port in
> > this scenario, for some reasons...)
> 
> I do not seem to remember a similar limitation... Can it be due to the
> issue I mentioned above (about the destination addresses)?

No, it doesn't seem so.

To test with VLC, do e.g. this:

ffmpeg -re -i <input> -vcodec mpeg4 -acodec libfaac -f sap 
sap://224.1.2.3?same_port=1

(Now the announcement is sent to the fixed address 224.2.127.254, but the 
packets are sent to 224.1.2.3.)

You'll see that the stream pops up under Network streams (SAP) in VLC. If 
I try the same without same_port=1, I get this message in the VLC message 
console:

> sap debug: Multiple media ports not supported -> live555

However, it does seem that it would work without aggregating the c= lines 
into one single line, I may have drawn the wrong conclusion while 
debugging that initially.

// Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-udp-Add-an-option-for-connecting-the-udp-socket.patch
Type: text/x-diff
Size: 2254 bytes
Desc: 
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101007/db9eb9e6/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-rtsp-Remove-the-start_time-field-from-RTSPState-use-.patch
Type: text/x-diff
Size: 2186 bytes
Desc: 
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101007/db9eb9e6/attachment-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-rtsp-Make-rtsp_rtp_mux_open-reusable.patch
Type: text/x-diff
Size: 1828 bytes
Desc: 
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101007/db9eb9e6/attachment-0002.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-rtsp-Factorize-out-code-for-opening-a-chained-RTP-mu.patch
Type: text/x-diff
Size: 8742 bytes
Desc: 
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101007/db9eb9e6/attachment-0003.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0005-Add-a-SAP-Session-Announcement-Protocol-muxer.patch
Type: text/x-diff
Size: 11377 bytes
Desc: 
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101007/db9eb9e6/attachment-0004.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0006-Add-a-SAP-demuxer.patch
Type: text/x-diff
Size: 9128 bytes
Desc: 
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101007/db9eb9e6/attachment-0005.patch>