[Bug 757688] New: rtponviftimestamp: element does not work properly

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 757688
           Summary: rtponviftimestamp: element does not work properly
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: ognyan.tonchev at axis.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Setting ntp offset with a property is not good enough. Setting an offset in
state other than NULL is not allowed but even if it was it would be racy. We
basically need to know from which buffer the new offset is to be applied.

Another issue is that the discont flag on the buffer can't be used for setting
the E/D-bits. The discont flag in a buffer can be set whenever 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.

The element currently uses running time for Onvif-timestamping. 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.

A bug that we found as well and have now fixed: 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.

There is also a small patch attached which splits unit tests in several
files(there are two separate elements and we now have one file per element) and
makes it work with CK_FORK=no and in valgrind.

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