Here me again boring you about Gstreamer.
But I found a very particular “issue”.
As we know Gstreamer is ufficially supported by Nvidia and it can access to HW acceleration to encode/decode/crop/resize…
But I’m trying to copy H264 packets from an RTSP to a RTMP, one of the easier thing that is possible to do. I found that Gstreamer uses more CPU (despite hw support) than FFMPEG.
How to test:
Gstreamer
nvidia-l4t-gstreamer 32.2.0-20190716172031
Pipeline:
gst-launch-1.0 rtspsrc location=rtsp://admin:Password@192.168.0.204:554/ latency=150 ! queue ! rtph264depay ! queue ! h264parse ! flvmux streamable=true name=mux ! rtmpsink location=rtmp://127.0.0.1:1935/live/camera1
Video Info: 1920x1080 25fps
CPU USAGE: 29-31%
FFMpeg
Version: 4.2.1
Command:
ffmpeg -fflags nobuffer -i rtsp://admin:Password@192.168.0.204:554/ -c copy -f flv rtmp://127.0.0.1:1935/source/camera1
Video Info: 1920x1080 25fps
CPU USAGE: 3-4%
I really cannot understand how is possible? any idea?
PS: If you are next to tell me “well… use ffmpeg”, the reply is: “no” cause I need also to grep H265 packets from RTSP and not only H264. To do that I need to transcode H265 to H264 in order to mux it in a FLV, so I need HW acceleration.
Hardware won’t accelerate demuxing and remuxing, only decode or operations on the video itself. With the ffmpeg example above you are using the copy codec which simply copies the stream without touching it’s contents. That will run well on anything. I use it on a pi zero to stream video and it uses <10% cpu.
I’m not a gstreamer expert so I can’t say for certain what’s wrong with your above example, but I don’t think those queues are necessary in that context. Removing them could possibly reduce cpu usage. Flvmux could also be the culprit. “Streamable” might be doing some surgery on the stream you don’t need (or you might, again, not a gstreamer expert).
As I understand it, only the gstreamer components starting with ‘nv’ are hardware accelerated (or omx). Muxing and demuxing in general cannot be hardware accelerated. You’re just taking a stream out of one container and putting it in another. If gstreamer is bad at that even after troubleshooting, in your case you might be better off using ffmpeg. If you don’t need video hardware, as in your simple example, you might as well.
1 Like
Thanks mdegans,
It’s a good starting point. I’m searching a solution because I need to copy H264 and transcode H265 to H264 if needed, for this reason I’m trying to use gstreamer.
I know that nvidia is working on ffmpeg with access to hardware acceleration but until it will not available I need to find a solution with gstreamer.
If both uses CPU for demuxing and muxing means that gstreamer do it worst than ffmpeg.
Nvidia mod, have you some suggestion?
If you need to copy the stream, either program will do. If you need to transcode, only Gstreamer will work. You can find examples in the Nvidia accelerated gstreamer user’s guide, the latest of which can be found by googling those terms.
As to why Gstreamer is worse in you example above, you can try removing those queues (or otherwise modifying the pipeline) and see what happens. Other than that you will have to experiment.