with your simple use case... If I inject enough single images eventually it does start spitting out images - so it's buffering things internally (even though -flush_packets is set.) - which indeed may make sense for video in order to try to keep the frame rate constant, but for single frame at a time. You then need to send the end() to push out the final few frames...
I still think it is the system buffering it, not ffmpeg. Also I believe that an mp4 file must be closed before it is valid mp4, I think additional data is written at the start (length and so on) when the file is closed. Therefore you can't do this with a long running process, you will have to close ffmpeg it in order for it to close the file. So I think you would be better to tell ffmpeg to write directly to the file. That assumes I am correct in my thinking.
Hey guys (@dceejay, @Colin),
After wasting some evenings setting up a debugger session for FFmeg, I finally managed to debug FFmpeg (when spawned from my Node-RED flow). And it appears that the images are not cached in NodeJs but in FFmeg.
This is what happens under the hood:
- When running FFmpeg it first reads all the input files.
- Since we are dealing with an input stream (instead of physical input files) it tries to find stream information. For example for an MJpeg stream it needs to know how to read the stream. This not really what we want, since we are dealing with individual images instead of a stream (unless we convert our images to an mpjeg stream ...).
- To get the stream information, it reads as much data as required (i.e. an endless loop that is only interrupted under certain situations: see below).
- So it reads the next image (in data chunks of 32768 bytes) from the input stream. Here the debugger will wait until Node-RED sends an image. As soon as I send an image in Node-RED, FFmpeg will immediately continue here!!
- For EOF signal, the loop will be interrupted.
- And otherwise - since the data chunk doesn't contain the required stream info - the data chunk will be added to a buffer here. And then the endless loop repeats the whole process by waiting for a next image ...
That is the root cause. But now I should find a solution/workaround somehow
PS. I tried to avoid that FFmpeg searches for stream info - see IF statement at (2) - by adding an extra "find_stream_info" argument:
-f image2pipe -find_stream_info false -i pipe:0 -vf scale=320:240 -f image2pipe pipe:1 -loglevel debug
Then indeed I don't arrive in the endless loop, but the FFmpeg just stops reading the stream...