Memory management and large video file creation

= Background =

If you have an embedded device that is capturing video, what happens with the overall memory as the video is captured, encoded, stuffed in a container and saved to a file?

= Where did my application go =

A problem I encountered recently had to do with a GUI response time increasing as the video capture continued. When first starting a video capture, the GUI response time was around 0.5 sec. However, after 7 minutes, the GUI took up to 10 seconds to respond. What is happening?

The video capture solution was based on GStreamer, using the multifilesink element to save the data to a file. In simplified terms, the pipeline was:

v4l2src ! h264_encode ! qtmux ! multifilesink

Giving the kernel hints
The fadviseand madvise provide a mechanism to give the kernel a hint that the memory contents will not be used again. In the case of writing a file, using fadvise allows the data being written to the file to not fill the page cache. In the case of the application disappearing, the cache was getting filled with video file data, and since the part of the application used by the GUI wasn't being activiated, it eventually grew stale in the cache and the kernel tossed out those pages. When the user pressed on the touch screen, page faults started occurring as the kernel brought the GUI related application code back into memory from the file system. Note: this can happen even with no swap as the kernel knows it can reload the application at any time.

By using fadvise, we were able to dramatically improve the GUI response time. However, it still isn't as fast as when you interact with the GUI at the start of recording. Does anyone have any suggestions on further improvements?