2016-12-05 21:12:24 +00:00
|
|
|
# Seqnums (Sequence numbers)
|
|
|
|
|
|
|
|
Seqnums are integers associated to events and messages. They are used to
|
|
|
|
identify a group of events and messages as being part of the same
|
|
|
|
*operation* over the pipeline.
|
|
|
|
|
|
|
|
Whenever a new event or message is created, a seqnum is set into them.
|
|
|
|
This seqnum is created from an ever increasing source (starting from 0
|
2016-12-30 06:58:58 +00:00
|
|
|
but it might wrap around), so each new event and message gets a new and
|
2016-12-05 21:12:24 +00:00
|
|
|
hopefully unique seqnum.
|
|
|
|
|
|
|
|
Suppose an element receives an event A and, as part of the logic of
|
2016-12-30 06:58:58 +00:00
|
|
|
handling the event A, creates a new event B. B should have its seqnum be
|
2016-12-05 21:12:24 +00:00
|
|
|
the same as A, because they are part of the same operation. The same
|
|
|
|
logic applies if this element had to create multiple events or messages,
|
|
|
|
all of those should have the seqnum set to the value on the received
|
|
|
|
event. For example, when a sink element receives an EOS event and
|
|
|
|
creates a new EOS message to post, it should copy the seqnum from the
|
|
|
|
event to the message because the EOS message is a consequence of the EOS
|
|
|
|
event being received.
|
|
|
|
|
|
|
|
Preserving the seqnums accross related events and messages allows the
|
|
|
|
elements and applications to identify a set of events/messages as being
|
|
|
|
part of a single operation on the pipeline. For example, flushes,
|
|
|
|
segments and EOS that are related to a seek event started by the
|
|
|
|
application.
|
|
|
|
|
|
|
|
Seqnums are also useful for elements to discard duplicated events,
|
|
|
|
avoiding handling them again.
|
|
|
|
|
2016-12-30 06:58:58 +00:00
|
|
|
## Scenarios
|
|
|
|
|
2016-12-05 21:12:24 +00:00
|
|
|
Below are some scenarios as examples of how to handle seqnums when
|
|
|
|
receving events:
|
|
|
|
|
2016-12-30 06:58:58 +00:00
|
|
|
### Forcing EOS on the pipeline
|
2016-12-05 21:12:24 +00:00
|
|
|
|
|
|
|
The application has a pipeline running and does a
|
2016-12-30 06:58:58 +00:00
|
|
|
`gst_element_send_event()` to the pipeline with an EOS event. All the
|
2016-12-05 21:12:24 +00:00
|
|
|
sources in the pipeline will have their `send_event` handlers called and
|
|
|
|
will receive the event from the application.
|
|
|
|
|
|
|
|
When handling this event, the sources will push either the same EOS
|
|
|
|
downstream or create their own EOS event and push. In the later case,
|
|
|
|
the source should copy the seqnum from the original EOS to the newly
|
2016-12-30 06:58:58 +00:00
|
|
|
created one. This same logic applies to all elements that receive the EOS
|
2016-12-05 21:12:24 +00:00
|
|
|
downstream, either push the same event or, if creating a new one, copy
|
|
|
|
the seqnum.
|
|
|
|
|
|
|
|
When the EOS reaches the sink, it will create an EOS message, copy the
|
|
|
|
seqnum to the message and post to the bus. The application receives the
|
2016-12-30 06:58:58 +00:00
|
|
|
message and can compare its seqnum with the one from the
|
2016-12-05 21:12:24 +00:00
|
|
|
original event sent to the pipeline. If they match, it knows that this
|
|
|
|
EOS message was caused by the event it pushed and not from other reason
|
|
|
|
(input finished or configured segment was over).
|
|
|
|
|
2016-12-30 06:58:58 +00:00
|
|
|
### Seeking
|
2016-12-05 21:12:24 +00:00
|
|
|
|
2016-12-30 06:58:58 +00:00
|
|
|
A seek event sent to the pipeline is forwarded to all sinks in it. These
|
|
|
|
sinks, then, push the `SEEK` event upstream until they reach an element
|
2016-12-05 21:12:24 +00:00
|
|
|
that is capable of handling it. If the element handling the seek has
|
|
|
|
multiple source pads (tipically a demuxer is handling the seek) it might
|
|
|
|
receive the same seek event on all pads. To prevent handling the same
|
|
|
|
seek event multiple times, the seqnum can be used to identify those
|
2016-12-30 06:58:58 +00:00
|
|
|
events as being the same and only handle the one received first.
|
2016-12-05 21:12:24 +00:00
|
|
|
|
2016-12-30 06:58:58 +00:00
|
|
|
Also, when handling the seek, the element might push `FLUSH_START`,
|
|
|
|
`FLUSH_STOP` and a segment event. All these events should have the
|
|
|
|
seqnum of the received seek event. When this segment is over and an
|
|
|
|
`EOS/SEGMENT_DONE` event is going to be pushed, it should also have the
|
|
|
|
seqnum of the seek that originated the segment to be played.
|
2016-12-05 21:12:24 +00:00
|
|
|
|
2016-12-30 06:58:58 +00:00
|
|
|
Having the same seqnum as the seek on the `SEGMENT_DONE` or EOS events is
|
2016-12-05 21:12:24 +00:00
|
|
|
important for the application to identify that the segment requested by
|
|
|
|
its seek has finished playing.
|
|
|
|
|
2016-12-30 06:58:58 +00:00
|
|
|
## Questions
|
2016-12-05 21:12:24 +00:00
|
|
|
|
|
|
|
What happens if the application has sent a seek to the pipeline and,
|
|
|
|
while the segment relative to this seek is playing, it sends an EOS
|
|
|
|
event? Should the EOS pushed by the source have the seqnum of the
|
|
|
|
segment or the EOS from the application?
|
|
|
|
|
|
|
|
If the EOS was received from the application before the segment ended,
|
|
|
|
it should have the EOS from the application event. If the segment ends
|
|
|
|
before the application event is received/handled, it should have the
|
|
|
|
seek/segment seqnum.
|