[Bug 757688] rtponviftimestamp: element does not work properly

[GStreamer (GNOME Bugzilla)]

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

Olivier Crête <olivier.crete at ocrete.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |olivier.crete at ocrete.ca
         Resolution|---                         |FIXED
   Target Milestone|git master                  |1.7.1

--- Comment #6 from Olivier Crête <olivier.crete at ocrete.ca> ---
Merged, thank you!


commit 4c482befbd339b626d598e20bf52c1f536564c36
Author: Branko Subasic <branko at axis.com>
Date:   Thu Oct 22 13:40:36 2015 +0200

    rtponviftimestamp: use stream time for timestamp

    The Onvif Streaming Specification specifies that the NTP timestamps
    in the Onvif extension header indicaes the absolute UTC time associated
    with the access unit. But by using running time we can not achieve that,
    since a frame's running time depends on the played interval, whether a
    non-flushing is done, etc. Instead we have to use the stream time.

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

commit 6f6fe37ed995f4631859414a08e15f35858d29c9
Author: Linus Svensson <linussn at axis.com>
Date:   Fri Nov 6 09:44:57 2015 +0100

    rtponviftimestamp: Update ntp-offset and d/e-bits with a GstEvent

    It is now possible to update the currently used ntp-offset with a
    custom serialized downstream event. The element will read the ntp-offset
    property when doing the state transition from READY to PAUSED and
    use that offset until it receives a "GstNtpOffset" event, which also
    has a "ntp-offset" attribute in that it's structure. In case the
    property is not set and no event has been received, the element will
    guess the npt-offset with help of the clock. If no clock can be
    retrieved, the element will error out and stop the data flow.

    The same event is also used for updating the D/E-bits in the RTP
    extension header. The discont flag in a buffer can be set whenver a
    live/network source looses a frame, but that is not the type of
    discontinuity that the onvif extension header should reflect. The
    header is mainly used for playback of a track concept, in which
    gaps can be present, and it's those kind of gaps that should be
    highlighted with the D- and E-bits.

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

commit a58826292eab80e83b9de525753895e56410e301
Author: Linus Svensson <linussn at axis.com>
Date:   Fri Nov 6 09:44:16 2015 +0100

    rtponviftimestamp: Do not rearange order of data

    If a buffer or a buffer list is cached, no events serialized with the
    data stream should get through. The cached buffers and events should
    be purged when we stop flushing.

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

commit fd0ca0a9723931463c8be93517d13b5ef799f6f0
Author: Branko Subasic <branko at axis.com>
Date:   Tue Oct 13 14:21:47 2015 +0200

    rtponvif: split unit tests in several files

    Split the unit tests for rtponviftimestamp and rtponvifparse
    elements in separate files.
    Setup and cleanup the element and pads in fixures. Make the tests work
    with CK_FORK=no as well, by cleaning up the 'buffers' list when needed.
    Make unit tests work when run in valgrind by unreffing all buffers,
    and by not allocating any payload in RTP buffers. Since we're not
    doing anything with the payload part, but we're memcmp-aring the
    complete buffer memory, valgrind complained about non-initialized
    memory being used.

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

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