I am uploading recorded data using gstreamer’s s3sink on a jetson nano. During the load test, gstreamer suddenly stops after 4 or 5 hours. The command used in the test is as follows.
The investigation we have done so far is as follows.
No recording data is generated in s3 when this phenomenon occurs.
The investigation of cpu usage and memory usage when this phenomenon occurred has not been completed, but at least the OS is not shut down.
Resources were not strained as far as ssh to jetson to see cpu usage and memory usage after 30 minutes or 2 hours while this command was being executed.
The exit status of gst-launch-1.0 was displayed as “PIPE”.
The logs of multipart uploads in the s3 bucket logs were all 200.
When this phenomenon did not occur, the recording data was generated in s3.
Although not tested a sufficient number of times, I don’t seem to have this problem when using filesink instead of s3sink
We tested with a total of three cameras, an HD Web Cam from logitech and two different 4K Cam modules from ELP, but the event occurred with all cameras.
The s3sink plugin was INSTALLED according to the following instructions.
If possible, I would like to use the latest plugin below, which allows detailed specification of retry settings and error behavior, but this plugin could not be compiled unless gstreamer is v1.16 or higher.
Also, it seems that the plugin for hardware encoding is only available in jetson with gstreamer 1.14.
Is there anything else we can do to investigate this phenomenon? Also, if you have any idea about this phenomenon, please advise.
The default release is with gstreamer 1.14.5. We would suggest use default release since it is validated in SQA coverage and shall be stable. It may not work properly if you upgrade to other version.
I was wondering if I was violating the restrictions on multipart uploads to s3. Checking the s3 log, the last log shows a multipart upload PUT with partNumber=5427 and a response of 200. 5242880 is the default partSize, so the total data sent is 28,453 MB. Neither the total size nor the partNumber limit was reached.
Hi,
We would suggest consult with the author for further information. Since we don’t have experience about the plugin, it is not easy to suggest next. Would be better if you can check with author of the plugin to get further suggestion.
I don’t know if the author will be able to accommodate me on that, so I would like to explore other options.
build official s3sink with 1.16 gstreamer, which has not been verified by nvidia but is officially created, and verify if it can work together with nvv4l2 related so files in the driver that nvidia has put out.
consider other methods for multipart upload to s3 other than s3sink
For 1. can we start the verification by putting the nvidia plugin in the following directory after building the official gstreamer ourselves? I know there is no guarantee that it will work, so I would like to know if this procedure is appropriate in preparation for verification.
Regarding #2, other than s3sink, are there any other plugins for multipart uploading that can be used with jetson nano?
