Develop minimum rate stream #11
Conversation
This is mainly useful for image topics which are published occasionally and which would end up in some buffer if not streamed at a minimum rate. Defaults to off. Signed-off-by: Peter Soetens <[email protected]>
Signed-off-by: Peter Soetens <[email protected]>
Signed-off-by: Peter Soetens <[email protected]>
Disconnection could happen during a restreamFrame or application cleanup. Signed-off-by: Peter Soetens <[email protected]>
cleanup_inactive_streams() misinterpreted the API of remove_if, which returns a new end iterator, but anything past that iterator is unspecified. In fact, it erased the wrong image_subscribers in most cases. Signed-off-by: Peter Soetens <[email protected]>
… can work A classical C++ error, the delete was done on an ImageStreamer, which has a non-virtual destructor, leading to the subclasses destructor never being called, leading to memleaks. Signed-off-by: Peter Soetens <[email protected]>
Signed-off-by: Peter Soetens <[email protected]>
Signed-off-by: Peter Soetens <[email protected]>
The constructor could lead to multiple calls to the setup functions of avformat. It's now put in a static function. Signed-off-by: Bert Willaert <[email protected]>
These settings are equally responsive and don't lead to the 'churning down' in the webbrower or vlc. Especially the time_Base parameter had a big influence on this. Signed-off-by: Peter Soetens <[email protected]>
Signed-off-by: Peter Soetens <[email protected]>
…te-stream Conflicts: include/web_video_server/web_video_server.h src/web_video_server.cpp
|
@mitchellwills can you take a look at this when you get a chance? |
|
While this performs fine when the browser is running on the same machine as the server it runs significantly slower when streaming over wifi (less than 50%). I think this has to do with the modified time_base.den |
|
We only tested this over LAN streaming from a fanless/embedded core i7 CPU. With slower, are you pointing at lag, or dropped frames? The main issue was that the stream just got choppy within 5-10 seconds anyway in any browser, so what are you comparing then ? |
|
I'm not sure if it was dropping frames, but the video was playing back at a rate slower than real time. This caused the video to lag further and further behind as time progressed (not a fixed lag). I do not see any lag, choppy video, etc, when streaming on the same machine. (NOTE these were for the mjpeg streaming) When using vp8 I see it freeze every few seconds and then catch up when streaming locally. I see similar results when streaming over wifi, but with a little more lag (but the lag time seems to be fixed). |
…eb tools. Also removed some deprecated/unused flags Signed-off-by: Peter Soetens <[email protected]>
|
Merge failure due to out-of-date code. Please re-open with up-to-date code if still valid. |
This is a series of patches to fix #7 but to also support streaming images of nodes that only publish an image once in a while. If nodes don't republish an image, the web_video_server and/or browser get lost and no longer update the video element in the browser.
Finally, it was necessary to modify some of the encoding parameters in order to get a clean video stream at the browser. Some lag seems to be added, it's not clear if this could be improved again.