Video wall realtime monitoring in 30fps

jknapp0011
Conversationalist

Video wall realtime monitoring in 30fps

The common complaint that I am getting from users is that the cameras are slow. Meaning that by the time they see the person on the camera the're already at there destination 10 to 15 seconds before it shows them there. It would be extremely nice to have the camera's stream 30 frames per second to the video wall. Is anyone else getting this complaint?

10 REPLIES 10
PhilipDAth
Kind of a big deal
Kind of a big deal

Yes @jknapp0011.  I had it kill a deal for a camera on trial because of this.  They were only using one camera.

 

We opened a case with Meraki support.  We managed to get the delay down to about 7s in perfect circumstances, but not good enough overall.


@PhilipDAth wrote:

Yes @jknapp0011.  I had it kill a deal for a camera on trial because of this.  They were only using one camera.

 

We opened a case with Meraki support.  We managed to get the delay down to about 7s in perfect circumstances, but not good enough overall.


What did you change/tweak?

BHC Resorts IT Department
MerakiDave
Meraki Employee
Meraki Employee

What you are experiencing is the HLS delay (HTTPS Live Streaming) which is normal and results in about a minimum of 4 to 5 seconds of delay because HLS turns the live video stream into a set of 2-second chunks and does sequential HTTP-based file downloads, and needs at least the first 2 chunks (about 4 seconds) to begins the streaming process.  Meraki has optimized HLS for MV quite a bit, I believe it was originally well over 15 to 20 seconds.

 

The trade-off is that Meraki MV is extremely intuitive and simple to use, natively traverses any firewalls or proxies that allow HTTP in the first place, and requires no special software or browsers or specific Java versions or plugins or ActiveX controls or any of that.  It's pretty much any browser on any device on any operating system and you're working with the full power of MV.  

 

There is a setting that can help just a little, change the quality setting on the "Quality & Retention" page from Enhanced to Standard and this can shave off 1-2 seconds.  This can slightly change the way the video is encoded as the stream gets split into files for the HLS stream.  This setting can be camera by camera as well, so if the camera is zoomed in for identity of someone being buzzed in through a doorway, the quality may not matter much but the extra 1-2 seconds can really help whoever needs to see who is standing there before buzzing them in.

 

Unfortunately there will always be some HLS delay (remember the tradeoff: powerful, simple & intuitive with no special software or plugins) and it's already been optimized about as much as it can be.  If it were to be optimized even further, it would introduce a lot more overhead, such as more numerous smaller video chunks therefore a higher percentage of protocol overhead, and could also introduce more of a chance for choppy video playback.

 

So be aware that users will have that perception that the cameras are just plain slow, they wave their hand in front of the camera and see it in Dashboard 6 to 8 seconds later and say "see how slow it is" but once they understand the architecture and the benefits and the reasons why there is a lag time, the HLS delay is typically an acceptable tradeoff.  

 

All that said, it doesn't fit every single use case.  Please continue to make wishes in Dashboard and share your use cases and requirements with your Meraki or Meraki Partner reps so they can filter these back to the product team to consider and prioritize feature development.

 

Suggested fix - dump HLS.  Use HTML5 video streaming and WebRTC - it was designed for exactly this job.

 

Second suggested fix - start by sending 100ms chunks doubling each successive chunk until you get to 2s chunks and then use 2s from there onward.  Personally I think any extra time spent working on an HLS solution is time spent working on the wrong solution ...

 

 

I like this quote from YouTube engineer Richard Leider:

https://www.theverge.com/2015/1/27/7926001/youtube-drops-flash-for-html5-video-default

 

 

"Leider called out HTML5's adoption of Adaptive Bitrate (ABR) as key in its switch. YouTube says ABR, which lets the site change resolution for viewers based on network quality, has reduced buffering by more than 50 percent globally, and by as much as 80 percent on heavily congested networks. The technology also lets people live stream their play sessions on Xbox One and PlayStation 4, and use streaming devices such as Chromecast. Also important was HTML5's support of the VP9 codec, which gives higher quality video at a bandwidth reduction of 35 percent, and new APIs that let YouTube show fullscreen videos with standard HTML UI."


@PhilipDAth wrote:

Suggested fix - dump HLS.  Use HTML5 video streaming and WebRTC - it was designed for exactly this job.

 


Bingo.

BHC Resorts IT Department

Does anyone know if any progress has been made on this.  We are doing an installation 800+ cameras for a school district with large displays in the Principal's Office with Video Walls.  Constantly getting the complaint on the cameras shooting the front doors and hallways as having a 5-7 second delay on the dashboard.  They had old analog cameras and they love the clarity and ease of use of the meraki cameras but I always get well the old cameras never had a delay.   

 

Any advice or suggestions in appreciated.  Gonna try that Enhanced to Standard setting and see if that helps.

MRCUR
Kind of a big deal

@Wibster73 Firmware version 3.8 added "Adaptive bitrate HLS stream". It doesn't seem to help a ton with the latency however, which I think is just inherent to the use of HLS. Changing the quality of stored video also doesn't change the latency. For now, they will have to get used to the delay (which our users have in a K-12 environment). 

MRCUR | CMNO #12
PhilipDAth
Kind of a big deal
Kind of a big deal

@MRCUR is right, the issue is HLS.

 

HLS sends data in 2s segments, and the receiver needs 3 segments before than can start display video.  So that creates a minimum of 6s of delay.

Thank You very much for your response @MerakiDave. Being a customer and a person that offers solutions to others I can tell you the delay is not acceptable. People/customers that want cameras in places generally want to know whats happening in real time. Seconds count when it comes to the safety of things. It's great that something is simple and easy to use, but if it doesn't do the most important primary function that I need it to do what use is it to me (Be the eyes in real time where I can't be)? And if I had to guess people in the industry that do this for a living would probably agree with me as well. 

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.