[vlc-devel] [PATCH 2/2] chromecast: don't close the client connection
Thomas Guillem
thomas at gllm.fr
Wed Oct 28 09:32:07 CET 2020
On Tue, Oct 27, 2020, at 20:14, Rémi Denis-Courmont wrote:
> Le tiistaina 27. lokakuuta 2020, 18.28.00 EET Thomas Guillem a écrit :
> > Fixes #25151
> > Fixes #25192
> > ---
> > modules/stream_out/chromecast/cast.cpp | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/modules/stream_out/chromecast/cast.cpp
> > b/modules/stream_out/chromecast/cast.cpp index 08defbd5a1b..12e175bc68a
> > 100644
> > --- a/modules/stream_out/chromecast/cast.cpp
> > +++ b/modules/stream_out/chromecast/cast.cpp
> > @@ -466,6 +466,13 @@ int sout_access_out_sys_t::url_cb(httpd_client_t *cl,
> > httpd_message_t *answer, * should also serve data used by the old client to
> > the new one. */ restoreCopy();
> > m_client = cl;
> > +
> > + /* Chromecast clients buffer lot of data (burst mode) and can wait
> > more
> > + * than 10 seconds between 2 consecutive reads.
>
> Linux limits the TCP send window to 4 MiB by default for security reasons.So
> at, say 15 seconds, between reads, the stream would be capped at 2 Mbps... And
> there are probably OSes with even lower limits.
>
> I have to doubt the accuracy of the statement because it should have been a
> major problem from the beginning. But if it's true, then it's a client bug
> that this patchset won't be able to work around.
Chromecast always worked with the default TCP timeout in 3.0. It doesn't work anymore with our httpd timeout.
This patch is not a perfect solution (since the TCP timeout can fire anyway) but this delay the timeout enough to allow low bitrate playback via chromecast.
The problem is when broadcasting sd video, two consecutive reads can be delayed by 10-20 seconds.
I tried reproducing it with very low bitrate video and could not trigger the TCP timeout on linux. I didn't test in on other OSses but I think it will work. Indeed, users started to complain about this timeout only since we fixed the httpd one.
We need a fix quickly because it delays the 3.0.12 release, that is critical for macOS.
What other solution are you proposing? We could also revert 67cdaeea58641d6d515728596f8b194f52538e2b for 3.0 but we want to keep 24824 being fixed.
Can I push this patch anyway for 3.0 ? After moving the timeout set from a function to the url callback definition?
For 4.0, we are thinking about using a hls/dash server for chromecast.
>
> --
> Rémi Denis-Courmont
> http://www.remlab.net/
>
>
>
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
More information about the vlc-devel
mailing list