amazon-kinesis-video-streams-producer-sdk-cpp: Error code 0x52000060

Hi there,

I am using the C++ Producer SDK to stream from an Axis camera (https://axis.com/en-au/products/axis-m1065-lw). I am getting the following error when doing so:

putStreamResultEvent(): Put stream result event.
writeHeaderCallback(): RequestId: e9f5139b-2571-1cf4-bf09-a8746b6bdc0d
Reporting stream error. Errored timecode: 0 Status: 1375731808
continuousRetryStreamErrorReportHandler(): Reporting stream error. Errored timecode: 0 Status: 0x52000060
 getStreamData(): Indicating an end-of-stream for a terminated stream upload handle 4038
 postReadCallback(): Reported end-of-stream for stream ac-cc-8e-b9-99-41. Upload handle: 4038

In particular, I see 0x52000060, which the documentation states that I should not receive 😃

“The Producer SDK enforces timestamps, so clients using the SDK should not receive this error.” (from https://docs.aws.amazon.com/kinesisvideostreams/latest/dg/producer-sdk-errors.html)

Can you help me understand why I would be seeing this error, and if there is anything I can do to fix it?

cheers, Stretch

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 15 (9 by maintainers)

Most upvoted comments

@str3tch Could I ask you to run a verbose logging and send the following info to kinesis-video-support@amazon.com or paste the info here?

Account ID, Stream Name, Region, Time, Logs (most of these will be available in the logs anyway)

MushMal on Apr 6, 2020

0x52000060 is an error that’s returned from the backend. The text representation that’s sent down contains error name which is FRAGMENT_TIMECODE_LESSER_THAN_PREVIOUS - the #define in the native code defines it as STATUS_ACK_ERR_FRAGMENT_TIMECODE_NOT_MONOTONIC - those are the same things.

The backend currently enforces Fragment start timestamp which is the key frame timestamp should be strictly greater than the last Fragments last Frame timestamp, assuming that frames are not points in time but have durations. The SDK, however, has a slightly relaxed enforcement which is greater or equal, this still preserves the semantic validity of the stream and the MKV format.

It seems that your pipeline is producing frames which overlap causing the issue.

What’s odd is that the logs contain stretches of successful streaming - for instance, all the last part starting from 08:16:05 and going until 08:26:15 has no issues.

I wonder if the RTSP link itself has some latency that produces this bizarre behavior.

Here is my recommendation:

Try to dump out the frame timestamps - those would be useful to clearly pinpoint the issue to what I described. You can do that by setting DEBUG_DUMP_FRAME_INFO env variable to true
Try to get as much information as possible as to why suddenly you have a couple of runs which are working just fine and some that get this bizarre error. Try to ensure you have a good networking throughput as the bandwidth is effectively doubling by streaming RTSP to the device and KVS stream out of the device. Try a different network, AP or region to see if this makes any difference.
We are attempting to track whether this might be caused by the RTSP GStreamer pipeline producing frames which are slightly apart from each other but due to a millisecond timestamp scale get squashed together to the same timestamp. If so, we are trying to remedy it by attempting to use the higher precision time code scale. Unfortunately, the default millisecond granularity allows to encode frames with signed 16 bit values which makes it around 32 second fragments. If we reduce it to 100micros granularity, we could only encode 3.2 second fragments max.

We will update this issue as we get more information.

MushMal on Apr 1, 2020