[Bug 772646] rtpjitterbuffer: fix lost-event using dts instead of pts

[GStreamer (GNOME Bugzilla)]

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

Sebastian Dröge (slomo) <slomo at coaxion.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|git master                  |1.11.1

--- Comment #13 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
commit fb9c75db360ff1aa61710804b08788b6c35f44df
Author: Havard Graff <havard.graff at gmail.com>
Date:   Sun Oct 9 15:59:05 2016 +0200

    rtpjitterbuffer: fix lost-event using dts instead of pts

    The lost-event was using a different time-domain (dts) than the outgoing
    buffers (pts). Given certain network-conditions these two would become
    sufficiently different and the lost-event contained timestamp/duration
    that was really wrong. As an example GstAudioDecoder could produce
    a stream that jumps back and forth in time after receiving a lost-event.

    The previous behavior calculated the pts (based on the rtptime) inside the
    rtp_jitter_buffer_insert function, but now this functionality has been
    refactored into a new function rtp_jitter_buffer_calculate_pts that is
    called much earlier in the _chain function to make pts available to
    various calculations that wrongly used dts previously
    (like the lost-event).

    There are however two calculations where using dts is the right thing to
    do: calculating the receive-jitter and the rtx-round-trip-time, where the
    arrival time of the buffer from the network is the right metric
    (and is what dts in fact is today).

    The patch also adds two tests regarding B-frames or the
    “rtptime-going-backwards”-scenario, as there were some concerns that this
    patch might break this behavior (which the tests shows it does not).

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