[FFmpeg-devel] [PATCH] SDP muxer
Fri Nov 21 08:41:04 CET 2008
Stefano Sabatini wrote:
>>>> while I think the expected behaviour for the muxer would be to take a
>>>> list of *AVStreams* and create from these the header.
>>> Maybe. But then, is it still possible to have different destination
>>> multicast groups for different streams? I mean: does an AVStream allow
>>> to store the destination MC group (and port) somewhere?
> I'm the mapping code of ffmpeg.c I'm storing the AVFormatOutput
> filename in the AVStream filename, which is then used to compute the
> destination address. It works but looks very fragile and I'm not very
> happy about it.
I did not know about AVStream->filename. What's its expected behaviour?
The comments says "source filename of the stream", which does not make
too much sense in this case... Is it ok to use AVStream->filename in this
way? Where is it used in libavformat, and who sets it?
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.
>>>> So I write a write_header() function which is very similar to
>>>> avf_sdp_create(), but which reads from streams rather than from a list
>>>> of files.
>>> I suspect this will result in some code duplication; you should not do
>>> it. What you should do is to write a write_header() function that prepares
>>> an array of AVFormatContexts for avf_sdp_create(), and then calls it.
>> Yes, this can be factorized.
I do not like the way you did it... In particular, I think that
avf_sdp_create2() is not needed: you can just move the needed code in
the SDP muxer "write_header" method, and then call avf_sdp_create()
>>>> renames in order to make them more meaningful and consistent (e.g.:
>>>> sdp_write_media -> write_sdp_media
>>> Sorry, but again I do not see the point in this change.
>>>> sdp_media_attributes -> write_sdp_media_attributes
>>>> sdp_write_header -> write_sdp_header)
>>> Sorry, but I'll not approve this kind of changes.
>> I think they make sense, but I won't insist on them.
>> sdp_write_header() may be confused with the muxer write_header()
>> function, also I think it is more clear to call it write_sdp_header
>> since what it does is to write the SDP header, same for the other
I am still against this rename. My preference is for a
<subsystem>_<verb>_<object> naming scheme.
- 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".
- implement-avf-sdp-create2.patch: I think this is not needed (and we
do not need a new function).
- implement-sdp-muxer-2.patch: This must be modified to use the attached
patch (if it makes sense - it depends on what AVStream->filename is, and
on how it is used), or to forge a proper array of AVFormatContexts and
then call avf_sdp_create()
I am not sure about implement-av-dup-stream-1.patch (I leave it to
Michael, since it touches the core of libavformat), and
implement-ffmpeg-sdp-mapping-2.patch looks ok, but Michael should comment
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1249 bytes
Desc: not available
More information about the ffmpeg-devel