- you can use “ffplay 1.h264” to view a H264 file.
- about " by filesink do you mean with mp4 format via deepstream filesink or gstreammer again?", I mean, using filesink to record two mp4 files for two rtsp sources. please still use the same two input RTSP sources in the latest test. please check if the two output mp4 files are fine. if the two output mp4 files are fine, that means the artifacts issue is only related to udpsink and rtspserver. could you share the two files? You can use forum private email. please click forum avatar → "personal messages’ → “view all personal messages” → “new message”.
Hi, thanks! I could view the test2.h264 and the output was better than what i viewed through vlc, no artifacts in test2.h264 , I tried recording test1.h264 again however it stopped recording automatically after 1 minute with this error
ERROR: from element /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstUDPSrc:udpsrc0: Internal data stream error.
Additional debug info:
../libs/gst/base/gstbasesrc.c(3127): gst_base_src_loop (): /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstUDPSrc:udpsrc0:
streaming stopped, reason not-linked (-1)
Execution ended after 0:01:02.134474514
Setting pipeline to NULL ...
Freeing pipeline ...
and I can see this sort of output via ffplay for test1.h264,
constantly covering the screen,
NOTE: test2.h264 didn’t have any artifacts of this sort and it was recorded before latest test1.h264
- I generated output through deepstream’s file sink through config, I can say without using new_nvstreammux i could export the videos and view it through ffplay and there was minimal artifacts, not as apparent as previous h264 outputs and I suspect the minimal artifacts could be because of the camera streams itself or not using new_nvstreammux. I couldn’t get a viewable file with new_nvstreammux enabled through file-sink in deepstream
[EDIT] I cannot attach .h264 files in the forum it’s not allowing me to attach the files.
Thank for the sharing! let’s still test these two input rtsp sources(source A and B).
- please refer to my last comment. if using two filesink to record two mp4 files, will the two output mp4 files be fine? does the artifacts issue persist?
- if using one source A and one filesink, will the output mp4 be fine?
- if using one source B and one filesink, will the output mp4 be fine?
the results above are important to narrow down the issue.
Hi,
- I tried recording the two rtsp outputs via gstreammer command and both files had the green artifacts, Note. this was without using New_nvstreammux, on stream B it was more apparent and in stream A it was minimal.
recorded using this command:
gst-launch-1.0 rtspsrc location=rtsp://localhost:8550/ds-test ! rtph264depay ! h264parse ! 'video/x-h264,stream-format=byte-stream' ! filesink location=test1.mp4
- when testing with source A alone and one file sink, I noticed the green artifacts only in the beginning moments of the video after which they disappeared [recording length of 1 minute]
- when testing with source B alone and one file sink, I noticed the same green artifacts only for a longer duration than before, and after that the artifacts disappeared completely. [recording length of 2 minutes]
[EDIT - I tried the same scenarios with new_nvstreammux and got same result in all 3]
we need to know if the issue occurred before or after encoding. In point 2,3, seems the result are the artifacts occurred at the beginning, and disappeared after a while. you can test old nvstreammux first.
- if using ffplay play the input rtsp source directly(not output rtsp)? Is there artifacts on the video?
- in your point 1, will the artifacts disappear after a while or after a long time? please refer to my last two comments. I would like to know, if using two rtsp source A,B and two filesink, will the two output mp4 be fine? will the artifacts disappear? Thanks!
- For input stream A, I observed almost no artifacts, however for input stream B there were momentary artifacts where the screen would turn blocky like before but no green artifacts present anywhere on either stream when played through ffplay.
After continued monitoring and recording a 4 minute output from just deepstream file sink, I observed no artifacts with two sources and 2 file sinks [this was through deepstream sink config with type=3]
- While using file sink to record rtsp outputs from deepstream rtsp sink, stream A kept causing errors while recording and stopped midway and stream B was a bit more consistent in recording.
the green artifacts were present in both stream outputs and only in beginning phase, stream B had more long lasting artifacts but they were gone from the frame after 30 seconds [the entire recording for stream B was of 3 minutes]
similarly for stream A the recording was only lasting 1 minute after which it stopped automatically, in the output the green artifacts were present only in the beginning, after which they disappeared completely.
however when i tried re recording the files I somehow got the output of stream B inside stream A’s output i.e
rtsp source B’s cam output was present in localhost:8550/ds-test output which I have been using constantly for rtsp source A. this happened similarly earlier too with rtsp source A as well, with localhost:8552/ds-test recording i ended up getting cam view of rtsp source A whereas i was using 8552/ds-test for rtsp source B only.
another thing to note, in the second recording instance where the outputs of input sources were interchanged, i didn’t get the green artifacts for some reason. This might be a different issue but I have faced this before too once where the sources are interchanged for some reason even though config is exactly same.
Finally as for artifacts, the green artifacts are only present in the initial few 30-40 seconds of the recordings for both streams [this was with both rtsp sources and file sinks enabled at the same time.
- It is a little hard to understand your description. please answer my questions first in my last comment. if you have test results. please add the test configuration and method, for example, what is source(A or B or both)?, what is sink(filesink or rtspsink)?
- about “I observed no artifacts”, do you mean when using source A,B and two filesink, there is artifacts at the beginning, then the artifact issue will not happen? if so, the artifact issue happens after encoding.
- what is fps of rtsp source A,B? are both 3fps? why is it so low? can you try two 25 fps source, wondering if the issue is related to the low fps.
- Hi, sorry for the confusion, according to this comment
the rtsp source itself had some blocky artifacts momentarily but nothing like the green artifacts i have been observing recently
- As for the test configurations according to this,
I used 2 rtsp sources A and B together in the beginning with 2 filesinks. These 2 filesink outputs in mp4 formats had no artifacts present in them [here filesink is the deepstream output directly, i didn’t use gstreammer separately to record the output, sink config:
[sink0]
enable=1
#Type - 1=FakeSink 2=EglSink 3=File 4=RTSPStreaming
type=3
gpu-id=0
rtsp-port=8550 # < change port
#1=h264 2=h265
codec=2
source-id=0 # indicate source-id here
container=1
output-file=out1.mp4
#encoder type 0=Hardware 1=Software
enc-type=0
sync=0
bitrate=2000000
#H264 Profile - 0=Baseline 2=Main 4=High
#H265 Profile - 0=Main 1=Main10
profile=1
nvbuf-memory-type=1
[sink1]
enable=1
#Type - 1=FakeSink 2=EglSink 3=File 4=RTSPStreaming
type=3
gpu-id=0
rtsp-port=8552 # < change port
#1=h264 2=h265
codec=2
source-id=1 # indicate source-id here
container=1
output-file=out2.mp4
#encoder type 0=Hardware 1=Software
enc-type=0
sync=0
bitrate=2000000
#H264 Profile - 0=Baseline 2=Main 4=High
#H265 Profile - 0=Main 1=Main10
profile=1
nvbuf-memory-type=1
]
when using 2 rtsp sources A and B together with 2 rtspsinks, the artifacts were present in the initial few seconds of both recorded rtspsink outputs via gstreammer, and after 30 seconds the artifacts vanished
these were the deepstream configs for sinks
[sink0]
enable=1
#Type - 1=FakeSink 2=EglSink 3=File 4=RTSPStreaming
type=4
gpu-id=0
rtsp-port=8550 # < change port
#1=h264 2=h265
codec=2
source-id=0 # indicate source-id here
container=1
output-file=out.mp4
#encoder type 0=Hardware 1=Software
enc-type=0
sync=0
bitrate=2000000
#H264 Profile - 0=Baseline 2=Main 4=High
#H265 Profile - 0=Main 1=Main10
profile=1
nvbuf-memory-type=1
[sink1]
enable=1
#Type - 1=FakeSink 2=EglSink 3=File 4=RTSPStreaming
type=4
gpu-id=0
rtsp-port=8552 # < change port
#1=h264 2=h265
codec=2
source-id=1 # indicate source-id here
container=1
output-file=out.mp4
#encoder type 0=Hardware 1=Software
enc-type=0
sync=0
bitrate=2000000
#H264 Profile - 0=Baseline 2=Main 4=High
#H265 Profile - 0=Main 1=Main10
profile=1
nvbuf-memory-type=1
these rtspsink outputs were recorded by this command
gst-launch-1.0 rtspsrc location=rtsp://localhost:8550/ds-test ! rtph264depay ! h264parse ! 'video/x-h264,stream-format=byte-stream' ! filesink location=test1.mp4
gst-launch-1.0 rtspsrc location=rtsp://localhost:8552/ds-test ! rtph264depay ! h264parse ! 'video/x-h264,stream-format=byte-stream' ! filesink location=test2.mp4
These had the green artifacts initially then got removed after 30 seconds. and the recording stopped automatically after 1-2minutes
- fps source is same 3fps for now, I will try to find a 25 fps source later but for now this is currently what im testing with, tho my final expected product will utilize 25fps source rtsp cams. Will try to find new sources but for now this is all I have and the fake rtsp links that we generate.
sorry for the confusion hope this clears out some doubts, thanks!
- do you mean the the output of A has the the content of B? please set “udp-port=5400” for sink0, and set “udp-port=5404” for sink1. they should use different udp port for udpsink. then the “stop midway” issue should be fixed.
- About the artfact issue, it is because decoding failed until it gets a key-frame. you can set “iframeinterval=5” for both sink0 and sink1 to improve. Please refer to opt/nvidia/deepstream/deepstream/samples/configs/deepstream-app-triton/source4_1080p_dec_infer-resnet_tracker_sgie_tiled_display_int8.txt
1 Like
Hi these resolved the artifacts a lot, the iframe interval and exported outputs have their respective sources, thanks a lot for all the help! will keep investigating and let you know if the artifacts reappear, thanks again!
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.