ufoid / ufo-detector Goto Github PK

The program crashes most of the time after selecting & saving the detection area xml file if the selected area has more than around 800'000 points. The file is still saved successfully. Program crash happens after the file is saved.

Refresh rate can be even something like 0.1 FPS or so. That's low compared to VLC which shows webcam video at ~24 FPS or more.

If you play around with the window size too much you get some interesting results

The aspect ratio should always stay the same

It would help when supporting user that experience problems when recording a video if there was an option in the settings to test the video recording.
Something that writes a 10 second (to check framerate / lag) video with the selected codec in the selected folder.

Sometimes when the app crashes or has other problems it leaves temp videos in the video folder. I suggest there should be a feature to recover the temp videos fixing the video name, checking the result data file, and generating a thumbnail image if it was missing. Related to #21, #22, #23.

The issue is with the mockVideoBuffer class. In both my windows and ubuntu environment. I keep on getting a similar error.

I run the test using make check

videobuffer.o: In function VideoBuffer::capacity()': videobuffer.cpp:(.text+0x0): multiple definition of VideoBuffer::capacity()'
mockvideobuffer.o:mockvideobuffer.cpp:(.text+0x50): first defined here
videobuffer.o: In function VideoBuffer::count()': videobuffer.cpp:(.text+0x10): multiple definition of VideoBuffer::count()'
mockvideobuffer.o:mockvideobuffer.cpp:(.text+0x40): first defined here
videobuffer.o: In function VideoBuffer::stopWait()': videobuffer.cpp:(.text+0x20): multiple definition of VideoBuffer::stopWait()'
mockvideobuffer.o:mockvideobuffer.cpp:(.text+0x60): first defined here
videobuffer.o: In function VideoBuffer::VideoBuffer(int, QObject*)': videobuffer.cpp:(.text+0x30): multiple definition of VideoBuffer::VideoBuffer(int, QObject*)'
mockvideobuffer.o:mockvideobuffer.cpp:(.text+0x0): first defined here
videobuffer.o: In function VideoBuffer::VideoBuffer(int, QObject*)': videobuffer.cpp:(.text+0x30): multiple definition of VideoBuffer::VideoBuffer(int, QObject*)'
mockvideobuffer.o:mockvideobuffer.cpp:(.text+0x0): first defined here
videobuffer.o: In function VideoBuffer::pushFrame(BufferedVideoFrame*)': videobuffer.cpp:(.text+0x110): multiple definition of VideoBuffer::pushFrame(BufferedVideoFrame*)'
mockvideobuffer.o:mockvideobuffer.cpp:(.text+0x70): first defined here
videobuffer.o: In function VideoBuffer::waitNextFrame()': videobuffer.cpp:(.text+0x1a0): multiple definition of VideoBuffer::waitNextFrame()'
mockvideobuffer.o:mockvideobuffer.cpp:(.text+0xa0): first defined here

Checking both the amazon and aliexpress sources, it appears that the IMX462 is no longer available. Do you have any plans to transition support to a different camera module?

Image scales OK when video is shown but when still image is shown during detection, it doesn't scale. It doesn't look nice so should scale.

When closing the program the UI closes but the process ufodetector continues to run with 0 CPU load. This seems to be new.

When web camera video is shown in the video view during detection, it has a lot of flicker.

Current icon is just a colored box...

I noticed that the video doesn't get written in Ubuntu 16.04.1 LTS. OpenCV version is 2.4.9.1. Version 3 is not available in the normal repository. Only a header 5686 bytes long gets written.

It might be possible to bypass cv::VideoWriter by writing video with Qt Multimedia framework or GStreamer which is the backend of the multimedia framework and possibly also the backend of OpenCV.

Properties like CAP_PROP_FRAME_WIDTH won't be found when compiling with an older version of OpenCV.

AFAIK the binaries that come with libopencv are always < 3.0 which is unfortunate.
I think the readme should be updated to require a build of 3.0 or higher

Currently the app needs to be restarted to load changed settings. It would be better from usability viewpoint to apply the settings on-the-fly.

Currently UFO Detector only detects bright objects. Add detection of dark objects, too, as many UFO's look dark, e.g. the so-called black triangles. This means more requirements for the detection algorithm as normally dark-looking objects like birds must then be distinguished.

• When starting the program, show the newest video. Currently the oldest is shown.
• When new video is added, scroll video list to show it
  • but if video list is somewhere else than on newest video, leave it there and don't scroll.
• Could also show the newest video on top.

Previously I ran my tests with ./testVideoBuffer/testvideobuffer -xml -o testvideobufferResult.xml etc
I would like to use the improved testsuite and simply call make check and also get the reports in xml.
How do I implement that in to testsuite?

Video recorder thread is started but the app crashes occasionally after that.
This applies at least to commit 15c8942.
Debug output:

"/home/***/Documents/UFO ID/Videos/Capture--2016-05-15--21-32-25temp.avi"
++++++++recorder thread called+++
*** Error in `/home/***/src/UFO-Detector/build-Detector-Desktop_Qt_5_6_0_GCC_64bit-Debug/ufodetector': free(): invalid pointer: 0x00007f0140000078 ***
The program has unexpectedly finished.

The video shown on the 1st line is the previous video and it's saved normally.
The recorder thread starts ok, and the next video is being saved in the video folder and can be found from there. The video has "temp" ending so the recorder doesn't finish the job.
Web camera video was being showed during this.
I don't know how this can be reproduced as it seems to happen occasionally.

Currently need to restart the app if camera is disconnected. CPU load goes to 100% when disconnecting. That seems to be due to image grab and/or copying thread continuing. Also there's no recovery after camera is replugged.

If camera size is set wrong in the settings, it causes segmentation fault in Raspberry Pi. Tested with OpenCV 3.2.0 which might have to do something with it. Setting correct camera dimensions in config file will run normally. Segfault doesn't happen in PC side (Linux) even if camera dimensions are incorrect (OpenCV 3.1.0).

The unit test of ActualDetector tells that bright objects are not always detected. In the current basic test a 10-pixel wide object moves across the screen in about one second. Detection rate is only around 50%. In this kind of controlled setup the detection rate should be 100%.

Detection algorithm parameter meaning will change when frame rate changes, making detection algorithm perform differently in different conditions. Frame rate changes due to automatic exposure time adjustment by web camera. If frame rate can't be achieved due to e.g. long exposure time on low light conditions, parameter values should be adjusted for changed conditions.

Sometimes there's video in the video list but nothing in the video folder, not even a temp video. This can be seen when clicking Play button in which case no video is found. Sometimes the thumbnail image is missing, too. I guess this might happen after application crash or if video recorder fails. Related to #21 and #22.

Currently the detection area file is point-based. Is there any important reason for that? I would suggest we changed it to polygon-based. There would be several benefits from it. Polygon-based file format would be faster to save and load. The file could be edited by hand (I'm thinking about CLI based usage). Polygons could be also managed by the detection area edit dialog much easier, e.g. there would be no need to re-define the area each time and it would be possible to edit the polygon in the editor.

At the moment video recording starts at the same time than the positive detection. It would be really nice if the recorded videos started a few seconds before the actual detection. That would be good for the user and the detection algorithms development. This feature would imply using frame buffer.

Guys, please add build/compile instructions to main README.md.

Especially how one can compile and run it under Ubuntu (that can be on Pine64, Raspberry Pi or other ARM based computer).

Detector thread is started two times which causes problems. Starting the thread the 2nd time will take some time after program start. I added debug message to the places where it is started and got this in output (these lines are together, nothing cut away from between lines):

ActualDetector::start(): Starting detection thread
started normal thread
ActualDetector::checkIfNight(): Starting detection thread
started normal thread

As a result, the app will jam eventually taking 100% CPU time and UI becoming unresponsive.

Hi!

When running it I get the following error:

Starting
[21:19:38 debug] - Config file already exists, not overwriting
[ WARN:[email protected]] global ./modules/videoio/src/cap_gstreamer.cpp (1405) open OpenCV | GStreamer warning: Cannot query video position: status=0, value=-1, duration=-1
[21:19:38 debug] - Creating recorder
[21:19:38 debug] - "Running on http://127.0.0.1:8080/ (Press CTRL+C to quit)"
[21:19:38 debug] - Server created
[21:19:38 warning] - "Error reading the detection area file /home/djtarki/Documents/UFO ID/detectionArea.xml"
[21:19:38 warning] - ERROR: Could not read detection area file
[21:19:38 info] - Detector failed to start
terminate called without an active exception
Aborted (core dumped)

I'd love to have this fix so I can test this very promising tool!

Thanks.

PS: Adding the steps I followed trying to make it work on laptop running Ubuntu
UFO_Detector_Installation_On_Ubuntu_Laptop.txt

Under heavy load, although the program works correctly - my computers memory will fill to 100% and the UFOID crashes - this only occurs when using higher resolution sizes like 1600x1200

It seems to be possible sometimes that result data file closing or some other operation fails for some reason, causing problems for the next video recording. I was testing the app by moving the web camera to get detection results. Here's the debug output:

++++++++recorder thread called+++
00:25
finished recording
failed to load the result data file 

++++++++recorder thread called+++
" pos: 0"
"/home/***/Documents/UFO ID/Videos/Capture--2016-05-15--23-09-23temp.avi"
00:09
finished recording
QFile::setFileName: File (/home/***/.UFO ID/logs.xml) is already opened
correctly loaded root element from result data file 

" pos: 0"
"/home/***/Documents/UFO ID/Videos/Capture--2016-05-15--23-09-49temp.avi"
++++++++recorder thread called+++
00:04
finished recording
correctly loaded root element from result data file 

" pos: 0"
"/home/***/Documents/UFO ID/Videos/Capture--2016-05-15--23-10-00temp.avi"

Repo name is UFO-Detecor, should be UFO-Detector

Faulting application name: Detector.exe, version: 0.0.0.0, time stamp: 0x5905f510
Faulting module name: ucrtbase.dll, version: 10.0.15063.413, time stamp: 0x5ba8b66e
Exception code: 0xc0000409
Fault offset: 0x00000000000734be
Faulting process id: 0x3024
Faulting application start time: 0x01d31213919ffb15
Faulting application path: C:\Program Files (x86)\Detector 0.7.7\Detector.exe
Faulting module path: C:\WINDOWS\System32\ucrtbase.dll
Report Id: 328feb0c-eb99-4332-9282-027f160a277a
Faulting package full name:
Faulting package-relative application ID:

UFO detector crashes frequently leaving this error message, its usually the same one involving 'ucrtbase.dll'

Also I would like to thank you for this fantastic Project! I wish more than 2 people were working on it.

My Computer Specs - Windows 10 x64 - AMD FX-8350, ATI R9 200 Series Graphics Card, 32 GB of RAM and an NVEM SSD for my system drive that detector.exe runs on. The only operating system Detector is stable, on my computer at least is on Windows 7. Also if the program is run in compatibility for Windows 8, it works a lot better for some strange reason.

Thanks

In settings dialog, closing any file name selection dialog will erase current file name even if no file was selected. The current file name should only change when a new file was selected.

For independent observation stations, board PC's like Raspberry Pi, background running etc. it would be nice if the app had a command-line interface / headless mode. That should be relatively easy to do. This shouldn't be a fork from UFO-Detector, but would be best done by just adding a new Qt project next to the current one. The engine would be the same, just the UI layer would be different. This feature is probably not on high priority but would belong to nice-to-have category. Raspberry Pi is probably an exception.

Currently only some of output text, messages, and dialogs are localized. Should convert all UI text localized (using tr()). Debug messages shouldn't be localized.

Video is saved but it is empty. I guess this only happens in Linux. Probably it has to do with the fact that Linux uses avconv for video encoding.

If you look the videos from http://ufoid.net/community, many of them are jerky and the speed of the moving object is changing back and forth, for example in this video: http://ufoid.net/videos/UFO-bright-flying. I suspect the frames were written to the video in a non-constant way, that is, not at the specified FPS rate.

I know the moving objects might move in a jerky fashion, but the videos just look like they were recorded in a non-constant fashion. I would like to be sure of this by adding some robustness into the code.

Video frames are not read in accurate times in Recorder class, that's probably one problem.

It might happen that the web camera exposure times are too long to be able to get correct FPS. For example, from the source code of a common Linux webcam driver spca5xx you can see the exposure time can be even 1/4 seconds. Well, in that case one might just write the same frame many times to gain correct FPS.

One way to check this is to add a diagnostic counter into Recorder to count the frames which were not written to video in time. Increasing the priority of frame reader and writer threads might help, too.

I ended up with a corrupted result data file for some reason. DataManager needs to be tested better for that. The result data file was missing few characters at the end of the last <video> entry, as well as the last </UFOID> tag.

The problem is the application doesn't care about the corruption but just continues. I didn't test what happens if more entries are added to the file when it's corrupt, but I'd guess it's not too nice to watch.

The desired action would be that the app would show an error message, asking whether or not to fix the file. If the user chooses to fix the file automatically, the app should try rescuing as many entries in the file as possible and as many videos & thumbnail images as possible, and give a report about what was done.

Lightweight approach would be to just give an error message explaining the situation and quit.

Hello there,
First off, ucrtbase.dll is causing multiple crashes of system upon positive detection. Worked more or less a couple of days but now software exits with error on each positive detection. Might be related to resolution wrong setting?

Also, user File detectionArea.xml is not created within user directory by install program, and removing program under Win 10 isn't resetting configuration (No traces left in registry??)

CCTV cameras are not supporting a pixel resolution / definition so to speak but a number of lines. Would be pretty cool if the resolution settings would also be settled in lines, for simplicity meanings. Also, the "check reported resolution" never worked with a composite camera plugged to some cheap A/D stick.

Windows 10 64b, Runcam Owl CCTV 700 lines camera, VideoDVD A/D converter (cheap STK1160).

Thank you for that unique piece of software, I already donated a couple of $$$ :))

Some camera models such as old Logitech QuickCam have brightness auto-adjustment which causes night detection to give incorrect result.

Editing would be easier in the detection area editor if there was zoom in/out feature.

When detection is started and video is not shown during detection, the camera image may sometimes show only black. The fact it only happens sometimes would imply some thread problems.