[FFmpeg-devel] [PATCH] mp4a-latm rtp output & dynamic payload type from URL
Tue Dec 22 14:01:08 CET 2009
On Tue, Dec 22, 2009 at 11:30:54AM +0100, Luca Abeni wrote:
> Sergiy wrote:
>> 2009/12/21 Luca Abeni <lucabe72 at email.it>:
>>> In case of RTP over TCP, the RTP packets are interleaved in the RTSP
>>> and they should be demuxed and split according to the "channel
>>> (the byte immediately following the "$"). Isn't this supported by DSS and
>> My fault, DSS works fine with multiple audio PT=97 (just checked) it
>> sends them in different channels, but some troubles still exists with
> Ok, so the problem is a bug in this wowza thing.
> If it is largely used, I am all for supporting it... The problem is that
> both your "file_index" patch and the "AVStream.id" patch requires change in
> ffmpeg.c, so they can accepted only is Michael agrees.
> Summing up, we have different possibilities for setting the dynamic payload
> 1) Michael's proposal: using PT 96 for video and PT 97 for audio. This is
> simple and does not require modifications outside rtpenc.c and sdp.c,
> but some media servers (wowza) have problems with it.
> 2) Adding a "file_index" field in AVFormatContext, as in your patch. This
> requires Michael's approval
> 3) Using AVStream.id. This does not require modifications in libav* (other
> than to rtpenc.c and sdp.c), but requires an explicit setting of the
> field in ffmpeg.c. Again, requires Michael's approval.
> 4) using a "?payload_type=..." tag in the URL, as in your original patch.
> Such a patch introduced some unneeded modifications in generic
> code, which I removed. A cleaned-up patch is here:
> I am fine with all of these solutions. Let's select the best one, and I'll
> commit it.
> I am also thinking at a fifth solution, using metadata:
> 5) Using a "payload_type" metadata for setting the payload type. So, it
> could be set in ffmpeg by using (for example)
> -metadata payload_type="97"
> This would not require changes in generic libavformat files, but only
> in rtpenc.c and sdp.c. However, I am not sure if this can be considered
> a smart usage of metadatas or an abuse of such a feature...
> Comments welcome...
2-5 need changes in all applications, not just ffmpeg.c
this is not reasonable as a workaround for a bug in wowza
theres nothing wrong with letting the user force the id but it must be
clear that this is not a requirement for use of the API (so it doesnt
Also someone should contact the wowza devels and tell them about the
bug if this fails, the sanest workaround is to detect wowza, print a
message informing the user about the issue and then do
static int id;
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel