[FFmpeg-devel] [PATCH] SDP muxer

[Stefano Sabatini]

On date Saturday 2008-11-22 13:24:26 +0000, Luca Abeni encoded:
> Hi,
> 
> Stefano Sabatini wrote:
> [...]
> >> Depending on the answers, maybe a patch like the attached one (completely
> >> untested, and maybe needs some fixes/cleanup) would make sense. This patch
> >> would greatly simplify the SDP muxer.
> > 
> > I see the point of your patch, but I cannot see how it could simplify
> > the SDP muxer.
> 
> The idea is that with this patch the SDP muxer could directly call 
> avf_sdp_create() passing the input AVFormatContext to it.
> 
> But looking at Aurelien's email it seems that AVStream->filename cannot 
> be used in this way... So the patch is not good (and I think the SDP 
> muxer should be designed to work in a different way, since I suspect it 
> cannot use AVStream->filename).

Yes, so the problem is to store the destination address of the stream,
which is different for each stream so it can't be simply specified in
the AVFormatContext.

Possible solutions:

* use the priv_data field (to fill in av_new_stream(), if it is an RTP
  stream then it will fill it with a structure containing the
  MC destination info)
* define some other field in AVStream

I don't know if any of this solutions is valid.

> [...]
> > Also in the code we're assuming that an RTP AVOutputStream may contain
> > more than one AVStream, does this make sense?
>
> I do not know... In the definition of AVOutputStream in ffmpeg.c I see 
> that it contains a pointer to a single AVStream: where is this "more 
> than one AVStream" assumption? 

Sorry I really meant AVOutputStream, in rtpenc.c we have
(rtp_write_header.c)

    if (s1->nb_streams != 1)
        return -1;

So for example:
stefano at geppetto ~/s/ffmpeg> ffmpeg -i slow.flv -vcodec mpeg4 -f rtp rtp://localhost:5004
FFmpeg version SVN-r15925, Copyright (c) 2000-2008 Fabrice Bellard, et al.
[...]
Input #0, flv, from 'slow.flv':
  Duration: 00:03:58.15, start: 0.000000, bitrate: 64 kb/s
    Stream #0.0: Video: flv, yuv420p, 320x240, 29.97 tb(r)
    Stream #0.1: Audio: mp3, 22050 Hz, mono, s16, 64 kb/s
Output #0, rtp, to 'rtp://localhost:5004':
    Stream #0.0: Video: mpeg4, yuv420p, 320x240, q=2-31, 200 kb/s, 29.97 tb(c)
    Stream #0.1: Audio: pcm_mulaw, 22050 Hz, mono, s16, 176 kb/s
Stream mapping:
  Stream #0.0 -> #0.0
  Stream #0.1 -> #0.1
Could not write header for output file #0 (incorrect codec parameters ?)

fails, while the logic in the avf_sdp_create seems to support more
than one stream in the output format:

        for (j = 0; j < ac[i]->nb_streams; j++) {
            sdp_write_media(buff, size,
                                  ac[i]->streams[j]->codec, dst[0] ? dst : NULL,
                                  (port > 0) ? port + j * 2 : 0, ttl);

and it will assign the port PORT, PORT + 2, PORT + 4... to the various streams.
 
> [...]
> >> - sdp-rename.patch: NACK. Some of the renames might make sense (I am
> >>   still undecided, but I do not like the ones like
> >>
> >>   "sdp_write_header ---> write_sdp_header".
> > 
> > What about something like:
> > sdp_write_header ---> sdp_write_sdp_header
> 
> Sorry, no. sdp_write_header is ok. If you really hate this name, or you 
> want to use it for different things, this can be changed in something 
> like sdp_write_session_level_description.

Mmh, afterall I begin to see the logic into those names, please check
the attached patch to see which of the remaining renamings I'm doing
make sense to you.

Regards. 
-- 
FFmpeg = Forgiving and Fast Multipurpose Porno Elitarian Guru
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sdp-rename.patch
Type: text/x-diff
Size: 2497 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081125/76a87ca0/attachment.patch>