Frame Drops When Recording Bag File in RealSense Viewer in Windows but Not Ubuntu #2216
Comments
|
Are you using the pre-compiled Viewer? |
|
I tried it with that now, but it recorded only 1082 frames for 1280 × 800 Y16 IR1 on D435 for 60 s at 25 fps (ideally, 25 × 60 = 1500 frames). It worked correctly for a shorter 1280 × 720 depth recording, giving exactly 6.5 s × 30 fps = 195 frames. We also get the correct number of frames when we use C++ (however, saving all the frames to disk only at the end of the recording, since saving the frames to disk while capturing again leads to frame drops). |
|
For reference, below is a link to a similar case on the Intel Support forums from last week with apparent frame drops from recordings when used with MATLAB. |
|
Thanks for the reference, @MartyG-RealSense, but I don't think MATLAB is the issue. (I would get the same frame drops on opening the bag file any other way.) I think it is something to do with recording in the RealSense Viewer. For reference, here are the frame numbers I get from the bag file (which match what is seen in the Viewer). The frames are recorded correctly up to frame number 701, after which only every alternate frame seems to be recorded in general. Info: D415, 1920 × 1080, 25 fps, IR2, Y16 S. No.) Frame Counter
|
|
[Realsense Customer Engineering Team Comment] looks like the issue just happen sometimes, i am wondering when you do recording, if there's anything running background? |
|
Most likely this is resolved now in v2.16.1 |
|
[Realsense Customer Engineering Team Comment] Any update? If no further issue, will close this. |
|
I have a similar problem, using v2.16.1, recording rgb and depth streams, I experience frame drops. Taking a 60 second video, I should expect 60sec * 30fps = 1800 frames. |
|
[Realsense Customer Engineering Team Comment] I don't see this issue when I use the realsense-viewer to record a ros-bag file and check total frame number from the bag file is expected based on the recording time. Do you also use the realsense-viewer in v2.16.1 to record and what resolution used? Test it on Ubuntu or Win10? |
|
@RealSense-Customer-Engineering This is using realsense-viewer in v2.16.1, recording 1280x720 video at 30fps, on Windows 10. |
|
[Realsense Customer Engineering Team Comment]
|
|
@RealSense-Customer-Engineering I just recorded approximately 15 seconds of video with the realsense-viewer. Playing back the bag file while checking stream info shows approximately 30 fps (sometimes slightly less, e.g. 29.7). However, the number of img messages is clearly less than 450 (there are only 237 frames). Do you know where this discrepancy comes from? |
|
@RealSense-Customer-Engineering
I hope we can find a solution for this problem. |
|
I'm not sure if my problem is the same, but I thought it best to try posting here before creating a new issue.
Issue DescriptionWe have used Realsense Viewer to record bag files in the past, without problems. After weeks of trying to debug a separate issue, however, we noticed that the video feeds had become choppy while recording (but not while just streaming). This is a consistent effect, and seems to happen every time we record now. When we looked at the data files, we found dropped frames were frequent, with some gaps up to 5 seconds long. I have spent a lot of time attempting to resolve this since we noticed the issue last week. Here is what I have tried:
I just tested recording with a python script, and there were no gaps to be found. A 1 minute recording in Realsense Viewer yielded a 2GB bag file. A 1 minute recording with the python script yielded a 4GB bag file. I saved both bags as well as videos of what the recordings looked like on playback (they have the same duration, as expected, but the Realsense Viewer bag file playback is choppy... as it was in real-time). I will send those if they are useful. I also have Windows usbview log files that I exported. I'm attaching the Realsense Viewer log file taken during the 1 minute of recording. That was at INFO log level, so I am also attaching another log file for a quick recording with DEBUG log level. import time, pyrealsense2 as rs2
if __name__ == '__main__':
device = rs2.context().devices[0]
serial_number = device.get_info(rs2.camera_info.serial_number)
config = rs2.config()
pipeline = rs2.pipeline()
config.enable_device(serial_number)
config.enable_all_streams()
config.enable_record_to_file('test.bag')
pipeline.start(config)
time.sleep(60)
pipeline.stop()
del pipelineIt's probably important to note that metadata is disabled, as that seems to be a critical factor pertaining to our other issue (described at great length on our community post, and to a lesser extent as part a github issue). EDIT: The recordings are choppy if metadata is enabled, as well. realsense_viewer-debug_log_level-2019-01-15.log |
|
I have the same issue as @realsens01 Any information regarding this issue @MartyG-RealSense @dorodnic ? We have tried it on three different pc's All software versions are 2.18.0 Compression on recording PC 2 with no lags Compression off recording PC 2 with no lags Recording specifications PC 1 (Lags) PC 2 (Works fine) PC 3 (Lags) |
|
The link below discusses how some PCs may have problems with using compression because the CPU does not handle the built-in frame compression. |
|
I've just realized after updating my apt so realsense should be v2.18.1 that I was running my compiled version, after deleting all compiled source code and reinstalling from apt, I can run it without any lag and disk write is around 79 MB/s. So it works from apt sources, but when compiling it from source it lags on Ubuntu |
|
Also PC 1 is running a m1200 quadro with i7-7700hq So the issue should not be due to low-end systems as in #2102 |
|
Hi @TheMikeyR, Did you build realsense-viewer 2.18.1 as Release Build and has the issue only when the compression enabled and depth+RGB records with the default configuration? And, the firmware is 5.11.1.0? |
|
I didn't specify to build it as a realease. The issue only occurs with compression enabled (or left as default which I assume is compression on). The depth+rgb record is set to 1920x1080 for rgb and 1280x720 for depth at 30 fps. Tried with both firmware 5.11.1.0 and 5.10.13 |
|
Hi @TheMikeyR, The issue you reported can be observed. If any update, will let you know. |
|
This depends on the system computing/process power (CPU, RAM, storage, SW stack, etc) in order to avoid the frame drops. |
|
Then why does recording function properly through the SDK but not through Realsense Viewer? Why did @TheMikeyR observe the issue when compiling from source but not via apt? Can you elaborate? It has to be more than just hardware restrictions if some changes to the software can resolve the issue, right? Am I mistaken? |
Issue Description
When I record even just one stream as a bag file from RealSense Viewer in Windows and open it in MATLAB, I find that the number of frames recorded is less than the correct amount—e.g. a 5.6 s recording at 25 fps should have 5.6 × 25 = 140 frames, but the bag file contains only 106 frames, even though clicking the information button in the Viewer shows a constant 25.00 fps (after enabling hardware metadata). The problem is worse when multiple streams are recorded, even though we use an NVMe SSD.
There are no frame drops when recording a bag file using RealSense Viewer in Ubuntu 18.04 LTS.
The text was updated successfully, but these errors were encountered: