1

I'm encoding images as video using FFmpeg using custom C code rather than linux commands because I am developing the code for an embedded system.

I am currently following through the first dranger tutorial and the code provided in the following question.

How to encode a video from several images generated in a C++ program without writing the separate frame images to disk?

I have found some "less abstract" code in the following github location.

https://github.com/FFmpeg/FFmpeg/blob/master/doc/examples/encode_video.c

And I plan to use it as well.

My end goal is simply to save video on an embedded system using embedded C source code, and I am coming up the curve too slowly. So in summary my question is, Does it seem like I am following the correct path here? I know that my system does not come with hardware for video codec conversion, which means I need to do it with software, but I am unsure if FFmpeg is even a feasible option for embedded work because I am yet to compile.

The biggest red flag for me thus far is that FFmpeg uses dynamic memory allocation. I am unfamiliar with how to assess the amount of dynamic memory that it uses. This is very important information to me, and if anyone is familiar with the amount of memory used or how to assess it before compiling, I would greatly appreciate the input.

zthatch56
  • 21
  • 8
  • Not sure understand. Your question is “am I on the rite path”. The answer is Yes, but I’m not sure how that is useful to you. Would you like to expand the question? – szatmary Apr 15 '19 at 22:52
  • Tyvm szatmary. To better understand if it would work for my embedded system, it would be helpful to know how much heap FFmpeg typically allocates when doing this type of conversion (ex, 1 second mp4 video w/ no audio from bitmap images in the stack). Without that information, I will end up doing trial and error on RAM heap size allocation until I potentially find out that I don't have enough space. If that were to happen, I would need to be able to assess whether or not it would be worth it (e. g. I am only a few bytes away) to restructure some code to reduce space complexity elsewhere. – zthatch56 Apr 16 '19 at 15:36
  • Please don’t use comments to ask new questions. You should update the question to include the information you want. – szatmary Apr 16 '19 at 15:37
  • Also, please don’t include unrelated details. If you need to know about ram usage, USB with FAT are not useful details that the reader needs to sort through. – szatmary Apr 16 '19 at 15:40
  • Thanks again. I will work harder to respect the reader's time. I greatly appreciate yours. – zthatch56 Apr 16 '19 at 15:56

1 Answers1

1

After further research, it seems to me that encoding video is often a hardware intensive task that can use multiple processors and mega-gigbyte sizes of RAM. In order to avoid this I am performing a minimal amount of compression by utilizing the AVI format.

I have found that FFmpeg can't readily be utilized for raw-metal embedded systems because the initial "make" of the library sets up configuration settings specific to the computer compiling, which conflicts with the need to cross compile. I can see that there are cross compilation flags available, but I have not found any documentation describing how to use them. Either way I want to avoid big heaps and multi-threading, so I moved on.

I decided to look for more basic source code elsewhere. mikekohn.net/file_formats/libkohn_avi.php Is a great resource for very basic encoding without any complicated library dependencies or multi-threading. I am yet to implement, so no guarantees, but best of luck. This is actually one of the only understandable encoding source codes that I have found for image to video applications, other than https://www.jonolick.com/home/mpeg-video-writer. However, Jon Olick's source code uses lossy encoding and a minimum framerate (inherent to MPEG), both of which I am trying to avoid.

zthatch56
  • 21
  • 8
  • It's perfectly possible to cross-compile ffmpeg. You need to specify at least `--cross-prefix` and `--enable-cross-compile` to the configure script along with some other flags that might be needed for your platform. See `./configure --help` in the ffmpeg source folder. I can't say though if it's possible to compile for a raw-metal type platform. – Shawn Apr 17 '19 at 14:21