Milestone VMS Adds H.265, SVQR, RAM Video Optimization

By Brian Karas, Published Sep 09, 2016, 10:07am EDT

Milestone is rolling out enhancements to XProtect to support H.265, enhanced edge recording functionality, and potentially allow users to reduce hard drive wear and tear through a new video buffering design.

We spoke with Milestone to get details on this release, where users will see benefits, what is limitations are, and how it will impact the market.

*******

** ***** ***** ******* [link ** ****** *********], Milestone ****** ******* *** features *** ******** **** R3 ********, ******* * in ********** ***** ***:

  • *.*** ******* *****
  • **** - ** **** recording ***********
  • *** ***** ********* - reduced **** *** **** on **** ******

H.265 ******* *****

********* ** ****** *.*** decoding ******* **** ** their ****** *** ********* platforms, *** ****** **** for *** **** **** no ***** ** *** H.265 ******* ** *** of *** ***** ******** versions. **** **** ************* limit *** ************ ** H.265 ** ********* ***** without ****** ** ******* to *** ***-**** *********.

********* ***** ******* *** Axxon ** *** * open ***** ** **** that ******* *.***, ****** Genetec *** ***** ******* H.265 ** *** ****** of ***** ********. **** move ** ********* ******** more *********** ** *.*** and ****** **** ***** support *** *.*** ***** camera ************* *** ***-*****.

********* ***** ******* *** Samsung ** *** **** tested/supported ******* *********, *** expects **** ** ** added **** ****. ****** other *.*** ********** **** claim **% ********* *******, Milestone **** **** ****** a **** ************ **-**% actual *******/********* *******.

*** ** *** **** intensive ******* ************ *** H.265 ****** ********, ********* recommends **** ****** ************ have ******** ****** ******* for *.***, ******* **** it "****** *****'* **** in *** ****".

Smart ****** **. *.***

********* ****** **** *** position **** *.*** ***** CODECs ***** ***** ****** overall ********* ********** ** compared ** *.***, ******* requiring ******** ** ****** machines.

SVQR - ******** ***** ******* *********

**** ****** ** ******* with *** ******* ** record * **** ********** image ****** ** ** SD ****, ***** ******* a ****** *** ********** stream ****** *** *******. With ****, ***** *** deploy ****** ******* **** no **** *** ** on-site ******, ********* *** low-res ****** ****** * network ** * *********** recorder, *** **** ******** segments ** *** ****-*** stream ** *** ** card ** ******.

********* **** **** *** be ********** *** ****** cameras **** ******* ********* ***********, or **** *** ******* that *** ** ************ from * ******* ************, such ** ******* ** transit ********, **** ****, etc. ***** *** ** pulled **** *** ** card **-******, **** ** when * **** ** investigating *********, ** ************* when ************ ** ********. Once *** ****-********** ***** is *********, ** ** stored ** ********'* ******** storage *** ******* **** any ***** ******** *****.

******* ********* **** ******* the **** ******** ** cameras ** * **** traditional "**** ****" **********, even ****** **** *** be ************ **** *** network ** *****, ** recording * **** ***** bitrate ***** ******.

**** ******* **** *** ability ** ****** ************ stream ***-********** *****, ** upload ***** ** *********, users *** ****** ***** from **** ****** ** the **** ****** ** any ***** ****** *****, which ********* **** ***** it ****** ** **** with *** ****** ** do *********** **************.

RAM ********* ** *****

********* ** ********* **** buffering ***** ** *****, to ***** *** ** buffer ******** *****. *****-***** ********* typically ******** * *** to ****** **** ****** of ***** *** * short ******** (********* ** seconds ** ****), ** case ** ***** ******* and *** **** ***** pre-event *****. ** **** cases, ****** *** **** unpredictable, *** ****, ******* to * *** ** data ***** ******* ** disk **** ** ****** overwritten ******* *****.

*** ******* ** *** buffering, ********* ** *********, is **** **** **** and **** ** ************ reduced, ***** **** ******* in ***** *** ******* savings, *** *** **** allow ***** ** *** standard ****** ******* ** surveillance-rated ****** *** *** disks **** ****** **** video.

*** ****** ** **** and **** ********* ** directly ******* ** *** much ******-**** *****-***** ********* is ****. ********* *** do ********** *********, ** rely ** ******-***** ****** detection ******* ** ******-***** motion *********, **** *** see ******** **** ****. Because **** ******* ** live ***** ******** ****, it *** ** ****** on ****** **** *** archive *****.

********* ** *********, ***** are ********* **** ******-***** motion ********* ** ******-***** motion ********* **** ***** XProtect, ** ***** ** take ********* ** ********'* meta-data ******* ** ***** for ***** ******. ***** users *** ****** ** see *** ******* ******** impact **** *** *** buffering ******.

Market ****** ********

**** *********'* *******, *.*** gains **** ********** ***********, but ** ***** ****** by ***** ****** ** terms ** ******* ********* savings *** ******* ************, a ***** ** ****** to ******** *** **** time.

****, ************ **** ******** on * ****** **** a ***** *****, ***** up **** ********* ** reduce ************** ********** ** remote *****, ** ****** cameras ** ********* **** may **** ********** *** been **** *********.

***** *** ***** ********* has ** ****** ****-****** impact, ** ****** **** reduce ******* *****, ****** in ***** ** ******* hard ***** *****, ** ongoing ******** *****, *** users **** *** **** to **** ********* ** it.

Comments (22)

Very helpful post, Brian. I know Hanwha (and probably others) are making smart codecs for H.265...did you get any indication as to whether those are supported in this latest Milestone update?

I did not ask about smart CODECs for H.265, but will ask about that and update with a response.

Thank you sir!

But does Milestone even claim to support h.264+?

It shouldn't need to do anything more than h.265 to support h.265+, just like h.264+ worked off of standard h.264 support.

I know that Milestone claimed to work with Zipstream a while back, though I'm not sure they actually did anything besides note that it worked.

It shouldn't need to do anything more than h.265 to support h.265+, just like h.264+ worked off of standard h.264 support.

In theory, yes, but I'd rather get an answer direct from them.

Yes, of course. Please ask about support for h.264 smart codecs as well.

We already know they support and endorse H.264 smart CODECs.

I didn't know that they explicitly supported h.264 smart codecs, besides Zipstream.

Which ones?

How long is video buffered in RAM for? And what happens in case of a power outage? I'm assuming video loss? It seems riskier than the live HDD approach.

Up to 15s, and it is configurable.

In theory, power loss shouldn't affect it. They're only buffering video that they do not know the final status of yet. Once it's known that video needs to be saved, it's written to disk, so for continuous recording or camera-motion this really does not come into play.

In the power loss case, you'd only lose video that was going to be overwritten later anyway, because if there was a motion event it would be sent to disk.

In any scenario, I'm not sure 15s of video loss is that critical, but if it is, you can turn this off and stick with HDD buffering.

And what happens in case of a power outage? I'm assuming video loss.

IMHO, worst case is that you could lose some pre-recorded video. But assuming the buffered video gets written to the disk the moment the event is detected, the exposure is only that window of time it takes to write the buffer to disk.

If your UPS isn't capable of 15 seconds of uptime, you need a bigger one! Lol

If your UPS isn't capable of 15 seconds of uptime, you need a bigger one! Lol

With a bigger UPS you would just lose the 15 seconds an hour later.

Wouldn't there be an orderly shutdown?

Yes there could be.

But it wouldn't save to disk any pre-event video because there is no event corresponding to it. (Yet)

On the other hand, even if someone were to pull the plug out of the PC without warning, the last x seconds of bufferred pre-record video would still be on the disk.

Somewhere...

Sorry, the sentence should read:

On the other hand, with the old way, even if someone were to pull the plug out of the PC without warning, the last x seconds of bufferred pre-record video would still be on the disk.

Panasonic is claiming Smart Codecs with H.265 post-ASIS. However, this was from a sales person so I give it a 50/50 of being true.

Vivotek H.265 + Smart Stream II

Are there any Milestone Corporate customers out there that are able to record pre-event video at a higher rate? Put another way, I'd like to record 1 FPS on non motion frames and 10 FPS on Motion frames including 3 seconds before motion occurred and 5 seconds after motion ended. So far working with tech support we were not able to accomplish this. We only have the higher rate starting at the motion event and 5 seconds after - not the buffered pre-event video which remains at 1 FPS.

I'd like to record 1 FPS on non motion frames and 10 FPS on Motion frames including 3 seconds before motion occurred and 5 seconds after motion ended.

Milestone says yes but it will require edge storage. Milestone notes:

With the upcoming 2016 R3 release (GA October 10) supporting SVQR, you can record at 1 FPS during non-motion times. On the VMD event he changes the stream to 25 FPS, and starts an edge retrieval which fetches the 3 seconds before in the 25 FPS quality. On the stop VMD event he defines that 5 second after it he changes to 1 FPS again.

John,

Thanks for asking Milestone about this. Having to add edge storage to each camera to allow for a pre-event buffer would be a giant effort in a large camera system. As your site reported a year or two years ago, SD cards have a relatively short life span (1-2 years).

This may be a topic for a stand alone discussion: Are there any enterprise level VMS that can utilize a pre-event buffer with H.264 compression without requiring edge storage by using RAM or hard drive storage to buffer the video?

I assume this means the edge storage has to be recording continuously at full resolution and 25fps.

Which will burn thru your local storage quicker than you might want.

Also, with the hq pre-buffer on the camera, someone pulling the cable out quickly might not get captured.

Read this IPVM report for free.

This article is part of IPVM's 6,817 reports, 914 tests and is only available to members. To get a one-time preview of our work, enter your work email to access the full article.

Already a member? Login here | Join now
Loading Related Reports