NVR Integration with video source SDK
Answered
Hi,
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
-
Hi,
That would be great to hear your feedback on this.
Ben,
0 -
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.
0 -
Hi Andrev,
Well noted.
Would it be possible for you to share sample code of current Hanwha plug-in? That would give us a better understanding and a boost start to develop the plug-in we need.
Sincerely
Ben
0 -
Hi Ben,
Hanwha plugin uses nothing special, but standard RSTP for pulling video steams. In other words, it's an analytics plugin, not a video source plugin.
0 -
Hi Andrey,
We heard that NX could playback from Hanwha NVRs. I thought there is a plug-in managing that activity. If that so, could you please share the code for playback and export functions from Hanwha NVRs? That would help us a lot.
Ben
0 -
Ben,
I'm sorry, but sharing this part of code is not possible.
0 -
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.
thanks0
Please sign in to leave a comment.
Comments
7 comments