[FFmpeg-devel] [PATCH] mp4a-latm rtp output & dynamic payload type from URL

Luca Abeni lucabe72
Fri Dec 18 09:42:06 CET 2009


Hi Michael,

Michael Niedermayer wrote:
[...]
>>>> Here is simple patch that adds AVFormatContext.file_index and increase
>>>> payload_type for every dynamic stream.
>> [...]
>>>> --- a/libavformat/avformat.h
>>>> +++ b/libavformat/avformat.h
>>>> @@ -536,6 +536,7 @@ typedef struct AVFormatContext {
>>>>      void *priv_data;
>>>>      ByteIOContext *pb;
>>>>      unsigned int nb_streams;
>>>> +    int file_index;      /**< file index, used in rtp-output for dynamic 
>>>> payload type */
>>>>      AVStream *streams[MAX_STREAMS];
>>> didnt review your patch but you cant add things into the middle ofpublic
>>>  structs
>> If this is fixed, would the addition of a "file_index" field be acceptable?
>> (I am asking in case I do not manage to use AVStream.id for this purpose).
> 
> Well, without reading the patch the description of
> int foobar; //foobar used in rtp
> tells me nothing so i cant awnser if the variable is ok (ive no clue at all
> what it is) what i can for sure is that the doxy is not ok :)

Ok, fair enough... Here is a short explanation of the problem: when
streaming audio and video over RTP, multiple output contexts are used
(one per stream).
So, we can have multiple AVFormatContexts composing one RTP session.
When packetising a stream in an RTP packet, a "payload type" number
is associated to it; most of the modern codecs use the so called "dynamic
payload type", which does not depend on the codec but is decided by the
streamer.
Unfortunately, some RTP clients want different payload types for the
different streams, so libavformat needs some way to associate a payload
type to an AVFormatContext. What Sergiy is doing here is to enumerate the
AVFormatContexts used by ffmpeg, storing their ID in this new "file_index"
field.

When the problem was discussed some time ago, you proposed to use AVStream.id
for this purpose. To do this, we need to set AVStream.id after the muxer and
the codecs are initialised. Is the ffmpeg.c part of the attached patch
(alternative to Sergiy's one) acceptable?


			Thanks,
				Luca
-------------- next part --------------
A non-text attachment was scrubbed...
Name: select-pt-streamid.diff
Type: text/x-diff
Size: 2833 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20091218/a25be52c/attachment.diff>



More information about the ffmpeg-devel mailing list