Camera head imaging-video monitoring with C #

DEMO code

Development Resources

Introduction:
Looking at the development trend of today's monitoring systems, it is easy to find that IP-based solutions are becoming increasingly popular. There are many manufacturers that provide a wide range of IP video and video servers, meaning that personal IP video surveillance systems are becoming increasingly popular. Furthermore, many companies provide solutions to convert their CCTV video surveillance systems into IP-based systems to consolidate existing devices and structures. These companies provide not only hardware equipment, but also software. Many other companies develop software for IP video surveillance systems to provide complete solutions for small enterprises, it also provides such services to individuals.
Here, I will share some experiences on developing video headers and video servers with various IP addresses. The information provided is about how to use a program to use the photo header. For an individual, it may be a simple program, or other more complex programs or work directly with some video monitoring software.
As a demo, I use C #, which allows shooting at the same time as multiple photo headers. This program allows synchronous imaging, not only several video headers on several video servers, but also many different types of photo headers to take photos at the same time. The program supports the following video resources:

Continuously update JPEG image resources;
MJPEG (Dynamic JPEG) video stream;
Some axis photo headers and Video Servers (205,206,210 0, 2110,212 0, 2130r, 2400,240 1, 2460 );
D-Link photo header (only JPEG supported );
Panasonic photo head;
Pixord photo head;
Stardot photo header (netcam, Express 6 );
Local device, supports DirectShow;
MMS (Microsoft Media Services) stream;
What is the IP photo header?
The IP address photo header provides digital signal output and can be directly connected to Ethernet for various operations through the IP network. To achieve this goal, the IP image header not only has an image header, but also needs a computer, usually running Linux. The intention of a computer is:

Compress images into digital images (some photo headers/servers also have an additional micro-compression processor for processing the cup );
Images can be accessed through an IP address. (generally, these image headers run on servers. They not only provide the digital image access function, but also set the parameters of the image header through HTTP ).
Video Servers are very complex devices and usually do not contain photo headers. It is connected to several video input devices (usually one to six), and users can connect to various photo headers. As an IP image header, the video server also converts the image header image into a digital image and provides access through the network. In addition, the option to create a video party case is provided (for these reasons, the video server is used as a hardware device ).
In fact, it is very useful to access the photo header and server through the network. It allows monitoring not only in the area where you have installed the photo header, but also in the world where monitoring software is used and IP functions are available, such as browsers (such as tablets ). Like working on workstation, PDA or other mobile phone. The IP video solution is not only used for monitoring and video filing. This video output technology of the photo Header/Server can be easily integrated with many software:
Dynamic Survey/tracking (based on a complete video framework or related fields );
Traffic control and graphic recognition
Tracking pedestrians and identifying identities;
.

Video Format:
The simplest video format is supported by almost all photo headers/servers. It should not be called only one video format. This format is only the common JPEG format. Many photo headers allow a single URL to access an image (recorded by the photo header manufacturer ). For example, an axis photo header allows an image to be accessed through the following URL: http://webcam.mmhk.cz/axis-cgi/jpg/image.cgi.
This feature has advantages and disadvantages. The disadvantage is that each time you want to send an HTTP request to the camera header server, you can get an image of the current image, because some additional data will lose some time (such as the HTTP header ). The advantage is that the monitoring software can easily control its maximum update rate-you can access the URL at any speed to get the next refresh (15 times per second or every minute, if the speed of the network and photo header is allowed ).
The second popular format is MJPEG (Dynamic JPEG ). This format not only downloads a JPEG image, but also a jpeg stream. For a common JPEG format, the client software sends an HTTP request to a specified image header URL, for example, http: // 146.176.65.10/axis-cgi/mjpg/video. cgi. However. Here, the image shooting header will not only return a single JPEG, but a stream with a defined JPEG format. The stream has an HTTP header mark. When the customer does not want to continue obtaining video data, the connection to the photo header will be closed.
The MJPEG method looks good because it has an obvious advantage: it sends an HTTP request once and can continuously accept data from the photo header. However, in this way, you cannot easily control the update rate. When you access an MJPEG website, your photo header will provide you with a series of pre-defined update rates. If you want to change it, you need to add some additional parameters to the URL. This does not sound a problem, but in fact, it will lead to some problems. Let me explain the most common problem first. Assume that you require (or the default setting) 15 FPS to the photo header. However, it happens that the speed between you and the photo header slows down and the FPS drops to 5. Assume that your image header has a buffer of 30 bytes, so that your image header processes 30 bytes every 2 seconds, but you have processed them within 6 seconds, this means that you will see the last shard in 4 seconds-this will usually be slow. Of course, this is just an example. The camera head will not stop refreshing the buffer, or do something else to avoid such waiting. However, I have encountered one thing. One time someone enters a room with a photo head, stays there for a while, and then goes to another room, he also saw his own screen on the Monitoring Program (which was provided by the camera head manufacturer ).

Multiple Image headers support JPEG and MJPEG formats. Some support MPEG-2, and support MPEG-4. Of course, some photo headers not only support videos, but also sound and bidirectional.
Let's talk more about accessing some image shooting headers-accessing a single JPEG clip and MJPEG Stream (the MPEG format is also introduced ). More photo header manufacturers provide APIs and sdks, so you can learn more about them on their websites.
Access JPEG and MJPEG:
It is easy to display data from a jpeg Resource (photo header)-You only need to create an HTTP request to the photo header, download the returned data, and decompress it into a bitmap file. Here is an example of how to quickly obtain a JPEG image from an IP image header:
String sourceurl = "http://webcam.mmhk.cz/axis-cgi/jpg/image.cgi ";
Byte [] buffer = new byte [100000];
Int read, total = 0;

// Create an HTTP request
Httpwebrequest Req = (httpwebrequest) webrequest. Create (sourceurl );

// Get Response
Webresponse resp = Req. getresponse ();

// Get the response stream
Stream stream = resp. getresponsestream ();

// Read Stream Data
While (read = stream. Read (buffer, total, 1000 ))! = 0)
{
Total + = read;
}

// Obtain the bitmap
Bitmap BMP = (Bitmap) bitmap. fromstream (
New memorystream (buffer, 0, total ));

But, don't forget that most cameras are not free with open access like in the sample above. most probably, you will want to protect your camera with a password, which shocould be specified somehow:
Do not forget that many photo headers are not as accessible as they are in the code above. Generally, you will use a password to protect your photo headers, which will be unconsciously specified:

// Create an HTTP request
Httpwebrequest Req =
(Httpwebrequest) webrequest. Create (sourceurl );

// Set logon and password
Req. Credentials = new networkcredential (login, password );
...

Accessing MJPEG resources is complex. First, let's take a look at the response directory type. As follows:
Multipart/X-mixed-replace; boundary = -- myboundary

Maybe they seem inconsistent, but their types are multi-part/mixed, and there is a clear demarcation. The separator here is "-- myboundary ". Now let's take a look at the actual stream data:
-- Myboundary
Content-Type: image/JPEG

... Image Binary data...

-- Myboundary
Content-Type: image/JPEG

... Image Binary data...

-- Myboundary
Content-Type: image/JPEG

...

To sum up all, the steps for accessing MJPEG resources are clear:
The resolution response directory type is decomposed into specified values;
Read the initial part of the stream and search for the first boundary;
Read the demarcation value, followed by the next decomposition;
Decompress the image to the buffer;
Process the image (display, or other );
Repeat steps 3-5.
In fact, the idea of accessing an MJPEG resource is not as complicated as I mentioned at the beginning, but it is not as easy as processing a jpeg resource.
Axis photo header and Video Server:
The Axis shooting header and Video Server seem to be the best IP video shooting header I have ever encountered. From the user's point of view, these photo headers provide excellent video quality and refresh rate, and are easy to install and set. From the developer's point of view, these devices are quite good-this company is the best developer party I have ever met in terms of IP address photo headers. The company provides a complete documentation and an SDK for accessing the photo header using HTTP.
The URL for accessing the JPEG and MJPEG streams of the Axis IP address photo Header/server is as follows:
JPEG:
Http: // <servername>/axis-cgi/jpg/image. cgi
MJPEG:
Http: // <servername>/axis-cgi/mjpg/video. cgi

The two URLs allow some parameters, which may affect the display effect. The most common parameter is the definition (specify the video output size), the shooting header (specify the number of shooting headers on the video server), and the refresh rate (only when MJPEG is used ):
Samples:
Http: // <servername>/axis-cgi/jpg/image. cgi? Resolution = 320x240
Http: // <servername>/axis-cgi/mjpg/video. cgi? Camera = 2
Http: // <servername>/axis-cgi/mjpg/video. cgi? Camera = 2 & des_fps = 5

Obtain the complete list of HTTP APIs and all parameters, and submit the request to the axis website.
Stardot photo header and Video Server:
It seems that the stardot photo header and video server have not provided a wide range of IP address photo headers and video servers, and they have not changed over the past two years. All of them are an IP image header model and a video server model. For me, I think they have only one advantage: they can improve the camera head support by six. Other aspects are less competitive than axis. For example, the update rate is very low (not secure) and the image shooting header does not support MJPEG. There are few comments from related developers.
The URL format for u to access their products is very simple:
Stardot netcam:
Http: // <servername>/netcam.jpg
Stardot Express 6 (Video Server)
Http: // <servername>/JPEG. cgi? <Cameranumber>
Http: // <servername>/JPEG. cgi? 3

Pixord photo header:
Pixord's product is composed of IP image headers of different models. It seems to be a good photo shooting header, providing good quality and refresh rate, and supporting MJPEG streams. The company provides product sdks, but users must register before they can get them.
The URL format for accessing their IP address photo header is as follows:
JPEG:
Http: // <servername>/images <channel> <resolution>
Http: // <servername>/images1sif
MJPEG:
Http: // <servername>/getimage? Camera = <channel> [& FMt = <resolution>] [& delay = <delay>]
Http: // <servername>/getimage? Camera = 1 & FMt = SIF & delay = 10

Panasonic photo header:
I am not very familiar with Panasonic photo headers. I just found several photo headers online. You can also find them in the examples provided.
URL format for accessing the Panasonic image header:
JPEG:
Http: // <servername>/snapshotjpeg [? Resolution = <resolution>] [& Quality = <quality>]
Http: // <servername>/snapshotjpeg? Resolution = 320x240 & Quality = Standard
MJPEG:
Http: // <servername>/nphmotionjpeg [? Resolution = <resolution>] [& Quality = <quality>]
Http: // <servername>/nphmotionjpeg? Resolution = 320x240 & Quality = Standard

At this moment, I know only one way to access D-link cameras (JPEG format ):
D-Link photo header:
D-Link's IP address video shoot has a wide range of headers and is the first company to start using MPEG-4 on the shoot head. In fact, these photo headers use MPEG as the primary application-they no longer support other types. Most of their photo headers support sound processing, and some even support bidirectional processing. From the user's point of view, it is very easy to install and set up. Supports many settings. From the developer's perspective, these photo headers are not easy to use. The company does not want to share most of the development materials, and it is difficult to find some developer materials. This makes it very difficult to develop some of your own monitoring software. In addition, the D-link photo header is used for someone to see their images from one room to another.
URL for accessing the D-link image header (JPEG format:
Http: // <servername>/cgi-bin/video.jpg

Other video resources:
Many other video resources can be accessed in a way other than HTTP. For example, you can easily access a local network photo header through a USB port, or remotely access the video stream through MMS (Microsoft Media Services ). The most common method to access these two types of video resources is DirectShow. This technology is used in case code. You can learn more in other articles.
Program code:
The main purpose of a program is to make it flexible and scalable. The program itself can communicate with any video resource-it may be an IP address photo header or a server. It can be a local USB camera header, a remote server's MMS video stream, or other video resources. The program can work with these resources at the same time and display them on the screen.
Another major feature is scalability. The main program module does not know any video resources and how to define them; it only knows how to display them. The communication logic of all special video resources is hidden in several different modules, and the program does not closely connect them together. If you have a new video resource and want the program to work with it, you do not need to change the code of any program. Just create a new module and create a response to the video resource. Then, place the module in the program folder.
The key to solving this problem is to create a class that describes all video resource functions. This class is ivideosource. Then, create a member in the class and encapsulate all the commands that communicate with special video resources to extract images. Provides charts of each class for the program. The code is not the code of the program, but can be compiled separately and provided to the program module, which can be conveniently added to the program to expand its functions.
Each video resource module contains a definite number for the provided video. The class provides video resource access. Most modules contain only video sources, but some of them have several-a group of videos may be provided (all video sources access the photo Header/server specified by the same manufacturer to the same module, for example ).
All these video sources can be used as complete classes to access different video resources in programs. But there are still two forgotten things that make them scalable and configurable. First, our video sources should be self-descriptive and self-configuration. For this purpose, two classes are added: ivideosourcedescription and ivideosourcepage. Each class has members, providing names and descriptions of resources, allowing you to save and call configurations and establish video resources. Ivideosourcepage members provide an attribute page to configure video resources. These added classes are also associated with the video resource module. Package all together to become one of the simplest modules, including only one video resource, which should include three categories: Resource Description, resource definition, and video processing.
The final work should be implemented in terms of procedures-the program can find all modules and collect all information about video resources. In fact, images can be easily used. First, the program searches for DLL files in all program folders. Then, try to call each file as an assembly and media, and search for the ivideosourcedescription class member type. Once a type is found, the name, description, and related information of the video resource are provided. The computing process of this module is called only once at the beginning of the program, but the program can be easily modified. You can also call this process (if you can easily add a new video module, without restarting the program ).
Some low-layer technologies:
The. net1.0 and 1.1 frameworks have bugs. In fact, they are not bugs, but a feature. However, this feature causes a major problem. In the MJPEG mode, it is used to communicate with the photo header. This problem is that some MJPEG video resources do not confirm HTTP by 100%. If it is not nice to say-Microsoft is too picky, and they have put too much emphasis on HTTP standards in their earlier framework versions. Some image headers slightly lose some HTTP header information,. Net immediately refuses to continue working, and packet out network exceptions, as shown below:
The underlying connection was closed:
The server committed an HTTP protocol violation.
Fortunately, this is only a feature of. NET and may be corrected in the future. First, you must use at least version 1.1 and install the first service package. Then, create a program configuration file and put it in the program folder. The following is the minimum environment for MJPEG resources to work:
<Configuration>
<Startup>
<Supportedruntime version = "v1.1.4322"/>
</Startup>
<System.net>
<Settings>
<Httpwebrequest useunsafeheaderparsing = "true"/>
</Settings>
</System.net>
</Configuration>

Another problem is that the. NET httpwebrequest class has a feature as a connection group. By default, all HTTP requests are established in the same connection group, but each connection group has a limit on concurrent connections. Therefore, there is a big problem. You cannot monitor and produce many photo headers at the same time. The good news is that the problem can also be easily solved-The httpwebrequest class has a connectiongroupname attribute. You can arrange your own connection group.
Conclusion:
The binding program demonstrates all technologies that allow monitoring of many different photo headers. The program allows you to monitor a single photo header, or monitor several photo headers on a screen (in full screen ). Please do not use this program as a complete monitoring program system. It is just a demonstration. It is to understand the concept, but it can be used as a starting point for your own program. Although the program may be used for personal reasons.
You can find some other program code, which is also monitoring, based on the technology I introduced here.
The demo contains many free photo headers: Las Vegas, Stuttgart Airport, and many others. You can easily find more convenient photo headers and add them to the program to see if they can be monitored.