Accessing Live and Recorded Video
Video is the very core of our API and make it easily available is the most basic element of what we do.
For all cameras connected to our platform, we provide the full video stream exactly as we got it from the camera. This is the original h.264 encoded video without additional compression or modification. As a convenience we wrap the video in a FLV container in order to make it into common file objects that.
Retrieving video is done by make a HTTP call our Get Video API endopint.
When requesting video through the API it will be served from our cloud instead of serving it from the bridge on the customer site. If the video has not been uploaded to the bridge yet (due to bandwidth or schedule settings), this request will be moved to the "on-demand" queue. The bridge will use all avialable bandwidth to immediately upload this to the cloud so that it can be forwarded to the reqeuster.
In order to play recorded video, you will need the camera ESN along with the start_timestamp and end_timestamp. You are able to pull a whole recorded video clip or you can slice part of the video. The video returned will start from the previous I-frame to the start_timestamp.
You can use the Video List API endpoint to get a list of start_timestamps and end_timestamps inside a time range.
Recorded video can be requested in either FLV or MP4 format. Requests for MP4 video will be transcoded for better compatability. One consideration about requesting MP4 videos is that the entire video must be uploaded to the cloud so that transcoding can begin. This API endpoint will return a 200 if the MP4 file is ready to be served and will return a 201 if the conversation process is not done yet. Please wait a suitable period and request again. Additional requests will not cause an additional conversation process.
The values send as parameters for requesting live video differ slightly from requesting recorded video. Instead of passing a timestamp into start_timestamp you can use the "stream_" identifier with a unique string appended to it. By using a stream identifier it makes it easy to make additional requests to extend the stream. For the end_timestamp we use an offset using the "+" symbol with a number of milliseconds. We suggest using "+300000" to stream for five minutes.
Camera and Bandwidth Settings
Retrieving video is dependant on the settings on both the camera and bridge. It is important that the camera and bridges settings are optimal to your performance requirements.
For example, if live video performance is a high priority, make sure that the bridge has enough to bandwidth availble to stream at the video bitrate of the camera.
Another example, if you are using a cellular or metered connection, it may be wise to limit the length of video requests that are being requested. A pre-roll of 2 seconds and post-roll of two seconds are added to each video clip. This additional video can be removed if trying to optimized for low bandwidth useage.
What else can we do with this?
Adding video to security and non-secuirty related applications is easy. We specialize on doing the heavy-lifting to make dealing with video easier.
I hope you found this helpful. If you have any questions please feel free to reach out to us at email@example.com