Set the capture keyframe, the result is not as expected

Please provide complete information as applicable to your setup.

• Hardware Platform (Jetson / GPU)
GPU
• DeepStream Version
6.1.1
• JetPack Version (valid for Jetson only)
• TensorRT Version
8.4
• NVIDIA GPU Driver Version (valid for GPU only)
515.86.01
• Issue Type( questions, new requirements, bugs)
bugs
• How to reproduce the issue ? (This is for bugs. Including which sample app is using, the configuration files content, the command line used and other details for reproducing)

I use deepstream to connect multiple channels of rtsp monitoring (about 100 channels), and only capture key frames are set in the code. The monitored i frame is 50, and the fps is 25. According to expectations, deepstream should capture an image in 2 seconds , but after running it for a few hours, I observed the log of the console and found that (every time I capture a picture, I will output the counter corresponding to the monitoring), the number of pictures captured by most monitoring is not much different, maybe more than a dozen Dozens of pictures, but there is one monitor that has 2000 more pictures than other monitors. This monitor reads an image almost every second. Why? The following is the code for setting key frames:

def decodebin_child_added(child_proxy, Object, name, user_data):
    logging.info(f"Decodebin child added: {name}")
    if name.find("decodebin") != -1:
        Object.connect("child-added", decodebin_child_added, user_data)
    if "source" in name:
        source_element = child_proxy.get_by_name("source")
        if source_element.find_property('drop-on-latency') is not None:
            Object.set_property("drop-on-latency", True)
    if "nvv4l2decoder" in name:
        decoder_elem = child_proxy.get_by_name(name)
        if decoder_elem.find_property('skip-frames') is not None:
            logging.info(f"only decode key frame")
            Object.set_property('skip-frames', 2)

• Requirement details( This is for new requirement. Including the module name-for which plugin or for which sample application, the function description)

Could you attach your whole pipeline? Is there only one channel soure have the problems?

At present, only one rtsp captures too many pictures, and the gap between the other 99 rtsp is not very big. What does the whole pipeline mean? I am new to deepstream, and I may need you to teach me how to operate it, please

I mean how do you run the 100 rtsp source. Did you run them separately? Could you attach your code? Also can you confirm the I frame interval of this rtsp stream again?

By the way, there is another problem, run the above code, execute the judgment logic here (if weekday != cur_weekday or releasable_flag or is_changed_queue.qsize() > 0), stop and remove the corresponding rtsp, but an error will be reported, and then deepstream The program is in a blocked state and cannot exit normally, the exception is as follows:

Error: gst-resource-error-quark: Unhandled error (9): gstrtspsrc.c(6585): gst_rtspsrc_send (): /GstPipeline:pipeline0/GstBin:source-bin-73/GstURIDecodeBin:uri-decode-bin/GstRTSPSrc:source:
Option not supported (551)

Let’s focus on the issue of I frames first. And if there are any other new issues, you can file a new topic.
Is this a problem with the same source every time? Could you attach the rtsp source uri that we can use?
Would there still be a problem if you only used this rtsp source?

this is rtsp in the factory area, there is network isolation, then I will test it, thank you for your reply, or can you use the known information to help me analyze the reason?

It sounds most likely that this is a problem with the rtsp source.
You can also try to dump the rtsp source stream to a file and attach the file to us. Just try to dump the rtsp source stream to a local file without extra encoding.

Thank you for your reply, but due to internal rules, it may not be available, I will test it again

There is no update from you for a period, assuming this is not an issue anymore. Hence we are closing this topic. If need further support, please open a new one. Thanks

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.