|ObjectPtr||source () const|
|quint64||timestamp () const|
|EventType||type () const|
|QString||typeName () const|
|quint32||sequenceNumber () const|
|void||setSequenceNumber (quint32 num)|
|EventPtr||copy () const|
Wrapper class for GstEvent.
Events are passed between elements in parallel to the data stream. Some events are serialized with buffers, others are not. Some events only travel downstream, others only upstream. Some events can travel both upstream and downstream.
The events are used to signal special conditions in the datastream such as EOS (end of stream) or the start of a new stream-segment. Events are also used to flush the pipeline of pending data.
Events are implemented as a subclass of MiniObject with a generic GstStructure as the content. Notice that the source property is set by GStreamer when the event is passed to the Pad with send() or push(). In the case of Element::sendEvent() the behavior is similar, as this internally translates to searching for a random pad with the correct direction and then pushing the event to it. So there is no need to set the source of the event in QtGStreamer.
In these bindings, for convenience, each event type has its own Event subclass. This does not reflect 1-1 the native C API, where there is only one Event class with tens of 'new_foo' and 'parse_foo' methods. You can use RefPointer::dynamicCast() to cast a EventPtr to a RefPointer of one of the Event subclasses and it will behave as expected (i.e. it will only succeed if the event type matches the event type that the subclass handles). Note however that the Event subclasses cannot be used with Value::get(), since a GValue will actually contain a GstEvent (the subclasses do not exist in C) and Value::get() is not able to do dynamic casts. As a result of that, Event subclasses also cannot be used as arguments in slots connected to GObject signals, even though you may know that your slot will only be called with that type of event.