Tag Archives: IP Video


Axis does not support RTMP as a transmission protocol in their firmware (correct me if I am wrong about this), this seems to be an omission as RTMP offers a pretty good way for the camera to initiate an outbound connection to an RTMP service somewhere outside the network. I believe this is how DropCam works (again, an assumption).

As most probably know (or should know), an Axis camera is basically a small Linux computer with a camera attached. Axis will let you download a development environment, which you can then use to compile applications for the camera. This is called ACAP.

Before compiling an RTMP library for ACAP, I decided to check if someone else had done this. Turns out CamStreamer had done so, and I decided to give it a whirl.

Setup is extremely simple, and the UI looks modern and clean. It has support for some of the most popular streaming services, but I needed the RTMP ingest server (Universal)  as I have my own RTMP servers in the cloud.


Setting this stuff up was trivial,


The system pretty much worked like a charm with a single exception. During configuration, there was an error message telling me that the camera could not reach an outside host on port 1935 (the RTMP port). The error message is helpful and accurate. But later, I lost my internet connection completely (a screw-up at my ISP, where they switched me back to DHCP) and I was unable to enter the RTMP configuration page on the camera entirely. I guess this is because the HTML/configuration is served from a host in the cloud. I did not dig into it, but it struck me as a bit odd.

The ACAP application is pretty expensive: $299 for a 1-camera license (at the time of writing). This is pretty steep as you can hook up a Raspberry-PI type device that will do the same for several cameras for less than half that.

I am not sure why RTMP support is not built into more cameras (again, correct me if I am wrong). The “push” model of RTMP is almost perfect for cloud-based solutions, so why this is not standard fare for IP cameras is beyond me.

While Flash Video uses RTMP, RTMP can be used w/o Flash being involved at all. E.g. if I publish a stream via RTMP to EvoStream, I can view the stream via RTSP instead (and what can you do with RTSP streams and your favorite VMS?). It’s true that the reliance on TCP for RTMP introduces a bit of latency, but in practice, this is hardly a problem (if you are going to use a cloud solution, latencies are going to be pretty high compared to a local one).

Tagged , , ,

Clickbaiting Copycat Caught

It’s pretty damn hard to make secure software. Years ago I commented on Shodan and worried that the IP video industry was next.

Run of the mill ignorance, carelessness, greed what have you, is so common that we scarcely care to click the link. Recently (or not) and old bug was discovered in Intel products that allowed remote control.

Now if you are commercial blogger (or “analyst” if you prefer), you’re not going to try to shed light on the issue. That just doesn’t trigger enough clicks and drama. It’s better to make some unsubstantiated claim that an “Intel backdoor is confirmed”.


I can guarantee that someone is now looking up the word “backdoor”, I’ll save you the trouble (it’s in the link above too)

A backdoor is a method, often secret, of bypassing normal authentication in a product, computer system, cryptosystem or algorithm etc. Backdoors are often used for securing unauthorized remote access to a computer, or obtaining access to plaintext in cryptographic systems.


So, yes, it is probably not a lie to use the word “backdoor”, but it sure is manipulative, something people with a certain mental defect excel at.

For l33t hackers, finding back-doors is sometimes a fun pastime. The purpose can be to cause extensive damage for lulz or filthy lucre, sometimes for companies, sometimes for governments. Usually, it’s a challenge to find vulnerabilities and defects that let’s you crawl into systems that should be locked down. But to the n00b, a backdoor might suggests that it was intentionally put there. After all, you don’t “accidentally” install a backdoor in your house.

Backdoors in code, however, come in various flavours,

  • Deliberate backdoor intended to give an unknown user remote access after the user has deployed the device/software, thereby granting the attacker access. These can be baked into the device, or installed later as a trojan.
  • Accidental backdoor caused by unexpected side-effects of the code. In the olden days, you could mess around IIS servers by using unicode strings in the URL.
  • Accidental backdoor caused by gross negligence/incompetence on the manufacturers side. Hardcoded credentials is an example of such foolishness.

Today you are not going to get away with #1 and #3 for very long. The hackers at blackhat are not like mortal programmers, they understand assembly code, and will locate a hardcoded password or a backdoor in a few days.

But it’s a gradual scale from #2 to #3. For example, HTTP used to have something called “basic authentication“. It used Base64 encoding to hide the credentials in flight, and plenty of cameras and VMSs would use it. 15 years ago, basic authentication would probably have been considered a #2 issue, but today it’s clearly a #3 (a certain unmentionable blog used it not long ago).

You can make up your own mind if CWE-287 is a #1, #2 or #3. It could, conceivably, be a #1. But it will be very difficult to prove, unless you have network captures showing malicious activity initiated by someone associated to the manufacturer (US tech companies and NSA for example).

Another company was notified of a vulnerability on March 5th 2017, on the 12th a security bulletin is released, and the hacker then states :

“I have been communicating with Hikvision since I notified them and they have actually been been quite responsive.”

Quite responsive indeed.

Eventually we will have software in IP cameras that is safe enough that you can expose it to the internet. But for now, I would be extremely careful about opening my CCTV system to the internet.

In Hikvisions case, I think one of the issues is that to reset the cameras password you need to send a specially crafted payload to the device. This causes a lot of issues for lots of users and it strikes me as a potential attack vector. And rest assured that this is not the only issue in the cameras.

As time passes hackers find ways into older cameras that have long been discontinued, but have been deployed and are still operational, they may get more sophisticated in their attacks and find more complex ways of breaching the software.

I guess this was not as exciting a post as you had expected. I’m sorry. You will have to go somewhere else for BREAKING NEWS about the evil Chinese shell companies set up only to spy on you.




Tagged , ,

Codecs and Client Applications

4K and H.265 is coming along nicely, but it is also part of the problems we as developers are facing these days. Users want low latency, fluid video, low bandwidth and high resolution, and they want these things on 3 types of platforms – traditional PC applications, apps for mobile devices and tablets, and a web interface. In this article, I’d like to provide some insights from a developer’s perspective.

Fluid or Low Latency

Fluid and low latency at the same time is highly problematic. To the HLS guys, 1 second is “low latency”, but to us, and the WebRTC hackers, we are looking for latencies in the sub 100 ms area. Video surveillance doesn’t always need super low latency – if a fixed camera has 2 seconds of latency, that is rarely a problem (in the real world). But as soon as any kind of interaction takes place (PTZ or 2-way audio) then you need low latency. Optical PTZ can “survive” low latency if you only support PTZ presets or simple movements, but tracking objects will be virtually impossible on a high-latency feed.

Why high latency?

A lot of the tech developed for video distribution is intended for recorded video, and not for low latency live video. The intent is to download a chunk of video, and while that plays, you download the next in the background, this happens over and over, but playing back does not commence until at least the entire first block has been read off the wire. The chunks are usually 5-10 seconds in duration, which is not a problem when you’re watching Bob’s Burgers on Netflix.

The lowest latency you can get is to simple draw the image when you receive it, but due to packetization and network latency, you’re not going to get the frames at a steady pace, which leads to stuttering which is NOT acceptable when Bob’s Burgers is being streamed.

How about WebRTC?

If you’ve ever used Google Hangouts,  then you’ve probably used WebRTC. It works great when you have a peer-to-peer connection with a good, low latency connection. The peer-to-peer part is important, because part of the design is that the recipient can tell the sender to adjust its quality on demand. This is rarely feasible on a traditional IP camera, but it could eventually be implemented. WebRTC is built into some web browsers, and it supports H.264 by default, but not H.265 (AFAIK) or any of the legacy formats.


Yes, and no. Transcoding comes at a rather steep price if you expect to use your system as if it ran w/o transcoding. The server has to decode every frame, and then re-encode it in the proper format. Some vendors transcodes to JPEG which makes it easier for the client to handle, but puts a tremendous amount of stress on the server. Not on the encoding side, but the decoding of all those streams is pretty costly.  To limit the impact on the transcoding server, you may have to alter the UI to reflect the limitation in server side resources.

Installed Applications

The trivial case is an installed application on a PC or a mobile device. Large install files are pretty annoying (and often unnecessary), but you can package all the application dependencies, and the developer can do pretty much anything they want. There’s usually a lot of disk-space available and fairly large amounts of RAM.

On a mobile device you struggle with OS fragmentation (in case of Android), but since you are writing an installed application, you are able to include all dependencies. The limitations are in computing power, storage, RAM and physical dimensions. The UI that works for a PC with a mouse is useless on a 5″ screen with a touch interface. The CPU/GPU’s are pretty powerful (for their size), but they are no-where near the processing power of a halfway decent PC. The UI has to take this into consideration as well.

“Pure” Web Clients

One issue that I have come across a few times, is that some people think the native app “uses a lot of resources”, while a web based client would somehow, magically, use fewer resources to do the same job. The native app uses 90.0% of the CPU resources to decode video, and it does so a LOT more efficient than a web client would ever be able to. So if you have a low end PC, the solution is not to demand a web client, but to lower the number of cameras on-screen.

Let me make it clear: any web client that relies on an ActiveX component to be downloaded and installed, might as well have been an installed application. ActiveX controls are compiled binaries that only run on the intended platform (IE, Windows, x86 or x64). They are usually implicitly (sometimes explicitly) left behind on the machine, and can be instantiated and used as an attack vector if you can trick a user to visit a malicious site (which is quite easy to accomplish).

The purpose of a web client is to allow someone to access the system from a random machine in the network, w/o having to install anything. An advantage is also that since there is no installer, there’s no need to constantly download and install upgrades every time you access your system. When you log in, you get the latest version of the “client”. Forget all about “better for low end” and “better performance”.


Java applets can be installed, but often setting up Java for a browser is a pain in the ass (security issues), and performance can be pretty bad.

Flash apps are problematic too, and suffer the same issues as Java applets. Flash has a decent H.264 decoder for .flv formatted streams, but no support for H.265 or legacy formats (unless you write them, from scratch.. and good luck with that 🙂 ) Furthermore, everyone with a web browser in their portfolio is trying to kill Flash due to it’s many problems.

NPAPI or other native plugin frameworks (NaCL, Pepper) did offer decent performance, but usually only worked on one or two browsers (Chrome or Firefox), and Chrome later removed support for NPAPI.

HTML5 offers the <video> tag, which can be used for “live” video. Just not low latency, and codec support is limited.

Javascript performance is now at a point (for the leading browsers) that you can write a full decoder for just about any format you can think of and get reasonable performance for 1 or 2 720p streams if you have a modern PC.


To get broad client side support (that truly works), you have to make compromises on the supported devices side. You cannot support every legacy codec and device and expect to get a decent client side experience on every platform.

As a general rule, I disregard arguments that “if it doesn’t work with X, then it is useless”. Too often, this argument gains traction, and to satisfy X, we sacrifice Y. I would rather support Y 100% if Y makes more sense. I’d rather serve 3 good dishes, than 10 bad ones. But in this industry, it seems that 6000 shitty dishes at an expensive “restaurant” is what people want. I don’t.



Tagged , , , ,

NVR Appliances Will Change The Landscape

In the good old days, if you were a VMS vendor, you’d offer 2 things : a little database engine, and a client to view video (live and recorded). In return, the camera guys would fret over sensor sizes and optics, but not worry about how video was stored and retrieved.

The core competency of the VMS guys was writing code that ran on a PC, while the camera guys would get their code to run on a small embedded platform.

What we are seeing now is that the lines are getting blurry. Milestone offers code that the camera guys can embed in their systems, and the camera guys now offer small databases embedded directly in the cameras, and obviously there’s a client to view the video too.

From an architectural point of view, the advances in camera hardware capabilities open up for a whole host of interesting configurations. In a sense, the cameras are participating in a giant BYOB party, only, instead of beer, the cameras bring processing power and storage. Prior, the host would have to buy more “beer” (storage and processing), as more “guests” (cameras) arrived. Now, if host has enough physical room (switches and power).

Cameras now have a sufficiently high level of sophistication that they can act almost completely autonomously. While my private setup does require a regular server and storage – somewhere – the camera pretty much cares for itself. It does motion detection, and decides on its own when to store footage. When it does store something, it notifies me that it did, and I can check it out from anywhere in the world. The amount of processing needed on the PC is miniscule.

So how do NVR appliances fit in?

A few years ago, the difference between a regular PC and an “appliance” was that the appliance came with Windows XP Embedded. That was pretty much it. The Hardware and software was almost 100% identical to the traditional PC platform, but the cost was usually substantially higher (even though an XP Embedded license is actually cheaper).

Now, though, we are seeing storage manufacturers offer NAS boxes with little *nix kernels that can connect to IP cameras, and store video. There’s usually a pretty cumbersome and somewhat slow web interface to access the video, but no enterprise level management tool to determine who gets to see what, and when.

The advanced DIY user, can buy one of these boxes, hook up a bunch of cheap Dahua cameras, and sleep like a baby, not worrying about Windows Update wrecking havoc during the night. As a cheapskate, I can live without the plethora of features and configuration options that a traditional VMS offers. It’s OK that it is a little bit slow and cumbersome to extract video from the system, because I only very, very rarely need to do so. I am not going for the very cheap (and total crap) solutions that Home Depot and Best Buy offer. Basically, if it doesn’t work, it’s too expensive.

Further up the pyramid though, we have the medium businesses. Retail stores, factories, offices, places where you don’t DIY, but instead call a specialist. And this, I think, is where the NAS boxes might make a dent in the incumbent VMS vendors revenue stream.

The interests of a DIY’er and the specialist align, in the sense that both want a hassle free solution. The awesome specialist is perfectly capable of buying the parts and building and configuring a PC, but to be honest, tallying the cost and frustration if things don’t work as expected. I think I’d pick the slightly more expensive, but hassle-free solution. Even if it didn’t support as many different cameras as the hyper-flexible solution that I am used to. I do not see an advantage to being able to play Hearts on my video surveillance system.

The question is then. For how long, will the specialist also sell a traditional VMS to go along with the NAS? How long before the UI of the NAS becomes so good that you really don’t need/want a VMS to go along with it? Some of the folks I’ve spoken to, show the fancy VMS, but advises, and prods the customer in the direction of a less open solution. Any of their employees can install and maintain (replace) the appliance, but managing the VMS takes training, in some cases certification and generally takes longer to deploy.

We are not there yet, but will we get there? I think so.

Tagged , ,


I have to agree with the Luddites. Analog PTZ is far superior to IP MP Video. Especially if you need to really zoom in on tiny details, and you have a manned system…

…But that’s like judging a fish by it’s ability to climb trees (as Einstein supposedly said once).

Let’s flip it around, and ask how well an analog PTZ camera can look in two directions at once. Let’s ask if analog PTZ can do a tour at 90 degrees per second, 24-7-365 without breaking. Let’s try and do analog PTZ in Houston, from an office in New York on a shoestring. Let’s ask if we can change our minds and zoom in on a different area after the video was recorded.

Now, if an IP based optomechanical PTZ camera was given the same budget as the cost of wiring an analog one, then you would not be able to tell them apart at all. And I am guessing you don’t really need to spend the full budget to get equal performance – you can probably get good (perhaps not as good) performance a lot cheaper.

But what if you really wanted to replace a mechanical PTZ with a MP camera?

I guess a lot of installation were getting mechanical PTZ’s in the past because there was no other choice. Now there is. It’s fairly cheap to install 3 fixed cameras vs. 1 PTZ (simply because you don’t need to pull 3 cables all the way back to the recorder – you can pop in a POE switch and cluster the 3 cameras). If you then put in 3 decent cameras you are golden. You even get to see things from 3 vantage points – something PTZ will never do. Even if a vandal breaks one, you still have 2 others that are recording.

It is true that right now, the cost of 2 additional camera licenses are a burden, but I think that cost will come down dramatically over the next 24 months.

But a mechanical PTZ camera is really equivalent to a Gigapixel camera. If you do the maximum zoom level, and do a full pan-tilt of the area you get a huge resolution. If you were monitoring highways it would make sense to have an optical PTZ at the intersections which would allow you to zoom in much more than the MP would ever let you.

Another disadvantage to HD cameras are that they take up a lot of space and they require a lot of processing power to decode. This is mostly an issue for the client side developer (as we need to decode the frames to show them to you 😉 ), but an issue nonetheless. Some people will just compress the crap out of those feeds, but that totally negates the purpose. You might as well use a lower resolution camera then. Sometimes the framerate gets lowered to the point where you might as well be looking at a slideshow – but that might just be good enough for the user.

So I think Todd Rockoff is correct. HD and PTZ are complimentary.

Tagged , , , ,

Preallocation of Storage

What is the principal argument against pre-allocating (formatting) the storage for the video database?

One problem that I am aware of is if you need to pre-allocate space for each camera. A camera with very little motion might record for 100 days in a 100 GB allocation, while a busy one might have just 1 day. Change the parameters and it gets real hard to figure out what a reasonable size should be.

But say that you pre-format the total storage you need for the entire system, and then let all the cameras share the storage on a FIFO basis. This way, all cameras would have roughly the same amount of time recorded in the database.

My, decidedly unscientific tests, show that writing a large block of data to a continuous area on the disk is much faster than writing to a file that is scattered across the platters. Disk drives now have large caches and command queuing, but these mechanisms were designed for desktop use, and not a torrent of video data being written and deleted over and over again.

Some people balk at the idea that you pre-format the disk for reasons I simply do not understand. If you have a 100 TB storage system, I would expect that you’d want to use the full capacity of the disk. There are no points awarded for having 20% of the disk empty, so why do people feel that pre-allocation is bad?

Any takers?

Tagged , , , ,

NVR Integration and PSIM

Axis makes cameras, and now they make access control systems and an NVR too. Should the traditional NVR vendors be concerned about it?

Clearly, the Axis NVR team is better positioned to fully exploit all the features of the cameras. Furthermore, the Axis only NVR does not have to spend (waste?) time, trying to fit all sorts of shapes into a round hole. They ONLY have to deal with their own hardware platforms. This is similar to Apple’s OS X that runs so smoothly because the number of hardware permutations are fairly limited.

What if Sony did the same? Come to think of it, Sony already has an NVR. But, it’s no stretch of the imagination to realize that a Sony NVR would support Sony cameras better than the “our NVR does everything”-type.

In fact, when you really look at the problem, an NVR is a proprietary database, and some protocol conversion. To move a PTZ camera, you need to issue various different commands depending on the camera, but the end result is always the same: the camera moves up. Writing a good database engine is really, really hard, but once you have a good one, it is hard to improve. The client and administration tools continue to evolve, and become increasingly complex.

Once it becomes trivial to do the conversion, then any bedroom developer will be able to create a small NVR. Probably very limited functionality, but very cheap.

The cheap NVR might have a simple interface, but what if you could get an advanced interface on top of that cheap NVR? What if you could mix cheap NVRs with NVRs provided by the camera manufacturers, and then throw in access control to the mix? You get the picture.

If you are an NVR vendor, it is going to be an uphill battle to support “foreign” NVRs. If Milestone decided to support Genetec, it would take 5 minutes for Genetec to break that compatibility and have Milestone scramble to update their driver. Furthermore, the end user would have to pay for two licenses, and the experience would probably be terrible.

The next time an NVR vendor says “we are an open architecture”, then take a look at their docs. If the docs do not describe interoperability with a foreign client, then they are not open. An ActiveX control does NOT equate “open”. Genetec could easily support the Milestone recorders too, but it would be cheaper and easier for Genetec to simply replace existing Milestone recorders for free (like a cuckoo chick).

In this market, you cannot get a monopoly and charge a premium. The “need to have” threshold is pretty low, and if you charge too much, someone will make a new, sufficient system and underbid you. Ultimately, NVRs might come bundled with the camera for free.

So, what about PSIM? Well, we started with DVR (which is really a good enough description of what it is), but then we decided to call it an NVR to distance ourselves from the – clearly inferior DVR. Then we weren’t satisfied with that, so then it became VMS. Sure, we added some bells and whistles along the way (we had mapping and videowall in NetSwitcher eons ago), so now we call it PSIM. It does the same as the old DVR. I think this kind of thing is called “marketing”.

Tagged , , , ,

Motion Detection on the Edge

When we design a surveillance system, we need to carefully consider how we allocate resources and distribute workloads. When you add a camera to an NVR, the most common use is to reduce the camera to a fairly dumb “video transmitter” and then let the server do the heavy lifting.

But even if the server is much, much more powerful than your humble IP camera, it is usually taxed with a lot of work. One of the tasks the server routinely carries out is to do what some folks call “motion detection”. The term is usually misleading as the NVR is not really detecting motion at all. It is detecting “changes in the frame”, which could be noise, light, and transition from color to B/W etc. not related to what we understand as “motion” at all. Analytics engines look at differences too, but they are truly looking for “motion” and not JUST changes.

Looking for changes is usually “good enough”, and does not need to be any more than that. And if looking for “change” is what you need, then you really should let your camera do the work and free up the NVR to do more important things.

The reason we initially decided to analyze the frames for changes was really motivated by storage problems. A common HDD in those days was 200-300 MB, the 640×480 frames were considered “high resolution” and the format was always MJPEG. Naturally, the Axis 200+ could not deliver these crisp HD feeds at anywhere near 30 FPS. 3-5 FPS was usually all you could get. But storing this massive amount of data became a problem, so we decided to discard frames that were almost identical.

Naturally, as time passed we got higher resolutions and higher framerates, we were suddenly able to do MPEG4 encoding on a consumer device – in real time!!! MPEG4 and H.264 actually looks at two successive frames in much the same way we do on the NVR. The codec simply “throws away” the redundant information just as we do. Except the codec is throwing away just the parts of the frame that is similar to the previous one, while preserving only the changes – a much, much better way of doing things.

For the codec to figure out what to throw away, it must look at two successive frames. If they are very similar, it can throw away a lot, if they are very different it needs to send almost all the pixels. On top of that H.264 does a lot of other things before the video is sent across the network. These involve among other things – discrete cosine transformation, quantization and Huffman encoding.

It does not seem like a far stretch that the codec implementation could provide a number that tells the camera how much 2 frames are alike. And in a primitive way it actually does – if the frame is large in terms of bytes, then we can deduce that the frames are very different, if the frames are small, then they are very similar. Naturally this is too crude and would not work on CBR feeds, and there is no windowing etc.

Nor does it seem totally unreasonable that the codec implementation could give the “difference parameter” for each macroblock (a small 8×8 pixel block). It is important to understand that the codec already is doing the computation, we are just asking to get to peek at the result. Furthermore, the codec is also working on the crisp uncompressed frames that have the highest level of fidelity, and no information has been thrown away.

In naive implementations like the one I describe here, there is not a lot to be gained from working on the raw frames in the camera, but ask any analytics vendor if they would prefer to work on the video BEFORE or AFTER compression and the answer will uniformly be the same : BEFORE compression. So while the benefit is not huge, it is not completely without merit.

To do the detection on the NVR, the NVR will have to completely reverse the process: Take the Huffman symbols, and expand them into imaginary coefficients, go from frequency to the spatial domain, and only then can you start to think about examining the frames. You can then make all sorts of tricks – perhaps you only look at every N pixel, perhaps you don’t look at every frame, perhaps you get a lot of noise from too heavy compression, perhaps you don’t. Every single trick lowers the “quality” of the detection. Perhaps the client doesn’t care, even with severe degradation of the quality, and that’s fine by me. I am focused on improving and providing better, more efficient solutions and offering them to the ones who appreciate such things.

The point is this – spending a lot of resources decoding a H.264 stream, to get information that could have been gathered almost for free in the camera, is not my idea of efficient allocation of the resources. It is like rejecting a free apple, only to ride 30 miles to the store to buy the same, exact apple, only now it is slightly bruised from transporting it to the store – AND it takes a lot of effort to unwrap the apple.

In time, an NVR will not need to do much, in fact, I expect an NVR to be very similar to a NAS. Cheap, easy to replace, and very scalable. This will require that the cameras become a little more advanced, but my experience tells me that progress doesn’t just stop. We were amazed by 640 x 480 at 4 fps when I started, and just as we laugh at that today, we will laugh at NVR side change detection 10 years from now.

I suspect that a lot of cameras do not have the fine grained control over the encoding process that is needed here. I assume that they are picking off-the-shelf H.264 encoders or reference designs offered by the chip manufacturers. For such cameras, there might not be a simple way to do on-board processing, and doing so may jeopardize the performance of the camera – for those, you will have to spring for the expensive PC’s.

Start preparing for the change 🙂

Tagged , ,

Pros and Cons of Web Interfaces in Video Surveillance Applications

Wow – longest headline ever.

A very common request is a web-based interface to the video surveillance system. An often used argument is that the end user won’t have to install anything, and that the system is readily available from a variety of platforms, after all – google.com works on macs, PCs, my 5 year old cell phone and my wife’s spanking new iPhone*

Most people are probably familiar with ActiveX controls that are needed when streaming various video formats from a camera to a web browser. While you may not think that you are “installing” anything (since the ActiveX or plugin does not necessarily appear in the Add/Remove programs window), you actually DID. A piece of executable code was downloaded and written to your hard drive, not unlike downloading and running a regular installer. ActiveX controls may require numerous supports DLL’s, which will be downloaded on demand. So even if the installation method is a little different for ActiveX, you are technically installing something on the machine.

The ActiveX controls are platform dependent (you can’t use a windows control on a mac), and they present a security risk unless managed carefully, but then there are Java Applets. These are sort of platform independent,  but can be (always are) a little slower than ActiveX. Adobe Flash is another option, but it won’t work on my wife’s iPhone, the same goes for Silverlight.

Although the second part of the argument is technically true, there are some costs to bear; although getting text and static images on the screen using baseline HTML is trivial, interactivity and streaming video is a different beast altogether. A commonly used technique is AJAX, which pretty much boils down to issuing requests asynchronously to a server using a XML object, but the XML object differs from browser to browser, so you need to write two different pieces of code to accomplish the same feat — on the same OS! Granted, the handing of the different browsers is well documented, and libraries exist that helps the developer overcome these annoyances, but for all intents and purposes, we have just doubled the number of platforms (IE and “everybody else”). The same applies to CSS, and even PNG handling.

Some companies will happily put together a “web solution”. But if you are still pretty much locked into Windows, IE, and you STILL need to install a bunch of ActiveX controls, what’s the point? Often the web solution is a little less useful than the traditional Windows application since the developers are limited to the browsers capabilities, whereas the old-skool application can pull all the levers in the system.

Recently Adobe added GPU accelerated video playback to Flash, and HTML5 is supposed to support H.264. Javascript is now very fast on a wide range of browsers (IE 9 was shown at MIX10 and looks promising, Chrome has always had fast JS). So perhaps a viable solution for desktop PC’s and macs will be available before too long.

*actually she has a Nokia phone, but I needed to add the iPhone in there somehow.

Tagged , , ,