Memory management and large video file creation

From eLinux.org
Revision as of 16:11, 22 February 2013 by Tfischer (talk | contribs) (Created page with "= 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 save...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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 fadvise()and 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