search

UFOID / UFO-Detector

UFO Detector
http://ufoid.net/
GNU General Public License v3.0
54 stars 8 forks source link

Verify the source of video jerkiness #51

Closed hekkup closed 1 week ago

hekkup commented 7 years ago

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.

UFOID commented 7 years ago

Yes I have noticed that as well. I don't have any "jerkiness" with my test system but I can definitely see it in some of the submitted videos and it is an issue. Actually, I have experienced the issue with my system if the CPU usage is very high (from running other programs simultaneously). However, this only happens when recording HD video. Some of the submitted videos that show the jerkiness were not recorded in HD and I doubt a high CPU usage was the issue there. I am guessing it has something to do with the camera/driver as you mentioned.

I am not really sure how to go on about this issue. Yes, we could count the frames that where skipped when writing the video but we still need to know how to fix it. Giving the video writer and the frame reader priority as soon as the recording process starts could be a solution. At the moment I am not able to replicate this jerkiness consistently

hekkup commented 7 years ago

I have been doing some measurements and it seems the frame grabber and video writer threads are not functioning in optimal way. Frame grabbing as well as frame writing can take more time than FPS allows, which is one source of jerkiness. I tested changing thread priorities and it worked but that's not a good solution because it requires running the application as super-user at least in Linux. I guess there are other solutions like keeping track of missed frames. If frame reader thread is too slow then the writer just has to write the same frame again. Also frame buffering might be needed. I'll continue fiddling with this.

hekkup commented 7 years ago

There were some issues which commit 2057a4c addressed:

An issue remains, though: in low light the exposure time will be longer than FPS time so there will be skipped frames. BufferedVideoFrame.m_skippedFrames helps in that.

UFOID commented 7 years ago

I have seen some small but noticeable improvements when running a build using your commit on my system under heavy load. I will see if I can send a test version to some of the users that where having noticeable video jerkiness.