You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Given problems discussed in #33 from Prairie View's API giving us inaccurate framerates, which means that the video codec in bruker_control is using an incorrect framerate when writing video frames to disk. This will mean that any analysis that attempts to use the videos' framerate in the metadata will be incorrect and fail to align to the behavior data. This issue is to document progress on that.
Remux Videos to Appropriate Framerate
Once all environment files have their framerates validated as correct in #33, we need to remux videos to their appropriate framerates. This appears to have solved the problems originally addressed here. This was initially accomplished through this code and could be made to do it again with slight modifications for what it's searching for/what it's writing to.
Get list of videos that don't match the validated framerate from Prairie View environment files
Remux the video feeds with ``ffmpegsimilar to theffmpeg_subprocessing.py` but with modification to have the `-r` call both before and after the input video instead of just before which is what originally was done.
This modification is from Jonny Saunders' suggestion here
Reprinted in case social.coop goes down somehow:
In reference to remuxing videos where true framerate is different than encoded framerate:
well that sounds substantially more complicated and I'd sort of wonder what the importance would be- like if you have the frame timestamps then just use those when analyzing, I'm p sure you can also burn those directly into the timecode with some codecs iirc. otherwise, if the camera fps has extremely small jitter (ie. constant framerate) relative to what you're measuring then you use -r twice: once before the -i to set input fps, then again before the output.
Double Check That Remuxing (Still) Works
Again, it appears that this remuxing solved the problem with the video data initially after visual inspection through a couple recordings timestamps both early and late in the recording. But re-validating this will be important if for nothing else other than peace of mind.
Archive old videos?
The old/non-remuxed videos should probably be put in a different location in the raw folders for each recording, something like .archive maybe?
The text was updated successfully, but these errors were encountered:
Given problems discussed in #33 from Prairie View's API giving us inaccurate framerates, which means that the video codec in
bruker_control
is using an incorrect framerate when writing video frames to disk. This will mean that any analysis that attempts to use the videos' framerate in the metadata will be incorrect and fail to align to the behavior data. This issue is to document progress on that.Remux Videos to Appropriate Framerate
Once all environment files have their framerates validated as correct in #33, we need to remux videos to their appropriate framerates. This appears to have solved the problems originally addressed here. This was initially accomplished through this code and could be made to do it again with slight modifications for what it's searching for/what it's writing to.
similar to the
ffmpeg_subprocessing.py` but with modification to have the `-r` call both before and after the input video instead of just before which is what originally was done.This modification is from Jonny Saunders' suggestion here
Reprinted in case social.coop goes down somehow:
In reference to remuxing videos where true framerate is different than encoded framerate:
Double Check That Remuxing (Still) Works
Again, it appears that this remuxing solved the problem with the video data initially after visual inspection through a couple recordings timestamps both early and late in the recording. But re-validating this will be important if for nothing else other than peace of mind.
Archive old videos?
The old/non-remuxed videos should probably be put in a different location in the raw folders for each recording, something like .archive maybe?
The text was updated successfully, but these errors were encountered: