FAQ

ONVIF^TM is an international non-profit organization promoting standardization of the interface of physical IP-based security products. The word ONVIF^TM is often used to refer to the standards established by the organization. Compared with other similar standardization processes, ONVIF is phenomenally successful. It gained the support of the vast majority of IP security devices in a short period of a few years after its inception in November 2008. As of April 2012, there were over 1700 ONVIF conformant devices. By early 2018, and there were well over 10,000 ONVIF devices.

The following is quoted from Wikipedia :

• Interoperability – products from various manufacturers can be used in the same systems and “speak the same language”.
• Flexibility – end-users and integrators are not locked within proprietary solutions based on technology choices of individual manufacturers.
• Future-proof – standards ensure that there are interoperable products on the market, no matter what happens to individual companies.
• Quality – when a product conforms to a standard, the market knows what to expect from that product.

In theory, our apps work with almost every network camera on the current market one way or another. However, we highly recommend ONVIF conformant cameras to protect your investment regardless of whether you use our apps. There are over 10,000 ONVIF conformant IP camera models. The challenge is determining the true ONVIF conformance of an camera as explained by the following Q/A.

It is impossible for anyone to recommend one specific model of camera even if a brand is specified. For example, Axis Communications has dozens of different models that suit different use cases. Like many other devices, the best network cameras do not have the best prices, and the network cameras with the best prices may have quality and standard conformance issues.

Here is a list of network cameras reported by a small portion (< 5%) of our app users.

ONVIF conformance is self-certification. This helps bring out a large number of ONVIF products to the market quickly with minimum burden on the manufacturers, but unfortunately also leads to poor ONVIF conformance by some manufacturers, especially some from a certain region. Many "ONVIF conformant" network cameras are not strictly ONVIF conformant. In other words, they do not support some features mandated by ONVIF. The only way to find out whether a network camera is ONVIF conformant is testing it. We highly recommend the popular free desktop tool ONVIF Device Manager . If ONVIF Device Manager can stream and retrieve medial profiles of both H.264 and JPEG video encoding from the camera, the apps should work with the camera without any problem. Unless a camera is from a well-known network camera brand such as our partners, we strongly suggest asking the vendor to provide an on-line demo for testing before purchase, or provide references from their customers showing their ONVIF products work with ONVIF client applications. The most common serious defects of claimed “ONVIF” conformant cameras are:

1. Not supporting RTSP over HTTP. Even though our apps support RTSP over TCP and UDP now, but we strongly recommend using RTSP over HTTP for ease of traversing firewall for WAN access.
2. Not supporting JPEG encoding. Some mobile devices usually cannot handle multiple H.264 streams, so multi-view requires JPEG encoded streams for them.
3. Not supporting snapshot. Though snapshot is not mandated by ONVIF, it is highly desirable.
4. Not supporting ONVIF PTZ service even though the camera is an opto-mechanical PTZ camera. Our apps rely on ONVIF PTZ service for PTZ functions.

There could be a number of reasons. When this happens, we highly recommend using a desktop client application such as ONVIF Device Manager , a great free tool, to check if the device can be discovered by a desktop client on the same network. If a desktop client also fails to discover the device, we suggest contact the technical support of the device's manufacturer to find out whether the device is discoverable. If a desktop client can discover it, please inform us via the Support page.

Some devices such as Axis cameras may need configuration change to enable ONVIF. When enabling an Axis camera for ONVIF support , it may be better to uncheck “Enable replay attack protection” which requires clock synchronization between the mobile device and the camera.

Unfortunately, some cameras have security holes. We have observed the following types:

• Web UI and ONVIF service use different authentication systems, and the ONVIF services do not require authentication even though the web UI does.
• Streaming not requiring authentication or providing a streaming URL including credential information.

ONVIF requires digest access authentication that is much more secure than the basic access authentication used by most cameras' web UI. Unfortunately, some manufacturers do not implement it. We suggest users contact the manufacturers of their cameras with this issue to urge them to fix it by updating the firmware. We will do our part whenever we have a chance.

Unfortunately, the app has deliberately made the password retrieval difficult for security reasons. This is because some users share the access to some their cameras by exporting a list and they do not want the recipients to know the passwords for the shared cameras. For this reason, we do not assist any users to retrieve passwords because the liability and the legal process to prove the ownership of a camera would be too costly for us.

When a mobile device is connected to a cellular network, it is on a wide area network (WAN), more specifically, a wireless wide area network. First, the ONVIF discovery uses Simple Service Discovery Protocol (SSDP) that is not applicable to WAN. Second, it would be impractical to send out probes to millions of devices on a WAN to discover potentially tens of thousands, or hundreds of thousands of ONVIF conformant devices. Discovery is available only for LAN connection. For current mobile devices, a LAN connection effectively means a WiFi connection most of the time.

There are many possible causes. The following are a few of them that we have observed:

• The camera does not have the required media profile. Our apps use H.264 media profile by default for most scenarios. You could try to switch to JPEG mode in this case.
• The camera does not support RTSP over HTTP (i.e. Tunneling RTSP and RTP through HTTP). IP CENTCOM apps use RTSP over HTTP on purpose to help users simplify port configuration and firewall traverse.
• HTTP port misconfiguration. IP CENTCOM apps obtain video streaming URI's from ONVIF devices, and respect the port numbers if they are specified in the obtained URI's. For the external access to an ONVIF device, one usually needs only to forward the default HTTP port (80) to the device.
• An erroneous streaming URI obtained from the ONVIF device. For example, a requested URI for H.264 video stream is actually for JPEG video streaming, or URI for RTSP over HTTP is actually for RTP over TCP

The reasons are:

• They are created to best suit the resolution of Windows Phone to avoid wasting bandwidth of data connection. In other words, try to avoid using a lot of bandwidth to display high resolution videos on a lower resolution Windows Phone.
• Some Windows Phone devices cannot handle HD H.264 video. This varies from device to device (see Supported media codecs for Windows Phone 8 ).
• The apps allow editing profiles. If they share a profile with other apps, editing the profile will affect other apps, so they create profiles for their own use.

Please note:

• Though the apps try to create a profile with resolutions closest to that of the running device, but it only use available resolutions. Some cameras have only 2 or 3 resolutions available. Some ONVIF devices do not allow media profile creation, and some limit the number of media profiles that can be created by the user.
• Users do not have to use the media profiles created by the apps. They can choose whichever profile they like from the list of profiles for H.264 or JPEG video.

There are three effectively:

• RTP unicast over UDP. This requires multiple UDP ports to be opened. Many routers do not allow this for security reasons. This also makes configuring port forwarding for a device behind a router/firewall complicated.
• RTP over RTSP over TCP.(Standard RFC 2326 Section 10.12). This uses a single port. It is usually the RTSP default port: 554. Many routers, especially enterprise routers are configured to block the RTSP port.
• RTP over RTSP over HTTP over TCP. This also uses a single port that is usually the default HTTP port: 80. The HTTP port is rarely blocked.

Though IP CENTCOM supports all of the above, we strongly recommend RTP over RTSP over HTTP over TCP (a.k.a RTSP over HTTP, or Tunneling RTSP and RTP through HTTP), the most robust streaming method.

RTSP over HTTP (a.k.a. RTSP and RTP over HTTP, or in ONVIF's term: RTP over RTSP over HTTP over TCP) has the following advantages compared with other video streaming protocols:

• It is almost guaranteed NAT (network address translation) traversal. In other words, the video streaming can traverse both the transmitter's router and the receiver's router because it uses only the HTTP port that is rarely blocked. Other methods of video streaming, especially, RTSP over UDP are prone to router blocking.
• Underneath HTTP is the lossless protocol TCP, so it is reliable.
• It simplifies router port forwarding configuration. For using RTSP over HTTP, the user only needs to forward a router's HTTP port to that of an ONVIF NVT (e.g. a network camera or video server)

Though the benefits come with some cost - extra overhead compared with UDP, our tests have shown the effect is negligible under most circumstances.

It has been noticed that some devices return an incorrect IP address in response to the discovery probe, so please check the discovered address carefully, and make corrections if necessary. Discovery essentially helps fill out a part of the device addition form automatically.

H.264 has a large number of forms. Firstly, there are at least 9 different profiles. Secondly, there are at least 17 possible levels for each profile. Usually the profile is not an issue because most IP devices use the Base Profile(BP), and both Android and Windows Phone support BP. The required level is often the cause for mobile devices not able to display H.264 video. HD (e.g. 720p, 1080p) H.264 video usually cannot be played by mobile phones though many tablet PC's can play them.

For Windows Phone, . Please refer to the Video Support section of Supported media codecs for Windows Phone . For Android devices, please refer to the Core Media Formata section of Supported Media Formats

For H.264 video, the video stream consists of I-frames and P-frames. An I-frame of H.264 is also called IDR (instantaneous decoding refresh) frame, and a P-frame of H.264 is also called non-IDR frame. Suppose an H.264 has a GOV length of 15, its normal sequence is the following:

I P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12 P13 P14 I P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12 P13 P14 I P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12 P13 P14 …

If the bandwidth does not allow sending all the frames, an NVT (i.e. a camera) needs to skip frames. In this case, it should follow the following rule:

Never include a P frame that does not have its previous frame. In other words, if frame Pi is skipped, all of its following P frames (i.e. Pi+1, Pi+2, Pi+3 …) should be skipped until the next I frame. The sequence should be like the following:
I P1 P2 P3 P4 P5 P6 I P1 P2 P3 I P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 IP1 P2 P3 P4 …

If the simple rule is followed, we will see perfect pictures even though the video may be a bit jumpy due to skipped frames, but usually it is in well acceptable range.

If the rule is not followed, the video will show abnormal images. If P frames arrive without any an I frame before them, the image will show only changing parts until the next I frame, and the image may be grayish. If a P frame is dropped without dropping its following P frames, the video image will be distorted until the next I frame.

Our apps do not have the function adjust a camera's clock. However, Every IP camera that we have tested allows the adjustment of its clock via its web UI.

Most users set the clock to sync with an Network Time Protocol (NTP) server (a.k.a., Internet Time Server). This needs to be done only once in the camera's lifetime.

ONVIF allows setting the NTP server but many IP cameras, especially consumer grade cameras, do not support this. This is why it is not on the high priority list.

Our Android app Onvier started to support H.265 from V9.69 released on 2016-12-09.

We are still trying to implement the support for H.265 by working with Microsoft.

Windows Phone does not support H.265

ONVIF starts to support H.265 from Profile T. However, Profile T is yet to be released officially. It is expected to be released in the 3rd quarter of 2018. Therefore, H.265 is available officially only through generic RTSP configurations in our apps. You cannot find a media profile with H.265 video encoding. However, we have noticed that camera models disguise H.265 as H.264 for some ONVIF media profiles, so one can get H.265 video by selecting an H.264 media profile in this case.

This is usually caused by the high resolution of a video stream and the limitation of mobile devices. Some IP devices do not offer any lower resolution (e.g. VGA 640x480) media profiles. Many mobile phones cannot display HD JPEG images.

Since many mobile devices can play only one or a limited number of RTSP video streams, some H.264 videos may not play in multi-view. Our apps use JPEG encoded RTSP for multi-view for ONVIF devices. One can determine whether a camera supports JPEG encoded RTSP by switching to JPEG RTSP in single-view. Some cameras support the good old generic MJPEG though they do not support JPEG encoded RTSP. In this case, one can add the camera using its generic MJPEG URL in addition to the one set up in ONVIF mode, then use this in multi-view.

IP CENTCOM apps always try to use JPEG encoded video streams for the multi-view. In theory, an unlimited number of concurrent JPEG encoded videos can be supported.
However, many RTSP streams carry H.264 encoded video, and some ONVIF Devices, especially many made in Shenzhen, China, do not support the ONVIF mandated JPEG encoded video. The maximum number of concurrent H.264 video streams depends on the OS and hardware because all IP CENTCOM apps rely on hardware codecs to achieve the best performance.

• Windows 8.1/10 appear to be able to support an unlimited number of H.264 video streams. At least, we have not seen any limit in our tests.
• Windows Phone 8.1 can support only one H.264 video stream.
• It appears that the maximum number of concurrent H.264 videos on an Android device is determined by the number of CPU cores. For example, a dual-core CPU can support 2 concurrent H.264 video streams, and a quad-core CPU can support 4 concurrent H.264 video streams. However, this is not guaranteed. In some cases, the number of allowed concurrent H.264 videos is smaller than the number of CPU cores.

Please refer to the answer of Why do the apps only use hardware codec for H.264 videos?

First, congratulate on making the camera work on your LAN.

You are taking the best approach to configure the access to your camera via WAN - ensuring it works on your LAN first.

When this happens, it is almost certain that the issue is related to port forwarding configuration. Please take a look at the answer to question: How to configure an NVT and a router to allow remote access via WAN?

The specific steps to realize this are highly NVT and router dependent.

We strongly recommend RTSP over HTTP as the video stream transport protocol. Mobile apps of IP CENTCOM use RTSP over HTTP by default. RTSP over HTTP makes port configuration the simplest and most robust - usually only one port needs to be configured. RTSP over HTTP is mandated by ONVIF, and all major network camera manufacturers support it.

Unfortunately, some NVTs do not support RTSP over HTTP. They usually support RTSP over TCP and/or RTP over UDP which is a lossy protocol and should be used as the last resort. In this case, one may need to forward multiple ports: HTTP port, ONVIF port if ONVIF uses a separate HTTP port, TCP port (sometimes called RTSP port) for streaming, and maybe more.

In the ONVIF mode, the apps use the port provided by a camera in the retrieved streaming URL, so it is important to make sure NVT's ports are forwarded to from the same ports of the gateway (i.e. the external port number must match the internal port number, e.g. 80 to 80, 8080 to 8080, 554 to 554). If no port is specified in the retrieved streaming URI, the apps use port 80 by default for RTSP over HTTP, and port 554 for RTSP over TCP and RTP over UDP.

Some organizations' networks only allow traffic through certain ports. They usually block ports such as the default UDP port 554. HTTP traffic and its default port 80 are always allowed. This is why RTSP over HTTP is the most robust way for remote video streaming.

Please refer to this Google+ post with large diagrams to help you configure port forwarding.

If a WAN access configuration worked before but has stopped working, you can use the following steps for diagnosis.

1. Check whether the LAN configuration of this camera works. If it does not work either, fixing the LAN configuration will likely resolve the WAN access problem.
2. If the LAN configuration works, then check if the forwarded port is open. If the port is not open, fix the port forwarding of the router.
3. If the port is open,

First, let us distinguish video encoding from video transporting. There are two primary encoding methods: JPEG and H.264. MPEG encoding is getting obsolete. Both JPEG and H.264 are supported.

As for video transporting, RTSP is used, but ONVIF specifies four specific methods to use RTSP:

1. RTP data transfer via UDP. UDP(User Datagram Protocol) is used to transfer video data. This has the least overhead, but its traffic and its default port 554 are often blocked by many organizations. If a user uses a LAN (e.g. an institution's WiFi) which is beyond his control, he may not be able to use this mode to monitor an NVT remotely. Even a major IP camera manufacturer does not allow UDP on their corporate network.
2. RTP/TCP. This has been deprecated.
3. RTP/RTSP/TCP
4. RTP/RTSP/HTTP/TCP

Many wish to see the zoom scale of an IP device with the zoom capability, but the apps only allow zooming without showing the current zoom status. This is due to the following reasons: 1. ONVIF^TM does not mandate a function providing specific zoom scale (i.e. magnification such as 1X, 2.3X), so the absolute zoom scale information cannot be retrieved from many devices. 2. Though ONVIF^TM mandates normalized zoom scale via its generic zoom position space (http://www.onvif.org/ver10/tptz/ZoomSpaces/PositionGenericSpace), we have noticed that currently some devices do not provide the zoom status information though they allow zoom control. To accommodate all devices, we have decided not to show the zoom scale.

This depends on the following factors:

1. Available memory of the device.
2. Resolution of the video. The higher the resolution, the shorter the allowed recording.
3. Frame rate. The higher the frame rate, the shorter the allowed recording.
4. Change rate of the scene. H.264 is an extremely efficient compression for scenes with few changing parts. A rapidly changing scene diminishes the compression. The more moving objects or luminance fluctuation, the shorter the allowed recording.

The most common reason is the provided online camera does not work with the apps due to incorrect reason, credential (user name/password), or insufficient privilege of the provided credential. Please verify the camera with IP CENTCOM or Onvier before contributing it to the demo list.

This can happen with Onvier that uses JPEG encoded video for streaming by default and uses H.264 encoded stream for recording. Some H.264 profiles are too high for mobile devices to handle. For example, some Honeywell and Vitek cameras use H.264 High Profile that many mobile devices cannot handle. However, the recorded MP4 video files can be transferred to a desktop computer, or video sites such as YouTube to play.

They do not.
There are two ways to rotate videos:

1. Rotation at the video source (e.g. an IP camera video encoder) before it is sent out. This is by far the most efficient way to do it, and it has almost zero impact on the video streaming performance. ONVIF allows configuring a video source's rotation, but we have not implemented it primarily because we have found few ONVIF devices support this optional ONVIF feature. Fortunately, many network cameras allow such rotation via their web UI. Since a user usually needs to do this only once after a network camera is installed at a location, doing it via the camera's web UI is the best choice.
2. Rotation by client apps such as ours after they receive them. There are many downsides and challenges for this approach. First, it can significantly reduce video performance on some mobile devices with limited computer power. It requires PTZ and stretch actions to change accordingly complicating the implementation further. For H.264 video, this is practically impossible in some cases because all of our apps try to maximize performance by utilizing hardware codec to render video. We will continue evaluating the value and cost of implementing the support for rotation.

Please see Axis's instructions about how to enable ONVIF for a camera.

There are two possible reasons:

1. Different cameras have different sets of features.
2. Many parts of ONVIF are optional. Manufacturers of ONVIF devices choose these optional features to implement quite differently.

Apple is the inventor of RTSP over HTTP (i.e. tunneling RTSP and RTP over HTTP). IP CENTCOM's apps primarily use RTSP over HTTP for good reasons. There may be times when the streaming does not work, and it may be a good idea to validate the streaming URI with Apple's QuickTime Player. To configure QuickTime Player to use RTSP over HTTP

1. Open QuickTime Player
2. Edit > Preferences > QuickTime Preferences...
3. Advanced > Transport Setup: Custom...
4. Select HTTP for Transport.

In addition to Apple's QuickTime Player, VLC Player can also be configured to use RTSP over HTTP that is the primary streaming method of IP CENTCOM's apps. To configure VLC Player to use RTSP over HTTP (i.e. HTTP tunneling of RTSP) (as of 2014-04-18):

1. Open VLC Player
2. Tools > Preferences.
3. Select "All" at the left bottom corner
4. Input/Codecs > Demuxers > RTP/RTSP
5. Check "Tunnel RTSP and RTP over HTTP"
6. Select the correct port for "HTTP tunnel port". This is important because VLC Player does not recognize the port specified in the streaming URL. In other words, you need to come here to change the port number whenever a streaming device uses a different port than the specified. This is a significant disadvantage of using VLC Player to play RTSP over HTTP.

It is straightforward for MJPEG and Win IP Camera: grab the current JPEG frame immediately.
For generic RTSP stream:

1. If the video encoding is JPEG, the app grabs the current image immediately.
2. If the video encoding is H.264/265, the app has to accumulate a number of packets to form an image due to the compression. If this approach failed, the app will try to use the supplied snapshot URL entered on the setup screen to get an image.

For ONVIF configuration (this type also uses RTSP for streaming):

1. If the video encoding is JPEG, the app grabs the current image immediately.
2. If the video encoding is H.264/265, the app has to accumulate a number of packets to form an image due to the compression.
3. If the above failed, the app will retrieve the snapshot URL via an ONVIF service automatically and use it to get an image.

Possible reasons:

• The ONVIF device does not support the snapshot function. The snapshot function is not mandated by ONVIF.
• Some models manufactured in a certain region give wrong port information for the snapshot URL. The apps rely on the snapshot URL retrieved via an ONVIF request. Some models do not have the correct port in the snapshot URL. For example, they may be configured to use port 81 for HTTP used by their web UI, port 1018 for ONVIF. The snapshot uses port 81 accordingly, but the device reports the snapshot URL without specifying port 81, so the apps would use the default port for HTTP: 80. The apps have no way to know the device is using port 81. Changing their HTTP port to the default HTTP port 80 is helpful for these cameras that do not comply with standards strictly.

IP CENTCOM apps' RTSP decoders rely on hardware codecs for the final rendering of videos for the following reasons:

• Performance. The hardware codec based video rendering is drastically more efficient than software codec based video rendering. It is faster and uses less resource. This is one of the reasons that IP CENTCOM apps can have smooth HD videos at high frame rates on low end devices.
• License issue. Using the popular open source codec as many other apps do would legally require the apps to use the same open source model. Additionally, the H.264 patent holder (i.e. MPEG LA) demands royalty from H.264 codec implementers.

This is usually caused by a malformed media profile. The most common cause is missing required elements. IP CENTCOM apps may be able to accommodate this. Please use the nice free tool ONVIF Device Manager (ODM) to confirm the ONVIF device works with ODM, then contact us with the information. We will try our best to accommodate this.

We need to talk about Onvier's history to explain this unintended behavior.
Onvier initially allowed PTZ gesture to be effective under all circumstances regardless of whether the control overlay is displayed. We received many requests for full-screen display - no status bar, not action bar - soon after Onvier was released. As always, we took this user feedback seriously and implemented the full-screen display. Apparently many users love this based on the feedback. However, there is an unfortunate consequence of the full-screen - the gesture listener of the app will not be notified until after the control overlay is displayed by the first touch. This is due to an limitation or glitch of the Android OS. Many Android app developers face the same issue. We hope this will be fixed in a future version of Android or a remedy for this will be found. We will keep watching the development of this Android issue.

Our apps support receiving audio from all NVTs using the audio stream in RTSP.
We support international standards (ONVIF, RTSP, etc.), and do not support proprietary protocols currently. The ONVIF way of audio output is via RTSP backchannel. Generic IP Cameras usually use proprietary protocols for outgoing audio.
Currently our apps support outgoing audio in the following two ways:

1. Backchannel audio for ONVIF devices. Devices conformant with ONVIF Profile T support backchannel outgoing audio. There are over 1,500 profile T conformant devices as of May 2019. Our apps will detect the backchannel capability automatically. You will see "Backchannel audio" by the microphone icon on the setup screen if your camera supports it. Some cameras have trouble in supporting it through RTSP over HTTP, so you may need to try TCP or UDP as the transport protocol if the backchannel does not work for RTSP over HTTP.
2. Outgoing audio CGI. If you know the outgoing audio CGI URL, you can enter it on the setup screen by the microphone icon. Our apps fill the field automatically for some popular brands such as Axis.

We try prioritize minimizing latency, so the apps try the best to reduce the video streaming latency. It is at the expense of smoothness sometimes. We believe the real-time nature of video surveillance requires this. The video latency should be less than 0.5 seconds in most cases. The latency of our Windows version IP CENTCOM is slightly greater than that of our Android version Onvier.
Unfortunately, many factors that affect the video streaming are beyond our control unfortunately.

1. Camera streaming server quality. This is the most important one. We see a wide range of video latency among different brands. In some cases, one may see low latency with the manufacturer's app, but high one with our apps. Please keep in mind that we only use international standards such as RTSP, MJPEG. Many proprietary apps use manufacturers' proprietary protocols. One way to check this is using the best known RTSP client VLC Player to test the video stream.
2. Video resolution. The higher the resolution, the greater latency. It should not make much difference with a good RTSP stream server and a good computing device (Android, PC).
3. Encoding. Generally speaking, MJPEG steam has the lowest latency but its low compression rates lead to low frame rates. There should be little difference between H.264 and H.265 in terms of latency.
4. Network speed. It usually is not a factor for a LAN connection (Wi-Fi or Ethernet), but it could be a factor with a 4G connection, or public Wi-Fi connection with speed throttle.
5. Device running the app. Our apps use hardware codec to maximize the performance, so they are not demanding for CPU or memory. However, a very old PC or Android device may see significant video latencies. One can determine this by simply comparing an old device with a newer one running the same app.

The perceived PTZ latency consists of two parts:

1. True PTZ operation latency from PTZ command sending and NVT response. This is usually small. Our apps send PTZ commands as soon as the PTZ gesture or button tapping is finished. It usually takes a small fraction of a second to finish sending the command depending on the network connection quality. Most NVTs respond immediately with little latency.
2. Video stream latency. This means the actual PTZ operation happens sometime before it is shown on the video. This is usually the most significant part. For some NVTs, it can be many seconds for H.264 RTSP streams. You can gauge this latency by watching a camera's movement to see the time lapse between the camera starting to move and the video starting to show the movement.
   We need to talk about the nature of H.264 RTSP video a little bit to explain this.
   Both RTSP and H.264 inherently contribute to the video latency. The latency is usually noticeably bigger than that of MJPEG (not JPEG encoded RTSP). We have put in a tremendous amount of effort to enhance the performance of our own RTSP decoder, hence reducing the latency as much as we can. Onvier's H.264 RTSP performance is superior to any similar Network Video Client (NVC) apps that we have tested. Onvier on a low end Android device has better video than some popular apps running on powerful desktop machines.
   However, there is a limit that an NVC app can do to enhance the video performance. Some latency is inherent to a Network Video Transmitter (NVT, e.g. IP camera). We often see the latency ranges from 0.5 to 3 seconds. In other words, even if PTZ commands are sent and executed immediately, it may still take 0.5 to 3 seconds to see the change normally.

We need to talk about the nature of H.264 RTSP video a little bit to explain this.
Both RTSP and H.264 inherently contribute to the video latency. The latency is usually noticeably bigger than that of MJPEG (not JPEG encoded RTSP). We have put in a tremendous amount of effort to enhance the performance of our own RTSP decoder, hence reducing the latency as much as we can. Onvier's H.264 RTSP performance is superior to any similar Network Video Client (NVC) apps that we have tested. Onvier on a low end Android device has better video than some popular apps running on powerful desktop machines.
However, there is a limit that an NVC app can do to enhance the video performance. Some latency is inherent to a Network Video Transmitter (NVT, e.g. IP camera). We often see the latency ranges from 0.5 to 3 seconds.
With the latency in mind, we can easily explain why Onvier does not allow continuous PTZ operation. Let's use a specific example. Suppose a video has a latency of 1 second (better than the average), and it takes 3 seconds to zoom from 1x to 30x. Suppose Onvier allowed continuous zoom while "+" is pressed, and the user wanted to zoom from 1x to 20x. Let's assume the camera and network connection were so good that the zoom command had zero latency. The user pressed the button, it took 2 seconds to zoom to 20x, but the user would not see the 20x video until 3 seconds due to the video latency. He released the button when he saw it at 3 seconds, however the zoom would be already at 30x due to the video latency at that point of time.
One may argue that he could get used to the latency and release the button before he sees the targeted PTZ level. Unfortunately, the latency varies from camera to camera. Even worse, for the same camera it may vary under different conditions - network connection speed, image changing rate, etc.
With current technologies, it is impossible to have continuous PTZ operations with remote viewing as responsive as that of digital camera we operate by pressing physical buttons.

First, please see the above Q/A regarding why Onvier does not allow continuous PTZ operation.
Pressing a PTZ button causes a discrete PTZ scale change. Onvier follows the conventions of software button operations - starting the action after a button is released. This may be different from that of mechanical buttons on digital cameras. If you look at other apps, you will notice the same behavior. A user can actually cancel the action after pressing a button by moving the touch or cursor off the button before releasing it. One can use the zoom buttons of Google Map to test this behavior.

It varies. Users do not want to see the control overlay at all when they are not needed. Onvier tries very hard to figure out when the control overlay is needed and when not. It is an evolving process. Usually it displays the overlay for 3 seconds after a touch. It will hide it immediately upon certain events (e.g. gesture), and it will lengthen the display time upon some events (e.g. overflow menu showing). We are keen to hear feedback from users to continue improving the control overlay display.

Our apps can automatically discover all ONVIF conformant devices that support discovery. All ONVIF conformant devices that we have tested support discovery. If your ONVIF device cannot be discovered, please use the nice free tool ONVIF Device Manager (ODM) to verify its ONVIF conformance.
If you believe a device is ONVIF conformant, and have entered the IP address manually, please make sure the IP address is correct, the device is on line and the port you have specified is for ONVIF services. All major brands use one HTTP port (default: 80) for everything - ONVIF services, RTSP streaming and snapshot. Some brands, especially many from certain region use multiple ports (up to three).

Usually this is caused by authentication failures. Please ensure the credential (user name/password) is correct and it has the privilege to access ONVIF services.
Some ONVIF devices (e.g. Axis models) use a set of users for ONVIF services different from that for their web UI access. In other words, ONVIF services require their own user management.
We have also heard from some users that some models made in a certain place require blank user name and password (i.e. DO NOT enter user name or password).
Some users told us that they have to set their camera’s ONVIF port to 8899 instead of 8000 by using the camera’s web UI or its own app to avoid this error (e.g., some Wansview models).

There are usually two ways:

1. If a DVR/NVR is ONVIF conformant, it can be treated as one ONVIF device. It may have different media profiles corresponding to different connected network cameras, so the user can access all the cameras by using their corresponding media profiles.
2. If a DVR/NVR is not ONVIF conformant, it usually provides an RTSP URL for each connected network camera. The user can add each camera as a generic RTSP stream. The DVR/NVR's user's manual or the manufacturer's tech support is the best source to find the URL format.

A user has told us that his NVR needs to whitelist IP addresses from which accesses are initiated.

The quick answer: our apps do not support them currently, but most IP cameras, if not all, have built-in motion detection and other alarm features that can work 24/7 without the need to run any app. The functions are done much more reliably and efficiently by cameras that have the raw data than client apps such as ours. We plan to support these features via ONVIF's event service. However, we have found that most, if not all, consumer grade cameras do not support ONVIF event service currently. Hope we will see more support for ONVIF event service in the future.
The following is the long answer:
We fully understand that many users would like to have these features that are given nowadays for any video surveillance system.
A video surveillance system usually consists of three parts: video transmitters (e.g. network cameras), a video management system (VMS) and video clients (e.g. apps viewing and controlling cameras). Some apps combine VMS and video client functions. At this point of time, we consider our apps primarily as video clients. Their primary function is viewing and controlling video transmitters.
In ONVIF terms, motion detection is a part of video analytics, and alarms are a part of eventing. ONVIF supports both video analytics and eventing.
The most efficient place to do video analytics is the video source (e.g. a network camera). Almost all network cameras have video analytics including motion detection. Unfortunately, at this point of time, most ONVIF network cameras support neither ONVIF video analytics nor eventing. In other words, these cameras have the features, but client apps such as ours are unable to utilize them through ONVIF services. Our apps are focused on the support for ONVIF services instead of proprietary APIs of different manufacturers.
One option could be reinventing the wheel by doing basic video analytics within our apps. Mobile devices (e.g. phones) run our apps only on demand. The apps understandably are not allowed to run in the background to consume resources including power constantly. Relying on our apps for video analytics and alarms is impractical under most circumstances.
With more and more network cameras supporting ONVIF video analytics and eventing services, our first priority will be supporting these features through ONVIF.
For now, we suggest users utilize network cameras' web UI to configure motion detection and alarms. They are usually simple to configure and very reliable based on our experience with many models.
Our apps support ONVIF Profile G. Profile G is about the edge storage (e.g. recording on camera SD cards). If a user configures an ONVIF device to store triggered recording on SD cards, profile G will allow the viewing and management of them. Please note that not all cameras with built-in storage support ONVIF Profile G.

Our apps control devices primarily via ONVIF services. Features such as IR control are not a part of ONVIF currently, so they are not supported by our apps. Most, if not all, cameras with IR turned on/off IR automatically based on the light level.

ONVIF has something called auxiliary PTZ commands that we are yet to implement because most, if not all, consumer grade cameras do not support this. For now, if you know the command URLs for turning on/off IR (something like: http://address:port/something.cgi?xxx=yyy), you can add them as custom commands.

This is true of other commands such as focus, PTZ commands for generic RTSP streams. Our apps support many commands such as PTZ, focus, presets automatically for ONVIF cameras via ONVIF services. However, this is not applicable for generic RTSP/MJPEG streams. For them, custom commands are the only way to achieve these functions.

The following are examples of commands for Axis cameras:

• Activate light to level 100:
  http://xxx.xxx.xxx.xxx:Port/axis-cgi/lightcontrol.cgi?action=L1:100
• Deactivate light (i.e. bring the light level to 0):
  http://xxx.xxx.xxx.xxx:Port/axis-cgi/lightcontrol.cgi?action=L1:0

The following are examples of commands for INSTAR IN-9020HD shared by a user:

• View the logfile of the IN-9020HD:
  http://xxx.xxx.xxx.xxx:Port/tmpfs/syslog.txt
• Turn the infrared off and on.
  http://User:Passwort@xxx.xxx.xxx.xxxx:Port/param.cgi?cmd=setinfrared&-infraredstat=close
  close=Infrared off
  open= Infrared on
• Switch the circuits to daylight/night/automation.
  http://User:Passwort@xxx.xxx.xxx.xxx:Port/param.cgi?cmd=set_instar_admin&-index=2&-value=auto&cmd=setircutattr&-saradc_switch_value=60&-saradc_b2c_switch_value=40
  auto = Daylight on automatic
  http://User:Passwort@xxx.xxx.xxx.xxx:Port/param.cgi?cmd=set_instar_admin&-index=2&-value=close&cmd=setircutattr&-saradc_switch_value=1&-saradc_b2c_switch_value=1
  close = Nigthlight on
  http://User:Passwort@xxx.xxx.xxx.xxx:Port/param.cgi?cmd=set_instar_admin&-index=2&-value=open&cmd=setircutattr&-saradc_switch_value=270&-saradc_b2c_switch_value=270
  open = Daylight on

The support for camera embedded SD cards is through ONVIF Profile G that governs edge storage. As of July 2019, there are about 6,000 certified models supporting Profile G. The vast majority of them are from major brands. We see more and more newer models of consumer grade cameras supporting Profile G.

For our Android version Onvier, if the context menu (hold a device tile to show it) has "Device Recordings" enabled, it means the camera supports Profile G.

A drawback of current Profile G is the lack of video downloading feature. Many users including us would like to be able to download recordings to a user’s device, then can use preferred video player to browse and play the downloaded files. The default video player and the Gallery app are quite good. One can browse hours video quickly to find interesting things. Unfortunately, Profile G does not support this. It only allows exporting from SD card to a configured NAS drive, not to the device running the app. Only proprietary protocols such as Axis' VAPIX allows downloading video to the client machine.

Some ONVIF devices have predefined media profiles corresponding to all available resolutions, but some are not. If an ONVIF devices is strictly ONVIF conformant, other resolutions can be obtained with any of the following methods:

1. Edit the video encoder of a media profile via our apps (Pro version) or the free tool ONVIF Device Manager.
2. Add a media profile via the free tool ONVIF Device Manager. Our apps usually create new media profiles to suit the screen resolution of the device running the app best. Please see the question of FAQ "Who are new media profiles created during setup?".
3. Some ONVIF devices allow editing/creating media profiles with their UI. Some devices only allow changing video resolutions for predefined profiles.

We fully understand the convenience of using P2P for IP camera connection. Our apps currently do not support P2P, and we will keep examining the suitability of supporting P2P. Our current thoughts regarding P2P are the following:

1. There are many platforms of P2P, and none of them are widely accepted as the de facto international standard. We are committed to the support of the international standard ONVIF due to the tremendous benefits that ONVIF brings to users. We continue to avoid getting into proprietary protocols.
2. A P2P service requires an IP camera maintaining a constant connection with its server. Though the bandwidth usage by this connection is fairly small, we think this is not highly desirable. A DDNS service is advantageous in terms of reliability. It requires a router to report its public IP only occasionally. DDNS is a very mature technology and many DDNS providers have excellent track records of reliability.
3. DDNS is also more transparent to users than P2P because their users know exactly which DDNS provider they are using while few users of P2P know which company's P2P server maintains a constant connection with their cameras. We always feel manufacturers ought to disclose these P2P providers to address any security concerns of users because these providers at least have the capability to access all registered cameras. The security risk is real.

The official policy for app or in-app purchases does not allow refunds. However, Microsoft is kind enough to consider refunds if there is a good reason. Each case needs to be handled individually by a Microsoft representative. It can be done as following:

1. Log into your Microsoft account.
2. Click “Contact Us” at the bottom.
3. Click “Windows. Office, and…”.
4. Click “Accounts & billing”
5. Chat online with a Microsoft Answer Tech
6. Ask the chat rep for a refund by providing a legitimate reason.

All demo cameras are from third parties. We do not have any control of them though we check their on-line status periodically. Only demo cameras that are on-line during our checking are provided for testing purposes. However, they may be off-line for a variety of reasons. There is a limit for the number of concurrent connections for each camera, so a connection may be rejected due to the limit being reached.

No, we currently do not have a version for iOS unfortunately due to the lack of the resource to develop the iOS version though it has been our plan, and we have tried earnestly to unify all versions targeting different platforms including iOS using Xamarin, but failed. We will support iOS as soon as we have the resource. We currently support Windows (8.1/10), Windows Phone and Android.

The Pro license is completely managed by the app store and is associated with a user's store account. It does not have a key. A user gets the Pro version automatically on any device running the app downloaded from the same store with the same account.

For example, if you upgrade to the Pro version via Google Play, you will get the Pro version automatically on any Android device running the app downloaded from Google Play with the same user account. This is true for Amazon AppStore and Microsoft Store for Windows apps. This is explained on our apps' upgrade screen.

This also means you will not get the Pro version if you download the app from another store or from the same store using a different user account. Please note this is the policy of app stores and we do not have any control of it. We must comply with the policy to have the apps distributed by the app store. Please see "Why do different versions have different Pro version licenses?" for detailed explanation.

The Pro license is managed by Microsoft server of which we have no control. A glitch to cause this has happened many times for many apps and users. We have been urging Microsoft to fix this permanently. Some users have found the following remedy working for them:

1. Click the button or menu item(e.g. "Upgrade") for upgrading. A pop-up message box shows up. This message box is still a part of the app, not Microsoft purchase process.
2. Click "OK". This will go to Microsoft Windows Store purchase transaction page.
3. Click "Cancel" if the Windows Store page shows up and with “buy” button instead of the “You already own this – Install” button. If you do not see the store page, but a pop-up box thanking you for the purchase, it means the license has been retrieved successfully.
4. Open the app again.
5. The app should retrieve the license correctly.
6. Out of caution, please check your Windows Store account. If Microsoft charges you again(this is extremely unlikely), please ask for refund and let us know ASAP.

Please note that the app goes back to the free version only if the Microsoft license server tells it specifically that you do not have the license. We have worked with Microsoft a few times, it took a few weeks each time, but have given up because they insist providing a way to reproduce this. This happens randomly. We are unable to reproduce it reliably. If you happen to know a way to reproduce this, please let us know.

The Android app license is completely managed by Google. This is likely related to a known Google Play cache issue. Some users have found the following remedy working for them:

1. Click the upgrade button in the app to try purchasing the license again.
2. Follow the instructions to reach the Google Play in-app billing page, but DO NOT complete the transaction. This should force the Google Play service running in the background to refresh the cache.
3. Restart the app, and you should be able to enjoy the Pro version again.

Another solution is clearing data and cache of Google Play Store app:

1. From a Home screen, navigate: Apps > Settings > Apps.
2. Tap Google Play Store.
3. Tap Storage.
4. Tap Clear Cache then tap Clear Data.
5. Tap OK.

A user has told us that he has consistently remedied this problem by reinstalling Onvier though we do not understand how reinstalling Onvier can affect this Google Play cache glitch.

If this issue is caused by using multiple Google accounts on an Android device, please try the following:

1. Clear Google Play cache using the above method.
2. Open Google Play and switch to the account used to make the purchase.
3. Reboot the device.
4. Open the app.

Please contact us if the above methods do not work. Thank you very much for supporting the app.

The Android app license is completely managed by Google. This is a known longstanding issue of Google Play billing service. The following is one of the suggested remedies verified by a user:

1. Uninstall Onvier.
2. In a BROWSER on your desktop: Log in to the web interface of Google Play with the account you used to purchase.
3. Install Onvier from the web interface to your device. DO NOT let it open Google Play, but use the install button and choose your device in the browser.

Android app licenses are managed by Google, and Windows store app licenses are managed by Microsoft, Amazon store app licenses are managed by Amazon.
Per Google's policy, there is no limit on the number of devices using a purchased license.
Per Microsoft policy, up to 10 devices can actively use a purchased license.

Not at this point of time. We will update this if it has changed.
Google introduced Family Library in July 2016, and we have debated on whether making Onvier Pro available the Google Play Family Library several times. We understand the usefulness for some users. The following points have made us hesitate to make the move:

• Onvier FREE has all the basic functions. As a matter of fact, most app users use the FREE version. The non-intrusive ad of the FREE version is minimal, and displayed only at the bottom of the home screen. It never shows during video streaming that is the most important and frequent task. A FREE version user does not see any ad usually more than 95% of the app usage time. If a family has a primary user needing all the extra features, and others do simple monitoring, one Pro license that can run on unlimited devices of the same user should suffice. BTW, the ad generates minuscule revenue for us. It is more of a FREE version indicator than anything else.
• We need to maintain some level of fairness. The Android license policy controlled solely by Google is already quite generous - it allows a Pro license used on unlimited number of devices; whereas the Pro license of our Windows version is significantly more expensive, and yet limited to 10 devices v.s. unlimited for the Android version.
• In the case of more than one family member finding the Pro version features necessary, we feel an additional license should not be a big burden because it is only a tiny fraction of hundreds of dollars that many users spend on multiple IP cameras.

Please note:

1. A license purchased in-app must be from the store that distributes the app (e.g., Microsoft Store, Google Play) according to the store policy.
2. A license purchased in-app is associated with the user account of the store, so it is good on any device using the store. For example, if you get an app from Google Play on different Android devices, one license will be good on all the devices.
3. An in-app purchased license is completely managed by an app store. We have no access to user account information. We have no control of store policies or in-app license management.

We rely on Google Play, Microsoft Store and Amazon to handle Pro version licenses, therefore the Android version has a license handled by Google Play or Amazon, and the Windows Phone version has a license handled by Microsoft Store. They are all associated with the accounts of these stores respectively. We have absolutely no access to any user accounts of these stores.
The Windows version came much later, but before Windows 10 came out to unify the OS for Windows Phone and Windows. It is a separate app, so it requires another Pro license. We wish that we could merge the licenses for Windows Phone and Windows version, but the technical burden is very significant, so two separate Pro licenses for Windows Phone and Windows respectively will remain for the foreseeable future.

Google Play started to reject our app updates in March 2024 by claiming the launcher icon of the app does not comply with their TV standards. Many Android app developers suddenly started to face the same issue at the same time. We used the tool provided by Google to create the app icon set. We worked diligently with Google to address this issue by exhausting all possible remedies that we could think of for a month. We decided to disable TV distribution temporarily to allow the app updating to continue. We will continue to work with Google to address this issue as quickly as possible to make Onvier app available for TV devices again. Unfortunately, we cannot offer an estimated resolution time because we share the opinion with some other developers that this is likely caused by a glitch of Google Play certification process and we hope Google will correct it eventually.

As a temporary remedy, the latest version can be downloaded from our website for side-loading.

Windows 10 makes this task much trickier that it should be.
The key is creating a shortcut of the Windows Store app and add it to the following folder:
C:\Users\[your user name]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
Finding the shortcut is the trickiest.
Here is one way to accomplish this:

1. Open File Browser, go to folder "C:\Users\[your user name]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup"
2. Go to Windows Start > tap All Apps (the bottom item) to list all apps in alphabetical order > Find the app.
3. Drag the app to the file browser opened earlier. This is easy to do if you have more than one monitors or Windows Start is not full screen. If you have only one monitor and Windows Start is full screen, you will need to drag the app to the file browser on the taskbar.

Periodically some users kindly agree to run a test version of our app for diagnosis or beta testing. In this case, the app package needs to be sideloaded. The process is simple and straightforward:

1. Download the package which may be in a zipped file.
2. Follow Sideload your app package.

The UWP version was released on 2017-11-06 finally.

The following is the long version:

We have been looking forward to migrating IP CENTCVOM to UWP since the release of Windows 10. Since we are unable to afford maintaining two Windows versions of IP CENTCOM - Windows 8.1 and UWP for Windows 10 - due to very limited resource, we waited till the number of Windows 8.1 users of the app dwindled to less than 10% before starting the migration. Please note that the Windows 8.1 version will always be available for downloading, but it will not be updated after the migration.

We were on track to release the UWP version by the end of January 2017 as promised to some users. We prepared the beta version to be published to Microsoft Store in late January and were ready to invite some Pro version users to try it. Completely to our surprise, the beta version generated a slew of errors related to ONVIF services while the debug version worked flawlessly. A frantic investigation ensued, and we resorted to a support ticket to Microsoft quickly.

Fortunately, Microsoft kindly responded quickly and assigned a very responsible and talented Engineer (David) to this issue on January 31, 2017. David found the culprit within 24 hours - the tool of Visual Studio for creating the release version of a UWP app not supporting a large number of APIs some of which are required for ONVIF services.

For those with inquisitive minds, here is a simple explanation of different app versions. Before UWP for Windows 10, Windows Store apps like IP CENTCOM use Just-in-time (JIT) compilation meaning they are compiled into machine code after user start running them. This is why they may be noticeably slow for the first run, and much faster for subsequent runs. JIT compilation needs to be done only once after an installation or update. To enhance apps' performance, Microsoft started using the .Net Native model. .Net Native compiles apps into machine code before users download them hence dramatically improving the app start performance. For unknown reasons, Microsoft chose to deprecate many APIs for .Net Native compilation while supporting them for app development. Since .Net Native compilation is very time consuming, it is impractical for developers to use it during app development when apps need to be restarted frequently. This is why the debug version of IP CENTCOM's UWP version works flawlessly while its release version generates many errors. Making the problem even worse, the errors cannot be detected by the .Net Native compilation, they will occur only when the app's relevant functions are performed. In other words, they are run-time errors.

David tried his best to come up with workarounds and involved other staff of Microsoft to lend their hands, but unfortunately, no viable method was found after a month-long diligent endeavor. We tried our best to find a remedy too. The burden is simply too high to overcome. Very fortunately, David managed to persuade the .Net Native tool team to fix this problem, and told us .Net Standard 2.0 to be released in Q3 2017 would include the fix. The Microsoft support ticket was closed on March 14, 2017, but we kept tracking the issue and crossing our fingers.

Microsoft finally released the new tool chain in July 2017, but only available with Visual Studio 2017 Preview version. Migrating the app project to the new Visual Studio took a few days with the extensive help from Shin, a Microsoft engineer on the tool chain team.

We were ready to publish the app to Microsoft Store for β testing in early August 2017. Unfortunately, the store did not support the new tool chain at that point of time, so we had to wait for the store to support the latest Microsoft technology.

Microsoft Store finally started to support the new tool chain in late August, but unfortunately, x-64 package of the app produced by Visual Studio kept failing though x-86 and ARM packages had no problems. With the help of Shin, we finally found the culprit - a residue from project migration causing wrong dependency - in the middle of September.

We largely completed the migration in the middle of October.

The UWP version was released on 2017-11-06 finally.

The UWP version relies on Microsoft Windows SDK. The SDK governs how ONVIF SOAP messages are sent out. The SDK prefixes each SOAP message with an HTTP/1.1 HEAD method request. The HEAD method request is legitimate though effectively useless for ONVIF services. Most network cameras can handle it without any problems, but some cameras (e.g. at least some Hikvision models) are unable to handle it.

We contacted Microsoft on 2017-12-07, and their engineers immediately agreed to remove the HEAD method request. Since this issue involves multiple teams, we were not sure when this would be fixed.

We also sough Hikvision to fix their firmware to make it accept the legitimate HTTP HEAD method requests.

One could add a Hikvisoin camera as a generic RTSP stream.

As the last resort, we could send you the old Windows 8.1 version that which can run on Windows 10.

This problem was finally solved on January 24, 2018 when a Microsoft engineer came up with a brilliant workaround.

In order to use your Tablet of Smart phone as a door-chime surveillance cam with auto-switch-on and auto-switch-off function, you need to make some changes.

You will need Onvier (V10.69 or above ). In Onvier, you need to uncheck “always on” so that the internal device timer for “screen-timeout” / sleep-mode-timer will be “active”.

You can also set Onvier as a default startup-app that starts with your device automatically. Your “Door-Cam” can also be selected as default-startup-cam when Onvier starts.

After these settings, your device is going into “sleep-mode” or “standby-mode” after the time you set in setup if you don’t “touch” the device for other use. I suggest 5 minutes.

At the device, the function similar to “wake-up after plugging-in power” or wake-up after putting into docking-station must be enabled.

Now the only problem left is how to connect the device with your doorbell.

I used a simple “trick” and installed a small relay parallel to the door-chime. This relay interrupts the device-charger ( in my case the USB power) for a short moment ( I installed the relay into the cable, between charger and my device).

You have to use this relay in “normal closed –mode”. Your device will be charged normally and only be interrupted for one second or so when someone is pressing the doorbell.

This will wake up your device and you will see the camera-stream of the cam ( in my case the door-entry cam). After 5 Minutes, the device goes into “sleep-mode” again if you have unchecked the “always on” in Onvier.

In a nutshell, a deep link is used to show specific content of an app. For example, the Pro version of Onvier has a deep link for the video streaming screen of each camera, so it can be used to start video streaming of the specific camera.

How to use deep links is the confusing to many users. Deep links usually are not meant to be used directly by end users. They are embedded in apps or web pages for clicking. They may look like regular web URLs, but they cannot be opened by a web browsers to our best knowledge as of this writing (2018-04-05)

Some apps, such as those for home automation, allow end users to enter deep links to open other apps. For example, an alarm/door bell app may allow a user to enter a deep link so that it can open another app automatically upon the going off the alarm

Tech savvy users familiar with Android Debug Bridge (adb) can use the following format to test a Onvier deep link for a video:

adb shell am start -W -a android.intent.action.VIEW -d onvifer_deep_link

The following is a specific example:

adb shell am start -W -a android.intent.action.VIEW -d https://ipcent.com/onvifer/streaming/cd512fa7-d686-47f4-8e8a-158532b44fa8

Chipsets are the brains of network cameras. Many major brands have their own chipsets. Generic brands use chipsets made by other manufacturers.

There have been quite a few network camera chipset manufacturers. Some have exited markets.

• HiSilicon a subsidiary of Huawei, a telecom company in China.
• Ambarella, a company based in Taiwan.
• Ralink, acquired by MediaTek, a company in Taiwan.
• Texas Instruments

The mysterious memory leak is a known issue for multi-view with certain video/audio driver configurations . IP CENTCOM is very efficient in resource consumption. Even a 3x3 multi-view (i.e. 9 concurrent video streams) normally uses less than 200 MB of memory and less than 10% of CPU on most computers.

We have tried to reproduce this memory leak numerous times on a wide range of devices (desktop PC's, laptops, tablets), but succeeded only once. The following is the only case:

It is desktop PC using an Asus motherboard, a AMD Ryzen CPU and a Nvidia GTX video card. After trying all kinds of combinations, we could pinpoint Realtek audio driver as the culprit.

• At one point, we could remedy the memory leak by updating the audio driver to the latest from Asus.
• When the memory leak started to occur again despite the latest audio driver, we could remedy it by uninstalling and cleaning Realtek driver as thoroughly as we could. The stubborn Realtek driver came back automatically in the end, but the memory leak did not.

We suspect Microsoft's MediaPlayerElement control has a bug causing memory leak with certain audio/video drivers.

Please feel free to contact us if you would like us to assist you in diagnosis or you would like to help investigating this by trying a debug version.

Pro version users have the option to start the multi-view automatically when the app starts. They also have the option to restart the app with a specified interval (under settings) allowing clearing the memory leak periodically.

The H.26x video streaming of IP CENTCOM is usually smooth with minimal latency. However, it may have a significant latency or jerkiness with some hardware settings. Though the app does not condition any code with hardware settings, the multiple layers underneath the app vary among computers and are largely out of the control of the app.

The first step of video streaming is decoding. IP CENTCOM uses our own RTSP decoder and sends demuxed H.26x NAL units with their timestamps to a Windows control as soon as possible upon requests from the Windows control, the rest is up to underneath layers. The following is a simplified flowchart (there are actually much more layers).

The second step of video streaming is the rendering of decoded video frames. IP CENTCOM is not involved in this step at all. Though it sends timestamps together with H.26x NAL units, it is up to the Windows control to decide when to render each video frame. Microsoft does not provide any details about how the timestamps are interpreted or affect the rendering

We have noticed that Windows may change the handling of the above processes with different builds. It may get better or worse with a Windows version update. We encourage users to report any issues with video streaming quality, and we try our best to address them. Hardware configuration and Windows version information is always useful in addressing these issues.

Our apps are not related to any apps installed by manufacturers, but unfortunately, some of them such as Samsung's Game Launcher and OnePlus's Game Space. We have tried, but failed to find a way to prevent these manufacturers' apps from misidentifying Onvier as a game. Only users can manually configure these apps to correct their mistake.

IP CENTCOM relies on hardware/OS codec to maximize performance and minimize resource usage. Some PCs, especially older ones, may not have the hardware capability or the latest video driver to decode H.265. We have heard from many users that they have good luck in using Microsoft HEVC Video Extensions in addressing this issue. Please do not be disturbed by the low ratings of Microsoft HEVC Video Extensions that are largely due to complaints about Microsoft charging $0.99 for this extension.

A user has told us a FREE version (HEVC Video Extensions from Device Manufacturer) works too.

There are a variety of reasons for this. Sending us the debugging log from the video streaming screen usually is the best first step to diagnose this problem.
There are sources of the problem:

1. RTSP stream of the camera. It may not like the standard keep-alive requests from the app, or the transport protocol. The debugging log should provide a good clue.
2. Poor network connectivity. This is usually related to WAN access or Wi-Fi connection. A user told us he solved the problem by fixing the Wi-Fi channel of his router instead of using letting it choose automatically.

We understand some users simply want to use the encryption part of Transport Layer Security (TLS) to enhance the security and obtaining a certificate from a third-party authority for each IP camera is usually unrealistic, so the apps were initially lenient with certificates.
Google started to require us to tighten the certificate validation in 2020, so we did it according to their instructions. Android version - Onvier - uses a device's default X509TrustManager to handle certificate validation. Please feel free to let us know if you need us to accommodate certain types of certificates.

We looked into the cast function. We have noticed a lot of our app users run our app on Android TV devices to display videos on TVs. A user of an Android app can always use Google Home to cast our app on a TV. We understand this is not as convenient as an app’s built-in cast function. We will continue to evaluate this option especially if we hear the request from more Pro users.

First, you can use the blue navigation buttons shown at the bottom consistently for navigation.

The app started to hide the system bars (both status bar and navigation bar) soon after its release in response to many requests by users. It intended to display only the navigation bar upon screen tap. The status bar display was not intentional. We simply lost control of the system bars on Android 11 devices (only Android 11) for the full screen mode because they have erratic behaviors varying from one model to another model. We really have no choice but to use our custom navigation controls. We do not know when and how much Google will mess up the system bars in the future. We followed their exact instructions to handle the system bars but they simply do not behave as documented on some Android 11 devices.

We plan to add an option to allow using system bars in the near future.

Export and import on a TV devices, especially Amazon TV devices, can be tricky because of the file management limitation on them.

A user has kindly made a great video to demonstrate this. Please watch it for step-by-step instructions.

XBox has a well-known bug that crashes Store apps that support multiple instances. Like many other developers, we have urged Microsoft to address this issue for a long time.

Our current awkward solution is making a special version of IP CENTCOM distributed through a special flight by Microsoft Store. Users interested in this should feel free to contact us to obtain this special version.

If you are interest in this approach, you can provide us your Microsoft Store email address and allow us to put it on the special flight list so that you can download the special version on your Xbox.

Please refer to this post by a kind app user for explanation and solution.

Wouldn't it be nice to have Win IP Camera send out video wherever we go as long as the phone has a cellular connection. Unfortunately, as far as we know, wireless carriers do not allow this even though it is possible technically. A mobile phone connects to the Internet through one or more firewalls/NAT devices controlled by carriers. The carriers configure them to block incoming connections to phones.

This is not just the case for Windows Phone devices. It is true for all mobiles phone (Android, iPhone, etc.).

This is a common symptom of camera driver crash. Rebooting a device almost always fixes it.
More than half of the time spent on Win IP Camera development is for dealing with video drivers that require extremely tender care. The vast majority of issues after the initial release of Win IP Camera are related to camera drivers one way or another. We have tried everything we can think of to avoid disturbing camera driver.
Built-in cameras of Windows Phone devices are under better control than attached web cams. Users may see more issues with the Windows version of Win IP Camera streaming from attached web cams. There are a lot of cheap poor quality webcams on the market. It is challenging to accommodate all of them. Even the camera drivers of major brands have issues.

Win IP camera taps into true video streams, not low lag still photos or preview videos, from cameras. If a phone and the network speed are sufficient, the app can stream at 30 fps. However, for practical purpose, Win IP Camera uses an algorithm to select the optimal sampling frame rate determined by device type and video resolution ensure the best reliability and performance. For example, the sampling rate for HD video will be 8 FPS for low memory (512MB) devices, and 16 FPS for all other devices.
That actual transmitted frame rate is lower than the sampling rate. It depends on the device's computing power required by JPEG encoding, the network bandwidth and the network capability of the client device(e.g., the device running our client app IP CENTCOM or Onvifer, or a web browser), the image size and image complexity. Large images with fine details result in low frame rates and small simple images have a higher frame rates.
Modern IP cameras usually use H.264/H.265 to achieve high frame rates with a limited use of bandwidth because H.264/H.265 have high compression ratio:
Approximate compression Ratio (they vary widely depending on multiple factors) :
H.265: 1000:1
H.264: 500:1
MJPEG: 10:1
Please note that only MJPEG is supported by web browsers without using any plug-in.

Win IP camera taps into true video streams, not low lag still photos or preview videos, from cameras. The app presents the image from the video stream after transcoding, but without any modification. Therefore, if there are some blank areas, they will show up because Win IP Camera has no way to know unless it analyzes each image frame. The rotation may be an exception because the blank areas are predictable.

We are fully aware of the power consumption problem, and have done everything we can to reduce the power consumption. Sending HD MJPEG streams over WiFi may be the major power hog. If we implement the support for H.264 RTSP stream, this may be alleviated due to the much smaller required data rate.

Motion detection is beyond the capability of many low end Windows Phone devices at any decent frame rate with HD video. Low end devices probably account for more than half of the market. We may consider this for the Windows version. Video recording is only practically viable after implementing the support of H.264 video.

Though it would be very easy to add the recording function in terms of coding, we are afraid that many phones would not be able to handle this.
We estimate that more than 70% of our development time for this app is spent on coping with camera drivers' vulnerability, especially for low end phones with 512MB memory. We have tried everything that we can imagine to reduce the workload to make the app have acceptable reliability.
We may try adding the recording option in the future with adequate warning of its potential detrimental effect. We will certain consider adding this function to the Windows version.

A user gets the ability to monitor all his cameras securely by simply using an Internet browser without installing any ActiveX controls or other add-ons that usually come with every camera.

Here is what one usually has to do when connecting to a camera directly:

1. One needs to remember the IP address of each camera to connect it (e.g. http://MyIPCameraAddres:port/).
2. One needs to remember the user name and password of each camera, and provide them when prompted.
3. If it is the first time to use a particular computer to monitor the camera, one needs to go through multiple steps to install ActiveX controls or other add-ons depending on the browser.
4. Repeat the above steps for each camera.

Anyone familiar with different IP cameras can tell how diverse the add-ons are. The installations range from being straightforward to nearly impossible. The worst under this scenario is that installation of these add-ons is usually not allowed by policy or computer configuration at workplace or public facilities.

IPCENT.COM eliminates all the above difficulties or nuances once the cameras are registered.

• IPCENT.COM uses Hypertext Transfer Protocol Secure (HTTPS) as used by many banks. The communication between your browser and IPCENT.COM is encrypted.
• Each camera's IP address, user name and password are all encryptped before they are stored in our database. In other words, even people with access to the database are unable to extract the information encrypted with the state-of-the-art algorithm.
• Users' camera video streams are routed from the cameras directly to the monitoring browser. They do not pass through our server. We do not have access the streams.
• As stated in our privacy policy, we never disseminate user information to any third-party

Maintaining the service and implementing support for various camera models can be costly. We plan to generate revenue to sustain and grow the service by the following avenues:

• Ads that are very carefully selected and placed to avoid any interference with user's monitoring. We will never insert any video ads into user's video streams.
• Premium service for some sophisticated users who would like to have more functions such as recording and broadcasting. We expect the majority of users will be content with the free service.