[vlc-devel] [PATCH 2/2] chromecast: don't close the client connection
remi at remlab.net
Wed Oct 28 10:03:12 CET 2020
Le keskiviikkona 28. lokakuuta 2020, 10.32.07 EET Thomas Guillem a écrit :
> 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.
The HTTPd timeout has not changed in many years either. I don't know if it
even ever changed from the current 10 seconds value.
> 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.
Neither the TCP nor the HTTPd timeout prevent low bitrate. The TCP timeout is
there to drop a disrupted connection if it has unacknowledged outbound data.
The HTTPd timeout is there to do the same (but faster), and in server-side
receiving state, drop connections with no incoming data.
Turning the HTTPd timeout off is essentially adding a remote DoS.
> The problem is when broadcasting sd video, two consecutive reads can be
> delayed by 10-20 seconds.
And so what? Unless available bandwidth is *insufficient* for the stream, the
connection will reach POLLOUT faster than the HTTPd (and later on, TCP)
Not to mention that, if you delay reads by 20 seconds, you will break any
media with bit rate at or above 1.6 Mbps from a Linux system. It breaks even
lower on some other systems or with non-default configuration. That's
potentially not enough even for a typical SD stream.
In other words, this sounds like yet another nonsensical, unintelligible or
elliptic problem statements. If you want to "fix" the HTTPd code, you have to
provide a sensible explaination of what is wrong with it. And in the mean
time, I can only assume that any bug lies elsewhere, likely in the Chromecast
More information about the vlc-devel