[FFmpeg-devel] RTCP question
Michael Niedermayer
michaelni at gmx.at
Wed May 14 02:55:14 CEST 2014
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140514/5c130ade/attachment.asc>
More information about the ffmpeg-devel
mailing list