[FFmpeg-devel] [PATCH] mp4a-latm rtp output & dynamic payload type from URL
Sat Dec 19 09:25:00 CET 2009
On Sat, 2009-12-19 at 02:05 +0100, Michael Niedermayer wrote:
> > 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?
Well, it really is a user choice (AFAIK, all the stream can have the
same dynamic PT. The problem is that some proprietary applications do
not like such an uncommon setting). Like the destination address, the
destination port, etc... So, yes, the application has to set it. The
default is that all the streams with dynamic PT will have the same PT
(just because this is the simplest thing to do :).
> and both fail if the user uses 2 seperate processes to stream the 2 streams?
You mean, two separate ffmpeg processes? Yes, in this case the streams
will have the same PT (although I would not use the word "fail" in this
Unless we implement a way to allow the user to explicitly set the
AVStream.id to a specific value (I wanted to implement this feature in
ffmpeg.c, but I decided to go for a simpler approach in a first patch).
If, instead, you use your own application then you can explicitly set
AVStream.id to the desired value in the application, and using 2
separate processes will not be a problem.
> how many bits does this payload type have?
It is 7 bits. Values up to 95 are statically associated to some codecs
(so, for those codecs we have no problems); modern codecs use "dynamic
payload types" ( >= 96), which are basically selected by the user.
> and what does the RFC say about how to set it?
For dynamic payload types, nothing particular: only that they must be >=
96. Although some players do not like seeing two different streams with
the same PT, I do not think there is such a constraints in the various
RFCs (I might be wrong, of course...).
More information about the ffmpeg-devel