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

[Luca Abeni]

Hi Michael,

Michael Niedermayer wrote:
[...]
>> Summing up, we have different possibilities for setting the dynamic payload
>> type:
>> 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:
>>    
>> http://repo.or.cz/w/ffmpeg-lucabe.git/commitdiff/d1232c8a4041f6addea3f4a6aec79b61802e336c
>>
>> 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

2-5 do not require the user to set the payload type, but allow the user
to set it... If the user program does not set the payload type, the default
(96 - which, as far as a know is correct) is used.

Anyway, we can use 1) as a default and then implement an option between
2 and 5 to allow user programs to set different payload types.

Since using 1) as a default is quite simple and does not depend on the
2-5 choice, I'd like to commit 1) in few days (if you agree that it's a
good idea). Then, we can discuss 2-5.


> Also someone should contact the wowza devels and tell them about the
> bug if this fails

I do not know much about wowza (it seems it is a proprietary streaming
server that can be feeded with RTP and converts the stream in RTMP or
something similar... But I am not sure). Maybe Sergiy can contact them.

> the sanest workaround is to detect wowza, print a
> message informing the user about the issue and then do
> if(wowza){
>     static int id;
>     context->id= id++;
> }

I do not know how ffmpeg is interfaced with wowza in Sergiy's setup, but
I suspect it is used in some kind of "push" mode, in which ffmpeg sends
RTP packets to wowza without receiving back any packet (or, it receives
RTCP packets, which arrive after the RTP stream is started, when it's too
late for setting the payload type). Anyway, any input about this is
welcome.


			Thanks,
				Luca