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

[Michael Niedermayer]

On Fri, Dec 18, 2009 at 09:42:06AM +0100, Luca Abeni wrote:
> 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?

hmm, lets see if i understand this correctly
both your patches need every user application to set this?
and both fail if the user uses 2 seperate processes to stream the 2 streams?
how many bits does this payload type have? and what does the RFC say about
how to set it?

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20091219/1e4e9cfc/attachment.pgp>