[Live-devel] disabling RTCP

[Frederic Bouilhaguet]

> >I've noticed problems of performance in
> >BasicTaskScheduler::SingleStep() on PocketPC platform because of the 
> >time passed in
> >RTCPInstance::incomingReportHandler() when RTCP Sender
> Reports are read
> >from the corresponding readable sockets.
> 
> Do you have any more details of this?  Because RTCP Sender Report
> packets are so small, and so infrequent, it seems unlikely that their
> reception is 
> the real cause of your performance problems.  Perhaps your OS's 
> implementation of "select()" is broken, so that the code 
> thinks that the 
> RTCP socket has newly readable data when it actually doesn't 
> (so that the 
> subsequent read from the socket ends up blocking for some 
> period of time)??

In Debug mode : each RTCPInstance::incomingReportHandler() call takes
around 8 secs.
In Release mode, it works fine : RTCPInstance::incomingReportHandler()
takes less than 1 ms.
And in both mode, the previous call to select() BasicTaskScheduler::in
SingleStep() in never block.

> Note, BTW, that
> the information in RTCP Sender Reports are used for audio/video time 
> synchronization.  If you disable RTCP, then you won't be able to 
> synchronize audio and video.

You mean in a "live" scenario ? But in a "content on demand" scenario
with RTSP (e.g. Hinted MP4 file + ISMA server), I can synchronize on rtp
timestamps without taking care of any RTCP Sender Report, no ?

Other question just for my understanding of the implementation : 
When you say "you won't be able to synchronize audio and video", are you
referring to the computation of "resultPresentationTime" in
RTPReceptionStats::noteIncomingPacket() ? 

> The real solution is to fix whatever problem in your OS is
> causing your 
> performance problem.

For now, I deactivate RTCP in debug mode, and reactivate it in release
mode.
I'll try to understand later why there is this problem in debug mode...

Thanks again for your precious supoport,

Frederic