No that is another test on my todo list. But trying to find out how the ffmpeg parameters is very time consuming 
Last night I was struggling with something else. My camera sends 15 frames per second and 1 I-frame (= keyframe) per 15 frames:
Which means it sends 1 I-frame (= keyframe) per second.
So in my ffmpeg arguments:
-skip_frame nokey -i <my_cam_rtsp_url> -r 1 -f image2pipe pipe:1
The -r 1 (to have 1 frame per second) is quite useless, since this the -skip_frame nokey only passes through 1 I-frame per second. However when I removed the -r 1, the cpu usage changed from 1 spike per second to a continious load:
Moreover when using a node-red-contrib-msg-speed node, the decoded number of jpeg's per second increased:
Then I came across this discussion which contained the answer.
Summarized: image2pipe is a constant frame-rate muxer so it will attempt to maintain stream frame rate when number of supplied frames is less than the frame rate. So when you pass only 1 I-frame per second to image2pipe, then it will create extra new frames (from that I-frame) to have its original framerate again.
Using -vsync 0 you can tell image2pipe to forget about that:
-skip_frame nokey -i <my_cam_rtsp_url> -vsync 0 -f image2pipe pipe:1
Then indeed the speed node indicates that I have again 1 frame per second (i.e. the I-frame):
And the continious cpu load dispappears again:
This -vsync 0 looks more interesting to me, compared to -r 1. Because when you change your camera settings (frames per second or frame interval) then you don't want to change your ffmpeg command? But not sure yet...
Note that the vsync parameter is obsolete, so I think we will need to use fps_mode parameter instead (see ffmpeg documentation).
