[Bug 738363] jitterbuffer: lost-events are broken

[GStreamer (GNOME Bugzilla)]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #10 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
commit ddd032f56b64316d5a1aa5b267ad34df4e774373
Author: Havard Graff <havard.graff at gmail.com>
Date:   Wed Jul 8 21:08:36 2015 +0200

    rtpjitterbuffer: fix gap-time calculation and remove "late"

    The amount of time that is completely expired and not worth waiting for,
    is the duration of the packets in the gap (gap * duration) - the
    latency (size) of the jitterbuffer (priv->latency_ns). This is the duration
    that we make a "multi-lost" packet for.

    The "late" concept made some sense in 0.10 as it reflected that a buffer
    coming in had not been waited for at all, but had a timestamp that was
    outside the jitterbuffer to wait for. With the rewrite of the waiting
    (timeout) mechanism in 1.0, this no longer makes any sense, and the
    variable no longer reflects anything meaningful (num > 0 is useless,
    the duration is what matters)

    Fixed up the tests that had been slightly modified in 1.0 to allow faulty
    behavior to sneak in, and port some of them to use GstHarness.

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

commit 40524e5a493702fa9ff67fde43f94a9da2f16233
Author: Stian Selnes <stian at pexip.com>
Date:   Tue Jun 30 11:21:31 2015 +0200

    Revert "rtpjitterbuffer: Fix expected_dts calc in calculate_expected"

    This reverts commit 05bd708fc5e881390fe839803b53144393d95ab0.

    The reverted patch is wrong and introduces a regression because there
    may still be time to receive some of the packets included in the gap
    if they are reordered.

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