Welcome to the series of posts I’m writing about my home security camera system. This post will discuss presentation timestamps, as they apply to an IP camera system.
In my IP camera system, the gstreamer rtsp plugin is used to receive data from the IP cameras. The resulting timestamps start at 0 when the camera starts streaming to the server, and the timestamps increase as long as the stream is connected. If the stream is ended and started again, the timestamps will reset back to zero. Since as discussed in my other post, the video player needs random access to the video, the video is split into segments when it is stored into the database. Each segment from each camera must be independently playable. I made this possible by tracking the pts offset, and modifying the timestamps so the timestamps for each video segment start at 0. This makes it possible to start playing at any video segment. In order to play video continuously, the video player modifies the timestamps again by adding the offset of the maximum timestamp of the previous segment to each timestamp in the current video segment.
Another reason why the captured timestamps are useless, besides the fact that they don’t start from zero, they can reset at any time if the camera restarts streaming, and also there are multiple cameras and their streamed timestamps are not in sync. Instead, the video segments contain their own pts timestamp sequence and the segments themselves are timestamped by the server so that video segments captured at any time can be queried accurately.
Here’s a mocked-up diagram of what the pts timestamps look like from the camera, in the database, and in the player:
In my next post, I will resume discussion of the software running in the server.