[vlc-devel] [PATCH 2/2] chromecast: don't close the client connection

[Thomas Guillem]

On Wed, Oct 28, 2020, at 10:03, Rémi Denis-Courmont wrote:
> Le keskiviikkona 28. lokakuuta 2020, 10.32.07 EET Thomas Guillem a écrit :
> 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.

You just changed timeout handling with 67cdaeea58641d6d515728596f8b194f52538e2b.

I don't understand why you are not updating the activity date just after httpd_Client*() like it was done before (that is what Francois tried to fix in the first time)

This change alone is breaking Chromecast. And yes, Chromecast support is a very fragile ecosystem.

The Chromecast client will fill its internal buffer to the maximum when opening/seeking a file. This result on many read requests. Then, it will wait quite a long time before doing another read request. This can be longer than 10seconds.
We can't control the Chromecast, we don't have other solutions to adapt our code to this behavior since we can't break Chromecast support in the middle of a 3.0.x release.

Here are some tests:

1/ With a 1 226 kb/s video: the chromecast client read 6MB from start, then try to read 1MB - 2MB every 10secs or more
2/ With a 4 487 kb/s video: the chromecast client read 15MB from start, then try to try 2MB every 2seconds.

The testcase 1/ is currently failing on VLC 3.0, it was working before 67cdaeea58641d6d515728596f8b194f52538e2b was merged.

I hope I gave enough informations.

> 
> > 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) 
> timeouts fire.
> 
> 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 
> plugin proper.
> 
> -- 
> Реми Дёни-Курмон
> http://www.remlab.net/
> 
> 
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel