capture: Add _bxt_cap_skip_non_gameplay_frames

[khanghugo]

Recording normally would have loading. Here is a recording with lots of segments.

yes_loading.mp4

Here is one without loading.

no_loading.mp4

The frame_count could be changed around to omit early frames entirely. Though it might come at a cost of recording become janky. Some frames are broken as #2 mentions. That would need something else.

[khanghugo]

Just realize I need to put a check whether it is demo is playing....

[khanghugo]

Hmmm, it is still not quite working right.

[khanghugo]

That one works but the last demo won't skip the loading because right now I have no idea how to check whether a demo is going to be played. Trying to approach the other way that the game is being played but not the demo but it seems bit complicated now.

[khanghugo]

This should be better. It will start recording as soon as the game is done loading in general, not just limited to demo anymore. However, the fact that it will record when the game is loaded means recording the game when a map is not running will not record anything. But if prompted to a map, it will record right away. Maybe if that is needed then that could be the default behavior and extra cvar or this could be instead and there is another cvar (like _bxt_cap_all_states).

[YaLTeR]

So, some thoughts on this:

1. How useful is imperfect removing loads? Like, if you're editing a segmented run, then with imperfect load removal you will still need to make the same number of cuts, but now they are smaller and harder to notice, making it more difficult rather than easier, right? Are there any other use-cases where this helps?

2. Does this implementation not break audio sync? I.e. what happens to the audio for the skipped frames.

3. recording the game when a map is not running will not record anything

   Yeah, it's confusing if the default bxt_cap_start will just randomly not record something. Maybe there should be a separate command for starting a segmented run recording that will make it obvious that it only records demos and skips the loading parts. Although, we should also consider the case of live-recording TASes without loading frames -- how much sense that makes (i.e. does cutting out loads always produce nice footage, does it preserve audio sync).

[khanghugo]

1. I think I choose my words poorly. This pretty much eliminates all of the game loading frames, which happens on the last frame of the last demo that has the next demo (or the first demo that needs some game loading, or just not being in the game in general). The broken thing I want to say is the broken early frames, which is not omitted right now because they are not part of the loading thing. That would be for issue Draw entities and viewmodel from first frame of demo #24. I just hope that this would help with putting the videos together easier. There is this frame_count I add that can help with aggressively cutting broken/unneeded frames that are not part of the loading. It is there. I think it is just me that wanting to record and be done without any much post-edit such as pointing out certain frames to cut. Overall, I think this would help with a portion of that goal where we can record and be done. It now just needs some fixes for aforementioned issue and it is all good.
2. I can make some tests with sound and see. But I don't think it would desync since this just squashes all the events happening during the load time to one single "time_passed". I can get some tests done and show more. Here is again a video and the sound comes out good. Could be 1 frame off, I don't know but there are 32 segments in this.

outout.mp4

3. I guess this will stay put here until Add bxt_play_folder #53 is properly done then? Also until another fix for the mentioned issue is out.

[YaLTeR]

@SmileyAG what do you think from segmented run rendering perspective?

[SmileyAG]

@SmileyAG what do you think from segmented run rendering perspective?

I think it's ok to remove wait gaps since for rendering I'm always memorise at my head all transitions per the next demos after a multiple times of playback, and cuz anyway later I had to re-record audiotrack of some demo or with enabled cmd like bxt_fade_remove 1, so that ain't make for me a issue.

[khanghugo]

👍

I am still wondering how this would get implemented. Yalter does mention there could be some intentions of just recording to see things. If we were to have a command to record for segmented run then we might have another bxt_cap_start. I also think of another use case for recording mentioned in #56; so we might have one more extra bxt_cap_start if that were to follow. I think the simplest thing would just having a cvar to explicitly enable these things. Something like bxt_cap_remove_loading, or more accurately bxt_cap_only_in_map, suits this.

[khanghugo]

Here are some testings.

This video is the normal and this commit with audio on top of another. Not sure how helpful it is.

out.mp4

Here is some waveform with video toggled off and on occasionally to see that videos are matched.

Screencast.from.2022-11-29.01-01-22.webm

[khanghugo]

Here is how it does with live TAS recording.
Without cut:

no.mp4

With cut:

yes.mp4

A selected portion from no cut that I edit myself to see how it compares with this:

select.mp4

[khanghugo]

Hmmm, I thought I sync the change so your forced changes will get here also.... Welp, feel free to force push that.
This one will have the bxt_cap_seemless cvar that is 1 by default to skip the broken frames. Values greater than 1 can skip extra frames at the beginning, at least for now until there is a fix for the viewmodel frame thing (still, some frames before that viewmodel frames are broken and can be skipped only manually).

I think it should be on by default because I think when people want to record, they wouldn't want to record the main menu as soon as they start the client.

I have counted some demo records so I give the recommendation for the number of skipped frame is six (bxt_cap_seemless 7) because that is when the game surely renders viewmodel. If you think it is okay to bump that default up to the recommended then that can be done. It a hundredo makes sure there are no broken frames during the record

[khanghugo]

The only problem with conditioning this variable is it will skipp all the frames if the player carries no weapon. Not perfect unless I find something else.

Edit: doing fallback instead because this is a hard problem for me.

[khanghugo]

Just re-did this by making it in its own module. Should feel better than before. I recently find myself recording lots of demos and this is indeed very useful to feel less irritating looking at the product(s).

I am also advocating to have this on by default. What do you think?

[YaLTeR]

I am also advocating to have this on by default. What do you think?

A bit of a problem with this is that it's natural to try bxt_cap_start in the menu just to test that the recording works--I frequently do this myself.

[YaLTeR]

Thanks

[chinese-soup]

Great addition, thank you, @khanghugo, very cool!