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.
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.
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
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 Android app Onvifer 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.
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.
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:
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.
Our app currently do not support camera SD card functions. Users usually can use a camera's web GUI to configure recording on the camera SD card.
We finally started to implement the support ONVIF Profile G that governs edge storage (e.g. recording on a built-in SD card) in August 2018 after a significant number of major brands had started to support Profile G in their cameras. Initially, only a few major brands (e.g. Axis, Panasonic, etc.) did. Generic consumer brands usually do not support Profile G currently, so Profile G may not benefit many consumers as 2018.
One useful and simple function is downloading the recordings to a user’s device, then the user can use his 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. We may consider supporting some most commonly used models with their proprietary protocols.
A user has told us that he has consistently remedied this problem by reinstalling Onvifer though we do not understand how reinstalling Onvifer can affect this Google Play cache glitch.Please contact us if the above method does not work. Thank you very much for supporting the app.
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 Onvifer (V10.69 or above ). In Onvifer, 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 Onvifer as a default startup-app that starts with your device automatically. Your “Door-Cam” can also be selected as default-startup-cam when Onvifer 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 Onvifer.
In a nutshell, a deep link is used to show specific content of an app. For example, the Pro version of Onvifer 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 Onvifer 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.
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.).
Here is what one usually has to do when connecting to a camera directly:
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.
Yes or No. Yes, if you just want to monitor your cameras. No, if you want to configure your cameras or do sophisticated recordings.
No. The built-in applications are needed for camera configuration tasks such as wireless network settings, user management. They are usually one-time tasks. With IPCENT.COM, you do not need the built-in applications for daily monitoring.
Yes, if you want to monitor a camera outside the local network where the camera resides. No, if you only need to monitor the camera within your local network.
Yes, this is because IPCENT.COM delivers the monitoring software and log-in information to your browser, but video streams travel from IP cameras to your browser directly without getting out of the local network.
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:
Our story is a typical one - we started this service because we needed such service. We are IP camera users. We have used many IP cameras from various manufacturers over the years. Our typical use is quick checking of what is going on at our homes or business locations. We have our share of frustration in installing or being unable to install web browser add-ons required by cameras. We felt there has to be a better way to monitor our cameras, and developed a Silverlight app for our own use. Then we decided to share this with the IP camera user community, and the IPCENT.COM was born.