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

[Perfomance] Frame drops #28

Open
Francescu opened this issue Oct 30, 2017 · 3 comments
Open

[Perfomance] Frame drops #28

Francescu opened this issue Oct 30, 2017 · 3 comments

Comments

@Francescu
Copy link

Hi guys,

The lib is awesome, but we get performance issue regarding frame drops.

Do you think recording in a buffer first and perform the actual write after the recording would solve the issue?

@okaris
Copy link
Contributor

okaris commented Oct 30, 2017

I believe the performance issues are caused by rendering the scene twice. First is for ARKit and the second render is for the recorder. I have tried to work around this issue by pulling the already rendered frame from sceneview but there were some complex color space problems, which Apple does not give up information about. They also suggested that approach should not be used.

Given these I think writing to disk is not the problem. Since iPhones operate on SSD's the write speeds are close to RAM and that is highly enough for the task at hand.

I would suggest that you check the performance issues part in the readme. Those might help. And also you can try setting the recording to a lower resolution.

We are actively working on this repo to overcome performance issues. Contributions are always welcome!

@Francescu
Copy link
Author

I believe the performance issues are caused by rendering the scene twice. First is for ARKit and the second render is for the recorder. I have tried to work around this issue by pulling the already rendered frame from sceneview but there were some complex color space problems, which Apple does not give up information about. They also suggested that approach should not be used.

Ok, thanks for the explanation. So, I get that most of the performance hurts come from the double rendering. Do you think a reversed could approach work? E.g disabling the sceneView rendering and displaying images we get from the snapshot method instead?

Given these I think writing to disk is not the problem. Since iPhones operate on SSD's the write speeds are close to RAM and that is highly enough for the task at hand.

I noticed that we had a lot of crash before you updated safeguard (like videoInput.isReadyForMoreMediaData and CMTIME_IS_VALID). I though it meant that we drop frames because of the writing itself.

I would suggest that you check the performance issues part in the readme. Those might help. And also you can try setting the recording to a lower resolution.

Yes I did, but it didn't affect performance so much. Plus, we don't want to lose visual appeal or resolution as it's very important to our product.

We are actively working on this repo to overcome performance issues. Contributions are always welcome!

Sure, I'd be glad to help in anyway I can. If I found anything, I'll PR you.

Thanks again for your great work

@Francescu
Copy link
Author

Francescu commented Nov 2, 2017

Do you think SCNView snapshot method also perform a new rendering? As it use the current state of the renderer, it should not be as resource consuming as snapshot(atTime:)?

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