Image Streams Now Stop When Connection Closed (ROS2)

[QuentinTorg]

WARNING: This has only been tested in ROS1. I have not confirmed the issue, compiled, or tested the fix in ROS2 yet.

Public API Changes
None

Description
I have a setup where my camera and my host computer are using different time domains (camera time is significantly ahead of computer time). I'm using the jpeg image streamer to stream to a browser. I found that when I close the image stream window in my browser, the subscription was not getting closed.

This is because the isBusy() function was comparing image header time stamp to ros::Time::now() when checking if pending footers were too old and needed to be removed. It would never clear old footers from the queue, preventing it from sending new images. Preventing sending new images meant that exceptions would never bubble up from the async_web_server library to indicate a connection issue

Forcing all time stamping to use ros::Time::now() instead of camera time fixed this issue because there was no longer a time domain mismatch. I chose to use system time instead of image header time because the restreamFrame() function also needs to make a timeout decision, but does not have an image header to compare to. It would be possible to use image header time all the way through by saving the latest image header timestamp, but it doesn't seem beneficial because there is no consumer for accurate camera timestamps from what I can tell. Maybe some of the other image streams care about this?

#171

[bjsowa]

Thanks for the contribution. I'll try to revisit how the timestamps are handled in web_video_server this week in my spare time and let you know what I think about the proposed fix.

[bjsowa]

After analyzing the code more in depth, I agree that there is no need for retrieving accurate camera timestamps if the point of the package is real-time video streaming.
I would go even further and use a monotonic clock instead of a ROS clock, as with the ROS clock:

1. If simulated time is enabled and the real time factor is not 1.0, the video encoded streams will not play at the correct speed as the presentation timestamps of the encoded frames is calculated from timestamps that move in a different speed than receivers internal clock.
2. If system time is used and the system time is changed (e.g. it gets synchronized with an NTP server), this could lead to the same bug that you described (pending footers not getting removed) and other unspecified behavior.

In #173 and #174 I propose a solution which uses chrono steady_clock for frame timing related functionalities. Could you please check if it solves your issue?