My initial version ran into this. I ended up looping the entire process (excluding finding the media port). Each channel will reconnect to control and media then start the stream.Phoenix84 wrote: If you can see your cameras in ffmpeg, you should be able to see them in Zoneminder. However I noticed an weird behavior with ZM that I had to adjust for in the program.
ZM will disconnect and reconnect frequently when it starts to stream. Sometimes this confuses my program and it exits.
I adjusted for this by making sure all children are automatically restarted if they exit for some reason (unless the parent is terminated).
However this change is only in the latest version I just posted, 0.4.
If possible, see if you can add your changes into that version. You've already done the hard work by figuring out the login steps.
If you want to confirm this behavior before proceeding, you can do the following:
After starting the program, execute 'pgrep zmodopipe' or 'ps -A | grep zmodopope' to get the PIDs. You should see # channels + 1 processes (so if you only stream one channel, you'll see two processes).
Now, restart zoneminder and wait about 30 seconds, then execute the above pgrep/ps command again.
If one or more processes disappeared, or the PIDs changed, then that might be your problem.
I tried experimenting with the command-line options in the ZM settings, but I didn't notice any difference.
I've done a little more exploration, and it seems like it might be related to the initial probe by zoneminder on the stream not being able to detect what the stream is. I'm looking
at some of the code in zm_ffmpeg_camera.cpp I believe and it is trying to probe the pipe and getting confused. I noticed this with ffmpeg as well. It can't probe unless I tell it
-f h264. Once it knows that, it can ascertain the resolution, fps, and whatnot. I started playing around with doing an additional pipe to ffmpeg after zmodopipe and writing
that to a pipe that zoneminder can look at. I initially did some testing of ffmpeg grabbing the pipe and writing to a file and that worked fine. I could pick up the pipe with ffmpeg
with -f h254 and output to a file with an .mp4 extension and then play the file. The problem is, I can't pick up the pipe from ffmpeg and write to another pipe. I'm kind of
clueless with ffmpeg and it seems to be because it can't put in a header and start writing the data (pipe related?). I thought I might be able to write the pipe with a different format
but can't seem to get the correct set of flags to write a simple mpeg stream or something else. While not ideal, I wouldn't mind piping through the two (zmodopipe and ffmpeg)
and then having zoneminder grab the final converted pipe. It seems like the stream I'm getting from the zmodo is full of all kinds of things that ffmpeg doesn't like, so I'm thinking
I can send it once through ffmpeg to clean it up. Again, not ideal, but I really didn't want to go through the trouble of recompiling zoneminder components.
I've also alternatively been looking into compiling zmodopipe to scrub the stream with ffmpeg and just outputting the cleaned up stream to a pipe output and then letting zoneminder
read this pipe. I'm looking through some exmaple libavcodec code to see if it's worth the trouble. A simple test to see if this is gonna work would be to get a working ffmpeg
command line that is something along the lines of ffmpeg -f h264 -i /tmp/zmodo0 -f <probably mpeg or something simple> <all the output stream parameters> /tmp/ffmpegpipe0
When I try that pipeline with ffmpeg -f h264 -i /tmp/zmodo0 -f h264 /tmp/ffmpegpipe0 it complains about not being able to write the header (I'm not sure of the exact error, I'm not
at the box at the moment). I'm assuming there are different containers and whatnot that are conducive to streams (pipes) as opposed to files due to using random access or other factors.
network analyzing/apk decompiling
