Looks awfully cool!
Looks awfully cool!
The answer is probably NO.
I guess we have all seen a somewhat “strange” requirement and wondered why the client had such a specific and odd requirement. In some cases the reason is that the client is legally obliged to place the project in an open bid. To ensure they get the system they’ve already decided they want, they might “tweak” the specs and thereby severely limiting the number of bidders.
You can try and provide a half-assed “solution” to meet the spec, and hope that the client will change their mind in the nick of time (how often does that happen?). But why chase these clients, and poison your platform with a bunch of poorly executed features? If you focus – REALLY focus, on the user experience and add meaningful thoughtful features then people will alter the spec to support your platform instead.
The trick is to understand when a spec is really a useful request, or if it is there just to fence you out of the bid. If people don’t want your product, it is not because you do not support the Apple Newton, but because the rest of your application is simply too shitty to compete. Instead of adding more shit to your already shitty app, you should consider improving and cleaning up the mess.
If your app stinks, it is difficult to instill a sense of pride in the product in the team. If there is no pride, there is no motivation, and with no motivation there is no productivity.
An amazing application with fever features will always beat a shitty app with a million features.
One day, they will be targeting COM objects distributed by NVR vendors or NVRs in general. All it takes is one weak spot and all hell can break loose.
Right now, they are targeting SCADA systems!!
It reminds me of our first web interface. We simply wrote a custom HTTP handler that did NOTHING but serve up images and video. No execution of scripts or arbitrary code on the server (no CGI, ASP, PHP or any such thing). Was it flawless? No, but when IIS had a UNC/unicode problem that allowed a visitor to delete random files on the server (which actually happened on our web-site), we just cruised through it.
Click the image to go to wordle!
There seem to be some buzz around hosted solutions these days. I still feel that hosted solutions are facing some pretty steep technical challenges, that most users may not be aware of until it is too late (make sure you have a 30 money-back-guarantee).
I expect that a hybrid solution would be optimal in most situations. By hybrid I suggest that the recording is done locally, or at least close to the cameras (in network topology), but that setup and investigation can be done via a remote host. The recording nodes health should be monitored by the host (notifying the client when recorders are not online or having trouble). The software on the nodes can also be updated from the host automatically and so on.
A solution could be to offer features on a subscription basis – as an example, you might buy the right to do motion detection on 4 cameras for 10 weeks for 10 bucks, or perhaps enable “left object” on 8 other cameras for a year for 100 bucks. Sort of an “app store” for video surveillance.
I suppose “clustered hosting” is another solution – a shopping mall may offer video surveillance as part of the lease.
Or – we can just wait for the bandwidth to become available and cheap enough that it is viable 🙂
OSX86 has been around for a while. It allows you to install OSX on a regular “PC” (Macs ARE regular PC’s, regardless of what Apple will lead you to believe). But what if you are not ready for that level of commitment?
Enter the wonderful world of virtualization: Lifehacker has a great guide right here.
Running Windows on a Mac has been trivial for a long time – even sanctioned by Apple themselves. Personally I have been running windows via Parallels on my MacBook for a while, but I now bootcamp into Windows 7 on a daily basis. I still think that Apple has the edge in terms of usability, but Windows is getting awfully close to nipping OSX in the butt.
The good thing about MJPEG is that the frames are independent. If the link between my camera and the NVR is capable of streaming 30 frames per second, but the link from NVR to client only is capable of 10 fps, then 2 out of every 3 frames will be dropped. I may have local clients that will do 20 fps, and a mobile client doing only 4 fps. The thing is – they all get the frame rate that their bandwidth will allow.
Now, consider MPEG4 –
The camera prepares a 30 FPS GOP and sends it to the NVR, the NVR will then try to relay the GOP to the client. But if the clients bandwidth is too low, then I will have to skip some data. I can either skip a whole GOP; causing latency (if we assume it takes 2 seconds to send a 1 second GOP, I will get the last frame with 1 second delay), AND I would skip one second of video every other second. I think it is safe to say that such a solution would not be acceptable to anyone.
So we can chose to “throw away” some P-frames (it should NEVER discard I-Frames!), but this leads to a new, but much smaller problem. Depending on the encoder, missing P-frames leads to different artifacts on the screen – these artifacts are frequently described as “ghosting”.
The artifacts are a symptom of a bottleneck in the system; but how do we handle these bottlenecks? I prefer a smooth playback, even if there are artifacts. It’s a personal preference, so I am not going to state that this is objectively the BEST solution. It is just the one I prefer. The other is to “freeze frame” until we receive a new I-Frame, and then continue from there. This leads to stuttering and jerky movements, but evidently a lot of people prefer that.
In the perfect system, the video would scale to match the bandwidth of the client. Hulu does this (Hulu is like a deluxe version of YouTube), but Hulu is not streaming real time. Hulu’s programming has been transcoded offline to 3 or 4 different levels of bandwidth, and Hulu can afford to buffer for 2 minutes before starting playback. That’s simply not a viable option for us.