curl timeout issues depending on camera #985
Replies: 13 comments
-
There is little information available in the logs. Here is an interesting part: [INFO ] [01-03-2023 00:21:06:498.228 GMT] writeHeaderCallback(): RequestId: cd3b8359-e463-eeea-9143-1febc07e745c There is a gap of 30 seconds which is the default timeout for the connection. If I were to guess, you have an issue with the camera not producing any frames or the RTSP link is broken. Suggest removing KVS from the pipeline and stabilizing the camera/RTSP link with a fakesink and then plug in the kvs. |
Beta Was this translation helpful? Give feedback.
-
Thanks for the fast response! Is there a way I can get you more information? I tried this with fakesink using the command
The RTSP link works using VLC, or at least as much as I can visually confirm (no significant frames dropping). What could be different between VLC and the producer example app?
I will also mention we are running this on an EC2 instance on us-east-1. |
Beta Was this translation helpful? Give feedback.
-
It seems that fakesink is getting some frames. I am wondering whether kvssink drops the frames at the source or something. Perhaps you could run kvssink with GSTDEBUG=4 or 5 which could give more information. I would also try to search the issues whether something similar related to EC2 and rtsp stream have been answered in the context of gstreamer. |
Beta Was this translation helpful? Give feedback.
-
I think I may of misformatted the command, but here is the log: gst_launch_log_fulldebug.txt. The log appears to be the same whether I use the public RTSP stream or our RTSP stream link, which is contrary to what I have with the sample app. Could there be a resource constraint issue? This EC2 instance is type t2.micro. Command
|
Beta Was this translation helpful? Give feedback.
-
It's hard to parse the output but it seems that there is a failure in the caps negotiation. I would recommend looking at the configuration of the stream and see some of the KVS documentation on it. I am not very familiar with it. If the two streams (working and not working) have the same configuration then I don't really understand what's going on. Perhaps someone from AWS can help. |
Beta Was this translation helpful? Give feedback.
-
Ok I'll see about getting assistance from them. When you say configuration of the stream do you mean the KVS instance or the sample app generating the pipeline? The two streams are the same RTSP URL, just changing some ports to direct it to a different camera. Would you also be able to describe what part of the process is not completing? I will link this issue, but I'd like to get a basic understanding of what's happening. |
Beta Was this translation helpful? Give feedback.
-
In this case it would be settings for the encoder and packager - the bitrate, q-values, encoding profile, resolution, frame rate. Making sure the GoP size is up-to 10 seconds long. Not much else comes to mind. From the logs I can see that KVS loads up and configures which means that it doesn't have any issues with memory pressure nor connectivity. |
Beta Was this translation helpful? Give feedback.
-
I was also looking for the source of functions like |
Beta Was this translation helpful? Give feedback.
-
These are defined in C producer layer https://github.com/awslabs/amazon-kinesis-video-streams-producer-c/blob/master/src/source/Response.c#L608 You might want to put a debug statement in the put frame call in PIC which is this: https://github.com/awslabs/amazon-kinesis-video-streams-pic/blob/master/src/client/src/Stream.c#L734 - see if the call is actually made there. Also, trace the call in the KVS sink here: https://github.com/awslabs/amazon-kinesis-video-streams-producer-sdk-cpp/blob/master/src/gstreamer/gstkvssink.cpp#L1153 see if gstreamer makes a buffer handling call and whether the buffer data is the frame data (as kvs plugin deems). Sorry I couldn't be of more help.. |
Beta Was this translation helpful? Give feedback.
-
I wanted to give a quick update for the developers with some hopefully relevant information. |
Beta Was this translation helpful? Give feedback.
-
Hi @stormon-force, To reiterate MushMal's response, we suspect that the other camera needs a different caps filter that the sample app isn't properly addressing, but the pipeline with kvssink is addressing the capsfilter just fine. Since the sample app does all the pipeline & element creation and capsfilters in C, it's probably a capsfilter the application misses that the CLI handles. We don't have any plans at the moment to look into this for recent releases. Thanks for bringing it up, though, we'll look into it in the near future. |
Beta Was this translation helpful? Give feedback.
-
Understood, I'm not very experienced with GStreamer and video streaming in general. What is the caps filter doing? But because this camera works on the Greengrass Edge Connector component, this appears to be a problem with the producer C++ SDK correct? Is it possible for us to modify the sample app to work successfully, or is it something in the SDK the team will have to look at? |
Beta Was this translation helpful? Give feedback.
-
Answering your questions:
What you may also want to try is using the sample gstreamer pipeline here: https://github.com/awslabs/amazon-kinesis-video-streams-producer-sdk-cpp/blob/master/docs/linux.md#running-the-gst-launch-10-command-to-start-streaming-from-a-rtsp-camera-source and tweak the parameters of some of the gstreamer elements according to the settings depending on your camera. If you could also, share the full gstreamer debug logs for the camera that isn't working properly, and also share what is the format of the media coming from their non-working camera? |
Beta Was this translation helpful? Give feedback.
-
Hi, we're having some issues with sending up an RTSP stream to KVS.
kvs_sample_app
, with no modifications.rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mp4
).Version: v3.3.1
Commit: 8867047
Below is a log that shows error we're experiencing when the RTSP link is pointed to the non working camera. Also attached is another log is an example of the same stream URL but with a different camera, that works. Any ideas? I'm not sure what to look for. Considering one camera works and the other doesn't leads me to believe it's a problem with some camera setting, but I'm not sure what to fiddle with. But based on some other issue pages, it may also have something to do with not producing frames for putMedia to execute? Will the basic example work here or will we need to modify it?
Log excerpt here. The error section will continue to repeat indefinetly, until token expires.
Working log
Beta Was this translation helpful? Give feedback.
All reactions