Inconsistent frames

[nevynwong]

In Python, wait for frames() is used to extract all the frames of the bag file, which are different from those obtained through rosbag. For example, rosbag only gets 5689 frames, while Python gets 6533 frames.

[dorodnic]

Hi @nevynwong
wait_for_frames does not return frames, but rather coherent frame sets (pairs, triples, etc..). If no match for a specific frame was captured during recording it can be skipped by wait_for_frames. Also, there is set_real_time method that can be used to reduce drops during playback.

[nevynwong]

Hi @dorodnic ,Here's my program.

import pyrealsense2 as rs
import numpy as np
import matplotlib.pyplot as plt
import cv2
import argparse
import os.path
import scipy.io as scio

pipe = rs.pipeline()
config = rs.config()
config.enable_device_from_file('/plant.bag',repeat_playback=False)
profile = pipe.start(config)
playback = profile.get_device().as_playback()
playback.set_real_time(False)

#pointcloud
pc = rs.pointcloud()
points = rs.points()

colorizer = rs.colorizer()

align_to = rs.stream.color
align = rs.align(align_to)
n = 0
m = 0
while (playback.current_status() == rs.playback_status.playing) :
n += 1
print n
frames = pipe.wait_for_frames()
****

I use n to record the number of frames in the bag file.
The result is much more than the result through rosbag. Is it my program's problem?

[nevynwong]

Hi @dorodnic ,
I would like to restate my problem, but actually my problem is that many framesets produced by using wait_for_frames() are the same, that is, adjacent timestamps and images in adjacent framesets are the same. What is the reason?How to solve it?

[ev-mp]

@nevynwong hello,
as noted by @dorodnic wait_for_frames produces synchronized depth/color/ir framesets, so in cases where only a subset of those were updated by the time the user call was made, the frameset exhibit a mix of new and old frames, i.e each frame will appear in more than one wait_for_frames invocations.
This is also true when, for instance you record only a single stream but during playback you invoke wait-for_frames twice as fast as they were recorded.

There are multiple ways to handle this -

• Inspect every frame obtained in the frameset. track and and process only those that change.
• Use non-realtime playback mode, as recommended by @dorodnic above. This can partially mitigate the number of duplicates
• Use 'poll_for_frames' API that is guaranteed to provide each new frame only once to avoid duplicates. This however, transfers the responsibility to synchronize the frames (required for cases such as align/pointcloud) to the user..

Related to #5143