Cops Blame Integrator: Audio Recording Controversy
A video surveillance installer apparently forgot to disable the audio functionality of recently installed cameras, causing an uproar in a NJ police department.
I know of one major VMS that by default would record audio if the camera supported it. How often is this an issue for anyone?
Good find! Insert NSA joke here...
Here's an interesting excerpt:
"[The Police Chief] laid the blame on Safe Life Security, the Manalapan company that installed the surveillance system.
"The vendor that originally installed the cameras has taken full responsibility for the error and has acknowledged that he was explicitly told by members of this administration to disable the audio microphones in all other areas of the police department with the exception of the cell block area upon installation," Bryan said."
So the real explanation is that the system recorded audio by default, and did so for months until someone noticed? Really? Sounds fishy that it would take that long to realize. Is no one ever using the system. Carlton, it would be interesting to see if Safe Life Security has a response.
I haven't come across any VMS that records audio by default. That's an interesting default option. If the integrator failed to follow directions, then that is their responsibility. But end users really should test systems themselves, just to be prudent. Especially if there are regulatory concerns.
This appears to be icing on the cake for the Edison, NJ police department. This same department has been embroiled in controversy fror the past year and the editorial board of the Star-Ledger has called for the state attorney to step in and take control.
It strains credulity to believe that the department failed to notice the system was recording audio for 11 months.
The law enforcement officials said the company’s technicians were seen inside headquarters late last week, disabling the microphones camera by camera.
if they had integrated mics, how exactly would they disable them camera by camera?
if they were external how didn't they know about them?
Surely they don't mean law enforcement saw technicians clicking a enable audio checkbox one by one...
Maybe they gouge out the diaphram with a star wrench...
Also interesting is of all the 'violated' parties, the police themselves are by far the most vocal!
Why the uproar about what police officers saying to other police officers in a police station during working hours?
I bet they wouldn't like the PoleCam!
Two points:
First, how many cameras with integrated mics exist? Not that many, and most of those suck. You've got the Mobotix, a couple of Axis models, a couple of Vivotek models, a very few ACTi models, and a couple of Bosch models. All the rest is consumer grade stuff. Carlton, can you use your super sleuthing skills to find out what model camera they used? Maybe see if they put this job out to bid, see if we can guess based on the specs. I certainly wouldn't want to imply that the integrator installed Louroe boxes and wired them into the line in audio input of the camera. Dear me, no.
Second, and more importantly: I am extremely disapointed the story was not illustrated by a full shot of the Edison Municipal Building, which is by far the very ugliest building in New Jersey and possibly the northeast United States. It's a poured concrete monstrosity in the Brutalist style, and looks like it was designed by Mecha Stalin as the headquarters of the Secret Police in some far future distopia. I always avert my eyes when I drive past it.
I have actually run into this. Milestone will allow and record audio by default (using the wizard). The instance I'm thinking about, it was an install with several IQEye Alliance-Minidome cameras, which have built in microphones which work pretty well. The server did not have speakers, nor did the client they were using to review footage. We didn't realize the audio was there until I remoted into the server with my laptop which had speakers on it (and audio pass-through enabled). I can believe accidentally recording audio and not knowing about it for quite some time.
Tyler, I have never recorded audio from my cams. Am I correct assuming the audio is just encoded in the video file? What does it do to the size of the recordings? Just asking out of curiosity.
Audio, in general, does not add much in the way of storage relative to video streams. As a rough rule of thumb, I'd say it's 1/10th the bandwidth of video.
Audio streams are not encoded into video streams - at least not in any VMS I have experience with. Audio and video files are separate and the VMS syncs the two files together.
Concur with John - audio files (though they do have size) are tiny in relation to the video files.
Audio and video files are separate and the VMS syncs the two files together.
Thats interesting. I always just assumed that the reason that mjpeg w/audio often has sync problems is because they had to be sync'd together, where h.264 I thought they were more or less intertwined in realtime, like strands of DNA.
But the real reason, as I'm sure you knew, is that h.264 has a standard, built-in mechnaism for syncing multiple streams...
Does that mean all cameras with audio also send 2 streams and if not would the VMS transcode them?
Wouldn't there be some reduction in network overhead by transmitting in one?
Or does H.264 always require seperate audio and video streams, like a DVD has the VIDEO_TS and AUDIO_TS files?
I have absolutely no clue about the differences.... maybe some of the audiophiles here on IPVM can school me(us)? :)
The NVR that I am (fairly intimately) familiar with stores video and audio in two separate databases. Consider the following setup - 2 cameras in the same room, only one of them recording audio. If camera A has the the microphone, and is set up to "record on motion", we might encounter situations where we have video on camera B, but if camera A had no motion, we'd have no audio.
With regards to H.264, then it is a video format. As far as I know it does not have intrinsic support for audio. What happens is that the H.264 is saved in a file, along with one or more audio tracks (which could be ACC, MP3 or something else). The way the video and audio is laid out in the file depends on the "container" - e.g. a quicktime file is a "container" file, just like an AVI file is a container file. A container may support multiple different video and audio codecs - so an AVI file might contain a h.264 encoded video and a MP3 encoded audio stream. But it might also contain a video file encoded with Cinepak, and thus you sometimes need to install a codec in order to open an AVI file; in the old days you'd download DivX or it's dark sibling Xvid (notice the clever reversal of characters).
A common way to place video and audio bits in the file is to interleave the files (guess what the "I" stands for in AVI). So you'd have 200 ms of video bits, then 200 ms of audio, then 200 ms of video and so on. In fact RTSP also supports this interleaving of data. Natually, this makes synchonization of audio and video a little easier. If you start playing 50% into the file, the data you read is already synchronized in the file. Chris calls it "strands of DNA" which is I think is a good way of looking at it. This interleaving will also work if the video is MJPEG. The RTP packet header actually contains the time-code of the video, and thus does not rely on the video format for synchronization.
The NVR might read the video and audio as one stream via RTSP, or it might read each stream individually, but some bytes will belong in the video bin, and others in the audio. So, depending on the camera driver, the NVR might tear those DNA strands apart.
When playing from an NVR (again - the ones I know), things are a little different. You basically have 2 streams coming from the NVR. The client will look at the timestamps of the two streams and make sure they are synced up at all times. Although this seems trivial, it turns out that it can be quite a hassle. It's doable - but it takes a bit of tinkering. For whatever reason, it's one of the things that people tend to screw up - I've lost count of the number of times I just needed to "fix this little thing", which then turned out to throw the whole A/V sync out the window.
LIVE is a slightly different matter. For video you can pretty much decode and show as you get frames, but you just can't do that with audio. You can tolerate stuttering framerates, but audio is a whole different ballgame. You just cannot decode and play, it sounds TERRIBLE and it is useless. So what you need to do is to buffer a bit of the audio. But if you are buffering audio, you need to buffer video as well (to remain in sync). Once you do that, you are introducing latency. Some people hate that, especially for PTZ cameras.
Who knows what was said, and what was and wasn't done? Isn't it easy to just say that "oh.. that was a technical error" and blame it on the integrator? Why did the cameras have mics in the first place?
Your're the man Mort!
Though one thing I'm not sure I'm getting, you said:
LIVE is a slightly different matter. For video you can pretty much decode and show as you get frames, but you just can't do that with audio. You can tolerate stuttering framerates, but audio is a whole different ballgame. You just cannot decode and play, it sounds TERRIBLE and it is useless. So what you need to do is to buffer a bit of the audio. But if you are buffering audio, you need to buffer video as well (to remain in sync). Once you do that, you are introducing latency. Some people hate that, especially for PTZ cameras.
Are you saying the the video is purposefully delayed by the nvr to match audio buffering when viewing live?
I appreciate that your comments apply to the NVR you work with.
Wouldn't it be better to just buffer the audio minimally and let the video freewheel? As if you were listening to the mic of one camera and the video of another.
So ATTENTION all IPVM PTZ with audio owners!
Pan your ptz and listen for the whirr and report back!
Thx again, C
Since everyone has avoided the 'blame' word so far, I think it would be interesting to see what people think?
I vote 100% integrator responsibility, though I'm sure lots will assign at least some culpability to the customer. IMO, it doesn't matter if the customer is a PD or a factory, it is the responsibility of the surveillance vendor to do their best to protect their customers from any litigation which might arise from use of that vendors' products.
Audio laws are very specific - and very different - depending on the location of the customer's site. While the alleged victim will most certainly sue the customer (as they should), the customer will always do their best to deflect it right into the integrators lap (as they should).
Interesting that you believe that this was inadvertant, not purposeful. I'll bet you a dollar the customer asked for audio and the integrator was too dumb or greedy to say "no". And now the customer is blaming the integrator, saying they had no idea that the audio had been recorded. Well, how did anyone know the audio was being recorded unless the customer had used the audio recordings?
Great point, Ari...
I had a customer back in the day who wanted audio in his 3 insurance stores - but he didn't want his employees to know. His particular brand of scumbaggery was that he wanted to hear what his employees said about him when he wasn't there.
I informed him that in NC you must put up signs in any place where the public has access - like his places where customers interacted with his employees via teller-like windows in a common area.
I was so concerned with his scumbaggery that I made him sign a document I created stating that we had our little discussion and that audio installation was not a part of the install.
I then made every future customer sign a similar document, as I like my ass completely covered. :)
thongs
I think it is possible that the Police requested audio recording capability in the Cellblock, in conformance with NJ DOC regs, but either specified no audio recording elsewhere, or dropped the ball with the other cameras in the specification. The integrator should have been aware of the differing requirements within different areas of the Police. In many NJ Police Departments the Dispatchers are the ones watching the live video feeds. I guarantee that the Police Department did not want audio recording capability within range of Internal Affairs or Supervisory Officers desks due to the nature of the conversations that would take place in those areas. Unless they enjoy union and legal problems would they want them in the non-cellblock areas. If the specification was at fault it might not be a bad idea to see where it originated. I know alot of Police Departments "borrow" bid specifications and from each other. This specification may have left footprints in other towns.
Was there a spec, was there a consultant, did they do a walk-thru after the install? There are a lot of questions to be asked and answered proir to placing blame.
We recently did a baseball stadium and there is a police precinct in the stadium where we installed a small ONSSI system with over a dozen cameras. Once the police moved in there were only 3 cameras left all the other common area cameras were "missing" and unaccounted for.
Newest Discussions
| Discussion | Posts | Latest |
|---|---|---|
|
Started by
Undisclosed #1
|
2
|
less than a minute by Brian Rhodes |
|
Started by
John Honovich
|
264
|
less than a minute by Undisclosed Integrator #21 |
|
Started by
Undisclosed Integrator #1
|
1
|
6 minutes by Undisclosed Integrator #1 |
|
Started by
Undisclosed Integrator #1
|
5
|
less than a minute by Ryan Hulse |
|
Started by
Undisclosed End User #1
|
9
|
less than a minute by Undisclosed End User #1 |