> The best solution would be if something like fileSystemWatcher could be > added to FFmpeg. > Below is a C# example for fileSystemWatcher.
FFmpeg is written in C++. Windows, Mac and Linux each have a different method for watching the filesystem change. Do you have any example C++ code that works across each operating system FFmpeg runs on? If not, that probably explains why it's not supported. Instead of trying to repurpose FFmpeg to make it your whole application, you could try making your application work with FFmpeg. You could watch the filesystem in your own code and when a new file appears, launch ffmpeg as needed. I don't run Windows so I'm not familiar with the options, but it looks like there are some .NET interops for FFmpeg which would let you skip launching the .exe and just pass the frames to it directly. Failing that, another option is to use two instances of ffmpeg. One (which your program calls when each new file appears) encodes the frame and sends it over a UDP socket, and the second ffmpeg instance simply streams video from the UDP socket. This should work well in your case because if no UDP traffic is coming in, the second ffmpeg instance will simply continue to display the last frame. However I do wonder whether FFmpeg is the best choice here for displaying the final video. It almost seems like it would be better to have ffmpeg launch when a new file appears, write the result of the transformation out to another new image file, then use some kind of image viewer to pick up and display those second sets of images. I wouldn't be surprised if some image viewers already supported watching the filesystem and reloading the image if the file changed, which would greatly simplify your problem and wouldn't require any changes to FFmpeg. Cheers, Adam. _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".