aws/amazon-kinesis-video-streams-parser-library

Trying to decode EML ID error

FlorianRuen opened this issue · 4 comments

Hi there,

First of all I'm sending all my wishes for 2021 !

I'm using the Kinesis video stream parser library in one of my project and recently I got a new error.
This library is used to extract image from Kinesis Video Stream and saved it on the disk as file (another project will treat this image after). So I take the FrameRendererVisitor to do this and I implement this in my own project.

https://github.com/aws/amazon-kinesis-video-streams-parser-library/blob/master/src/main/java/com/amazonaws/kinesisvideo/parser/utilities/FrameRendererVisitor.java

But since yestarday, I got a new error that come directly from that peace of code, here is the screenshot of the error message :
Capture d’écran de 2021-01-11 21-41-32

I don't really understand what this message mean, maybe someone have an explanation ? This is caused my the video send to my stream (maybe corrumpted video stream ?) or by the project which extract the frames ?

My stream was send to KVS using C++ Gstreamer and it's RTSP stream from CCTV system
I've an Cloudwatch alarm on IncommingBytes for this stream, and the alarm state is OK (all the time > 0, so no network interuption) ; the max PutMedia was 0.2 Mbits/s
This project run on an GPU EC2 instance (in Frankfurt AWS region) and save it to a local directory

Thanks in advance for your help,

Regards,
Florian

Hi Florian, thank you for highlighting this. My name is Hunaid and I'm a Product Manager with Kinesis Video Streams. We are trying to resolve this issue. It seems like your end usecase is to run ML pipeline on video frames. I would love to get on a call and learn more about your usecases and brainstorm ideas for possible upgrades to our service. Please feel free to drop me a mail at hunai@amazon.com.

It's hard to understand what's going on. I assume this is happening on a non-continuous basis and this is not something that started happening and continues happening?

@FlorianRuen on a "realtime" path when you are running GetMedia on the head you might encounter what seems to be a corrupt stream in the parser. This is by design and let me explain. In order to provide for low latency, we use GetMedia with the appropriate selector. The bits produced by the Producer SDK are immediately delivered to the GetMedia consumer which then uses the parser to parse out the bits. If, for some reason, there was an issue on the Producer side, you will be getting the "error" on the consumer side (due to low latency requirement). The producer will then re-stream automatically but your consumer application needs to handle this.

  • Your consumer application needs to handle the different types of errors. For example, on these types of errors you might want to restart your consumer application
  • Your application can keep the fragment number that's was the last to be processed so you can continue from there - sort of check pointing.
  • Check your producer SDK and make sure that these issues are caused by temporary conditions such as networking hiccups and not your encoder (given the error in the picture, it's related to the packaging - aka MKV generator in the Producer SDK which does the correct thing.)

@has253 Thanks for your message, I will drop you an e-mail soon

@MushMal

Thanks for your answer.

After this error, if we restart our application, it works again before the next same error message (can be fired in hours or days it really depends). So yes, after this error, we want to restart our consumer application. I will add a try / catch block to handle the IllegalArgumentException, maybe it will fix this.

If I understand what you say, if the producer encounter an error (slow bitrate or something) and there is no stream on KVS, my producer can create this kind of error (due to the real time / low latency constraint) ? Because I've an CW alarm on my stream and the status is always OK, but sometime, for few seconds, my producer stops (slow bitrate) and restart almost immediatly.

Resolving due to staleness. Please cut a new issue if you have further questions.