[FFmpeg-devel] [PATCH] Use the actual RTSP peer IP for RTP sessions

[Martin Storsjö]

On Wed, 10 Mar 2010, Ronald S. Bultje wrote:

> On Wed, Mar 10, 2010 at 5:26 PM, Luca Abeni <lucabe72 at email.it> wrote:
> > On 10/03/10 23:18, Ronald S. Bultje wrote:
> >> On Tue, Mar 9, 2010 at 9:47 AM, Luca Abeni<lucabe72 at email.it> ?wrote:
> >>> What about this: creating the SDP from an RTSP context (as
> >>> you are doing now), but instead of using the original AVFormatContext
> >>> you can create a copy (and modify the filename in the copy).
> >>> This looks like a good compromise to me,
> >>
> >> Eehw, ugly.
> >
> > Well, we clearly have different opinions on what is ugly :)
> > What's happening here is that the RTSP muxer wants to create an SDP using a
> > different destination address respect to what is specified in the
> > AVFormatContext (using the numeric IP instead of the symbolic name).
> 
> Well, different, they _should_ be the same, just different ways of naming them.
> 
> > (if
> > we want a different destination, let's pass an AVFormatContext containig a
> > different destination).
> 
> Is fine with me also, I guess it'd mean some re-setup in the RTSP
> muxer. How difficult would this be, Martin?

That's what both the last ugly one does (where I copy the AVFormatContext 
just for the sake of setting a custom url) and what the initial one did 
(where I temporarily changed AVFormatContext->filename for the original 
RTSP muxer, then reset it to the original after creating the SDP) - 
forcing an AVFormatContext with a custom url even if it's still the same 
normal RTSP muxer context. Ugly, but works with the current SDP creation 
interface.

If we instead wanted to create it from proper RTP muxers, things get much 
more complicated, I showed an example of this earlier in this thread. The 
executive summary is: In the RTSP muxer, we first announce an SDP and thus 
need to generate it, then we set up the actual RTP streams. Reversing 
this, creating half-initialized RTP streams just for the sake of creating 
the SDP, messes things up big time. It also complicates the cleanup since 
we can have the RTP streams in both a fully-initialized state and a 
half-initialized state. Luca agreed that it's not worth it.



My opinion is that creating the SDP simply is a general utility function, 
the RTSP muxer could just as well use some simplified SDP generation 
function of its own, just looking at the individual AVStreams to set 
proper codec metadata. But that would be code duplication, so instead, we 
use the same SDP generation code that's exposed publicly through 
avf_sdp_create.

This utility function doesn't have a flexible enough interface for this 
use case, but we don't need to expose the more flexible function outside 
of libavformat, it can be an internal function, ff_sdp_create.

The attached patch series is one example on how this could be done. This 
also solves the control name parameter problem as a bonus.

// Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-a-new-internal-function-ff_sdp_create-which-allo.patch
Type: text/x-diff
Size: 4579 bytes
Desc: 
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100311/845e5d4e/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Use-ff_sdp_create-in-the-RTSP-muxer.patch
Type: text/x-diff
Size: 1738 bytes
Desc: 
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100311/845e5d4e/attachment-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Construct-a-temporary-URL-for-the-SDP-destination-IP.patch
Type: text/x-diff
Size: 1686 bytes
Desc: 
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100311/845e5d4e/attachment-0002.patch>