Well if anyone here is familiar with ONVIF standard and can take the time to look at the above reference to HDSM 2.0 they would know why HDSM 2.0 is not compatable with ONVIF. It is really an awesome way to manage high resolution streams with H.264 compression. These things must have a ton of processing power!
I think the biggest thing here is the possibilities behind utilizing something like HDSM 2.0... Can you do a review on your thoughts of the HDSM 2.0 approach?
This [HDSM2.0] is much more than mutlistreaming supported by ONVIF. So you know current Avigilon H.264 cameras actually connect to their own servers through ONVIF. Also, Avigilon supports dual streams from other cameras through ONVIF and sure, it appears they just use a couple of the streams from this camera for ONVIF but this is much, much more than that. According to the documentation it actually creates multiple full resolution streams of specific sections of video in addition to the other full image varying quality streams which means ONVIF would have to have the ability to dynamically select one of many streams based on zoom ratio within a specific section ofvideo - which it does not.
I'm interested in this idea because it seems like a great way to deal with the problem of really high resolution feeds using H.264 on the client side for both live and recorded feeds. It must be very processor intensive but it is still very intriguing.
I would be interested in examining HDSM 2.0 further. Do you know of other software / cameras that do anything similar? I know IQEye has had the ability to setup regions for a really long time within the camera feed - not sure about the new cameras. What is cool about this is it appears this functionality will just happen automatically when using Avigilon software & cameras... of course for this to be incorporated into other VMS ONVIF would not be an option it would take custom coding.
Ok, the existing HDSM for H.264 is regular multi-streaming.
For 2.0, they are claiming:
"When the user engages a camera and digitally zooms in for greater detail, the higher resolution stream is provided. However, only the portion from that region of interest is sent. This dramatically reduces the amount of information exchanged between the server and client, by only providing the information that the user needs at that time, regardless of resolution."
My first guess is that this is a feature in the new generation of Ambarella chips. A lot of manufacturers have or are moving to them. [Update: according to the marketing claims in the HDSM paper, this is incorrect.]
That said, I am not aware of surveillance manufacturers doing this. Dropcam does something like this (with their enhance feature using Ambarella). It will be interesting to see what others release at ISC West.
Even in the 2.0 whitepaper, they are not claiming to do these multiple streams from the camera. It clearly says "between the server and client", and in the figure above that block of text, makes reference to both full resolution and low resolution streams being saved by ACC (I'm assuming more than two, because they also reference intermediate resolution).
You're right. I am not sure how they are dong this. The example they give is:
"The image is divided into 12 distinct areas. When a user zooms in an area for more detail, only that portion, in this illustration 1/12th of the total resolution, is sent from the server to the client."
I have not heard anyone be able to take an H.264 video and only stream a portion of it.
I am wondering if they are not doing transcoding here. I am not aware of H.264 lending itself to cutting up and only sending out portions of a video feed. On the other hand, transcoding would be able to deliver what they are saying.
Transcoding is not a bad thing, but it is very resource intensive and not novel.
It almost sounds as if HDSM 2.0 breaks the original high-res stream into twelve smaller high-res streams, indexes them to the original stream, and stores them that way on the server then feeds those smaller streams back to the operator when targeting a specific section of the lower resolution stream being viewed at the console.
That's how it sounds except H.264 historically does not work that way. So they have either developed some novel proprietary variant of H.264 or have some special technique or are actually transcoding. It's hard to be certain from a marketing white paper.
"So they have either developed some novel proprietary variant of H.264 or have some special technique or are actually transcoding"
Transcoding is not scalable in larger systems. Most likely Avigilon has developed a proprietary way of streaming video as they are always trying to innovate their product and software.
Its a combination of the H.264 multi stream technology and the best part of JPEG2000 HDSM streaming. Small amounts of zoom will switch between different size streams and just like when you zoom multiple times into with a JPEG2000 camera to get the detail of the car, it will only pull one of the higher detail 12 streams on the H4. The whole point is you cant typically display more than 2 megapixels on a monitor or image panel, so why send more than 2 megapixels?
Are you speculating or have been you told that by someone who knows the internals of Avigilon's HDSM 2.0 implementation?
There's certainly value in only pulling 'one the higher detail 12 streams' but the question is how they are implementing this. The way everyone has done this with H.264 historically is to transcode. They may very well be using a 'proprietary way of streaming video' but it still needs to answer the question how they are ingesting 16MP H.264 feeds and outputing subsegment streams.
Avigilon held a webinar yesterday, titled Surveillance in the new year: 5 trends for 2014 hosted by Willem Ryan, their Senior Product Marketing Manager. If you jump to 42:07 of the playback, someone asks the question about processing resource utilisation, assuming in the question that H4 uses transcoding - was that you John? ;) -, to which Willem replies:
It's not quite transcoding at all.
As could have been expected, he doesn't elaborate on the process used, but goes on to say that there are no special server requirements, apart from having a server that is up to current technology standards, to allow HDSM to stream high quality region of interest video back to the console based on the original high resolution image.
The webinar was obviously geared towards promoting Avigilon's product strengths, but listening to the entire presentation was still informative and the presenter knowledgeable, made particularly evident during the 15 minute or so Q&A at the end.
Undisclosed, help me out as I'm only finding 3 three things on Av's website that explain HDSM, one vague overview, one vague video and one much more detailed white paper which for me raises more questions that it answers, in addition to the fact that a large part of it is touting how HDSM and JPEG2000 are a marriage made in heaven.
I don't claim to be an expert in video transmission/compression technology. All I know well is what I've got, a mid-size COTS system with 24 channels on a version of ONSSI so old they don't even consider me a customer...
But I do know its got some middleware called an Image Server that I assumed composited the higher-def feeds into a single client stream that was no bigger or smaller than it needed to be based upon the windows and their current sizes/zoom level on my client, all while recording the ind. high-def streams to my drives. I never questioned this because it seemed so obvious. Buf after reading the HDSM paper, I'm confused and think either my system doesn't do this or HDSM is doing much more than this or both.
Basically, Avigilon is a me-too company now. First, they came out with a scaled down VMS now this. They are following Exacq and others that were true innovators. Watch them come out with NVR appliances next. Milestone is doing the same thing with the Husky line, just another me-too product. I find it interesting that the bigger manufacturers either copy smaller companies or buy them. The larger players fail to be innovators in today's climate.
As for this release, a 16MP, high quality, H.264, 10fps would be rare, if not unique, for surveillance.
On the other hand, lots of manufacturers are gearing up for 4K / 12MP camera releases at ISC West. Those will besimilar resolution, similar frame rate, H.264 but open cameras. That's going to be a lot harder for Avigilon to defend against. Surely they will emphasize the Canon chip / lens combo but that's still more nuanced than saying no one else has those resolutions at all.
Many software companies have been offering tiered product pricing/feature sets for as far back as I can remember...well maybe with the exception of DOS.
It just makes sense when clients have differing needs, otherwise they would never be able to capture a wide spectrum of the market who's needs they are trying to address, or would end up selling more advanced features for well below market value.
"be able to select only parts of each stream" sounds a bit like h.264 SVC (Scalable Video Codec). Maybe Avigilon use it? Anyway, it wouldn't be unique, as at least two cam manufacturers use SVC already. Problem as usual is the lack of support on VMS.
SVC H.264, even for camera manufacturers, has very limited support and even then it's typically for lower resolution cameras, not 16MP, etc. Also, one of the manufacturers that currently supports it, only supports the temporal / frame rate aspect of it, not the splitting up of segments/regions of a stream.
If Avigilon is doing full H.264 SVC on 16MP streams, that would be a huge breakthrough, though their marketing material does not point to that.
We discussed the Indigovision 5K / Ampleye OEM here. The downsides of the IndigoVision / Ampleye one is that it only supports H.264 for HD. To get the 20MP, or anything above HD, it's JPEG2000. To that end, the Avigilon has a bid advantage.
And if you really want an open JPEG2000 camera, might as well buy directly from Ampleye and not have to rely on IndigoVision.