I am dealing with a use-case that may involve long pauses in streaming. Because of this, it may be useful to ensure that a fresh RTCP SR packet is sent when streaming restarts. Here is a code fragment from rtpenc.c, round line 500: rtcp_bytes = ((s->octet_count - s->last_octet_count) * RTCP_TX_RATIO_NUM) / RTCP_TX_RATIO_DEN; if ((s->first_packet || ((rtcp_bytes >= RTCP_SR_SIZE) && (ff_ntp_time() - s->last_rtcp_ntp_time > 5000000))) && !(s->flags & FF_RTP_FLAG_SKIP_RTCP)) { rtcp_send_sr(s1, ff_ntp_time(), 0); s->last_octet_count = s->octet_count; s->first_packet = 0; } Notice the AND between the byte-ratio and time-elapsed conditions. Would it make more sense to make this an OR? IE: shouldn't we send a fresh SR message if *either* condition were true, as opposed to both simultaneously? As written, there could be a pause for 10 minutes, but if not enough bytes have been sent yet, it may be several packets before a fresh SR message is sent. Am I missing something here? I suppose the intention is that if the overall bandwidth use is very low, then don't fill it up with SR messages. I would argue that in that case, you won't add much to bandwidth usage anyway.
On Thu, Apr 24, 2014 at 05:05:17PM -0600, Fred Rothganger wrote:
I am dealing with a use-case that may involve long pauses in streaming. Because of this, it may be useful to ensure that a fresh RTCP SR packet is sent when streaming restarts.
Here is a code fragment from rtpenc.c, round line 500:
rtcp_bytes = ((s->octet_count - s->last_octet_count) * RTCP_TX_RATIO_NUM) / RTCP_TX_RATIO_DEN; if ((s->first_packet || ((rtcp_bytes >= RTCP_SR_SIZE) && (ff_ntp_time() - s->last_rtcp_ntp_time > 5000000))) && !(s->flags & FF_RTP_FLAG_SKIP_RTCP)) { rtcp_send_sr(s1, ff_ntp_time(), 0); s->last_octet_count = s->octet_count; s->first_packet = 0; }
Notice the AND between the byte-ratio and time-elapsed conditions. Would it make more sense to make this an OR? IE: shouldn't we send a fresh SR message if *either* condition were true, as opposed to both simultaneously? As written, there could be a pause for 10 minutes, but if not enough bytes have been sent yet, it may be several packets before a fresh SR message is sent.
Am I missing something here? I suppose the intention is that if the overall bandwidth use is very low, then don't fill it up with SR messages. I would argue that in that case, you won't add much to bandwidth usage anyway.
what does the RFC say about the RTCP SR interval ? if theres a max time specified then the code should honor that independant of how many bytes have been transmitted [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML.
participants (2)
-
Fred Rothganger -
Michael Niedermayer