[FFmpeg-devel] rtp streaming x264+audio issues (and some ideas to fix them)

[Luca Abeni]

On Sun, 2010-02-07 at 11:25 +0200, Martin Storsj? wrote:
[...]
> > Bettter have the muxer (or any caller) coordinate the value (instead  
> > of rtp_write_header()). That'd work for demuxing also (which has thd  
> > same bug, as said).
> 
> Yes, the caller (which knows about all the RTP muxers for the session), be 
> it either ffmpeg.c, the upcoming RTSP muxer or an application using the 
> RTP muxers directly, would have to coordinate the value - the RTP muxer 
> itself can't do it since it doesn't know anything about the other RTP 
> streams.

I agree on this; without a concept of "session" in libavformat, the RTP
muxer cannot do this. The RTSP muxer can implement the concept of
session, so it can help with there synchronisation issues.

An alternative would be to implement the session concept at application
level (but I do not know if it's worth introducing more complexity in
ffmpeg.c... Maybe a "dedicated" streaming application should be used for
this).
 
> The 
> proposed patch at least is a step in this direction, getting less bad 
> sync, although it isn't the full, final solution.

I still have to consider all the details, but I think the proposed patch
is a good improvement, and I'll probably commit it in few days.


> So, how should the RTP muxer callers communicate the coordinated NTP start 
> time for the stream? My suggestion is setting it in some metadata field - 
> then the RTP muxer can use that if it is set, otherwise just locally fetch 
> the current NTP time as it does currently.

I tend to agree with this. Of course, if someone can think about a
better solution...


				Luca