I have been using videos with different resolutions in all examples.
But that is a feature of new streammux, rather than a bug?
Is that the reason for artifacts?
Also,
with mp4 with different formats/resolution no artifacts issues comes.
If I am writing a nvvideoconvert with caps converting to FHD, with 25fps from all the different channels, will this issue be resolved?
if the issue persists after add nvdieocovnert, could you share 6.log after doing the following test, Thanks!
gst-launch-1.0 --gst-debug=rtpjitterbuffer:6,nvstreammux:6 "start comnd" >6.log 2>6.log
No artifacts issue on the below
gst-launch-1.0 nvurisrcbin uri=rtsp://192.168.1.6:8555/video1 latency=2000 ! nvvideoconvert ! videorate ! "video/x-raw(memory:NVMM), width=640, height=480,framerate=20/1" ! m.sink_0 nvstreammux name=m config-file-path=streammux.txt batch_size=30 ! nvstreamdemux name=d d.src_0 ! nvvideoconvert ! autovideosink sync=0
But seeing artifacts in the below
gst-launch-1.0 nvurisrcbin uri=rtsp://192.168.1.6:8555/video1 latency=2000 ! nvvideoconvert ! videorate ! "video/x-raw(memory:NVMM), width=640, height=480,framerate=30/1" ! m.sink_0 nvstreammux name=m config-file-path=streammux.txt batch_size=30 ! nvstreamdemux name=d d.src_0 ! nvvideoconvert ! autovideosink sync=0
this is the streammux.txt
[property]
algorithm-type=1
batch-size=30
max-fps-control=1
overall-max-fps-n=20
overall-max-fps-d=1
overall-min-fps-n=20
overall-min-fps-d=1
so controlling framerate will fix the issue!!
Thanks for the sharing! Is this still an DeepStream issue to support? Thanks!
I will implement it on the python and let you know.
Hi @fanzh
I implemented capsfilter before streammux, fixing the issue once and for all
pipeline.add(streammux)
for i in range(number_sources):
print("Creating source_bin ", i, "\n")
uri_name = args[i]
if uri_name.find("rtsp://") == 0:
is_live = True
source_bin = create_source_bin(i, uri_name)
if not source_bin:
sys.stderr.write("Unable to create source bin \n")
pipeline.add(source_bin)
# Create nvvideoconvert, videorate, and caps filter elements
nvvideoconvert = Gst.ElementFactory.make("nvvideoconvert", "nvvideoconvert_%u" % i)
if not nvvideoconvert:
sys.stderr.write("Unable to create nvvideoconvert \n")
videorate = Gst.ElementFactory.make("videorate", "videorate_%u" % i)
if not videorate:
sys.stderr.write("Unable to create videorate \n")
caps_filter = Gst.ElementFactory.make("capsfilter", "capsfilter_%u" % i)
if not caps_filter:
sys.stderr.write("Unable to create caps filter \n")
caps = Gst.Caps.from_string("video/x-raw(memory:NVMM), width=640, height=480, framerate=25/1")
caps_filter.set_property("caps", caps)
# Add elements to the pipeline
pipeline.add(nvvideoconvert)
pipeline.add(videorate)
pipeline.add(caps_filter)
# Link elements: source_bin -> nvvideoconvert -> videorate -> caps_filter -> streammux
srcpad = source_bin.get_static_pad("src")
if not srcpad:
sys.stderr.write("Unable to create src pad bin \n")
sinkpad = nvvideoconvert.get_static_pad("sink")
if not sinkpad:
sys.stderr.write("Unable to get sink pad for nvvideoconvert \n")
srcpad.link(sinkpad)
nvvideoconvert.link(videorate)
videorate.link(caps_filter)
padname = "sink_%u" % i
sinkpad = streammux.get_request_pad(padname)
if not sinkpad:
sys.stderr.write("Unable to create sink pad bin \n")
srcpad = caps_filter.get_static_pad("src")
if not srcpad:
sys.stderr.write("Unable to create src pad bin \n")
srcpad.link(sinkpad)
Thank you
Hi @fanzh
What might be the reason for the above phenomenon.
I used the following code.
gst-launch-1.0 nvurisrcbin uri=file:///opt/nvidia/deepstream/deepstream-7.0/sources/src/1.
mp4 latency=2000 ! nvvideoconvert ! videorate ! "video/x-raw(memory:NVMM), width=640, height=480,framerate=20/1" ! m.sink_0 nvstr
eammux name=m config-file-path=streammux.txt batch_size=30 ! nvstreamdemux name=d d.src_0 ! nvvideoconvert ! nvv4l2h264enc ! rts
pclientsink protocols=tcp location=rtsp://localhost:8554/v
and this is the streammux.txt
[property]
algorithm-type=1
batch-size=30
max-fps-control=1
overall-max-fps-n=25
overall-max-fps-d=1
overall-min-fps-n=25
overall-min-fps-d=1
max-same-source-frames=1
Well adding a queue improved it
gst-launch-1.0 nvurisrcbin uri=file:///opt/nvidia/deepstream/deepstream-7.0/sources/src/1.mp4 latency=2000 ! nvvideoconvert ! videorate ! "video/x-raw(memory:NVMM), width=640, height=480,framerate=20/1" ! m.sink_0 nvstreammux name=m config-file-path=streammux.txt batch_size=30 ! nvstreamdemux name=d d.src_0 ! nvvideoconvert ! queue ! nvv4l2h264enc ! rtspclientsink protocols=tcp location=rtsp://localhost:8554/v
Thanks for sharing!
- if using nvv4l2h264enc + filesink, will the issue persist? wondering if it is related to encoding.
- if the issue persists, if using nvstreamdemux + nveglglessink, will the issue persist?
I will inform about this one, queue before encoding has improved the situation a little bit.
But I have a major issue now.
I have 4 channels using nvurisrcbin with file-loop on and rtsp retries on,
Whenever, the rtsp channels goes down, other mp4 file playbacks, starts its stuttering. Please see the video above.
When rtsp comes back, play back is smooth again.
Thank for the sharing! seems the new issue is not related to the original artifact issue. could you open a new topic to focus on the new issue? Thanks! let’s focus on one issue in one topic.
Sure, I believe everything is related to streammux, and nvurisrcbin.