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

Michael Niedermayer michaelni
Sat Dec 19 15:42:20 CET 2009


On Sat, Dec 19, 2009 at 09:25:00AM +0100, Luca Abeni wrote:
> Hi Michael,
> 
> 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
> case :).
> 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.

If you simply use 96 for video and 97 for audio it would work with 2 ffmpeg
processes
does this have a problem i miss?

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
-------------- 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/b534fdea/attachment.pgp>



More information about the ffmpeg-devel mailing list