NVR Integration with video source SDK
AnsweredHi,
We are planning to develop a plug-in for having playback and export functions with a certain brand of NVR. When we have checked the video source SDK found out that the nx_video_source_sdk contains the programming interfaces that at first glance may seem appropriate to do the integration of a live video source (nxcip::CameraMediaEncoder* family of interfaces) and archive video source (nxcip::DtsArchiveReader).
There's however a problem. While the nxcip::CameraMediaEncoder has the method getMediaUrl, which suites us ideally (since we could just substitute the RTSP URL from NVR), -- the other one, nxcip::DtsArchiveReader, only has the method getStreamReader, which is supposed to return an instance of StreamReader interface, which, in turn, only has the method getNextData(MediaDataPacket **packet), suitable for reading media data packets (basically, encoded video frames), one by one, iteratively and incrementally.
Here's the problem we see with that approach. From our experience, 3rd party NVRa, often only provide a streaming interface to get the video from the media archive. Even worse, in most cases that's the same RTSP interface. Sometimes it comes with with peculiarities and/or additional requirements, however what's important for our purpose is: in RTSP, the data producer defines the pace at which data is being read from archive and sent to client. This is a fundamental thing.
And unfortunately it's not compatible with programming interface suggested by Nx. Because the semantics of StreamReader interface, -- it provides the method getNextData which is called by data consumer, means that -- it's the consumer who wants to determine the pace at which the data is being read.
One cannot assume that this method will be called by NxWitness core in exactly the same speed as the data is being produced by the NVR at the other end of the system. If the speed at which data is being produced from NVR mismatch the speed at which data is consumed by Nx, -- and this is definitely going to happen, -- the end user would see either stalling video, or data loss.
Here are the questions:
Is NX team is having any plans to add getMediaUrl kind of function to nxcip::DtsArchiveReader?
We found out that there is already a plug-in developed for Hanwha NVRs. Would it be possible to have the codes of the Hanwha NVR plug-in?
Sincerely,
Ben
-
Hello Ben Kimski ,
Sorry for the late response.
Is NX team is having any plans to add getMediaUrl kind of function to nxcip::DtsArchiveReader?
no, there are not such plans, just because there is no actual necessity.
All the camera drivers use the same interfaces you've describes.
And unfortunately it's not compatible with programming interface suggested by Nx. Because the semantics of StreamReader interface, -- it provides the method getNextData which is called by data consumer, means that -- it's the consumer who wants to determine the pace at which the data is being read.
One cannot assume that this method will be called by NxWitness core in exactly the same speed as the data is being produced by the NVR at the other end of the system. If the speed at which data is being produced from NVR mismatch the speed at which data is consumed by Nx, -- and this is definitely going to happen, -- the end user would see either stalling video, or data loss.
If the speed at which data is being produced from NVR mismatch the speed at which data is consumed by Nx,
This mismatch occurs all the time. The pace the Server invokes getNextData in never less than the pace the camera is capable of streaming at. The approach would be
1. To fork a thread pulling video data over RSTP from a camera, extracting and storing in a queue of MediaDataPacket.
2. When the getNextData is invoked, it returns a ready MediaDataPacket (if any) from the queue.
-
Ben Kimski
we don't handle the code by those types of requests. That being said, we do plan to open source big part of our software (Desktop Client). But that won't have any code you are asking for.
Maybe in some future we will also publish all integrations that we do in-house, but I doubt that will happen any time soon.
If you have any contacts with Nx besides this forum -- you can try requesting the code samples through those channels, but there is no solid process for that.
thanks
Please sign in to leave a comment.
Comments
7 comments