Motion Only V Continuous Recording

[cutwitt]

no sorry thats what the cops usually say to me, i offer to email them images they go 'oh no cant recieve email'

I suppose it was invented in the 80's so they do need chance to keep up

Plod needs to get their act together. The law is clear that recordings must be submitted in their original format whether or not transcoded stuff is provided. Most recorders use locked codecs for good reason. Player apps I have seen are all license free.

[Doktor Jon]

so to summerise, where hard disks are no object

as high frame rate as your disks will take

where not

low frame rate when the scene is inactive, and high framerate when there is activity in the scene

Doktor, what do you class as realistic framerates for the above situations?

James

Couldn't agree more James.

It's actually quite difficult to arrive at a definitive solution, simply because every application is likely to have it's own specific requirements.

Setting aside any issues with compression techniques, number of cameras connected to the DVR, and a myriad of other considerations, the ideal set up should provide a continuous stream of images that are of sufficient quality to prove the presence of, or lack of, anyone within camera shot at any given time.

In this situation, generally 1 - 3 ips would suffice for that part of the requirement. Where more activity is noted, ideally it would be advantageous if the image rate increase to perhaps a minimum of 10 - 12 ips at maximum record quality.

If the disks are fat enough then obviously nobody is going to with 25ips

I've always believed that image quality should take precedence over the actual number of recorded images. Unfortunately, too often system operators go for real time recording, and then turn down the quality to try and stretch the record period as far as possible.

As I said before, there is no absolute answer, just common sense applied in relation to the actual application.

I'm still trying to work out what the countings all about .... must be me

[cutwitt]

Couldn't agree more James.

It's actually quite difficult to arrive at a definitive solution, simply because every application is likely to have it's own specific requirements.

Setting aside any issues with compression techniques, number of cameras connected to the DVR, and a myriad of other considerations, the ideal set up should provide a continuous stream of images that are of sufficient quality to prove the presence of, or lack of, anyone within camera shot at any given time.

In this situation, generally 1 - 3 ips would suffice for that part of the requirement. Where more activity is noted, ideally it would be advantageous if the image rate increase to perhaps a minimum of 10 - 12 ips at maximum record quality.

If the disks are fat enough then obviously nobody is going to with 25ips

I've always believed that image quality should take precedence over the actual number of recorded images. Unfortunately, too often system operators go for real time recording, and then turn down the quality to try and stretch the record period as far as possible.

As I said before, there is no absolute answer, just common sense applied in relation to the actual application.

I'm still trying to work out what the countings all about .... must be me

Hi Jon,

Hope you had a pleasant holiday and good luck with your new project.

Your comments are true for jpeg like compression methods but the situation is different if you are using conditional refresh type compression like mpeg4 and H.264. I am currently using an H.264 based solution and whether I set the frame rate to 10 fps or 25fps makes little difference to the recorded file size. What does makes a huge difference is the amount of motion being recorded - basically the bit rate goes up when there is a lot of motion.

Agree with you on the quality issue

[Doktor Jon]

Hi Jon,

Hope you had a pleasant holiday and good luck with your new project.

Your comments are true for jpeg like compression methods but the situation is different if you are using conditional refresh type compression like mpeg4 and H.264. I am currently using an H.264 based solution and whether I set the frame rate to 10 fps or 25fps makes little difference to the recorded file size. What does makes a huge difference is the amount of motion being recorded - basically the bit rate goes up when there is a lot of motion.

Agree with you on the quality issue

[cutwitt]

Just thought I should add the mpeg bit for completeness as we will no doubt be seeing more of it in the future.

With technology moving towards IP cameras ( market forecast is 2:1 sales of IP over conventional in 18 months!) and the higher resolution it can offer, mpeg type compression has a bright future.

With some manufacturers planning to put the TI DM642 DSP in the next generation of IP cameras we should see quite a jump in resolution from the current generation (mostly just toys imo). The DM642 is capable of encoding 16CIF at 25 fps with whatever codec you care to use. Advanced mpeg compression is really the only option for transmitting this amount of data and has the advantage that motion detection is built in to the codecs

[Phil Sumner]

I see the biggest problem being the local forces not having the software to watch it all, happened twice to us recently. Now i keep CD`s with software on me all the time so I can hand to the investigating officer.

Must admit we get lots of calls from the ol' bill - tends to be people who claim to be from video analysis units - generally asking whether video from X or Y can be converted into AVI.

I understand why people ask for AVIs/MPGs - it would make things much easier for compatibility, but the evidential integrity is most important. What use is a file that's been converted which can't be 100% proved to be taken from a unit and untampered.

[Doktor Jon]

I understand why people ask for AVIs/MPGs - it would make things much easier for compatibility, but the evidential integrity is most important. What use is a file that's been converted which can't be 100% proved to be taken from a unit and untampered.

Ain't that the truth

Whatever happens in terms of long term technological developments in the presentation of video recorded evidence, unless there is some consideration towards standardising submission protocols, it's quite likely that evidential recordings will increasingly be challenged in court on a minor technicality, and that's not really in anyones interest (other than perhaps the defendant ).

[Phil Sumner]

consideration towards standardising submission protocols

Actually, that's something. I'm going to have to email myself at work to remind me to do this... I wonder if it's even being looked at by anyone. I can't think of many good reasons not to have at least similar standards.

[cutwitt]

Some kind of standardisation would no doubt be welcome by many but would not come without potential problems.

The fact that many DVRs record in a proprietary format using locked codecs means that video cannot be edited by video editing software, so you cannot be accused of tampering. Also, the smart ones do not allow the time/date code to appear on the transcoded video because all avi formats can be edited.

If we all used the same codec it would only be a matter of time before someone hacked it allowing the recorded files to be opened and edited: remember what happened with the encryption of DVDs.

With many different locked codecs in use, hacking and tampering with evidence becomes increasingly improbable.

All that law enforcement needs to do is install the appropriate codecs.

[cutwitt]

i am a big fan of ip but again i will still prefer jpeg over mpeg even at megapixel, but then i havnt seen i high bandwidth mpeg encoder in action yet.

I think that for transmission mpeg rules but for storage im not so sure. I wonder what the broadcast people store in?

But framerates for jpeg will get even harder at megapixel, but i still think 5 fps is fine for most purposes. I will create a video from our lowly 1.2 megapixel we have on a cross roads and maybe post it here in jpeg and mpeg form

James

Most recent digital video is stored in mpeg2 format with moves towards advanced mpeg4. What will be used for HDTV still seems uncertain. Some will stick with mpeg2, some may move to H.264 and then there is the BBCs own DIRAC codec, still in development.