@kevingodell/node-red-ffmpeg published to npm

Share Your Nodes
1

npm install @kevingodell/node-red-ffmpeg

It replaces a test version that was only available from github by
npm install kevinGodell/node-red-contrib-ffmpeg-spawn, which needed the end user to have git installed.

The name change comes with a small, but not impossible problem. I also changed its type name from ffmpeg-spawn to just ffmpeg. If you are like me and have many ffmpeg nodes running (i have 22), then this will require a small extra step to migrate from the old to new node. If you only have a couple, then you could just install the new node, copy over your old settings manually for each node and then delete and uninstall the old test node.

These are the steps I took to migrate from the old node to the new one. Be careful and make backups before proceeding.

  • node-red-stop
  • cd .node-red or wherever your node red dir is located
  • npm install @kevingodell/node-red-ffmpeg
  • locate and backup your flows file
  • edit the flows file with a string replace of ffmpeg-spawn with ffmpeg
  • npm uninstall kevinGodell/node-red-contrib-ffmpeg-spawn
  • node-red-start

There may be a better way to migrate and somebody with more experience may tell you not to edit your flows file and you should probably listen to them.

6 Likes
2

Kevin, I have one suggestion on the node. There is one option that confused me (so far). The 'Outputs' option
Screenshot 2023-01-29 at 3.01.36 PM

Now I've figured out that there will always be one output and any number here will show one more output on the node itself.

I think it would be easier to understand it read "Number of outputs (minimum 1, maximum 6). Outputs above 1 will be stdio outputs.

Then initialize this value at 1.

Just my two cents, for what it' worth :grin:

1 Like
3

It worth at least 4 cents. :blush: I agree that it could be labeled much better, especially since the function node has an outputs setting which many people are accustomed to seeing. A while back, either somebody else or maybe you, mentioned this, so I added the little yellow explanation box above.

I probably will ditch the name outputs and just call it pipes. Then the explanation above can describe that it is output pipes of the spawned process. This will probably be the most backwards compatible way.

1 Like
4

I wonder if there was a breaking change in this latest version? Not sure but here is my experience, thoughts & questions

In a larger HSS solution I have a pretty advanced sub-flow where I had configured ffmpeg-spawn nodes (now upgraded to ffmpeg nodes) for the purpose to take snapshots from a video stream

image
image931Ă—678 50 KB

Previously I had it working fine with the following args configured in the nodes:

[
    "-f",
    "mp4",
    "-i",
    "pipe:0",
    "-c",
    "mjpeg",
    "-f",
    "image2pipe",
    "-vframes",
    "1",
    "pipe:1"
]

So when the buffer/stream in the msg.payload arrived on the input it worked even though there was no action.command.start included in that msg. But with the latest ffmpeg node version I just noticed it did not

Struggeling and thinking, debugging, long story, I finally added a change node in front that adds msg.action.command "start" to the incoming msg. Then it started working again!

So my question is, is this expected? The start command is now required? If so, fine but I we then need to update our flows.

I also tried to be smarter by defining the following args directly in the ffmpeg node but that was not valid ("Error: cmdArgs "[object Object]" is invalid"):

{
    "command": "start",
    "args": [
        "-f",
        "mp4",
        "-i",
        "pipe:0",
        "-c",
        "mjpeg",
        "-f",
        "image2pipe",
        "-vframes",
        "1",
        "pipe:1"
    ]
}

So just to summarize, is it now necessary to add the start command and is it possible to configure it directly in the node settings to avoid the additional change nodes I temporarily added?

Best regards, Walter

1 Like
5

Sorry. You caught me. I made changes and pushed them dec 5, 2022, but it was to mp4frag, not ffmpeg. I was able to track the change that affected your flows. I only take partial blame and I will explain why.

Previously, I attached the little extra data action: {command:'start'} to the initialization message of mp4frag's buffer output so that any downstream ffmpeg nodes could receive that and spawn ready to use the mp4 buffer it was going to receive. I didn't think that I documented it, but probably shared it in a flow and obviously you adopted that technique. Also, it seemed to keep the nodes a little too tightly coupled.

At some point, the core mqtt node was updated to be dynamic and it started using the action property. Unfortunately, the mqtt node did not like seeing my invalid action in my message and spits out errors. So, in order to stay compatible with mqtt video relaying, I removed the attached action object, and that was that.

It would probably be better if you put a single function node (instead of multiple change nodes) right after the mp4frag node to add back the action command into the correct messages. If you don't need the stop command, then you can omit that part.

[{"id":"92aae736d1160672","type":"function","z":"0eb5dd623a753eb1","name":"function 7","func":"if (msg.topic.endsWith('init')) {\n    if (msg.payload.size > 0) {\n        msg.action = { command: 'start' };\n    } else {\n        msg.action = { command: 'stop' };\n    }\n}\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":1040,"y":1220,"wires":[["ee147845b41acf2d"]]}]

if (msg.topic.endsWith('init')) {
    if (msg.payload.size > 0) {
        msg.action = { command: 'start' };
    } else {
        msg.action = { command: 'stop' };
    }
}
return msg;
1 Like
6

Hello Kevin, no problem, good to have an explanation to my worries why it stopped working :+1:

:innocent:, yeah I think you gave me an example once upon a time

I think it makes sense, keeping it independent, decoupled and compatible sounds to me as correct decisions

Good there is a solution to it, no problems then, we can just update the flows we have and everything will work fine again (confirmed, I have tested it)

Best regards, Walter

1 Like
7

Thanks for confirming. I will document here that after your post I was looking into having ffmpeg automatically start when it receives buffer and not explicitly requiring the start command. That could be done, but there are scenarios that it could not handle, such as if you have args set to have ffmpeg exit after a single jpeg as your example shows. If buffer was still being sent to it after it exits, then it would accidentally start again, leading to processes running and eating up precious cpu and memory. I think it has to remain the way it is, requiring the start, stop, or restart commands. Thanks again for adapting your flows.

1 Like