[SOLVED] Mint 17.3 No video

[zamar17]

@bbunge

Thanks for pointing to that. As mentioned here, I lately reinstalled ZM. Before it didn't work with all setup exactly following your guide. After reinstall, I indeed forget to change this path - sorry. Now I changed it, and both cam pictures show up right away. I think, ZM install script needs update to fix that path.

Still getting this mootools error - what this package is used for in ZM? The package version is the same as on latest ZM ISO.

Code: Select all

2016-04-16 14:02:36.095954	web_js		15228	ERR	TypeError: e[c] is undefined	http://127.0.0.1/zm/tools/mootools/mootools-more.js	1

@ SteveGilvarry

Looking at ZM Github activity around IP Cam Onvif support, it was promised that next ZM release will incorporate it, including this project code. Most modern IP cams are now H264 RTSP, so Onvif support and Probe become a primary user requirement.

My TOP-201 Onvif IP Cam outputs H264 RTSP. If your viewer only captures jpeg or mpeg, does it mean my IP Cam stream is transcoded on-the-fly to be viewed thus consuming some CPU resources instead of being just decoded? Why there is ongoing disk activity when any monitor is open in the viewer - does it write to file the transcoded stream and then reads it to show pic? Can it write to RAM instead? What alternative viewers would you suggest to avoid transcoding, and what to change in WebUI to use them?

How I can check cams config strings with zmu command? I tried sudo zmu -d -q -v , but it shows syntax error. Is it possible to modify a Cam config string via Terminal rather than WebUI, and how?

[SteveGilvarry]

Yes as per bbunge in path_zms needs to match the ScriptAlias in Apache, so red text should be identical.

In WebUI:
PATH_ZMS Web path to zms streaming server (?) /cgi-bin/nph-zms

zoneminder.conf

# Remember to enable cgi mod (i.e. "a2enmod cgi").
ScriptAlias /zm/cgi-bin "/usr/lib/zoneminder/cgi-bin"
<Directory "/usr/lib/zoneminder/cgi-bin">
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
AllowOverride All
Require all granted
</Directory>

Alias /zm /usr/share/zoneminder/www
<Directory /usr/share/zoneminder/www>
php_flag register_globals off
Options Indexes FollowSymLinks
<IfModule mod_dir.c>
DirectoryIndex index.php
</IfModule>
</Directory>

<Directory /usr/share/zoneminder/www/api>
AllowOverride All
</Directory>

[SteveGilvarry]

With the number of people that actually contribute to the project on a regular basis being 4-5 volunteers we do what we can. The onvif code was merged to master and if I build it I get it, I know because I see a thousand perl files being built every time I build. I believe it is only probe at this stage using ws-discovery and then populating a monitor setup.

So Zoneminder core is old, it uses jpegs as the only method to store video. We are working on changing that, and I run a branch that stores h264, but as per above resources are constrained so when it will change we hope is next version. Back on topic as ZM decodes frames the image is shared with streaming, if that is active, using shared memory, no idea if streaming is what is writing to disk. There are no alternate viewers, well I guess you can just watch your camera in it's GUI.

Don't use zmu for anything so not sure what you hit there. Changing camera config might be possible via command line, but not something I do, zmc would need to restart.

I will be trying to spend some time coding this week so may not respond.

[zamar17]

as ZM decodes frames the image is shared with streaming, if that is active, using shared memory, no idea if streaming is what is writing to disk.

When cam footage is viewed in ZM Viewer (which is a Firefox tab), the browser actually uses decoded-reencoded stream H264-to-MJPEG to show camera footage - correct? May be this process requires to save decoded stream to a file and then read that file to re-encode the stream to MJPEG? Is it possible to move this process to RAM?

Similar issue was reported for Motion long ago, and was explained as "replacing the compress process, for jpeg images, from disk ( tmpfile() ) to memory." The patch was then merged, but I see similar disk load in Motion now when watching cam footage in web browser, or even in FFPlay standalone. It appears to be FFMpeg stream processing related. Disk load is very low when playing the same stream in standalone VLC using the same command to access the H264 RTSP IP cam. However, when using LibVLC source in ZM for the same cam, disk load is about the same as using FFMpeg source.

It looks like a significant drawback, and definitely needs more investigation what exactly causes ongoing disk writes. RAM is only half used, SWAP is almost empty, so something else is causing it. The disk load also seen on USB webcams playback via ZM. Do you observe the same issue? What settings would you suggest to change to eliminate it?

I managed the TOP-201 IP Cam preview to work with LibVLC as well by using the same command as with FFMpeg source, but a modified option:

Code: Select all

rtsp://192.168.1.218:554/user=admin_password=admin_channel=1_stream=0.sdp?real_stream

for FFMpeg: -rtsp_transport tcp
for LibVLC: :rtsp-tcp

[bbunge]

If you want to save some hard drive time change PATH_SWAP to use tmpfs. For Ubuntu 14.04 it should be /run/shm For newer versions it is /dev/shm

Many Linux systems use half of the RAM for tmpfs or, as it was called in the days of DOS, RAM Drive.

When you view a single camera, jpg files are written to PATH_SWAP (up to 999 of them before starting over). Using memory for this makes sense as it is far faster than writing to and reading from a mechanical drive.

bb

[zamar17]

I changed the path and restarted ZM and Apache. Disk tools still show ongoing disk writes when IP Cam monitor is open, about the same as before. Almost no writes when its closed. Is there anything else to change to eliminate these senseless disk writes? The problem is, when ZM is run from SSD or Flash on Raspberry, ongoing writes are going to harm the disk.