mp4ctl: rewrite recording loop to fix chunk timing inconsistencies

[nicolasroche898]

The previous loop_worker implementation attempted to maintain several incorrect timing assumptions and mathematically incompatible invariants simultaneously:

1. Exact video duration (e.g., 60s).
2. Filenames with "round" timestamps (e.g., :00 seconds).
3. Zero processing time between files.
4. Keyframes/metadata arriving exactly at minute boundaries.
5. System clock is monotonic and never jumps (e.g. via NTP).

In practice, this caused issues because:

• Processing overhead (open/close) takes time (1-2s), causing natural drift.
• Wall clock adjustments (NTP) can shift time unexpectedly.
• Keyframes/metadata arrive at unpredictable intervals, often requiring 1-2s delay before creating a new mp4 file.
• The "catch-up" logic intended to align timestamps caused drift, dropped segments, and errors.

This rewrite abandons the attempt to "beautify" timestamps in favor of reliability:

• Independent Iterations: Each recording loop iteration is now independent.
• Natural Drift: We accept that filenames will reflect the actual start time (e.g., 12-34-56.mp4) rather than a forced round number.
• Current Time: Timestamps are derived from now() immediately before file creation, ensuring accuracy over cosmetic alignment.
• Simplified Logic: Removed round_up_to_minute and sleep_until_time helpers.

[nicolasroche898]

there seems to be an unrelated build error in libfaac ?

[themactep]

@virmaior, want to look at the proposed changes? I believe you were rooting for round minutes in recording. This PR will remove that unless we find a nice alternative way to implement it.

[virmaior]

Thanks for the heads up.

Briefly looking at the thorough description of the summary, I recognize how it's better in every respect except one in terms of assumptions and completeness:

Natural Drift: We accept that filenames will reflect the actual start time (e.g., 12-34-56.mp4) rather than a forced round number.

This particular element is more of a choice being driven by the underlying challenges of recording or perhaps a philosophical choice.

In my case, I need video in minute boundaries in order to process it. Somehow the ingenic sample code / wyze/atom stock imlpementation does it.

Maybe this is the wrong layer to accomplish videos with minute boundaries breaking at human logical temporal boundaries?

[virmaior]

@nicolasroche898 this looks pretty awesome overall. How would you propose that I can get videos at minute boundaries on top of this code?

[nicolasroche898]

Exact minute boundaries requires re-encoding with an I frame inserted exactly at the beginning of each minute.

Ask your favorite GPT about merging video files and chopping them up at specific boundaries / intervals, it's a common task for https://en.wikipedia.org/wiki/HTTP_Live_Streaming that can be done with ffmpeg

[virmaior]

I am not unaware of how to split/combine video. My question was more about the design choice to provide separate video files for each minute as ingenic's own code does for wyze/atom etc. Reading up a bit, I think I now grasp the cold water you're splashing.

For the reference implementation, it basically tries to accomplish close to 1 minute 00 second videos by having enough key frames to simulate something close to this.

I think what you're saying is that: that's a bad way to record video and one that will always require hacky crap to work. Wyze etc. do so because they are 100% willing to sacrifice quality to create this illusion.