Month: October 2010

Axis’ Corridor Layout

Axis presented their corridor idea recently. I like it. But you don’t need a special camera as you can simply mount any camera on a 90 degree angle, and then have the client rotate the video when displaying it.

As we have a pretty powerful video rendering engine I thought I would give it a whirl.

This is just a concept demo, but it shows the principle I think. Around 30 seconds into the video I start changing the feed in the rotated pane. The pane really does not care where the feed comes from, it will rotate it 90 (while keeping the correct aspect).

The issues here is that the layout needs to restrict the selection of cameras sent to a rotated viewport to only cameras that are marked as “corridor”, but as I said – this is just a conceptual demo.

Update:

Rotating video is “free” in terms of CPU cycles if a) you have a GPU and b) the code utilizes the GPU. Some clients will use the GPU as a “dumb” framebuffer, in which case the CPU will taxed with the burden of rotating the video, instead of letting the GPU do it (for free). Such a design  is like having a 5.7L Hemi V8 in the front, while driving around in 1st gear all the time. The GPU can perform other functions too – color space conversion for example.

Mindless Consistency Is The Hobgoblin…

When you work with WPF for a while, you realize that a lot of people who decide to share their knowledge are probably dogmatists. The dogma seem to be that separation of presentation and data is paramount, any mixture of code and presentation is evil and must be avoided at all cost.

I might be wrong about this, but I think we are hinging a lot of the examples on the facade pattern. The idea that you create different facades depending on the presentation context. E.g. a geometric object – say a circle – does not know anything about the presentation. To present a circle to a user, a facade is created. If the context is a web-page, the facade might create a PNG and return it to the user, in a regular app, we might just use GDI to draw a circle on the screen.

This frees the Circle-developer from knowing anything about HTML and mime-types, or GDI, or if a new technology comes along we just create a new facade. But the flipside is that the interface between the circle and the facades need to be fairly static. The circle dev might decide to add color to the circle, but now the facade developers in the other end of the world need to update all their circle presenting facades… ugh..

I like to have object “render themselves”. I think this is a little more object oriented. If I decide to add color to my circle object, then I will need to fix “drawToBitmap” and “drawToScreen” in my class (or inherited classes). But it seems logical to me that when I change the object, I will frequently know if the change also affects the presentation, and subsequently require editing of the presentation FUNCTIONS (rather than classes).

One example I came across was to show and hide an element based on whether the mouse was over ANOTHER element. Fairly simple to implement in code (a.onMouseOver = show b), but in “pure” XAML it becomes a hellish brew of ancestral selectors and relative bindings. In Javascript this would be an absolute piece of cake, and we’re mixing “code” with “presentation” like there was no tomorrow. WPF does not prevent you from doing this (at all, and that’s the route I take), but naturally I have to be aware if the code I am writing is “logic code” or “presentation code”.

If XAML is a hammer, some XAML tutors are seeing nails all over the place.

Web Rings

Remember those? I once dabbled in Console Emulation. The way to get ROMs and emulators was not Google, no sire; The Google was not invented back when granddaddy was young. Instead we relied on web-rings. Nowadays its all SEO “magicians” trying to trick the search engines into putting whichever site on top (must be like selling toilet paper).

I stumbled across a web-ring when I revisited a pinball emulator, and I needed to pust a blurb.

Is SSD Viable Today?

The biggest problem with HDD based video is storage. You can’t compare it to the life time of you workstation although it seems to be “always hitting the disk”; although the platters are spinning 9 hours a day they usually are sleeping the rest of the time (or should be). If you want to record the video for later playback, you will need to hit the disk eventually, and this goes on 24/7. There’s no way to cache this stuff since the data is usually written once, and never read again. Caching mechanisms usually work great if you read the same data over and over again, but this is mostly fire and forget, so no amount of caching will save you here. As I’ve discussed before, I don’t believe that you can rely on “no recording, no incident” as proof of anything. You might want to record the “no motion” video at a low, low quality, but you probably should record (if possible).

Mechanical drives burn out as the heat in their small cupboard enclosure rises to the level where you can bake a loaf of bread in there. Fans are of no use if fresh, cold, air cannot be drawn in. Instead they will just spin faster and faster in a futile attempt to lower the temperature as they merely recycle the increasingly warmer air inside the box. In a way, hard drives then become modern day video tapes. They work for some amount of time, and then they got to be replaced.

Naturally, a large scale client will have a dedicated server room with sufficient air conditioning, but it all adds up to the cost of running the system. Offsite storage is one way of mitigating the cost of an expensive server room, but now you need to pay for the DSL line instead, and one way or the other you will pay for that server room (or a part of it at least).

So, will SSD save the day?

Not sure it will happen just now. I read that new drives can write about 30TB before they start showing problems, and someone even made a wiki about the topic of SSD durability.

But I can’t wait to get one (the older ones where just not viable for my kind of work).