Write overall macro duration on export

[vadosnaprimer]

Hi. Over at tasvideos we're trying to support this replay format, and the one bit that's missing is a way to calculate overall movie time automatically. Normally we do this by either counting how many frames a movie has for cases when their rate is constant, or we parse the resulting time from the movie metadata when framerate is variable.

The latter seems to be the case for GZ macros, but there's no metadata we could parse directly (or indirectly). Macro duration is stored but frequency of those frames changes and there's no way to know which frames had which frequency without running it against the game (tho those aren't stored either). movie_last_recorded_frame is exported but not only is it in that VFR format but it seems to indicate whichever frame the author was recording last, which may not be the last frame of the movie.

Would it be feasible (and sufficient) to append gz.cpu_counter at the end of the macro upon export, or maybe a new variable would make more sense that'd store cpu_counter value that it had on the final frame of the macro? Since movie navigation is non-linear, I feel a bit of extra logic would be needed to properly update that value on movie extension or truncation.

[Thar0]

Hi, I'm just a contributor but I have a lot of interest in seeing this supported and have thought about this before. Here's my assorted thoughts:

The key issue that I encountered while thinking about this is that gz macros do not strictly have a well-defined real-time duration. This is because on this console lag is strongly non-deterministic*, leading to variance in input polling and rng seeds sourced from CPU counters that cannot be accurately reproduced. gz is designed to be resistant to these issues that would cause desyncs during playback, but cannot guarantee consistent lag frames per playback.

Appending a cpu count duration to the macro after a full uninterrupted playback on some chosen platform (hardware, an emulator) would provide just one of several possible real-time playback durations. Emulators would yield a more consistent duration at the cost of the duration itself being inaccurate to hardware.

Framerate hints could be added to the movie format, but at best this would only yield a movie duration in the absence of any lag frames. Storing lag frame durations at recording time sounds like it could be done, but it would be inherently inconsistent and playback may not reliably be able to reproduce the same lag frame count as at the time of recording.

Other games suffer from the same or similar issues in defining a "canonical" movie duration. Super Mario 64 for instance, while it can be played back on hardware using an unmodified ROM, will yield different durations per playback. Could you describe your policy for handling these cases? It would help me understand what a suitable way forward could look like. If it's acceptable to take just one possible playback duration and consider that the playback time, this could open up many options.

Thanks for reaching out to discuss! I hope this is something that can be supported

--

* We know of at least one reason why this is: The N64 has a shared memory architecture and two crystal oscillators, one for the system clock and one for the video clock. The video clock drives RAM refreshes on HSYNC, rendering the entire system sensitive to the relative phase of the two oscillators.

[vadosnaprimer]

Does this mean when actual TASers determine duration of their movie, they will also get inconsistent results if they just keep replaying it over and over (on hardware)? There's also a test to be done by running those movies on the Ares64 core of bizhawk, which is much more accurate than mupen, just to reduce the arbitrariness of the numbers a bit (and it doesn't require hacking the core to expand its memory).

If there can't be definitive canonical duration even on console then we just accept that any result we end up with is an approximation, which is clearly better than no parser at all for this format. Worst case scenario we retime them on our end by exporting the macro from the Ares64 core, which will at least be fully deterministic and reproducible every time you rerun the macro.

[Thar0]

Right, there's no guarantee that any two playbacks of the same movie will produce an identical duration, even on hardware. When a time is cited for a gz movie, it's typically based on the time achieved in one particular playback; the variance in playback time is small compared to total movie durations.

A standard emulator for measuring timing sounds reasonable enough to me. If framerate hints and a total count of lag frames elapsed during uninterrupted playback were added, that would be sufficient to extract a time from a gz movie after playing it back once in the emulator of choice. I'm happy to look into adding the features to support this if that sounds good to you and @glankk

[vadosnaprimer]

BTW would it even be possible to export a macro onto PC when running GZ in an emulator?

[Thar0]

One way is to let the emulator core support one of the flashcart interfaces gz supports (various models of everdrive 64 or summercart 64), possibly as an option behind a checkbox. I've already made a local modification to the ares64 core to emulate a summercart unconditionally, since I've wanted to load gz macros into Bizhawk to record to a video before. This would also allow exporting a macro after playing it back

[vadosnaprimer]

Oh wow. Can you send a pull request to show the code and also start the discussion? Sounds very interesting.

Anyway, the thing I also thought about. If the cpu counter is appended to movies, and there's a way display it every frame in the HUD, we could let people export it from consoles, and then when judging we'd run it in ares and simply replace the final number with the one that appears in ares on the final frame. It'd make things predictable and standardized for the purposes of tasvideos.

The only thing I wonder is how far apart can time durations be on console from extreme minimum to extreme maximum, roughly? If the discrepancy is a few seconds, and ares is also only off by a few seconds, that sounds to me like a decent compromise for the sake of consistency (you know, on tasvideos we also sacrifice accuracy to determinism when it comes to emulation authenticity).