Amazon Kinesis Video Streams Producer SDK for C++ is for developers to install and customize for their connected camera and other devices to securely stream video, audio, and time-encoded data to Kinesis Video Streams.
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:
Play the pipeline.
Start a new thread to handle the start/stop mechanism at a specified interval.
Wait for the playing interval to finish using a conditional variable to allow for early exit with sigint.
Stop the stream by sending an EOS message on the pipeline.
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).
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.
Wait for the paused interval to finish using a conditional variable to allow for early exit with sigint.
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.
Issue #, if available:
What was changed?
autovideosrc) and test (videotestsrc) GStreamer sourcesWhy was it changed?
x264encelement 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.How was it changed?
The following is the flow of the new intermittent sample:
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.