Asking for help, I encountered a problem, but I don’t know how to solve it
When I use element “nvv4l2decoder” with property “drop frame interval = 2” to reduce the video frame rate, the video frame rate is indeed reduced, but when I re encode and stream the video with low frame rate, there is a problem with the open video stream FPS. For example, the FPS of the original video is 25. After setting drop frame interval = 2, the new video stream is still 25, As a result, the new video stream is opened slowly and the delay is high. With the increase of drop frame interval, the phenomenon will become more obvious. How can I get a standard video stream with a frame rate lower than the original video stream.
**• Hardware Platform Jetson Xavier NX
**• DeepStream Version 6.0
**• JetPack Version 4.6
**• TensorRT Version 8.0
**• Issue Type( questions, new requirements, bugs) questions
**• 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)
Hi,
Do you mean you would like to encode the stream with identical frame rate as source? For example, if you set drop-frame-interval=2, the source frame rate becomes 12.25 but the encoded video files is in 25 fps so it is played fast-forwarded. Is this correct? Please check and confirm what the issue you are facing.
Thanks for your reply.
Here I want to get a live video stream with a lower frame rate. For example, my camera is 25 frames per second, but I want to do AI infering at 12.5 frames per second and push it out again at 12.5 frames per second, so I set the “drop-frame-interval = 2”; When I open this new video stream, it can be opened, but the opening is very slow and the delay is very high. It can be seen from the decoding information of the player that the FPS information of the video stream is the FPS of my camera, not the 12.5 FPS obtained after dividing by 2.
Now, I have solved this problem by no longer setting the “drop-frame-interval”, but connecting a “framerate” after the decode to adjust the speed.
It seems that the “drop-frame-interval” can complete the speed regulation, but it can not modify the video stream information in the pipeline, resulting in that the FPS contained in the new coding information is still the FPS of the original video source.