CCTV detective puzzle

[Seekingadvice 0]

I would really appreciate some technical information from the very knowledgeable people on this forum.

 

The issue concerns a brief clip of CCTV footage that was given to the police along with a complaint that it showed a person vandalising a car parked in the street.

 

The individual output the 15 second CCTV clip from an unknown system onto a USB drive. From a witness statement given by the investigating officer the file was playable on the police computers so presumably was not in a proprietary format. (I'd guess it was .mpeg or .avi)

 

The police technical department burnt the file to DVD. That DVD is the only version of the CCTV clip that I have been able to get following a court order for disclosure. The person who told the police that he had set up the CCTV camera and recorded it, now says that the clip was posted to him anonymously or given him by a person he won't name. There is no possibility of getting any co-operation or honest answer from this person. He will tell any lie no matter how improbable or self contradictory.

 

So this is a kind of detective puzzle. The CCTV footage was in a multiplex 4 channel format. Channel 1 shows an image. The other 3 channels are empty. There is a just discernible signal noise but no image.

 

My first question is how easy or common is it to output CCTV footage as a 4 channel view from a probably cheap consumer system. The models I have looked at seem to offer backup to USB of individual camera files based on archived files by date and camera.

 

Before my second question I need to explain a little more.

 

The copy of the footage burnt to DVD by the police is a PAL DVD because PAL is the TV standard here in the UK. The image file was thus encoded in the DVD as an mpeg-2 file @ 25fps. I extracted the file and exported it as a 25fps image sequence. The quad view incorporates a date and time stamp in the frame at lower right. The clock advances by one second every 25 frames. So it is reliably recorded at 25fps. But the inset image at channel 1 is a time-lapse image. The image advances to the next progressive frame erratically. The frame length at 25fps of each time-lapse image varies between 6 and 10 frames in length. There is no pattern to the erratic frame lengths, and the image does not respect the time code at all. That is the clock advances to the following second while the time lapse image has not yet changed. So you have two adjacent frames @ 25fps where the image is the same but the time code is different.

 

So my second question is if the file was downloaded (backed up) to the USB stick from a secondary device. Would that account for this. i.e. If the player software existed on one device that was viewing the CCTV image on a remote DVR hard drive connecting through the web or wireless, might that account for the corruption of the image file. Or can anyone suggest what else might be going on here.

 

With thanks in advance for any light that can be shed on this conundrum.

 

I've attached a frame from this CCTV clip.

[Seekingadvice 0]

If I've posted this query in the wrong section of the forum, I apologise. I wonder too if I've put my questions with too much detail, so I'll post some more concise queries.

 

Does anyone recognise the style of the image view? Any guess at the brand name of the equipment used?

 

What equipment would have been on the market in 2008 that would output a file like this to a USB flash drive?

 

In 2008 were consumer CCTV units linking up to the internet and smart phones like they now seem to?

 

Any thoughts or pointers in the right direction would be appreciated.

 

Thanks

[GrouchoBoucho 0]

I would really appreciate some technical information from the very knowledgeable people on this forum.

most of them appear to be in hiding... i love a good detective story!

 

My first question is how easy or common is it to output CCTV footage as a 4 channel view from a probably cheap consumer system. The models I have looked at seem to offer backup to USB of individual camera files based on archived files by date and camera.

that's extremely uncommon, in my experience - frankly, i can't recall ever seeing a system that exported video that way. it's possible it may have been recorded during playback by a screen recorder program, or by feeding the dvr's monitor output to another capture device (come to think of it, this seems more likely).

 

either way, i suspect it's not a direct export from the dvr.

 

The copy of the footage burnt to DVD by the police is a PAL DVD because PAL is the TV standard here in the UK. The image file was thus encoded in the DVD as an mpeg-2 file @ 25fps. I extracted the file and exported it as a 25fps image sequence. The quad view incorporates a date and time stamp in the frame at lower right. The clock advances by one second every 25 frames. So it is reliably recorded at 25fps. But the inset image at channel 1 is a time-lapse image. The image advances to the next progressive frame erratically. The frame length at 25fps of each time-lapse image varies between 6 and 10 frames in length. There is no pattern to the erratic frame lengths, and the image does not respect the time code at all. That is the clock advances to the following second while the time lapse image has not yet changed. So you have two adjacent frames @ 25fps where the image is the same but the time code is different.

 

So my second question is if the file was downloaded (backed up) to the USB stick from a secondary device. Would that account for this. i.e. If the player software existed on one device that was viewing the CCTV image on a remote DVR hard drive connecting through the web or wireless, might that account for the corruption of the image file.

that sounds quite plausible as well. a client app with a poor network connection could certainly account for it - the timestamp might be generated by the client along with the quad view, while it's receiving a 'stuttering' stream from the dvr. it's also possible that if the monitor output of the dvr was being recorded by another capture device, and that device was on too slow a system, that that system wasn't able to record it smoothly... although that would likely show as 'skips' in the timestamp at some point or another.

 

again, it doesn't sound like this is an original export from the dvr itself. unfortunately it also leaves no way to authenticate either the time of the event, or the veracity of the footage itself... meaning it's highly unlikely this clip would stand up as evidence in court. don't know whether that helps or hurts you (sounds like probably the latter), but there it is.

 

Does anyone recognise the style of the image view? Any guess at the brand name of the equipment used?

i wouldn't even begin to hazard a guess. it looks like a generic multiplexed display - it could be from almost any dvr's monitor output, it could conceivably even be from a vcr playing back through a quad or multiplexer - there's frankly nothing there to prove otherwise.

 

What equipment would have been on the market in 2008 that would output a file like this to a USB flash drive?

anything computer-based. iirc usb export would have been rare on standalone units then, as usb storage was still pretty expensive. cd-r export would have been more common, not even dvd-r (still pretty expensive).

 

if the original scene was recorded on a standalone (or even vcr) it could have been captured via the monitor output, into a pc capture device (tv tuner card, perhaps?) - that would definitely be more likely to produce a 'generic' computer-playable file format.

 

In 2008 were consumer CCTV units linking up to the internet and smart phones like they now seem to?

internet, yes, usually with remote client software... smartphone, no, considering 2008 was when the iphone 3g was first released and this was still pretty new stuff (and data plans were a lot more expensive).

 

put it all together, i'd bet dollars to donuts what you've got is a basic recording device (standalone dvr or even vcr), feeding the quad output through the monitor jack, into a pc capture device (most likely tv tuner card) on an under-powered pc, and that recording finally

exported to usb for the police.

[Kawboy12R 0]

I'm not a cctv expert by any means, and I'm not sure why copying the file from thumbdrive to disk would change the file and somehow break it so that only one channel is now visible when there used to be more, but I do know that the good folks at YouTube are experts at converting just about any video filetype imaginable. Upload it there with all of the privacy settings turned on so it isn't publicly viewable and see what happens. If it works there are a ton of programs to dload YouTube videos to your HD.

 

I've suggested this before to people that had cctv files compressed with unknown proprietary codecs and had it turn out well for them. It MIGHT work out for multiplexed files as well, because if I understand your problem correctly then the video isn't merely a single-screen recording of a multiplexed video stream, it's actually a digital file with 4 streams encoded with only one stream now visible with the software you have available, right? Either the file got slightly damaged somehow or something else changed to make it not work fully.

 

If YouTube won't crack it, there are tons of people on here with lots of knowledge but some of them might speak up a bit more clearly if money were involved. You might want to add a cash incentive to see if someone on here is knowledgeable enough tell you or might be able to dive into the file and possibly extract the other streams separately if it's not possible to figure out what software did the multiplexing just from looking at a screenshot.

 

Even looking at a copy of a digital file with a hex editor can uncover interesting ASCII text strings that might give clues to the original file type or company that produced it. I used to fiddle with that stuff quite a bit although I don't know much about raw video file formats.

[GrouchoBoucho 0]

^it's none of the above. the attached image is a still frame from the dvd - it's a quad-view screen showing only one camera. all the op has is the dvd.

[hardwired 0]

Give the erratic frame rate of the image, but not the video itself, I would guess that this was the output from a tape based, multiplexed analog system, then recorded to digital format from that monitor output via a USB or similar video capture device.

 

The big unanswered question is why the person recording the video did not select a single image for display before recording it, this would have significantly increased the resolution of the captured event (and, apparently, you have to decide whether that would help or harm the case).

[GrouchoBoucho 0]

Give the erratic frame rate of the image, but not the video itself, I would guess that this was the output from a tape based, multiplexed analog system, then recorded to digital format from that monitor output via a USB or similar video capture device.

pretty much what I figured. a clip of the video itself might help determine the cause of the 'stuttering' issue - time-lapse tape playback has a pretty unique look.

 

The big unanswered question is why the person recording the video did not select a single image for display before recording it, this would have significantly increased the resolution of the captured event (and, apparently, you have to decide whether that would help or harm the case).

two possibilities: the mux or quad didn't provide that option, or (more likely) the operator didn't really know what he was doing.

[Seekingadvice 0]

Thank you so much for all your replies, particularly to Groucho Boucho. It really is helpful because until a while ago I knew a fair bit about imaging generally and a little about cinematography, but was entirely ignorant about CCTV systems and technology.

 

The technology is advancing at an astonishing pace. My problem is now historic because it relates to the beginning of 2009. So the equipment used must have been acquired before that date. So it could be of any vintage but not newer than December 2008.

 

I do have an interest in the matter, but that is beside the point. I'm interested in establishing facts that can be stood up, whether for or against any suspicion. So any pointers are really helpful.

 

I'd like to show a couple of other images, for your thoughts

.

The first shows the first six frames @ 25fps of the recording. I've brightened the shadow tones to make it clearer and added the red circles. When the file opens only Channel 4 shows in the quad view. By frame 3, Channel 4 comes on line. By frame 5, Channel 1 comes on line and Channel 2 follows at frame 6.

 

Is this consistent with demuxing of a multiplex file occurring from a standing start. i.e. where the transfer is being initiated from a bookmarked place in the file?

 

If so does this shed any light on the device outputting the movie file?

 

The second image shows the channel 1 image where one of the time-lapse images has a horizontal bar. I don't really know what to think about this. It's obviously a phase issue or an analogue glitch caught in the digital file. It occurs to me that it could be of no particular significance. But it may reveal something to CCTV insiders.

 

Is this a common issue in CCTV? Any thoughts?

 

Thanks again for your help.

[groovyman 0]

My first question is how easy or common is it to output CCTV footage as a 4 channel view.....

It can happen. There are several ways to accomplish this, here's some examples:

As mentioned before, a screen capture/recording program can capture the 4 channel+ view and output as avi, mpg or other video formats. Then there's dvr playback software that can output a 4 channel+ view to avi &/or mpeg - the Aver Remote Console software can do this (I happen to really like that feature). I suspect other systems & software have the ability as well. Another way is to just point a camera directly at the playback monitor and record. There are other ways, but I think you get the jist of it - it can happen and it's not difficult.

[tomcctv 187]

Hi. Has this already been used in court????

 

Your saying 2008 . Footage is 2006 . So can't be used in court...........not in uk anyway

 

 

 

Also are you in the north east

[Seekingadvice 0]

Hi. Has this already been used in court????

 

Your saying 2008 . Footage is 2006 . So can't be used in court...........not in uk anyway

 

/quote]

 

Well spotted!

 

I'm a little reluctant to go into the ins and outs of any litigation because it might tend to prejudice opinion, and I'm turning to this forum for its members impartial knowledge and experience. I'll have to explain a little more inevitably, but bear in mind I'm looking for technical and practical insight rather than judgement of right and wrong. In this case there were court proceedings in which the police were the defendants. That was resolved following a trial. But I'd rather not explain too much because I don't want to prejudice your input.

 

I will say a little to explain a bit and contribute some learnings for the forum.

 

The individual who originally went to the police in 2009 saying that he had CCTV of a crime occurring and who gave them the file on a USB stick, made a witness statement. He said the time on the CCTV is all wrong because he had not reset the system following a power cut. But, he said, he could prove it was taken about two weeks ago (in 2009) because of features that he claimed to be able to determine from what the footage showed. The police went along with this explanation and prepared a case to go to court and then made arrests.

 

It did not end up in court as a criminal prosecution because the police dropped the matter after it was pointed out that the CCTV wasn't even evidence of identification. But when you say about something like CCTV evidence that it can't be used in court, or won't stand up in court, you need to understand that court proceedings are adversarial. Evidence doesn't stand up in court only when the other side points out that it doesn't stand up. Either side in court proceedings will put forward all kinds of evidence and testimony that are plainly at odds with the other side. Frequently the evidence of one side or both will seem ludicrous, but that does not mean that it won't persuade a judge or a jury. It's only when a defendant's lawyer or the prosecution challenges evidence to point out that say, "...the date is wrong", that the evidence falls apart and hopefully the court makes the right decision. Advocates set out to win. They don't point out the flaws in their own case. They'll repeat any rubbish their client tells them with a straight face. That's their job. It's only if the other side is astute enough to pick apart the rubbish that the truth will emerge.

 

For these reasons, as CCTV practitioners, you should give very careful thought to designing systems that present unimpeachable evidence. That means time codes that derive from an automatic exterior source such as the atomic clock. High definition and high sensitivity camera sensors, expensive lenses, recording at frame rates of at least 24fps. File recording with minimal compression in open source formats. Output design to allow the entire hard drive content to be recorded verbatim in the case of needing to use the material (because the context of the recording may be as important as evidence as the isolated incident recording). And operators should be compiling a contemporaneous log of every intervention they make in their system so that if it came to it they could give credible evidence of how they came to record anything. Of course that list looks very expensive and difficult, but technological advance will reduce the cost, and what you really need to consider is the potential costs of getting it wrong. Excluding any issues of mendacity, if through honest mistake and micky mouse equipment or procedures, you cause a blameless other person to be got out of bed and thrown in the slammer, how would you feel? If someone else operating a micky mouse system caused you to be wrongly accused, how would you feel then? So, you see going into the evidence collecting business needs to be undertaken very seriously.

I've written this to contribute. But before you have a debate about file formats, frame rates and lenses, could you look at my previous post and the last two images.

 

 

Thank you again

[GrouchoBoucho 0]

I'd like to show a couple of other images, for your thoughts

.

The first shows the first six frames @ 25fps of the recording. I've brightened the shadow tones to make it clearer and added the red circles. When the file opens only Channel 4 shows in the quad view. By frame 3, Channel 4 comes on line. By frame 5, Channel 1 comes on line and Channel 2 follows at frame 6.

 

Is this consistent with demuxing of a multiplex file occurring from a standing start. i.e. where the transfer is being initiated from a bookmarked place in the file?

 

If so does this shed any light on the device outputting the movie file?

this is *highly* consistent with a time-lapse vcr playing back through a multiplexer, where video frames are written sequentially to the tape - save a frame from the first channel, then the next, then the next, and so on, then cycle back and save another frame from the first, and so on. and so, playback reverses this process. if you play a time-lapse tape back in a standard vcr, you just get a video that's constantly flipping from camera to camera; the multiplexer generates this sequence and sends it to the vcr to record, and then on playback, "de-sequences" them back to their individual channels. this is somewhat over-simplified, but you get the idea.

 

The second image shows the channel 1 image where one of the time-lapse images has a horizontal bar. I don't really know what to think about this. It's obviously a phase issue or an analogue glitch caught in the digital file. It occurs to me that it could be of no particular significance. But it may reveal something to CCTV insiders.

actually, this is also common with vcrs - a slight wrinkle or crease in the tape, a little dirt on a video head, anything that can interrupt playback of that segment of the video stripe.

 

Is this a common issue in CCTV? Any thoughts?

 

Thanks again for your help.

as noted: everything in this posts fairly screams time-lapse vcr. so at one time, it certainly was common. vcrs were still widely used in 2006, as this is well before digital surveillance recording was economically feasible for most.

 

this, coupled with the fact the original file the police had was in a readily-playable format, supports the idea that someone hooked the output of the multiplexer into a capture device on their computer (i was using an ati all-in-wonder display/tuner card in my pc well before 2006, to record tv shows and "rip" video tapes), and recorded it to a standard multimedia file.

[GrouchoBoucho 0]

The individual who originally went to the police in 2009 saying that he had CCTV of a crime occurring and who gave them the file on a USB stick, made a witness statement. He said the time on the CCTV is all wrong because he had not reset the system following a power cut. But, he said, he could prove it was taken about two weeks ago (in 2009) because of features that he claimed to be able to determine from what the footage showed. The police went along with this explanation and prepared a case to go to court and then made arrests.

this, by the way, is entirely possible - i've seen both analog (vcr) and high-end dvr/nvr systems that have had the time drift off, or even never had it set properly at installation. i had muxes, back in the day, that i'd set the time, and they'd be off by an hour within a month. vcr/mux systems would be much more rare in 2009, but certainly not unheard-of.

[groovyman 0]

The individual who originally went to the police in 2009 saying that he had CCTV of a crime occurring and who gave them the file on a USB stick, made a witness statement. He said the time on the CCTV is all wrong because he had not reset the system following a power cut. But, he said, he could prove it was taken about two weeks ago (in 2009) because of features that he claimed to be able to determine from what the footage showed. The police went along with this explanation and prepared a case to go to court and then made arrests.

this, by the way, is entirely possible - i've seen both analog (vcr) and high-end dvr/nvr systems that have had the time drift off, or even never had it set properly at installation. i had muxes, back in the day, that i'd set the time, and they'd be off by an hour within a month. vcr/mux systems would be much more rare in 2009, but certainly not unheard-of.

Agree w/ GrouchoBoucho. I experience time fluctuations w/DVR's frequently. Other electronics as well. Very common.

 

Couple of months ago I forgot to set the correct year on a DVR & it drove me nuts for about 10 minutes trying to figure out why there was no recording of the current date & time. Doh

[GrouchoBoucho 0]

For these reasons, as CCTV practitioners, you should give very careful thought to designing systems that present unimpeachable evidence. That means time codes that derive from an automatic exterior source such as the atomic clock. High definition and high sensitivity camera sensors, expensive lenses, recording at frame rates of at least 24fps. File recording with minimal compression in open source formats. Output design to allow the entire hard drive content to be recorded verbatim in the case of needing to use the material (because the context of the recording may be as important as evidence as the isolated incident recording). And operators should be compiling a contemporaneous log of every intervention they make in their system so that if it came to it they could give credible evidence of how they came to record anything. Of course that list looks very expensive and difficult, but technological advance will reduce the cost, and what you really need to consider is the potential costs of getting it wrong. Excluding any issues of mendacity, if through honest mistake and micky mouse equipment or procedures, you cause a blameless other person to be got out of bed and thrown in the slammer, how would you feel? If someone else operating a micky mouse system caused you to be wrongly accused, how would you feel then? So, you see going into the evidence collecting business needs to be undertaken very seriously.

you're preaching to the proverbial choir, but as you also realize, all these things can get quite expensive. as professionals, we can offer all these solutions to our customers, but at the end of the day, it's up to them what gets implemented. your 'innocent man' scenario is probably not enough to convince them, though - 99% of the time, the only thing on the line is their own money, and even that is rarely enough to get them to spend an extra $50 for more storage, or $100 for a gps time-base receiver to make sure everything stays sync'd. heck, i have customers that are a major chain of retail outlets that could have time sync by simply plugging their dvrs into their existing network, and they refuse to allow it.

 

btw, 'open source file formats' are generally incompatible with 'unimpeachable evidence' since, afaik, there are no open source video codecs designed specifically with surveillance in mind, with things like embedded timecode and authenticity verification.

[Kawboy12R 0]

I know of one theft case locally where the thieves were known and got IDed well on the video but the judge let them off because the time was off by an hour or so. It might even have been a daylight savings time error. Wrong timestamp = no conviction sometimes.

[GrouchoBoucho 0]

I know of one theft case locally where the thieves were known and got IDed well on the video but the judge let them off because the time was off by an hour or so. It might even have been a daylight savings time error. Wrong timestamp = no conviction sometimes.

true. as op notes, it's not always a matter of the evidence being 100% perfect, but about the *relative* reliability and veracity of the evidence. i had to provide a statement once on a fraud case, where stolen credit cards were used to for a large lottery purchase at a store. the timestamp was off, so i went in with the lottery rep, he did some test prints on the lotto terminal, and we compared those timestamps to the dvr to determine the delta. he then had me write a statement laying out the procedure and concluding with my 'professional opinion' on the actual time offset and the reason(s) for it. i assume that if it ever got to prosecution, my written statement was sufficient, since i was never called on to testify.

[Seekingadvice 0]

as noted: everything in this posts fairly screams time-lapse vcr.

 

Thank you very much . That is very helpful. It would be very significant if the original had been tape based because not only would the person who recorded the CCTV have possessed an original other of the image, he must have known he possessed it. One cannot be oblivious of having to put new tapes into a machine.

 

If the original had been recorded to tape, would the image size have been likely D1 equivalent (768x576) ? I suppose it's difficult to equate analogue to digital easily, and I'd guess it would be expressed as lines (625?). But in rough terms equivalent?

[Seekingadvice 0]

I know of one theft case locally where the thieves were known and got IDed well on the video but the judge let them off because the time was off by an hour or so. It might even have been a daylight savings time error. Wrong timestamp = no conviction sometimes.

 

Here in UK there is a Home Office guidance to the police on retrieval of CCTV evidence from private systems. The protocol has been adopted by all the police forces, though that doesn't mean that plod on the ground will be clued up.

 

The advice is that a technical officer must visit the system. establish all the specifications of the system and that it is working. Establish and evidence the present system time displayed. Establish true time from a dependable source such as the speaking clock (a telephone service). The officer should then record any deviation and be able to give evidence of the time record. He should then extract the file in native format and secure any software needed for playback. If in doubt he should seize the hard drive or the equipment taking care not to lose any digital data by so doing.

 

Generally speaking where a defended prosecution ensues the two sides will attempt to agree any areas of evidence possible. Thus if both sides agree the evidence on such details as times of recording beforehand it won't be tested. Only if one side doesn't agree would the officer need to give evidence of his notes and procedure on retrieval, which would then tend to support one view unless the other side could throw doubt on it.

 

I think I am right in saying that O J Simpsons defence was largely based on throwing doubt on circumstantial evidence of timings by reference to media camera coverage of events, and tracking the timings on news ENG cameras which were then customarily set by the cameraman's wristwatch on the day of the assignment.

[GrouchoBoucho 0]

If the original had been recorded to tape, would the image size have been likely D1 equivalent (768x576) ? I suppose it's difficult to equate analogue to digital easily, and I'd guess it would be expressed as lines (625?). But in rough terms equivalent?

vhs spec, if memory serves, is 220-240 lines at 'sp' speed (2 hours on a t-120 tape). on a time-lapse machine (24 or more hours per tape - i've seen machines that will do up to 192 hours on a t-160 tape) it's substantially less. you're lucky if each camera's effective resolution is qcif (160x120).

[ilk 0]

If the original had been recorded to tape, would the image size have been likely D1 equivalent (768x576) ? I suppose it's difficult to equate analogue to digital easily, and I'd guess it would be expressed as lines (625?). But in rough terms equivalent?

vhs spec, if memory serves, is 220-240 lines at 'sp' speed (2 hours on a t-120 tape). on a time-lapse machine (24 or more hours per tape - i've seen machines that will do up to 192 hours on a t-160 tape) it's substantially less. you're lucky if each camera's effective resolution is qcif (160x120).

 

There is also the scenario (in the early days of digital) where the time lapse VCR installed to record the output of a mux or a quad was replaced a single channel DVR.

 

Police Technical officers? A rare breed now almost extinct.

 

Ilkie

[GrouchoBoucho 0]

There is also the scenario (in the early days of digital) where the time lapse VCR installed to record the output of a mux or a quad was replaced a single channel DVR.

true, but the 'roll lines' in one of op's pictures indicates actual tape in this case.