[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

Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nicolas at ndufresne.ca

--- Comment #6 from Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> ---
(In reply to Olivier Crête from comment #5)
> Yes, the packets can be re-ordered.. The idea is that we should catch the
> wrap-around, but reasonable differences should be ignored.

Did you read the doc ?

 * This function makes sure that the returned value is a constantly increasing
 * value even in the case where there is a timestamp wraparound.

Reading the code of this function, clearly it was in no way meant to support
consecutive backward timestamp. Those currently cause a big forward jump if I
read properly. Because of the doc, I would have expected the exttimestamp to be
returned, and left unmofied if timestamp is detected as going backward. That of
course assumes we can always detect it.

Can we hold on a bit and not rush this change right before a release ?

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