[Bug 751311] rtp: Dynamic dropout / reorder limits

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=751311

--- Comment #25 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to Miguel París Díaz from comment #24)
> Review of attachment 306390 [details] [review]:
> 
> ::: gst/rtpmanager/rtpstats.c
> @@ +39,3 @@
> +guint32
> +gst_rtp_packet_rate_ctx_update (RTPPacketRateCtx * ctx, guint16 seqnum,
> +    guint32 ts, gint32 clock_rate)
> 
> What happens if it changes?

The caller calls gst_rtp_packet_rate_ctx_reset() with the new clock rate

> @@ +60,3 @@
> +  }
> +
> +  diff_ts = ts - ctx->last_ts;
> 
> How can I manage wraparounds?
> There is any utility?

gst_rtp_buffer_ext_timestamp()

> Do you mean use this values?:
>  rtpsource: RTPPacketInfo.ntpnstime
>  jitterbuffer: dts

No, those are different things

> @@ +63,3 @@
> +  diff_ts = gst_util_uint64_scale_int (diff_ts, GST_USECOND, clock_rate);
> +  ctx->avg_packet_rate =
> +      ((7 * (ctx->avg_packet_rate + 1)) + (1000 * diff_seqnum / diff_ts)) /
> 8;
> 
> This may be more inefficient?
> Or something insignificant?

Insignificant, and less confusing :) We already have too many different units
in the RTP code, let's not add yet another one.

> ::: gst/rtpmanager/rtpstats.h
> @@ +209,3 @@
> +void gst_rtp_packet_rate_ctx_destroy (RTPPacketRateCtx *ctx);
> +guint32 gst_rtp_packet_rate_ctx_update (RTPPacketRateCtx *ctx, guint16
> seqnum, guint32 ts, gint32 clock_rate);
> +guint32 gst_rtp_packet_rate_ctx_get (RTPPacketRateCtx *ctx);
> 
> I do not know what do you mean

E.g. GstRTPSource struct would contain
struct _GstRTPSource {
  ...
  RTPPacketRateCtx packet_rate_ctx; /* no pointer */
  ...
}

and would call things like gst_rtp_packet_rate_ctx_reset(&src->packet_rate_ctx,
src->clock_rate).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.