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

Martin Storsjö martin
Thu Oct 7 13:12:51 CEST 2010


On Thu, 7 Oct 2010, Luca Abeni wrote:

> On 10/07/2010 10:35 AM, Martin Storsj? wrote:
> [...]
> > > 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>.
> 
> Looks good, thanks.
> 
> [...]
> > > 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.
> 
> This (or asking the user to explicitly specify the output interface) is
> the approach I generally used... As I said, I am not sure about what's
> the best solution. If other people are ok with connect(), I do not object.
> 
> 
> > > 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.
> 
> I think some proper #ifdeffery would solve this problem, but #ifdefs do
> not seem to be too trendy, so I leave this discussion to someone else ;-)
> 
> 
> > 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.
> 
> Ok, this works... But having the SDP demuxer as a dependency for the RTSP
> muxer looks quite strange to me...

Yeah, it's not too obvious. If you're interested in seeing how complicated 
it is, have a look at the other RFC thread I posted recently - it's 
possible, but it's not easy at all. :-)

> [...]
> > 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
> 
> Ok, so this is a known vlc/live555 issue... I think your muxer is ok, then.

Ok, great, thanks!

So, reviews that still is required:
- Opinion on the connect() stuff, Ronald, Luca B, someone else?
- Splitting out the RTP chained muxer setup from the RTSP code, Ronald, 
Luca B?

- Luca A, any opinion on how the demuxer is used? That is, currently it is 
used via a sap:// url that specifies the announcement ip to listen on, so 
for most IPv4 cases, one would use sap://sap.mcast.net

// Martin



More information about the ffmpeg-devel mailing list