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

Save two Streams to bag-files at the same time #2882

Closed
CasimirBo opened this issue Dec 12, 2018 · 6 comments
Closed

Save two Streams to bag-files at the same time #2882

CasimirBo opened this issue Dec 12, 2018 · 6 comments
Assignees

Comments

@CasimirBo
Copy link

Required Info
Camera Model D400
Firmware Version 05.10.06.00
Operating System & Version Win 10
Platform PC
SDK Version 2.17.0.409
Language python

Issue Description

Hello,

I m trying to save two camerastreams to a .bag file at the same time.

My code looks like this:

image

My Problem is, that I lose many frames from both cameras,. Also the frames from both cameras added together are significant less than the theoretical amount with 90fps in 5 seconds.

Is it general possible to save two sreams at the same time and where could be my fault?

Thanks for your supper,

Casimir Bokranz

@MartyG-RealSense
Copy link
Collaborator

There was a past case where a user managed to record streams from multiple cameras in the RealSense wrapper for the Unity game engine by making a few edits to a script in the wrapper

#2203 (comment)

Also, here is a YouTube video this user made that demonstrates multi-cam recording with Unity. The audio is in French though.

https://www.youtube.com/watch?v=Zm8ZjLsw-vs

@realsens01
Copy link

Does a similar problem occur when using Realsense Viewer to record bag files? Do you have frame metadata enabled? Is logging enabled?

This sounds like it could be similar to the issue I am having with a pair of D435s. I'll point you to the issue and community post. The issue has not been resolved, but there is a lot of additional information in those posts.

The reason I ask about Realsense Viewer is that it seems like an easy way to get more information, and to compare it to the errors that I was having. The reason I ask about metadata is because myself and another user both confirmed that disabling metadata reliably reduced errors (this is not a solution, but it adds information).

@CasimirBo
Copy link
Author

Hi,

the Problem was, that there was to much dataflow.

In my first try, I saved the files to an server. ->I lost frames

In my sceond try I saved the files to a HDD and connected the cameras to an Laptop (probably with an usb-hub) ->lost frames (also a waring of usb-overflow in RealSenseViewer)

In my last try I saved the frames to a HDD on my normal Computer. Here I had no Problems and all Frames were saved correct. In this try I just saved the depth stream wth 848*480 and 90fps.

So the cause for the bad saving was not in the sdk or the code.

Best wishes.

@dorodnic
Copy link
Contributor

Thanks for the update @CasimirBo
I recommend using an SSD for recording. Some time ago I ran the numbers on RealSense data rates vs regular hard-drive and it came out very close.
Perhaps compression on a GPU can be applicable, but it is not an easy problem AFAIK.

@realsens01
Copy link

Worth noting that my configuration -- which might have the same problem (links above) -- has an SSD, is a brand new Dell computer, and reports relatively low CPU and RAM usage. The problem occurred whether recording to disk or not, and was reliably affected by enabling metadata. The issue might be related to USB bandwidth, but that seems to be much harder to debug / confirm. I'd be interested to test utilization of the GPU, too, but I don't know how to do that. If you have pointers, that would be appreciated.

@RealSense-Customer-Engineering
Copy link
Collaborator

[Realsense Customer Engineering Team Comment]
Hi CasimirBo,

Thanks for the updates. It is good to be noted about the results from your tests on saving to server/laptop/computer. This definitely helps other people on similar use cases.
I am going to close this one for now, based on your results and conclusion (So the cause for the bad saving was not in the sdk or the code.).

Thank you!

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

5 participants