Proactive CCTV is claiming to offer "the only affordable video archiving solution on the market", reducing the storage typically required for H.265 by 89%. Where did Proactive come from? What are they providing, and how affordable is it?
Thank you Matthew. We currently do not have a mobile application. As the Sean pointed out there is decompression that happens with the hard client to retrieve the archived video. That decompression uses cpu, and mobile devices, just dont have enough processing power at this time. However, as other manufacturers work with our API, the retrieval process, will be handled using those native apps. If you have any other questions we are happy to set up a call if or when you would like to learn more.
What is the real world impact of a 1080p RTSP upstream on an average 10/100Mbit Internet connection with the Proactive compression? Let's say we are looking at a 50% reduction in bandwidth, is Proactive claiming the RTSP stream is 2MB/sec or less? How will this scale to 25 cameras? This seems to be the major challenge in cloud storage. Are you uploading it during off hours? It would be helpful to understand how Proactive is overcoming this challenge.
Hello Brian. Thank you for your comment! You are 100% correct, upload speed is a major issue with cloud. To be clear when working with the RTSP there is no reduction on the Local Area Network. The real reduction and savings comes when uploading to the cloud(Wide area netwrok WAN). The device that is onsite is doing the compression and essentially creating files. So when uploading we are uploading files NOT video streams. So for the example of 16 cameras @ 1080p refenced above we would need a minimum upload speed of 2mbs upload for all 16 cameras, depemding on scene acitivty, quality, and file sizes max upload would be 5mbs upload for all 16 cameras. That being said, due to the low bandwidth requirements we rarley have to do a schedule, however we can if needed.
at first I was skeptical, since most bandwidth calculators will give numbers 10x for comparable MJPEG compression.
but the secret seems to be the LMAZ2 compression. LMAZ2 (or 7z) normally doesn’t compress a jpg or even a folder of jpegs much, maybe a few %. because they are compressed already and LMAZ2 is a lossless encoder, so...
but this changes dramatically when you encode large groups of jpgs that are very similar, as surveillance frames tend to be.
using the two compression technologies together this way would seemingly rival h.264!! for free.
could a camera do it directly?
perhaps, but the CPU requirements to compress might be too much, plus there has to be some delay to buffer the frames,
You definitely get part of the component of how it is achievable and works, thank you for recognizing that.
The h.264 and 265 codecs work as a first layer to our software by providing a stream that is reduced in bandwidth, and results in smaller file footprint than a completely uncompressed video stream.
On a file system level when compressing data, grouping video is far less substantial, than grouping jpeg images. Along with our software grouping the images, analyzing redundancy, adjusting dpi and quality to optimal levels, and then using a file compression engine such as LZMA2, the result is a significant reduction of file size, with minimal quality impact. File compression can be good to excellent, based on the environment of the cameras and redundancy, but redundancy plays a large factor in getting the most out of the compression. However, our software has many parts besides the file compression itself, as our engine acts somewhat as an analytical calculator, in predicting the best outcome of grouping redundant images, and allowing it to be reversed back into a video format such as AVI/MP4.
At a time, we were actually in development of a camera that could act as a file compression engine, but the amount of CPU consumption required, and ability to process images in milliseconds, then compress, would cause major latency to stream to a VMS and/or NVR. Not to mention having to offload that archival data to the cloud or local storage appliance, was a lot of overhead.
File compression requires high amounts of CPU and memory to predict the best file reduction results when feeding images through it. Our software runs on hardware that can go as high as i9 processors, and higher end Intel Xeon chips for server grade applications. Cameras just don’t have the kind of processing power you are going to find in a server.
Great questions. And thank you for the compliment.
why did you choose security as an application point for that, to begin with?
I personally have been in the security industry for 26 years. At the time we created this software(6 years ago) I had an integration firm, this was our way of differentiating ourselves. Storing video for the full length of statute of limitations was unheard of. Especially to be done affordably to an end user. We realized we filled a gap in the industry (affordable archiving) 4 years ago and decided to create Proactive Data Storage and Monitoring.
can you offer this compression method to google/youtube maybe? If not, why?
Never say never. I don't see why not. From a video surveillance side I can not speak of names but I can say we have been speaking to companies of such magnitude for their video arching needs.
2) does the world need H.265/H.264 or other MPEG moving forward?
Absolutely. We did not create a new codec here. And our business model is simple, we stick to be an archiving solution. The reason is very simple, in as much as we would all like to sell our clients the latest and greatest my experience has shown they typically dont replace what's not broken. So we suggest that if a client needs 2 years of video let's say, do they really need the quality and frame rate that far back. Serious crimes where that image quality and frame rate is required is (in my experience) identified within a few days. Typical reasons for the long term storage are more lawsuits.
I hope that answers your questions. Thank you again for your comment and questions.
well they seem to be inferring 5x the performance of (non-smart) h.264 according to the exacq calculator, which gives the bandwidth for a 16 camera 1080p/5 fps high activity as ~25 Mbps, compared to 5Mbps as Tom has stated.
As a general rule, I don't put a lot of weight into references since it's easy for companies to cherry pick them. But if anyone who is reading this or has already commented can give insight, I'd like to see. I still don't get the value of this versus smart codecs.
Converts the H.264 or H.265 to group of JPEGs Automatically organizes the JPEGs for image redundancy Packages the files using LZMA2 file compression prior to storing locally or in the cloud
The challenge I have is understanding how that is valuable vs smart codecs, smart codecs look for similar redundancy savings but it's done inside the camera for 'free', so I am not sure why one would use this if you already have smart codec supporting cameras.
Isn't the value in hitting a storage bench mark? At least that is how it is pitched to us from the sales side. Cheap long term storage that meets a minimum requirement. Some customers need 90 or 180 days of storage and are reluctant to spend on storage for some odd reason.
John I do not have much experience with smart codec cameras. What I can say is that our clients and the technology they use ranges across the map, from hik, dahua, DW, hanwha, axis, avigilon ect.
I should state that I am not trying to compete in the 90 day local storage, the truth is I'm not that competitive in that realm, except for the California cannibis market.
Our archiving servers for local storage start at 6 months local storage and go up to as much needed. At this time, the most amount of time we have out there is a 4 year server. So what happens is the longer the end user need ls the more effective my solution becomes.h
That again depends on what the client has. For clients with hundreds of cameras we tend to be way more cost effective.
Again I do not have much experience with smart codec, I am just speaking on what my clients are seeing and doing.
Thank you, I can appreciate your perception, to be clear, I have not personally installed them. And have not seen the actual effects of this technology. I understand the technology but I will also not claim to be fully educated on something I can not speak intelligently on.
As I have worked with hundreds of integrators, and countless camera models, the question of comparing smart codec and our solution has never come up. We have quoted and won many enterprise level systems using current camera technology and smart codec on the cameras.
I can also say(from experience) from a sales side it is a lot easier and cheaper to have a client purchase an add on service instead of a full system replacement.
I am by no means claiming to be a solution for all. As I stated earlier it is not the 30 to 90 days that is my market. The higher the requirement of storage the more competitive we are.
If your open to it, I would be greatful for the opportunity to have a conversation with you and go over some facts from both sides.
We completely understand. And appreciate your feedback.
yes you can absolutely do that, I know I have, as an integrator. In about 6 months I racked up 1.2 petabytes at a penny a gig per month you can do the math and see why we where forced to rethink what is affordable and what the end user will pay for.
The difference is with our compression that works with your $200 dollar camera msrp will be $4 per month per camera for 90 days cloud storage. The bandwidth requirements is another factor. As mentioned above a 16 camera system would need a max upload of 5mbps for all 16 cameras.
If you would like we are happy to do a demo for you and go over a cost comparison to show you the value of what we offer. Please feel free to contact us if you have any questions.
Unfortunately, I am unable to post a video or snapshot here. You can see the image in the article above of a 1080p camera which has been compressed and decompressed. However, I'm a little confused are you questioning the image quality or the compression? As mentioned above we do not by any means say we are a replacement for the dvr/nvr/vms we are an addition to. We do claim to save substantial hard drive space when storing for long periods of time or in the cloud. Also, as mentioned above we have used exaq calculator to show a comparison. So for 16 cameras at 1080p at 5fps for 1 year of storage we would only need less then 7tb based on 12 to 16 hours of motion a day.
I would be happy to do a demo for you if you would like.
The compression claim is very interesting. Assuming that we compare apples to apples of course.
Small test using regular camera footage of parking with minimal background movement for duration of 2min30sec of 11.5mb, 1080p video, h.264, 12fps (h264 (High) avc1, yuv420p, 1920x1080, 643 kb/s, 11.99 fps)
Generate 5 jpeg frames/sec with high compressions using: "ffmpeg -i clip.mp4 -vf fps=5 thumb%04d.jpg -hide_banner" and naturally losing quality:
original frame vs jpeg compressed
Grabbing 5 frames/sec from 2min30sec generates 750 images. Each image 69kb. Compress with latest 7z/Ultra compression with command: 7z a -t7z test.7z *.jpg -mx9
Resulting file size - 36.6mb. Original mp4 footage file size - 11.5mb. Resulting file roughly 3x larger. In case we compress jpeg even more let say to 40kb, resulting file would 21.2mb - roughly 2x more then original mp4 file, while image quality would be really bad.
Possibly one way to explain such huge compression result “91% compare to native h.264” would be to compare h.264 stream at 6mbit/sec with JPEGs in 7z archive. But even in such case just h.264 compression would provide better result storage/quality wise.
But even in such case just h.264 compression would provide better result storage/quality wise.
agreed. i did similar tests and got similar results.
to note, they are placing a lot of stock in their redundancy analysis and optimization.
Along with our software grouping the images, analyzing redundancy, adjusting dpi and quality to optimal levels...
forget smart codecs or h.265, i couldn’t come close to even straight h.264 using low quality jpegs and 7z on max settings. of course, depending how much you degrade the jpeg you could get there i suppose.
but, imho, the only way this method is likely to save space AND retain the same image quality is if you are storing MJPEG streams. but against h.26x, no way.
Video stream analysis and optimization that is essentially what h.264 does - Motion Compensation and Variable block sizes. H.264 is a lossy compression as well as JPEG. Lzma2 is lossless. For Vsaas cloud - storage is a major cost, bandwidth is a bottleneck and therefore video stream compression is always a problem.
In my opinion main questions were already asked by Sergey:
1) why did you choose security as an application point for that, to begin with? can you offer this compression method to google/youtube maybe? If not, why?
2) does the world need H.265/H.264 or other MPEG moving forward?
Today, we’re excited to announce the release of Proactive Live View! Seeing Your Cameras Live will now be accessible through our CMS. We’ve created a walkthrough video just for you, to show you how to access Live View and use our features.