[FFmpeg-devel] [RFC] SDP Generation
Fri Jun 8 19:02:20 CEST 2007
On Fri, Jun 08, 2007 at 05:24:08PM +0200, Luca Abeni wrote:
> Hi Michael,
> thanks for the comments; I'll fix the code during the weekend.
> Michael Niedermayer wrote:
> >> There still are some open issues (look at the FIXME's), but I'd like to
> >> have some feedback to know if I am going in the right direction, and if
> >> the interface is ok.
> > the interface does not look ok, it depends on a 1 stream per AVFormatContext
> > i thought this multi AVFormatContext was only needed for obscure multicast
> > cases noone would use in practice anyway, please elaborate on the
> > problem ...
> Well, the problem is that every single media stream can have a different
> destination address. If the "filename" field in AVFormatContext is used
> for indicating the destination address, then I need an AVFormatContext
> per media stream.
in what cases are different destination addresses needed/wanted?
and why do we need them in a single SDP thingy?
i can also put each stream into a different file, this though does not
prevent me from putting them in the same file ...
also if they are in seperate files each has its own header ...
> I am not happy with this solution (that's why I asked :), but I did not
> find anything better. And this is the solution currently used by ffmpeg too.
> So, using this interface I can modify ffmpeg to generate an SDP file
> when streaming RTP by simply adding something like
> sdp = avf_sdp_create(output_files, nb_output_files);
> printf("%s", sdp);
> in ffmpeg.c:av_encode(), before start streaming.
> A different option would be to support both the "multiple
> AVFormatContext" (in which case each AVFormatContext must have only one
> stream) and the "single AVFormatContext" cases (in the second case, all
> the streams have the same destination address, and are inside the same
> AVFormatContext). I did not implement this to simplify the code, but
> maybe it's a better way to go?
i would like to fully understand/disscuss the differences between both
options before deciding this
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the ffmpeg-devel