wah888

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. Hey soundy, How are things? Just got back from a trip and thouught i'd get you an update a whats been happening in trying to solve this issue. 1. getting hold of someone at Exaq is hard work with no one answer their phones and not returning emails. I guess its an US comp and trying to get support in UK will be out of their range. 2. Just got hold of the lastest Samsung SDK kit with has an small inbuilt .avi encoder. I'm now trying to locate someone who can do some programming to extract the relevant code out and make it suitable for my application and plug into a more userfriendly GUI. Know anyone? 3. Looking at another piece of software called eyesoft: http://www.nvrpros.com/eyesoft.html that can link to Samsung cams as well as give out .avi output. Hopefully I will find something useful here. 4. Funnily enough we will be using FCP as well to do the editing as well as running a FCP lite version on a laptop which I can take to site. 5. Samsung has just updated their hardwrae range and they now offer a software and server option as well as the NVR. I think they will probably phase out the NVR eventually as I can see the benefits of both other that ease. Thats all to say right now so no happy story yet. Hows your stuff getting on? Cheers, Wah

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. Thanks for the lively debate guys although I'm not any further on development than I was last week. I'll be doing some more testing and digging around and hopefully will have some breakthrough results soon. I'll get an update then. Hey Soundy, it seems like you know a lot about video and windows stuff other than just the IP cams and networking. Do you spend a lot of time tinkering with kit?

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. I'm going to be doing some more testing but right now I'm back to where I started this thread with; How to get the CCTV footage off the NVR and in more manageable state...avi or mpeg; then I'm sure there are software that can put the SMPTE stamp on. Just got an email back from video insight, they dont support Samsung IP cams but could write a plugin depending on how many cams I was going to buy. Any more suggestions or are we probably closed on this one? I'll just have to think of new extraction methods.

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. I've been digging around and found out that the CCTV timestamp system is NTP which is unique to IP cams so not useable in FCP unless there's some special plugin around? I'm still not convinced that the SMTPE is critical in making this work and will need to test using 8 cams to gauge results. I'm still trying to reach Samsung in getting some info there and will post findings here later. I will crack it and its just a matter of time. Soundy can look forward to the Caramel Flappachinno..I'd probably expect one as well... Hell we can all have one....

It will not be staged scenes, completly unrehearsed and live; which adds complexity and definitely no use of clapperboard.

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. Had a look at the NVR again and it can time stamp the 8 cameras connected on the network with either the time on the NVR or with a general UMT time which can be sync across multiple nectworks. Not sure what this format is but at least its readable by the NVR. Assuming its not readable by FCP or other NLE softrware. Not so keen on the clapper board or physical clapper to denote a time period on the footage as I may need that part of the film. Likewise a visible timestamp is not desired as this will create additional time in taking this out at editting stage. I would imagine that I will be recording in short bursts of up to 1hr at a time from 3-5 camera streams so the file sizes are manageable. Currently the Samsung NVR makes shortish clips due to some settings and I need to figure this out. And then from these streams, take out the important/required sections across the 3-5 camera views for editting in FCP. And my headache is in being able to control and manage that process flow. Once its in FCP, the process is universal, my issue is the translation bit of getting there.

thanks for this info. I'll have a look but its looking very technical. I may need to seek further expertise here..

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. had a look on the Video Insight webpage but they dont mention supporting the Samsung IP camara range and you are right, I've tried to contact Samsung in getting some codecs or encoding software. I'll let you know if I get anything back.

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. Thanks for the detailed info. Following your last email, I goggled the SMPTE function and now know a lot more about this procedure. Also checked it out with some A/V guys and they replied that it really helps in editing work although I'm not totally sure that the footage from the CCTV cams need to be perfectly sync'ed with each other. I need to check if the timestamp from CCTV cams, either from the cams themselves or NVR get translated/encoded along the way so they are readable downstream. Do you know if the time stamp from the CCTV is normally done locally at the camera stage or the NVR? I guess there must be some form of communication between the cams through the network to sync to UTS or something and I'd guess it isnt a universal standard. I couldn't say right now if I would ever need to sync multiple sources of cam feed across different networks; but certainly to have at least the 8 cams in one network on the same time. You are right in saying that editting CCTV footage is not a common occurence in your world but I'm looking at a different application of the IP cams where post porduction processes are needed; hence the problems occuring here. My project involves the use of IP CCTV cameras to achieve a proof of concept so I am interested in the installation, process flow, and the end product. Using digi cams is not the way to go. Some more specs were listed in an earlier post but I'm hoping that i will crack this and produce a smooth solution that is easy to implement. There are plans to set up similar installations at 3-4 other sites, hence the use of robust, proven camera technology. The ability to monitor info in a simple format is needed as well; hence CCTV technology. Thanks for challenging my thinking. Speaking to guys like yourself really helps me to understand more of what I'm trying to achieve.

Yes, not only are there better tools, but a six pack of digicams is likely cheaper than some of the VMS applications that are being proposed. Best, Christopher Both danielsan2222 and cglaeser are right in what I am trying to achieve. The recorded footage from the CCTV cams will be put into final Cut and Premier for special effects and final burn. Digi Cams are v cheap and good for filming but I'm using CCTV cams over them because of : 1. Proven reliability over long term recording. 2. Networkable and recordable to a server to aid post processesing 3. Robustness in the environment 4. Megapixel technology up to 2meg. Digi cams may give better quality but I dont need that right now and certainly dont want to worry about the bandwith over the network. 5. Ability to switch on/off over network. 6. Possibility in future to control cams over dsl. 7. And at the end of the day to use CCTV cams in a new application. 8. Cost is not really a consideration right now as I need to prove that what I'm building is going to work and give me the results I need through the processing and hardware of CCTV cams; unless someone here can offer smilar results using networked digicams. I really appreciate the help/advice I'm getting here as it really challenges my thinking and assumptions of what is possible in the CCTV world. What may seem a simple process to me may turn out to be a really complicated, totally incorrect process. So thanks for those.

Well that is not really true. There is one standard and Exacq is fully compliant they problem is the camera manufactures not implementing the full standard I am assuming that is to get the cameras to market faster. This does not surprise me in any way, I have been in this business for over 10 years. Yes. My mistake. ONVIF is the standard and cam manufacturers should follow it; which is not always the case.

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.

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? You mentioned using editing software to make a timecode offset; why is this needed? Do you have any info about the networkable cameras around which could record to a central server as this makes sense to me. CCTV cams are also robust and designed for long term usage which is another requirement; hence the reasoning with trying to get CCCTV cams to work for this project. Having done some testing, the samsungs seem to produce an acceptable picture quality and able to cope with lighting conditions etc..

Sorry wireguys, could you explain what you mean by ONVIF and if its plug and play? cheers. http://www.onvif.org/ thanks for the information. I've had a look but have been informed that although onvif is supposed to be the standard, there are various flavours of it. samsung is not on their supported IP cams list.

Yes; you are right, I've told "cglaeser" to start his own thread.