- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi there,
It seems like the first frame of a saved .bag file gets skipped when loading the data. Below I've pasted a code snippet based on SDK 2.0 (build 2.16.1).
So I'm not sure if I'm doing something wrong or that it's a bug in the SDK. I both tried using "wait_for_frames()" and "poll_for_frames()" to retrieve the frames.
I've also tried toggling the "set_real_time" option to true and false.
This following code snipped returns on the first loop a frameNumber of "3483" with it's corresponding timestamp. However, when I open the bag file in the RealSense rosbag inspector the recording starts at frame number 3482. Am I doing something wrong here?
std::shared_ptr pipe = std::make_shared();
rs2::config cfg;
string bag_filename = "actual_bag_file.bag";
cfg.enable_device_from_file(bag_filename);
pipe->start(cfg);
rs2::device device = m_pipe->get_active_profile().get_device();
rs2::playback playback = device.as();
playback.set_real_time(false);
while (true) {
rs2::frameset frameset = m_pipe->wait_for_frames();
rs2::frame color_frame = frameset.get_color_frame();
long long time = color_frame.get_timestamp();
long long frameNumber = color_frame.get_frame_number();
}
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If the first frame is being skipped, you may not be losing useful data anyway because it takes the first several frames after the start of a stream for the exposure to settle down.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In this case I was trying to use the timestamp from the first frame to determine the end of the file, preventing the file to start reading from the start (see code snippet below).
The saved files are quite large (>10 GB) and stored on a HDD. When the end of the file is reached, it takes a while before the first frame is retrieved again.
Therefore it seemed better to detect the end of the file and then break out of the loop. That's when I found out the bag file wasn't reading the first frame properly, because the break condition was never met.
If there are better ways to determine the end of the file that would also be great.
Another solution would be to skip the last few frames, by setting "duration.count() - newTime < 1000" from 1000 nanoseconds to a higher number (which ideally should be set to zero).
But it felt like a sloppy solution, therefore I was wondering if there's a better way to do this.
chrono::nanoseconds duration = playback.get_duration();
long long initialTimestamp, timestamp, newTime;
int count = 0;
while (true) {
rs2::frameset frameset = pipe->wait_for_frames();
rs2::frame color_frame = frameset.get_color_frame();
long long frameNumber = color_frame.get_frame_number();
timestamp = color_frame.get_timestamp();
if (count == 0) {
initialTimestamp = rgbTOA;
}
newTime = timestamp - initialTimestamp;
if (duration.count() - newTime < 1000) {
break;
}
count++;
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If the bag is being recorded in ROS, you can use a Split command to start a new file automatically after a certain time period has passed or a file size is reached. You still need a good amount of hard disk space, but the reduced size makes the files more manageable.
https://github.com/IntelRealSense/librealsense/issues/2424# issuecomment-423284173 Recording multiple clips consecutively · Issue # 2424 · IntelRealSense/librealsense · GitHub
If the bag is recorded with the RealSense SDK, the SDK has a function called Keep() that stores the frames in memory instead of saving them during recording. When the stream ends, it lets you save the memory-stored frames in a single action, and optionally do post-processing on them. It is best suited to short-duration recording though.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page