Soundy

It shouldn't be hard to find something that will do at least SOME of the conversion... although it likely won't be free. Might not even be cheap. Recording to a more common format to begin with is probably the best place to start. Not lately, but I have before. My only real formal training after high school is actually in audio engineering (this was the late 80s, before digital audio and video recording were commonplace). I've worked professionally in IT since the early 90s, and ended up back doing IT support in the late 90s until the early 2000s at the same school where I originally did my audio training. My only formal training in IT was a one-week Warp Server intensive from IBM, but I got an incredible amount of knowledge out of that. A lot of our work in the school involved building NLE workstations (Premiere and FCP in addition to high-end stuff like Avid, Matrox, Grass Valley, and some wicked Sun Indigo and O2 systems) as well standard tape-based systems. Later on we added a live-editing suite (can't remember the system that we used - basically a fully computer-based live switching/titling/effects system). And then there were three or four labs with 3D modeling/animation systems like 3DS Max, XSI, and others... all of which generated output that needed to be imported, synced and composited with recorded live video. Other students would take the video and add recorded and MIDI-sequenced music to it in Logic, Cubase, and of course, ProTools. Not to belabor a point, but all of these systems used SMPTE timecoade to effect near-universal sync of audio and video across platforms. I didn't actually do a lot of USING the systems, but I did have to test and configure them all, so I got some pretty wide-ranging exposure to all of it.

Don't ever apply for a job with Bahamas Tourism.

I don't find it surprising at all - there are probably few people working there who were around when it was installed 20 years previous, and even fewer who WOULD know anything about it, let alone such technical details. You wouldn't keep a repair/service tech on staff for such a thing; SOP would be to call in for service when needed. Even the "machine administrator" is probably third or fourth generation to the position, if not even further removed from its installation... IF there's still documentation around, some is probably lost, damaged or destroyed, and would either contain very little real technical data beyond operational instructions and basic troubleshooting... or would be a 4" thick binder (or two) filled with overwhelming technical gibberish. As the OP says, too, the system exists in "several cabinets"... each one would likely have its own separate technical manual; getting any useful information would mean first determining which cabinet is the relevant one, then finding the right manual for that. No, I've never dealt with X-Ray machines before... but I've dealt with these TYPES of massive, spread-out, highly-proprietary specialized systems before. The people making them gave little thought to anyone on-site being capable of servicing them; it was expected that issues would be dealt with by a factory technician. To the OP: it also wouldn't surprise me if the thing uses some modified version of NTSC or PAL standard (depending on where you're located) to obtain higher resolution from its custom monitor (although at the very least, it obviously is BASED on one of the two standards, since it does display on your TV and GV input)... for something that specialized, and in the absence of mass-market HDTV or other hi-res transmission standards, it wouldn't be at all unusual for the manufacturer to use something (semi-)proprietary. It's also possible the monitor itself is providing some internal processing. Is there a model number on the monitor? What are the results if you feed a regular video signal (say, from a DVD payer) into the monitor? The easiest way to make it remote-viewable, other than using your GV system, would be to add a video-server box. Something like this: http://cam2life.net/products-VS306.html Or these: http://www.axis.com/products/video/video_server/index.htm Or these: http://www.vivotek.com/products/video_servers.php

Well said!

There some reason this really needs to go INSIDE the cage? You'd need something super-wide-angle to see the whole interior, and you'll have a hard time getting that without fisheye distortion, unless you're willing to spend a few hundred JUST for the lens. Why not just a camera to watch the cage from the outside? Your Axis should work fine... I can't find any specs on it offhand, but I'm guessing it should work with any common 12VDC power supply... if not, it does support PoE, so you could either add a PoE switch to your network, or pick up a simple PoE injector.

Since Alex gave you a good laugh... it's only fair that you gave me one with this.

^Agreed... plus, unless you have a time-lapse VCR, you're not going to get more than 8 hours to a tape - that's the max for a consumer VCR at SLP with a T160 tape. A time-lapse VCR, if you can find one, will give you 12, 24, 96, I've even seen them up to 960 hours to tape (at very poor quality).

A PC VGA monitor uses a 15-pin connector, not 9-pin (unless you're using a very VERY old CGA monitor). That port is for alarm in and/or out connections - some multiplexers (according to the label, this is a multiplexer, not a quad) can output a signal, for example, when motion is detected on a camera, that can switch the VCR to a higher record speed for higher quality.. or may accept an alarm input, like from a motion sensor, that causes the display to switch to an associated camera. You'll need to connect the VCR OUT jack on the MUX to the VIDEO IN jack on your VCR... *AND* connect the VCR's VIDEO OUT to the VCR IN jack on the MUX. The video recorded on the VCR will likely not be viewable without going through the multiplexer.

http://www.maxmax.com/aXNiteFilters.htm

As for microphones, most analog cameras DO NOT have them built in, unless you're talking the uber-cheapo cameras that come with uber-cheapo package systems. A few IP cameras have them, but most don't.

It's WAY too good for the price. Megapixel IR lens? Really? 60m throw out of 18-20 LEDs (as shown in the picture - I still have the link open in another tab)? Looking at it again this morning, this DEFINITELY seems to fall into the "too good to be true" category - it's almost like they just copied various top-end specs into their copy.

I dunno... the specs on that camera LOOK good... but at <$90, in an industry where "you get what you pay for" really does apply most of the time... that seems like it falls more into the "if it sounds too good to be true it probably is" category. But, if it serves the purpose of a deterrent...

Hey Soundy, what's your favorite selection at Starbucks? I have a Starbucks gift card with your name on it. When wah888 posts a clip showing that he successfully pulled clips from a Samsung 32 channel NVR, injected SMTPE, and converted the the clips with SMTPE to a format suitable for input to FCP and then synchronized the clips on the timeline using SMTPE, I'll put the Starbucks gift card in the mail addressed to you. A cup of joe never tasted so good! Best, Christopher Don't mock cglaeser, this is a serious project and discussion. Hahahah, I've know Chris for some time from this and other forums - he's not mocking! Network Time Protocol is not unique to IP cameras - it's the same thing Windows uses to sync to internet time servers, and what client machines on a LAN use to sync to a domain server. http://en.wikipedia.org/wiki/Network_Time_Protocol The actual method a camera or NVR uses to embed a timestamp in its video files will probably be manufacturer-unique. It's not CRITICAL... the whole idea will work without it. I just think it will make the whole process SUBSTANTIALLY easier, especially if you're cutting back and forth between cameras, since it's what almost all NLEs use to keep multiple clips in sync.

I just answered an ad on the provincial government job bank. That's probably something of an anomaly, though, as more specialized businesses like this tend to not use those kinds of channels. You could try using a "professional networking" site like LinkedIn; there are options to post your resume as part of your profile, and there are employment-specific groups for most industries there. Doesn't hurt to spam your resume around on employment sites like monster.com, workopolis.com, or whatever else services your area, either - most are free for job seekers, so there's nothing to lose. You could also try contacting local CCTV companies directly. Look them up online or get their names/numbers from the stickers on store windows (you know, the "video surveillance by company name" types). Ask them whether they work with IP cameras, or if they plan to - your network training and experience could be particularly useful to them. I came from several years working professionally in IT, and even longer dabbling in computers, when I started in CCTV, and it really gave our company an edge on several of our competitors when we started getting into IP cameras and network-distributed systems. Some CCTV companies also deal with things like access controls, videoconferencing systems, alarms, and so on... more and more of these are also starting to use IP connectivity so your knowledge could be valuable there as well. Don't be afraid to approach companies that specialize in these other areas and only do a little CCTV, either - you may be just what they need to expand their CCTV business.

You're allowed to link to a manufacturer's page for the camera, or to an online review. You're not allowed to link to an online store.

We had a couple of those kicking around once... figured it SHOULD be possible to adapt it for standard power, but none of us could ever figure it out. (Okay, granted, I only just glanced at it, but the boss has a degree in electronics and he couldn't suss it...)

And there you have the beauty of having SMPTE timecode on your video: even if each stream doesn't exactly match the other, timewise, you can specify the offset for each one, and your NLE should be able to track that, so when you load that file, it will apply the proper offset relative to your master timeline, and everything should sync up, even if you're just pulling a little snippet of it out. Sounds like you ideally need something that can convert the proprietary video and then add the SMPTE timecode to the output files... again, the individual files don't have to have matching timecode; that's what the offset is for. SMPTE time code is generally self-referencing: it's not locked to a clock or anything, you set a start time on a tape, recording, or project, and the code on the video is advanced linearly from there, so that stream will always have a consistent timeline.

The most self-contained you can get is a camera with built-in recording. Look up The MemoCam products from www.vdomain.com, or look into megapixel cameras with built-in SD slots from makers like IQEye, Mobotix, Hikvision, and others. You would still need to get power to it, usually over a thin pair of wire from a wall-wart adapter, but otherwise, it doesn't get much more self-contained. At the very least, you'd need an access point device on each floor, hard wired to a network (I assume internet) connection. A building like that would be certain to have steel-in-concrete floors, and there's no way you'd get a usable signal from one floor to the next.

The card drivers have no relation to the motherboard - they're strictly little bits of software to let the operating system communicate with the specific hardware. You'd probably want to use a motherboard that at least uses the same chipset as the old one (Intel, SIS, VIA, whatever) for best compatibility, but in theory, you should be able to just drop another board in there and have it work. On the second card, see if there's an "FCC ID" number, either on a label or silkscreened to the board. If so, you can look that up at www.fcc.gov and at least find the manufacturer.

If you have your cameras recording constantly to an NVR, as the OP appears to be doing, you'd still have to FIND those sound marks in potentially very long clips... and differentiate one from another. Doesn't sound like he's starting and stopping the recording like you would be with a standard camera.

That's generally selectable. Most cameras can embed a visible timestamp on the image; most I've seen display to the second, some to the 10th or 100th of a second. This is just a visible timestamp though, not usually machine-readable (meaning your editing software can't read it). NVRs and DVRs will usually embed a machine-readable timestamp in the file itself, which on playback is read and displayed by the player software, but that too will usually be something specific to that manufacturer, and while the editing software might be able to read it (if you told it how), it wouldn't understand it. SMPTE code, you see, relies on video standards with set framerates, particularly on the video being 30fps (or more specifically, 30fps drop-frame for color video) and film being 24fps. It doesn't make accommodations for user-adjustable framerates, which is what IP cameras and NVRs give you. Most IP cameras have the ability to sync to an internet time source... the problem is still that your editing software can't use that timestamp. What you're doing should WORK... editing will just be a pain because you'll have to manually synchronize multiple video sources. Think of it this way: say you have three cameras, one watching a hallway, the other two each watching a door at either end of a hallway. For your "movie" you want to have a subject (actor, say) enter one door on camera one, walk down the hall on camera two, and then exit on camera three... but camera two also sees both doors, and you want the three synchronized at least enough so you don't see huge jumps in the movement. Now to sync these scenes in editing, you first have to find the same point in time on all three clips. To do that, you either need to use the NVR's playback software so you can see the embedded timestamp, or you need to have a visible timestamp on the video that you can read yourself (which would then need to be removed from the final product). Otherwise, you'd have to line up the three clips on your FCP/Premiere timeline, zoom in to the segment you want, then try to match the frames on all three and attempt to align the clips. Either way, it's a lot of work that's normally automated using SMPTE timecode... simply because the editing software can read that directly. In initial testing you're probably editing and syncing two or three short clips, but now imagine doing this with clips that are an hour, eight hours, even 24 hours long... and you're doing it with right or more cameras. That's a LOT of work just lining things up. Over the course of the project, I suspect you'll find it's a lot more than you bargained for. I suppose the work-around would be a conversion process that adds SMPTE timecode to your footage... either that, or convince an NVR manufacturer to add it to their recordings.

Right. I dont necessarily need the Cams to record in .avi or mpeg but i need a method to simply be able to encode into a more universal standard so i can take into a post production editing software. FWIW, I believe Video Insight can record directly to AVI (MPEG-4) or WMV... or could in the analog versions 3.x, anyway... not sure how it handles it with IP cameras on newer versions. However, if the NVR manufacturer provides an actual installable codec along with their basic playback software, most editing packages (Premiere, Vegas, etc.) should be able to use the codec to import the NVR files directly.

I agree that the timecode should be synchronized and recording across all video feeds which makes editing simpler but as far as I understood, this was a base configuation of CCTV hardware; that the timing and synchronizing across all cams was in tune; or correct me. Is the SMPTE timecode a standard for filming industry or just for the CCTV world? SMPTE (stands for Society of Motion Picture and Television Engineers, pronounced "simp-tee") timecode is used in just about every area of film, video and audio and music production these days. Most audio recording and editing systems support it, as well as video systems. In A/V production, it almost universally allows for frame-accurate synchronization of multiple media streams from multiple sources. CCTV recorders can synchronize playback of their own streams internally, but what if you have streams from multiple sources? If the clocks of each source are off by even a little bit, you'll have problems. As an example: say you have two cameras watching the same event from different angles, and you want to perfectly sync the two for a transition. You record all these cameras to an NVR... if the NVR embeds its own timestamp on the files, you can then use that to synchronize playback and editing... however, if you have only the timestamp that the camera itself puts on the video, then you'll have issues if one of them is off by even a fraction of a second. I've never seen or heard of SMPTE timecode being implemented in CCTV, probably in large part because it would be of limited usefulness there. There's rarely call to synchronize playback THAT ACCURATELY of video from multiple sources - most times you'll be wanting sync playback of clips from the same machine, and will play them ON that same machine. Frame accuracy is not typically required for this. And editing itself is almost an antithesis to surveillance video: CCTV recordings need to be trusted as being unaltered, especially if they're to be used for legal proof, and any editing inherently destroys that trust. Which is not to say that you CAN'T or SHOULDN'T edit CCTV footage... only that support for highly accurate editing isn't generally a design consideration for camera, recorder, and software developers, so you won't have as easy a time with it. Offset is a common function in SMPTE editing. It's used if two sources don't match timecode exactly... say, for example, one camera starts recording an event at 00:00:00.00 (hours:minutes:seconds.frames), and another recording the same thing starts its count at 01:00:00.00. You would then tell the editing software to apply an offset of -1 hour to the second clip. A third camera might have then started its count at 00:41:20.00 - you would then simply tell the software to use a -00:41:20.00 offset on that file... so at any time, you could jump to a certain point in the first clip, and the software could instantly give you the same point in time on the other clips, and keep them synchronized. Without this function, you'd have to do the math yourself. Imagine having to do that for eight cameras and keep track of it all on through the length of the project. Before delving into that, I'm curious... others have suggested that the POINT of this project IS to use IP CCTV cameras for the recording... I would presume as some sort of proof-of-concept or something. If that's the case, then there's no sense pursuing the alternate-camera path, as the tools ARE the job. If the point is simply the end product, then it's worth exploring cameras and systems that are better suited to the process itself. If your main concern is the final content of the video, and not how you got there, then you're certainly using the wrong tools for the job.

Well, the errors point to a problem with the Java runtime, if not the applet itself... but the fact that it works with the DVR set to a .254 address is odd. Since that does work though, can you not just forward the necessary port(s) to that address and be done with it? Short of that, you could see if there's an update for your Java runtime, or simply uninstall and reinstall Java.

I asked one of our suppliers about getting in a Theia lens a while back... something in about a 2.0mm for 1/2" camera, I think... seems to me it was going to be about $650. Like I said, "you can AVOID the fisheye effect entirely with the right lens. Unfortunately that lens will probably cost more than the camera."