[Bug 780446] gst_rtp_buffer_ext_timestamp() math is incorrect for big jumps

[GStreamer (GNOME Bugzilla)]

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

--- Comment #14 from Miguel París Díaz <mparisdiaz at gmail.com> ---
Hello,
it seems that George and I have come across the same issue. I opened a new one
few days ago: https://bugzilla.gnome.org/show_bug.cgi?id=783443

>From my point of view, I am pretty sure that we should provide an utility to
deal with backward RTP timestamp to be used in places where missordered packets
are handled. So, there are typically 2 alternatives:
  a1 - Create a new function to provide this functionality.
  a2 - Update gst_rtp_buffer_ext_timestamp implementation.

In relation to (a2) the main problems are:
  p1 - doc says "This function makes sure that the returned value is a
onstantly increasing value even in the case where there is a timestamp
wraparound."
  p2 - Could this break currently usages of this function? Or just would fix
them?

Regarding (p1) is not really true because this happens:
  ext = -1;
  gst_rtp_buffer_ext_timestamp(&ext, 2) == 2
  gst_rtp_buffer_ext_timestamp(&ext, 1) == 1
So what I think is that the doc is not properly written and I suppose that what
it wants to say is something like "This function takes into account timestamp
wraparound making sure that the returned value is increased." (actually this is
what it does).

In relation to (p2), I think that taking into account backward timestamps and
performing unwrapping will fix the function.

In conclusion, I would update the implementation of
gst_rtp_buffer_ext_timestamp and the doc.
What do you think?

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