kvssink soft start/stop support

[stefankiesz]

Issue #, if available:

What was changed?

• Added a sample for intermittent streaming with kvssink that involves no tearing down of the gstreamer pipeline nor kvssink resources - a "soft" stop.
  • The sample supports device (autovideosrc) and test (videotestsrc) GStreamer sources
• Modified kvssink's handling and the behavior of EOS events
  • kvssink no longer sends an EOS message and event nor frees the KVS stream upon null buffers
  • kvssink does now send an EOS message to the bus upon receiving an EOS event
  • kvssink now sends an EOFR frame upon receiving an EOS message

Why was it changed?

• Not sending an EOS upon receiving a null buffer more closely aligns kvssink with expected sink element behavior. It is typical for the source element of a pipeline to send EOS events down stream. The x264enc element will send null buffers to itself to clear its queue of buffered frames upon receiving an EOS event, so freeing KVS resources upon a null buffer would not allow for soft stops in this fashion.
• Upon receiving and handling an EOS event, sink elements should notify the bus via an appropriate message that the pipeline has completed the EOS. This proper handling of the EOS event allows the intermittent sample application to listen in for the EOS message to confirm when it will be safe resume the stream - we want the EOS event to have fully propagated down the pipeline before resuming the stream. The sending of an EOFR prevents the latest fragment prior to pausing from being held in the KVS buffer for the KVS intermittent wait duration.

How was it changed?

The following is the flow of the new intermittent sample:

1. Play the pipeline.
2. Start a new thread to handle the start/stop mechanism at a specified interval.
3. Wait for the playing interval to finish using a conditional variable to allow for early exit with sigint.
4. Stop the stream by sending an EOS message on the pipeline.
5. Wait for a return EOS message to come on the bus once kvssink receives the EOS (this is on the separate, bus/main_loop thread).
6. Send a flush start event on the pipeline. This removes the EOS from sticking on the elements, but they still remain in a stopped state.
7. Wait for the paused interval to finish using a conditional variable to allow for early exit with sigint.
8. Send a flush stop event on the pipeline to resume streaming.

What testing was done for the changes?

Testing for data loss was conducted by streaming footage of a running stop watch at a start/stop period of less than a fragment (6, 8, and 10 second intervals were tested). The time segment captured by the ingested KVS stream was compared to the desired start/stop increments. All fragments were within 100ms of the expected duration, except for the first fragments of streams which were ~300ms shorter than expected, likely due to time taken constructing resources.

Testing was also conducted with longer increments of 2min playing and 5min paused. The stream continued to stop and start with no issues. Below shows 1 hour of such a test with the orange-colored timeline showing where there were ingested fragments.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[disa6302]

Awesome!

[sirknightj]

Saying null ptr in warn looks scary & looks like an error. This is handling the case where kinesis_video_stream failed to initialize?

[stefankiesz]

Yes and as a safety measure in case either of these two pointers get nulled. This correlates with a STATUS_NULL_ARG error we get from Producer for these kind of null checks. How does "Null argument, failed to put EOFR for " sound?

[sirknightj]

I'm thinking that we should just make this an INFO log and say what it's doing literally.

"Kinesis Video Stream failed to initialize, not putting EOFR".

[stefankiesz]

I'm still leaning towards having it be a WARN since it 'failed' to initialize. @disa6302 any thoughts?