Faster frame extraction than ffmpeg
I have a video analytics program that processes various frames from a video. (Several hours) The video will probably be MP4, but there could be other formats coming forward.
At the moment, I have a C # wrapper around a ffmpeg call to fetch a single frame at a specified time. (I am using the ffmpeg.exe binary. Not libraries directly) At the moment it all works. But this is slow. So slow.
I have found ways to improve the speed by storing the extracted frames in the ramdisk during processing. Changing the saved aspect ratio, etc.
I just wanted to check if anyone could come up with some way to pull the individual frames. To the nearest second. I know this is possible with DShow etc. I went straight to FFMPEG as I have used it before. But if DShow is likely to be faster, I'll gladly change it!
source to share
On Windows, you have built-in APIs for processing and in particular reading from media files:
- DirectShow
- Media fund
Both provide support for MP4 video (H.264 video), DirectShow as a platform extended by a third-party MP4 demultiplexer and H.264 decoder (of which Windows 7 is also required), and Media Foundation natively or extended by third-party extensions depending on OS version ...
Both can interact with .NET through the open source DirectShow.NET and Media Foundation.NET wrappers, respectively. This speeds up the way faster than the FFmpeg CLI for single frames. Also note that you will be able to get frames in stages, without having to time out and do excessive duplicate work, not even mentioning the overhead of starting / initializing a process. Alternatively, you can use FFmpeg / Libav binaries through a wrapper in C # and get similar metrics.
source to share
You can change the position of the offset parameters. Order matters for speed if the video contains valid metadata that you can search through the video faster.
If you put the offset in front of the input file, the offset will be calculated at the bit rate, not exactly every time (in the case of a variable baud rate), but it is much faster. The correct way is to go through the video (the offset parameter is after the input file), but this takes time.
source to share