Init nix flake

[the-furry-hubofeverything]

⚪ Koda) Tada!!!!

Currently very hacky (as we chopped much of setup_python for us to use python from nixpkgs, as well as reassigning different directory locations), but it builds and runs.

Uses python 3.13 because it introduces breaking changes to numpy, bumping it to version 2.x. Which meant that the python environment requires several rebuilds from various dependencies because nixpkgs had much newer packages than ones that are used.

The goal of this change is to introduce as little changes to the actual code as possible, while preserving usability on NixOS. MacOS is not considered in this PR, nor is Aarch64 (since something happened with mediapipe's linux wheel builds after 0.10.21, and the last version of mediapipe that does have linux aarch64 doesn't explicitly support py313)

Feedback is appreciated

[the-furry-hubofeverything]

Forgot to mention, currently one problem - twitch integration doesn't work under nix build. But tracking works and stuff

[the-furry-hubofeverything]

Forgot to mention, currently one problem - twitch integration doesn't work under nix build. But tracking works and stuff

Oh wait TwitchGD4 is a submodule, we need to tell nix that

[the-furry-hubofeverything]

Added a patch that remove frames_queued_mutex, as after testing, it is no longer needed for mediapipe 0.10.32.

[ExpiredPopsicle]

Unless the mediapipe deadlock issue is explicitly resolved on their end I would not advise removing the frame queue tracking.

This is an issue that comes up in cases where the tracking cannot keep up with frames being sent to the API. Once it reaches a high enough number of frames queued, it will freeze on attempting to add more frames, requiring the whole process to be killed and restarted.

It often comes up in situations where SnekStudio is limited on CPU resources due to other processes using up the rest of the available CPU time.

[the-furry-hubofeverything]

Unless the mediapipe deadlock issue is explicitly resolved on their end I would not advise removing the frame queue tracking.

This is an issue that comes up in cases where the tracking cannot keep up with frames being sent to the API. Once it reaches a high enough number of frames queued, it will freeze on attempting to add more frames, requiring the whole process to be killed and restarted.

It often comes up in situations where SnekStudio is limited on CPU resources due to other processes using up the rest of the available CPU time.

⚪ The problem is that task runners has been entirely removed since v0.10.32 (google-ai-edge/mediapipe@87cc4a3), since (as far as I understand) a lot of the runner functionality are now specifically handled by the C parts of mediapipe (google-ai-edge/mediapipe@f8f6fba)

Further more, when we ran SnekStudio under load (with both synthetic stress test and with OBS open, as we were streaming on Piczel at the time), there's no freezes other than the slowdown that the load causes. The reset logic did trigger multiple times during that load. During testing, ._runner.restart() is removed, since it no longer exists in mediapipe 0.10.32. Even so, there were no crashes or freezes that we noticed.

As we don't know other ways of restarting the task (other than recreating it via create_from_options, which, for some reason, causes the tracking to restart over and over again), and there is no impact towards the functionality or stability as far as we could test, I removed that part.

[the-furry-hubofeverything]

⚪ I'm assuming that this specific behaviour only applies to the new version of mediapipe, though we didn't compare it to the older version. I think that it's may be worth exploring if you decide to update mediapipe in the future. We could open an new issue for it.

[the-furry-hubofeverything]

After using this PR for a couple streams, we noticed two things:

• the deadlock does happen, but it only happens when a hand is rapidly detected and then removed. This doesn't sound like it's similar to the original problem, and might be new

• We forgot to add wayland dependencies