[FFmpeg-devel] [PATCH] Add an RTSP muxer
Sat Jan 9 21:16:19 CET 2010
On Sat, 9 Jan 2010, Luca Abeni wrote:
> On 09/01/10 20:12, Martin Storsj? wrote:
> > IIRC, using this doesn't require too much config of the DSS - after
> > getting it up and running, you should be able to send streams to it using
> > this muxer, and then just connect to the same URL with a player.
> Yes, the problem was installing it... DSS wants to mess with /usr/ so I
> decided to install it in a virtual machine (and here the fun begun: finding a
> small-enough distribution that can support DSS, installing all the needed
> packages, adding users by hand because of bugs in DSS install script, etc...).
> Maybe it's time for a lighter, libav-based server ;-)
Ah, yes, the installation is a bit troublesome. I think I used some script
to wrap up the installation into a .deb, to make it cleanly uninstallable
later. Don't remember where I saw it, though, perhaps it's googleable :-)
> Ah, right... I'll try to see if the code can be modified so that
> rtpctx->priv_data is filled only when the header is written.
If you're ok with generating the SDP based on the RTSP context, with an
RTSP url, this should be easy to do, and I could give it a go myself, too.
> > Exactly this point would have been good to check how it's done with other
> > chained muxers, had there been examples of such. :-)
> Well, there currently are no other chained muxers, but I think in the generic
> case we want to av_new_stream() and then to initialise the AVCodecContext by
> copying the parameters from the "previous" codec in the chain. For example,
> some weeks ago I was trying to chain a LATM muxer with an RTP muxer: in this
> case, the codec in the RTP muxer is not exactly identical to the codec in the
> LATM muxer (the codec ID changes).
> Maybe, it's worth doing the same also in this case?
That's probably doable here, too, but requires a few more lines of code,
and just copying the context pointer is easier as long as exact same codec
context can be reused. But I don't have too much opinion on this issue.
> > Generally, is the amount of ugliness due to using chained muxers small
> > enough for you to prefer this version over the initial one using an
> > internal muxer interface?
> I would say that the chained muxer here looks ok, but maybe I am biased. I am
> also convinced that some of the ugliness is due to how the RTSP (de)muxer is
> structured, and this can be improved... But I am not sure until I can try some
> tests (hopefully tomorrow).
Ok, then I'll try to proceed with this approach.
> > That would ease at least some things, yes. Then all the creation of the
> > chained RTP muxers and their AVFormatContext could happen at the correct
> > place, within rtsp_open_transport_ctx.
> But you point out some other problems that I did not consider... I'll have a
> better look at this tomorrow.
More information about the ffmpeg-devel