Indeed, your understanding is correct, so far. Most of these things are not related to Danne's changes; mlv_lite has the same quirks in the main repository (so, the discussion here is probably off-topic).
Anyway - mlv_lite is pretty much the codebase from the original raw_rec (i.e. most of that is my code, updated by dmilligan to support the MLV format at the same recording speeds as the original raw_rec implementation,
if not a bit faster). Long before that, mlv_rec was written by g3gg0 in an attempt to completely replace raw_rec; unfortunately, it was a little slower, and its menus and internals were a bit too complex for my taste, so... we ended up maintaining both. Not ideal, I know. It would make sense to merge both modules somehow, keeping both the raw recording speed and the features, if possible.
Regarding 'loads of "NO_THREAD_SAFETY_ANALYSIS"' - there are only two, that I could find, and that's because the
static analysis does not handle cli/sei correctly. I don't see this as a reason to be concerned - on the contrary. But I cannot guarantee 100% correctness either - maybe rewriting some parts of ML in Rust could help with that. No, I don't know Rust, besides trying to run Hello World some years ago, but it seems to be something worth learning.
About what things are executing - there are our own DryOS tasks, more or less straighforward to understand, and there are hooks placed at various locations in Canon firmware (usually in their DryOS tasks). The most interesting one here is the VSYNC hook, aka "EvfReadOutDone" on recent models (i.e. triggered once after capturing every single LiveView frame, in Canon's Evf/LiveView task, which runs with very high priority). That's where each frame is processed, and the next slot is chosen (ideally continuing the previous memory chunk, as it's a lot faster to write several megabytes at once).
However, what exactly happens within each LiveView frame was
only recently understood, and only to a very limited extent.
