Avoiding dropped frames about amazon-kinesis-video-streams-producer-c HOT 7 CLOSED

@ronievron you need to mention which asset you are attempting to use.

The default policy that's applied in samples, etc.. will keep the frames in the buffer for as long as there is physical space in the content store to put a new frame or if the buffer duration is reached (controlled by StreamInfo.StreamCaps.bufferDuration).

The SDK will call notifications when maxLatency duration is accumulated in the buffer to trigger a response from the application. Some applications might choose to do frame thinning or pausing the encoder to clear up the buffer.

More info is here: https://github.com/awslabs/amazon-kinesis-video-streams-producer-sdk-cpp/blob/master/docs/buffering.md

Your application could have its own policies on how to deal with frame dropping but in general, it's best to leave it to the SDK to handle the buffering. Again, if your encoder is producing frames at the constant rate but your network is not allowing them to be forwarded to the cloud, something has to give.

from amazon-kinesis-video-streams-producer-c.

Please resolve if you have no more questions regarding this subject itself.

from amazon-kinesis-video-streams-producer-c.

Hi,

Thanks for the quick response.

Looking at the doc that you referred to, it says:
As the content store fills up (due to buffering) storage pressure callback will be issued when the Content Store utilization reaches 95% (less than 5% available storage).
So, I assume that this will happen before any frames are dropped, giving me a chance to reduce the frame rate or bit rate.
If this is so, is there a way to monitor the Content Store so that I can increase the frame rate once conditions improve?
Also, looking at PClientCallbacks, I see the following members:
storageOverflowPressureFn
bufferDurationOverflowPressureFn
streamLatencyPressureFn
But, it's not clear which of these will be invoked when the Content Store reaches 95% capacity.

Thanks again,

Roni

from amazon-kinesis-video-streams-producer-c.

The document describes both aspects of the pressures - the physical content store pressure and the temporal pressure on the content view. Depending on your scenario and the configuration, you might get the content store pressure first or the temporal pressure first. These will be fired before the frames are dropped. The continuous retry policy which is implemented in e C Producer layer will react to these. For example, on latency pressure (temporal content view pressure callback) it will attempt to reset the connection in hopes of getting a faster connection. You can model your application reaction based on these callbacks. Another alternative is to base the logic on the metrics that your application could periodically extract from the PIC. You can see the content store availability and the current view durations.

from amazon-kinesis-video-streams-producer-c.

Sounds like getting metrics from the PIC is the right solution for my use case. Is there any documentation or examples on doing this?

from amazon-kinesis-video-streams-producer-c.

The C Producer itself retrieves the metrics and prints them on every key frame after some period lapse. The APIs and the public structures are well commented.

Your application can periodically call both client and the stream metrics to make decisions. Note: content store is shared among the steams so it’s a client object level metric whereas the content view info which is a temporal info is a stream level metric.

https://github.com/awslabs/amazon-kinesis-video-streams-pic/blob/master/src/client/include/com/amazonaws/kinesis/video/client/Include.h#L2075

from amazon-kinesis-video-streams-producer-c.

Looks like that's what I need. Thanks!

from amazon-kinesis-video-streams-producer-c.