ZoneMinder Forums

I have a h264 pass-through stream (fullhd, 25fps), no saved JPGs. When i use live view in Browser (Firefox) i only get JPGs served to the screen. I'm on 100Mbit/s connection and traffic is hard on the limit (9,8MB/s) when viewing in 'high b/w' mode. Also, the browser's canvas (mouse over reaction) is very laggy. Playing with 'options/bitrate' doesn't have any effect but 'max fps' has. Reducing from 30fps->15fps reduces traffic to 6.7MB/s and the browser canvas is much more responsive. I'm not sure if its really 15fps because when i set it to 1fps its clearly 2fps instead (can be judged easily by comparing the hard branded date/seconds to the background mosquito noise updates).

Sometimes the live view stops for a second, the screen gets white, the log shows zms lost connection to the socket and a new connection gets established. Now the screen quality is noticeably worse. The double-pixel time characters are clearly blurred and the network traffic is quite low (maybe 2MB/s). I guess this is a higher jpg compression. This runs for some time then the game repeats and the quality is back up high.

How can i control that? How to set this low/high compression modes on purpose? I've played with bitrate/maxfps/highbw/medbw settings but it doesn't have any effect on the two quality modes described above.

On the other hand, when i play 'events' in the browser they are always on best quality without any lag or high traffic. I guess they are played as mp4 directly. Why is that not possible on live view?

ZM 1.34.5

Solution:
I have defined Misc/Default Scale to 1/2x so when i initially open the liveview the picture is 50% downscaled and Zoneminder does a good job here by reducing the image quality correspondingly. When i manually switch to 100% the downscaled picture gets upscaled as its still the same stream. That's what i called 'low quality' above.

Now, when i close liveview and reopen it (in the same browser session) the last (manually set) scale factor will be remembered (100%). And this time the stream was initially started with 100% and it gets pushed with corresponding bitrate (high quality). That's the critical point. How the stream gets initially requested. It is 'scale factor' dependent.