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

[Martin Storsjö]

On Thu, 7 Oct 2010, Martin Storsj? wrote:

> 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?

Pinging this thread, so Ronald finds it easier in the mailbox :-)

// Martin