The default behaviour of rtponviftimestamp is to drop buffers
outside the segment. This creates obvious problems for reverse
playback.
The ONVIF specification unfortunately doesn't describe how to handle
that specific use case, but we can expose a property to let the
user disable the dropping behaviour, and forward these buffers with
a G_MAXUINT64 ONVIF timestamp.
Also modify rtponvifparse to handle such timestamps appropriately.
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
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
