RTCP packets and hooking about uvgrtp

[altonen]

Hi,

as Marko already mentioned/implied, the RTCP code was hacked together fast and is quite untested so there be dragons but unfortunately I'm not sure what kind of pressure there is to fix these bugs right now at least.

As for these issues, I'm not sure what you mean by RTCP being horribly out of sync. I believe we set, for simplicity's sake, the RTCP interval to maximum which I believe is around 5 seconds. So every 5 seconds you should receive an RTCP report. RTCP reports are not tied to any single RTP packet but to an interval of time where multiple RTP packets may arrive.

The fix to stop the RTCP reports from coming after sender has stopped streaming is quite simple. The RTCP runner could keep track of when the last packet from the participant was received and if it was more than some interval, it could convert the participant back to receiver (i.e., it wouldn't send RTCP packets to that participant anymore). Somebody should check what the specification has to say about this though.

The crash is probably quite easy to fix. When the session is destroyed, the RTCP destructor must block until the RTCP runner has stopped. This could be done with a condition variable/simple boolean to signal the RTCP runner that is must stop.

[jrsnen]

Just to clarify on the previous response, we (Ultra Video Group) will fix all reasonable issues users encounter, but we have somewhat limited resources to dedicate to this task (after @altonen graduated). If no one else has time, I will look at this bug when I have the time. Unfortunately, I'm not very familiar with the library.

As far as I understand, RTCP reports are supposed to be sent at constant intervals regardless of how many frames the user sends.

[wowaser]

@polusto That is fine, I will submit a pull request to the previous issue (about APP packets) tomorrow. This one is not as critical

[jrsnen]

I'm closing this issue since there doesn't seem to any direct bugs. There will probably be a slight improvement to the timing accuracy of the reports coming in near future. We may continue the discussion of RTCP reports in issue #59