Cameras unusable from Argentina
Closed this issue · 6 comments
The new ros_http_video_streamer sends video with a lot of artifacts that make the cameras unusable when doing anything realtime, like navigating.
We should provide an option to fall back to the old mjpeg_server video streams. A simple solution would be to create a robot which has a different set of camera URLs pointing to the mjpeg_server cameras.
However the web UI uses video tags as containers for the video streams, and the old mjpeg_server requires img tags instead. So the simple solution does not work. The web UI will have to be aware of the fact that it's displaying mjpeg_server feeds and create img tags to contain them instead of the current video tags.
Right, as @jkammerl was mentioning yesterday, it seems that for now we do need to support both options in a solid way. Streaming was very promising, but it's turning out to have intrinsic incompatibilities with what we're trying to do, and currently provides an advantage only over decent networks (e.g. SF to Menlo Park)...
@tlau: It would be interesting to know if the video streamer works within your local network. You already installed the ros http streaming node, right? Could you test this? Thanks!
Great idea! We'll try it tomorrow with the Turtlebot.
On Dec 19, 2012 7:38 PM, "Julius Kammerl" notifications@github.com wrote:
@tlau https://github.com/Tlau: It would be interesting to know if the
video streamer works within your local network. You already installed the
ros http streaming node, right? Could you test this? Thanks!—
Reply to this email directly or view it on GitHubhttps://github.com//issues/149#issuecomment-11552151.
I think I found a way to fix the disturbing artifacts that we saw when streaming to video data from/to Argentina. If the video encoder generates more more video data than the communication link can handle, we must somewhere drop video data. The way the ROS video streamer dealt with this problem was to run the encoder in a separate thread which distributes the encoded webm packets to all connected clients. If one client has a slow network link, it would always select the most recently generated video packet for transmission and hence some packets might have been dropped here. Apparently, chrome doesn’t like that at all which leads to these annoying artifacts (interestingly vlc and mplayer do work). In order to address the synchronization of the encoder and the network capabilities, I revised the code to make the encoder wait as soon as the network socket blocks. However, this also means that each client needs to have its own video encoding thread (no multicasts).
I pushed my changes and updated the code on prl:
Argentina: Could you please test if the streaming works better for you now? http://prl:9999/
Thank you Julius for the update! At a very quick glance (cameras quickly
stopped working) it looked better. I didn't get any artifacts during the
short while I was looking at them.
If we can build this tomorrow morning on our side we can have a new
Turtlebot race :-)
On Sun, Jan 6, 2013 at 10:33 PM, Julius Kammerl notifications@github.comwrote:
I think I found a way to fix the disturbing artifacts that we saw when
streaming to video data from/to Argentina. If the video encoder generates
more more video data than the communication link can handle, we must
somewhere drop video data. The way the ROS video streamer dealt with this
problem was to run the encoder in a separate thread which distributes the
encoded webm packets to all connected clients. If one client has a slow
network link, it would always select the most recently generated video
packet for transmission and hence some packets might have been dropped
here. Apparently, chrome doesn’t like that at all which leads to these
annoying artifacts (interestingly vlc and mplayer do work). In order to
address the synchronization of the encoder and the network capabilities, I
revised the code to make the encoder wait as soon as the network socket
blocks. However, this also means that each client needs to have its own
video encoding thread (no multicasts).
I pushed my changes and updated the code on prl:
Argentina: Could you please test if the streaming works better for you
now? http://prl:9999/—
Reply to this email directly or view it on GitHubhttps://github.com//issues/149#issuecomment-11938359.
The new video_streamer has been working really well. Closing this bug.