Videoarchiver Tool

© 2018, Kevan Hashemi Open Source Instruments Inc.

[15-JUN-18] The Videoarchiver is a program written in TclTk. It is available in the Tool Menu of the LWDAQ Program. The Videoarchiver works with the Animal Cage Camera to record video that is synchronous with the local computer clock to within a fraction of a second, and therefore synchronous with any Subcutaneous Transmitter (SCT) recordings made on the same computer.

Figure: Videoarchiver Tool on MacOS, Recording with Recording Monitor Window. We see two windows. The one in the background is the monitor window that opens during recording, showing a delayed version of the video stream. The Videoarchiver window itself contains verbose reporting of its recording activity. On the desktop, we see the video files have been written to disk.

The Videoarchiver Tool is listed in the LWDAQ Tool manu. Before you can use it, however, you must download the Videoarchiver libraries, which are available in De-compress the zip file and place the Videoarchiver directory in your LWDAQ directory, next to the Tools, Sources, and Build directories.

Having followed your Animal Cage Camera set-up instructions, the Videoarchiver will be able to communicate with your camera. There are buttons to turn on and off the visible and infra-red LEDs. The Reboot button will reboot the camera. Although the reboot command takes only a moment, the camera itself will take about thirty seconds to reboot. Its lights will shine during the reboot process.

The Live button starts live display of the camera image. Stop the display by closing the Mplayer window or pressing Stop in the Neuroarchiver. If you close the Videoarchiver, or quit LWDAQ, the live display will persist. You should notice a delay of roughly 200 ms between movements in the field of view of the camera and their appearance on the live display. This delay is the time it takes the camera to read the image out of its image sensor and transmit the image over the local network.

Note: On Windows, you may encounter a color scheme error. Our video display does not work with the more sophisticated color schemes you can select for your Windows desktop. To avoid delays and notifications, we suggest you right-click on the desktop, select "Personalize", and change your "Color Theme" to "Windows 7 Basic", which you find by scrolling down.

The Record button starts recording of video from the camera. The recording process is designed to synchronise the video with the computer clocks. The product of recording will be H264-compressed video files of twenty frames per second stored within in mp4-containers. The files are saved in the recording directory. You specify the recording directory yourself. The file names have the format Vx.mp4, where the x is a ten-digit Unix timestamp. Video file V1525281033.mp4 has timestamp 1525694641, which is "Mon May 07 08:04:01 EDT 2018". The first frame of the video shows a cell phone with time "Mon May 07 08:04:01 EDT 2018". If the cell phone clock and the computer clock were in perfect agreement, we expect a 180±50 ms delay between capture and storage, so that the time on the phone should be 180 ms delayed with respect to the time in the video defined by the video file name. But we find that our cell phone clock is up to 1 s ahead or behind our computer clock. When compareing videos to EEG and ALT recordings made on the same computer, however, the recordings and the videos will be using the same clock as their timestamp, so we expect the video to be 180 ms behind the EEG and ALT recordings.

We can accompany recording with simultaneous monitoring of the recorded video in a separate display window, much as we do in live display. By default, when we start recording, this monitor window will open. We can close it, and it will stay closed. We can open it again later with the Monitor button. During recording, the video we see is delayed by the segment_length_s. During the recording process, the Videoarchiver is receiving twenty separate image frames per second, with no inter-frame compression. Because there is no inter-frame compression, the Videoarchiver can start a new video file between any two frames of the incoming stream, so it can start a new segment at the start of a new system clock second. The Videoarchiver stores segments in its segment directory. The first frame of segment S2018-122-13-10-33.mp4 is the first frame to arrive after the start of system clock second 13:10:33. Each segment contains segment_length_s seconds of video. Once a segment is complete, the Videoarchiver feeds the segment to its monitor display and compresses the segment into a new file. In this case, the compressed file would be called V1525281033.mp4. Thus the delay between movements in the field of view of the camera and movement in the recording monitor is one segment length. Our default segment length is one second.

When we start recording, the Videoarchiver copies its first compressed segment file into the recording directory, where it forms the start of a new video file. Every transfer_period_s seconds, the Videoarchiver copies all available compressed segments to the recording file. Every record_length_s, the Videoarchiver starts a new file rather than copying to an old file. Thus the video files have approximate duration record_length_s. The video file V1525694641.mp4 was constructed out of 1-s segments transferred every 10 s into a recording file until sixty such segments had been combined together to form a single 60-s recording. The time on the phone clock at the beginning is 08:04:01 and at the end is 08:05:01. The file itself is 7.4 MBytes, or 120 kBytes/s on average.