Tweet
Back again,
Now Patrick, I'm chastising you for even THINKING that I'd ever chastise you !
Experience here has proved to me time and again that no matter what results I get off my own machines, somewhere, someone will get different results. There are obvious areas that others experiences will give us valuable pointers, many others that are far more subjective.
What is the role of a swap file in a general manner ? It's to enable the swapping of code or data segments in and out of RAM during operation. During many standard graphic operations it is critical because of the size of graphics files. However, when considering video capture there are two considerations. Firstly is the data swapping - but when capturing multi-megabytes per second, it becomes redundant with seconds (max) of capture starting. In this situation you have to rely on the capability of your HDs to absorb the datarate, and all that the swapfile is achieving is bottlenecking that dataflow (IE by the time it gets to swapping it's contents, the datarate has caused virtual memory to overflow and is directly streaming to the HD itself). Secondly we have to consider head-clashes. This occurs when the HD cache controller has received instructions to write blocks to different sectors of the same physical HD. If the swapfile resides on the same physical HD as the captured stream then all this can do distract the heads from the constant write flow of the video file, and position them at the location of the swapfile. In extreme cases (especially where the capture file has not been pre-allocated), this could actually cause the capture file to fragment (around the swapfile) and the heads to seek across the tracks continually in order to satisfy both demands.
In theory (again), having the capture and prime drives (assuming that the swapfile is on the prime drive) on the same IDE header could also result in bottlenecking of instructions within the HD controller, but these should logically be less than than physical head-seeks.
In conclusion, I can agree that extra RAM can help out while editing,but since the size of RAM is so small in comparison to the flow of an incoming videostream, it has no relevance in this respect.
BTW, all this has absolutely no bearing at all on the problem of capturing high contrast video, in which case the problem is (usually) situated in the inability of analogue capture cards to resolve transient dataflow above it's own peak limit. In this case, the datarate must be reduced, either by normalising the peaks using an external filter or by increasing the compression rate to limit the datarate trhough the capture device.
As always, this is my own POV and is open to criticism/denial as folks see fit.
Now Patrick, I'm chastising you for even THINKING that I'd ever chastise you !
Experience here has proved to me time and again that no matter what results I get off my own machines, somewhere, someone will get different results. There are obvious areas that others experiences will give us valuable pointers, many others that are far more subjective.
What is the role of a swap file in a general manner ? It's to enable the swapping of code or data segments in and out of RAM during operation. During many standard graphic operations it is critical because of the size of graphics files. However, when considering video capture there are two considerations. Firstly is the data swapping - but when capturing multi-megabytes per second, it becomes redundant with seconds (max) of capture starting. In this situation you have to rely on the capability of your HDs to absorb the datarate, and all that the swapfile is achieving is bottlenecking that dataflow (IE by the time it gets to swapping it's contents, the datarate has caused virtual memory to overflow and is directly streaming to the HD itself). Secondly we have to consider head-clashes. This occurs when the HD cache controller has received instructions to write blocks to different sectors of the same physical HD. If the swapfile resides on the same physical HD as the captured stream then all this can do distract the heads from the constant write flow of the video file, and position them at the location of the swapfile. In extreme cases (especially where the capture file has not been pre-allocated), this could actually cause the capture file to fragment (around the swapfile) and the heads to seek across the tracks continually in order to satisfy both demands.
In theory (again), having the capture and prime drives (assuming that the swapfile is on the prime drive) on the same IDE header could also result in bottlenecking of instructions within the HD controller, but these should logically be less than than physical head-seeks.
In conclusion, I can agree that extra RAM can help out while editing,but since the size of RAM is so small in comparison to the flow of an incoming videostream, it has no relevance in this respect.
BTW, all this has absolutely no bearing at all on the problem of capturing high contrast video, in which case the problem is (usually) situated in the inability of analogue capture cards to resolve transient dataflow above it's own peak limit. In this case, the datarate must be reduced, either by normalising the peaks using an external filter or by increasing the compression rate to limit the datarate trhough the capture device.
As always, this is my own POV and is open to criticism/denial as folks see fit.
I've returned my 200MB fixed size swapfile to the outer edge of my boot drive using Norton Utilities Speed Disk. I guess now I'll hear from someone that this is a no-no. 
Comment