Aug 2, 2013 Friday Updates

• The Hawk Technology post 1st draft is here: MOVED Hawk Technology Patent Suits Target End Users
• I wasn't able to get a hold of any lawyers for the Hawk post today to see if either of those dismissals involved settlements.
• Word back from Burger King people is that the contract exists, but they're going to release any details about it.
• I'll spend most of Monday morning making follow up calls and then looking at the DR RFP and writing that up.
• Interview the guy on the 3VR stuff at the hotel is Tuesday

Wrote an update about programmable relays for unique surveillance and access control applications.

attended the study hall, learned a lot.

Wrote a post on Salto.

Talked to Jack Sink about the Burger King/Polaroid deal, but very quickly determined he didn't know any relevant details, and just spent most of the phonecall regretting ever calling him.

I'm monkeying with my door now. I am spending Monday morning filming our overview.

• Upgraded firmware on Q-See NVR and connected a multitude of different cameras to it. Only camera we had difficulty connecting was the Sony VB-600.
• Started color / pattern bandwidth test, but the colors orange and yellow were turning out greenish/brownish on stream. Took screenshots, but did not measure those colors. Also noticed the "burning" or ghosting of previous patterns on stream & recorded footage and exported a quick clip of it (want to see if it happens with all cameras. Only showed up severly on the Bosch NBN-733).
• Cropped images for bandwidth report (will finish on Monday).
• Looked over bandwidth measurements with Ethan and Figen and analyzed differences/patterns.
• Study Hall, which, according to Brian, my questions failed, and for that, I apologize. I'll bring out the big guns next Friday ;)

Took the point source and Q1604 home with me and I'm going to test WDR On vs. Off in a few more scenes at max/min sharpness this weekend, and measure it's effect on bandwidth. Really curious as to why in some scenes, WDR Off was saving more on bandwidth, and sometimes WDR On saved in others.

lol

Went over bandwidth data and further organized the spreadsheet. Then, analyzed the results with Ethan and Derek.

Shadowed Derek during upgrading of the QSee NVR firmware and checking whether ONVIF cameras can work with it.

Set up the color and pattern / bandwidth test and performed a few measurements with Derek.

Enjoyed the Study Hall.

I edited Carlton's post on Hawk Technologies - very fascinating. A couple of things:

• You have to try to understand the specifics of the patent. Hawk basically has a patent on MULTISTREAMING! We have to properly explain this plus it makes it a stronger patent. I'll do it for this post but keep this in mind for future reports.
• Make sure to add links right away up top to the company and any individuals you reference
• Hawk's claim that "Analog systems would not apply, he said because the patents deal with digital recording." A analog camera to a DVR certainly would apply. Only a pure analog system would not (i.e. a VCR).

Wait a minute- what?! I'm reading the articles/docs now, but had to comment first...so I can get sued for writing a multistreaming article, since I tested the multistreaming features in all of these VMSes, essentially.

Also, should the article link to multistreaming and what it is?

Btw- sorry about the omitted Friday daily report: I finalized most of the videos (7)... today finished the article and added one more video and some images.

I am going to write a new section explaining the patent and its relationship to multistreaming. My understanding from reviewing the patent and reading the interview is that they are checking end users to determine if they are watching video at a different stream setting than they are recording (either by watching multiple streams or recording at a different stream). If they are, then Hawk will claim they are violating their patent. Theoretically, the end user could simply say or choose to only view and record at a single stream size. Of course, this is a big problem for people using megapixel, ergo why they likely sued Avigilon first.

Bottom line: I think this is going to be a serious mess. At least with analytics people have and could continue to ignore. Not so with multistreaming. OR they switch to transcoding but still a mess.

I'll update here when I've added that section later today.

One additional note regarding this: "Schwab believes targeting end users benefits everyone involved and avoids long drawn out lawsuits." meaning he won't go after the big companies because they have great lawyers and it will be drawn out, go after the little guy.

What he failed to consider is that this little guy and others can actually create mass number of class action law suits targeting the VMS manufacturers for providing a VMS with this feature enabled (nothing in EULAs transferring liability) without informing the end users they are doing something that's either unlicensed or illegal- crazy, crazy, crazy. How can they be allowed to patent an inherinet capability such as this? Is it the patent's office fault for not truly understanding the technology and the variables involved to making multistreaming work?

Plus, how the heck can he do this: "they are checking end users to determine if they are watching video at a different stream setting than they are recording"

It will be a great debate!

I added two sections to the post - MOVED Hawk Technology Patent Suits Target End Users

To Sarit's questions:

• in terms of how will they know, they'd likely target customers of VMS manufacturers who emphasize the use of multistreaming (like Avigilon)
• in terms of manufacturers getting sued by customers, this might happen or at the very least the threat of such lawsuits and uproar from end users being sued ("i bought this VMS from you and now I am being sued for a function you included") is going to put a lot of pressure on manufacturers

I'm sorry, I typed up status on Friday and forgot to hit the "post" button, and have gone since Friday evening.

• The bandwidth report's key findings are in. After looking though spreadsheets of measurements, we boiled it down to averages, which were surprisingly consistent across multiple settings and FOVs.
• I started fleshing out some of the sections, as well. Tomorrow we will have image comparisons which support the key findings, which I've already gone over with Derek, so they can be inserted and this can be wrapped up.
• This test took a lot of analysis. The data is so spread out it took more time than expected to get through those findings. Thanks to Figen for putting together some of this in an easier to read format.
• Did some work on Q-See, enough to get cameras connected.
• Discussed and set up color/pattern test with Derek and Figen.

Tomorrow will be nothing but bandwidth report til it's done. Q-See, VMD 2.1 are on deck.

Ok, make sure to call out any cameras that deviate significantly from the average for each scenario/test. For instance, if the mean was +30% for a certain test but 1 camera was -5% and another was +80%, those both should be noted.

Also, we need to offer theories why.

I have started analyzing camera-to-camera bandwidth variations with a new sheet in here.

A few things I have noticed so far, open for discussion:

Changing from wide to narrow FOV, I can not see a clear pattern of bandwidth changes considering different scenes.

In the intersection scene, all cameras had an increase in bandwidth. Although most of them increased by about 50%, Avigilon and Bosch showed about 10% increase. However, for the other scenes, results are less consistent from camera to camera. For the track field scene, two of the cameras, namely Avigilon and Axis M1144, experienced about a 20% drop in the bandwidth from wide to narrow, while all others showed an increase (including a 64% increase with Bosch). The park and indoor results also differ a lot from camera to camera. Among all tested cameras, only Axis Q1604 (both WDR on and off cases) experience an increase in all of the scenes.

The narrow and wide FOV measurements were taken at the same FOVs for all cameras at each condition. Therefore, there should not be a major issue coming from FOV differences between cameras. However, there can be a slight difference in the measurement time of each camera. Do you think this can have a significant effect? What should be the recommended time interval to make the bandwidth measurement more accurate for each scene?

For the sharpness effects on bandwidth, I think we have more consistent results.

Overall, sharpness seem to have considerable effects on bandwidth.

Axis Q1604 has the highest range of bandwidth changes with max and min sharpness measurements. This is consistent for all scenes and also "WDR on" case although it helps reducing the bandwidth a little. Then Sony and Dahua seem to be affected the most after Axis 1604.

I think the min and max sharpness levels for each camera can be corresponding to different levels which may be causing these differences in the bandwidth.

This is the rough analysis before we discuss in more detail tomorrow.

Please let me know if you have any questions.

Contrasting to Images

First of all, we have to LOOK AT IMAGES when discussing bandwidth. Otherwise, we are blind men touching elephants.

Let's figure out the best way to connect together but one immediate way is to add a comment for the bandwidth measurement that links to the image.

We HAVE to compare numbers to images so we can spot trends. Maybe all the images where bandwidth decreases show a notable decrease in visible quality or maybe those images have less detailed objects inside.

Has anyone done this? Because this is MANDATORY.

FoV Bandwidth Variations

I ran an average, per camera, of the percentage variations across each scene:

The numbers are all over the place. Indeed, even for certain cameras, across scenes, the numbers vary crazily. The M114 is down 84% wide vs narrow in one and up 65% in another. What's going on here? We need to look at the images.

FIRST CORE TAKEWAY

Regardless of what else we find (and we will find more once we compare images to numbers), we have discovered two interesting things:

• People recognize that different scene types make a difference (e.g., a stairwell requires less bandwidth than an intersection) but no one has ever argued that an intersection with wider or narrower FoV would make a significant difference. Our results show otherwise.
• Some recognize that camera manufacturer's bandwidth consumption varies but our results show they vary a lot.

The last part is to figure out WHY - What is causing these variations. There must be some patterns in the images corresponding to some changes in technology or low level camera settings that cause this.

After reviewing this, a couple of things:

• I updated the key findings. Instead of working from the averages, we broke it down per scene, so generally speaking, the intersection and track went up 30-40%, the park went down about 35% from wide to narrow. This is mostly due to details revealed in each scene when zooming in.
• The park actually ended up with fewer detailed areas than the other two in the tight field of view.

You can see that here, in the H3. The boxed in areas on the left had substantial movement, with less area in motion on the right.

In some of the scenes that were anomalous, I removed a camera or two due very fine focus issues. This was the Avigilon and M1144 in the track scene. In the park scene, also, the Q1604 jump substantially while others do not. This is because by default it's much sharper than others, and you see patterns in the grass, pavement, trees, etc., which you don't see in others. See this image: