Buffering streams from capture devices

[pants]

I noticed that it's possible to pause the input stream from a capture device and resume it later, after it has advanced, apparently without dropping any frames. I was curious where the stream is buffered and how big the buffer is so I opened up the activity monitor (I'm running on a Mac) and observed that memory associated with VLC does not increase when the stream is paused (and therefore buffering) but the memory in the "File Cache" does increase steadily. Where/how is the buffer for input streams implemented, how big is the buffer, and what happens when it overflows (does VLC start dropping frames after the buffer grows to the size of the virtual address space, etc)?

Perhaps more appropriate to this forum, when duplicating an input stream from a capture device to the display and a file I noticed that if the display is paused the stream is not written to the file (when the display is unpaused writing to disk resumes). Is it possible to pause the stream in the display while continuing to write it to disk? If so, is it possible to use the on-disk representation in place of buffer?

Thanks for your time!

[pants]

I continued my investigation today. By redirecting successive calls to "lsof -p <VLC-pid>" to output files after pausing my capture device and then diffing the contents of those output files I found that VLC is creating files of size 52230720 under /private/tmp/ named vlc-timeshift.[XXXXXX].

VLC 1027 user 29u REG 1,5 52230720 87589911 /private/tmp/vlc-timeshift.DGLP9P
VLC 1027 user 30r REG 1,5 52230720 87589911 /private/tmp/vlc-timeshift.DGLP9P
VLC 1027 user 31u REG 1,5 52230720 87589912 /private/tmp/vlc-timeshift.920IKZ
VLC 1027 user 32r REG 1,5 52230720 87589912 /private/tmp/vlc-timeshift.920IKZ
VLC 1027 user 33u REG 1,5 52230720 87589913 /private/tmp/vlc-timeshift.CFQF06
VLC 1027 user 34r REG 1,5 52230720 87589913 /private/tmp/vlc-timeshift.CFQF06
VLC 1027 user 35u REG 1,5 52230720 87589915 /private/tmp/vlc-timeshift.VK0COR
VLC 1027 user 36r REG 1,5 52230720 87589915 /private/tmp/vlc-timeshift.VK0COR
VLC 1027 user 37u REG 1,5 52230720 87589919 /private/tmp/vlc-timeshift.IX1C2B
VLC 1027 user 38r REG 1,5 52230720 87589919 /private/tmp/vlc-timeshift.IX1C2B
VLC 1027 user 39u REG 1,5 52230720 87589921 /private/tmp/vlc-timeshift.F4C950
VLC 1027 user 40r REG 1,5 52230720 87589921 /private/tmp/vlc-timeshift.F4C950
VLC 1027 user 41u REG 1,5 52230720 87589922 /private/tmp/vlc-timeshift.WAZJNJ
VLC 1027 user 42r REG 1,5 52230720 87589922 /private/tmp/vlc-timeshift.WAZJNJ
VLC 1027 user 43u REG 1,5 52230720 87589924 /private/tmp/vlc-timeshift.DOME2G
VLC 1027 user 44r REG 1,5 52230720 87589924 /private/tmp/vlc-timeshift.DOME2G
VLC 1027 user 45u REG 1,5 52230720 87589927 /private/tmp/vlc-timeshift.7BDWC9

I assume this is where the forward stream is being buffered. I therefore hypothesize that the increasing memory consumption while buffering a paused stream can be attributed to the open file descriptors referencing these files and that the buffering strategy will fail when VLC reaches the ulimit set for open files (in my case that's 2560 by default).

When VLC is idling on my machine it maintains 259 open file descriptors.

lsof -p 1027 | wc -l
259

This leaves 2560-259=2301 file descriptors for timeshift files each of which provide 52230720 bytes for a total of ~112GB of buffer space (nice):

(52230720 bytes/file * 2301 files) / 2^30 ~= 112 GB

Presumably I could bump this up by increasing my ulimit.

A few questions:

While looking at the timeshift files I noticed that all the timeshift files with odd file descriptors are open for read and write access (FD followed by 'u' in the lsof output above) whereas the files with even file descriptors are open for read access (FD followed by 'r'). What's the rationale behind this?

I have an SSD and an HD in my machine and would ideally like to write these timeshift files to the HD to protect my NAND gates from burning out over the next 5 years. Is the location of these files configurable or would I have to take more extreme measures to achieve this?

[pants]

Upon closer inspection, the read write file descriptor and the read only file descriptor both point to the same file so my math is off by a factor of 2. Meaning we have ~56 GB of space available in the buffer.

[pants]

Solved my SSD/HD question by changing the "tmp" symlink in the root directory to point to a directory on my HD instead of my SSD. Of course this has the potentially undesirable side effect of creating all tmp files used by the system on the slower media.