Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pre-launch playback commands #90

Open
classicstrike opened this issue Dec 19, 2023 · 4 comments
Open

pre-launch playback commands #90

classicstrike opened this issue Dec 19, 2023 · 4 comments

Comments

@classicstrike
Copy link

classicstrike commented Dec 19, 2023

Additional bxt commands to select which player pov to record, record start timestamp, record end timestamp before bxt_cap_start commences. This will also solve the time mismatch between demo duration and output.mp4 duration as the two timestamps will serve as an absolute duration.

In terms of implementation, it seems there isn't an interface that can be used to manipulate playback, it's possible that a hacky approach where rounds and players are stripped from the demo before playback would be necessary.

@khanghugo
Copy link
Contributor

khanghugo commented Dec 19, 2023

record start timestamp, record end timestamp

#68

which player pov to record

If you are on HLTV demo, that is something entirely different and I doubt it would be easy to implement. Feel free to try though. Also on that, bxt-rs fundamentally works on playdemo. For HLTV demos, you must use viewdemo and that is not something that I personally do not want to deal with (and bxt-rs isn't developed on that either).

This will also solve the time mismatch between demo duration and output.mp4 duration as the two timestamps will serve as an absolute duration.

Not sure what you mean by this.

it's possible that a hacky approach where rounds and players are stripped from the demo before playback would be necessary.

You can parse the demo to know where the round starts or end. Nonetheless, it is not something that I personally won't be invested in enough to implement. I am not talking on behalf of other contributors that might be interested in that though. Maybe it will be there, maybe not.

Lots of what you say here could be easily worked around by recording a low quality demo then you can time the demo properly from there for higher quality recording.

@classicstrike
Copy link
Author

Not sure what you mean by this.

That sometimes other things are recorded such as the 1 second loading time before the demo starts playing which makes the output.mp4 1 second longer than the demo duration, for example. In other words, currently the starting point is registered as soon as bxt_cap_start is executed but if it was based on a timestamp then it would be more accurate.

@khanghugo
Copy link
Contributor

That is something I have answered you in the SourceRuns discord... You can use the bxt-rs from Github Actions page and do bxt_cap_skip_non_gameplay_frames 3 or so.

bxt-rs does not record a demo, it records whatever pumps out of the screen. So when you do record along with play demo, it will record the frame you executing that command. The reason why it is "1 second longer" for you is that your hardware is very slow so the initializing phase takes very long time. With all of that said, there is no issue with being "accurate" here because your recorded demo still ends up with the same duration as it should. You can just cut them in post.

@classicstrike
Copy link
Author

We tried it but it doesn't work. It was just clarification on the original point that was saying a timestsamp would deliver more accurate cuts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants