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

Luca Abeni lucabe72
Tue Dec 22 11:30:54 CET 2009

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 stream,
>> and they should be demuxed and split according to the "channel identifier"
>> (the byte immediately following the "$"). Isn't this supported by DSS and
>> Wowza?
> My fault, DSS works fine with multiple audio PT=97 (just checked) it
> sends them in different channels, but some troubles still exists with
> wowza.

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 "id"
    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 libavformat's
    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...


More information about the ffmpeg-devel mailing list