search

databrary / datavyu

Desktop video coding/annotation tool
http://datavyu.org/
GNU General Public License v3.0
27 stars 18 forks source link

Jog function skipping multiple frames and causing discrepancies between where the video is at and what the timestamp says #348

Open LDriggersjones opened 4 years ago

LDriggersjones commented 4 years ago

My team is working on coding multiple behaviors, such as gaze shifts, where we need time stamps to be accurate and we need to move slowly through the video to find the exact frame where the behavior begins. When we use the jog function to move slowly through the video (either forwards or backwards - but especially when jogging backwards) the jog will sometimes jog multiple frames without changing the timestamp, and at times, the timestamp quickly jumps to an incorrect time.

We are using Windows and DataVyu version 1.5.1

RickHuey commented 2 years ago

I'm using Windows and Datavyu version 1.5.3 and having the same problem. When Jogging backwards, it jogs a few frames and then the video freezes while the time indication continues to count down. I'd like to use this for the same type of coding that the original poster described, but there seems to be little agreement between the times logged from one pass through the video and the next. I tried coding blinks in a simple video and then using the find to jump to the correct location. Most coding was off by up to .5 seconds in that find function. Has there been any attention or progress on this problem?

JessLeov commented 1 year ago

I'm having the exact same problem outlined by RickHuey. The time codes are off between 0.5-1.5 seconds the timing is never consistently off. Are there any recommended fixes for this issue?

JessLeov commented 1 year ago

Hello, I'm posting this here in case anyone else encounters this problem in the future. This is the response I got from datavyu (hope it helps).

I see you’re using the FFmpeg plug-in on a Windows machine - it sounds like what you’re experiencing is a result of a known limitation on Windows that we’re hoping to fix in a future update. FFmpeg will force the video to seek to the controller timestamp to make sure that the time on the video, datavyu video controller and the cell are synced; the FFmpeg plugin has some discrepancies as a result of how this process is being done. We are working optimizing the FFmpeg plugin for different types of hardware and it should be improved in future versions (note, this is already not an issue in the native osx plugin available on Macs).

We have multiple users (including some of our own coders) who have reported this issue, so until we are able to fix the problem in a future update, we suggest the following “soft” fix: When you are creating a new cell, use the NUMPAD (+) right after you create the cell to make sure that that frame is the onset that you wish to use. If it's not the correct onset, use the jog function NUMPAD (1) or NUMPAD (3) to adjust the onset and set the correct onset using NUMPAD (7). Use the NUMPAD (+) again to double check the onset.

Repeat the process for setting offsets. Although this will cause a minor slowdown in the coding, this will get a closer result between systems and versions in terms of reliability. The time that is shown on the video controller is the exact time that will replicate on the spreadsheet, but it won't necessarily produce that time in video because of how Datavyu is set up. Therefore, if you were to create a cell at that time, and have Datavyu jump to that time, it will always show up correctly. Essentially, you are forcing Datavyu to show you the onset/offset you have jumped to._