Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remux Videos With Correct Framerate #34

Open
2 tasks
jmdelahanty opened this issue Feb 2, 2023 · 0 comments
Open
2 tasks

Remux Videos With Correct Framerate #34

jmdelahanty opened this issue Feb 2, 2023 · 0 comments

Comments

@jmdelahanty
Copy link
Contributor

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant