ozonesecurity
updated dlib to current master and ffmpeg to release/3.1
now that v4l is enabled on my build system I found some more renames necessary. I will add more commits to fix soon.
finally it compiles again. I did not know that it would show all these like this. Sorry for the mess
No problem, and thanks for your efforts. This sort of thing is generally the reason why we have fixed on particular releases or commits for submodules so far as otherwise one day it's all compiling fine and the next you hit all the sort of issues you have encountered doing this.
I am assuming this will live as an unmerged PR for now? Its important that all the changes actually also roll back to our existing stable release and they work well across all our examples. FFMPEG is notorious for breaking all kinds of things in newer releases. @phirestalker, I'll echo Phil's comments on your efforts - much appreciated. Once you go down the path of testing the effect of these changes, we can look at potentially merging.
I found that there are more libraries that need to be updated and will be working on that so I can run the example code. Should I go ahead and push those updates here (more cleanly of course)?
Also, is adding a few feeds to nvrcli and running for a few hours without crashing or "bugginess" considered a test?
Yes, please free to push here. And yes, given nvrcli is the most complex of all the examples, its a fair test
I ran nvrcli with no errors, but I'm not sure it is working properly. What does nvrcli normally do when it reaches the end of the Big Buck Bunny file? Is it supposed to stop processing the stream? it has been at least the runtime of the "movie" and my console is still outputting ret=0 c=0a [ ] over and over again. It has one output file, but it is only the mp4 header I believe with no streams.
I'm not sure how else to test it.
nvrcli is the "backend" server built on top of ozonelib. The front end of this lies in nvrcli_web. To test it, edit nvr.js to the IP address where nvrcli is running. Then open a browser, and double click on nvr.html and see if you can see all the streams.
I realize that. I ran it once before using the web interface and was able to see the streams. When the movie ended it seemed to just hang. Now I wanted to just let it run its course without using the interface, but I am unsure if it has an end. It seems it is stuck in a loop somewhere around line 1168 in ffmpeg's rtsp.c
with ret=0 and c= the same code each run, it would seems the stream ended, but it is still trying to read it?
yep - I don't recall whether I handled end properly or not in the example. If the videos are playing properly and you can see windows for person, face, shape detect, then it should be good.
This last commit has nvrcli running and streaming to the interface. It was also able to successfully record events. When watching it in the interface, it seems to get stuck just a second before the end of the stream. I am not sure if it is the streaming platform or something in the example.
@web2wire any thoughts on why the FW gets stuck before the stream ends? It looks like a core lib issue. I know we had issues around this a while ago, but not sure whether we resolved it.
@phirestalker is this ready to review/merge from your side?
This branch fails to render video on OSX - either using nvrcli or example_osx (example_osx crashes). Needs further investigation.
Luckily I have OSX, I guess I should have tested both. I will look into it.