You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have been having a problem where when a topic that is being published from webrtc_ros disconnects then reconnects all of the systems have a delay in getting the new feed if they have previously received the feed. If it is their first time getting the feed, then no problem. Except that nodes which subscribe using image transport seem ok.
I haven't checked in the WebRTC code base, but this reminds me of a similar issue we had with encoded video bitstreams. If a video client joins an existing bitstream transmission later (i.e. not right from the beginning), it has to wait for the next key frame before it can start decoding, because the other frames only encode differences. Maybe the connection lingers and gets reused if you disconnect and reconnect?
Yeah, that is possible. My initial thought was that the that in a destructor, maybe the image transport should be closed, after being opened. But I dug into the docs a bit and it seems that should happen when it goes out of scope. I would think that the image publisher goes out of scope when the webrtc connection is closed here. That is where I will start debugging if I ever get around to it.
I have been having a problem where when a topic that is being published from webrtc_ros disconnects then reconnects all of the systems have a delay in getting the new feed if they have previously received the feed. If it is their first time getting the feed, then no problem. Except that nodes which subscribe using image transport seem ok.
more detail
I think there might be something that could be done to the video renderer to fix this. But I don't know what that would be.
The text was updated successfully, but these errors were encountered: