Michel, I think the probability of loosing the first SR is very minor, SR packets are relatively small in comparison to the video packets and are less likely to get dropped by routers. Or do you have any indication otherwise? Ross's fix should do the trick.
However if you want to decrease that probability further RFC6051( http://tools.ietf.org/html/rfc6051 ) might be of use. I'm not sure if it applies here, but from what I recall it's basically an extension header for RTP that includes an NTP timestamp allowing one to do as the name says: rapid synchronisation. You could add this extension header to the first e.g. 5 RTP packets *if* you notice a problem with the first SR being lost. To be sure read the draft to make sure it applies to this use case. > As I said before (and am, I hope, saying for the last time), I'm not going to be doing anything non-standard here. @Ross I would say this is a standard-conformant way? Standard conformant RTP applications *should* ignore the header in any case if the don't understand it, so it shouldn't break other clients... @Michel If you do write the extension header and rapid sync code, you could consider contributing it back to the live555 codebase. Regards, Ralf
_______________________________________________ live-devel mailing list [email protected] http://lists.live555.com/mailman/listinfo/live-devel
