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

[Francois Cartegnie]

Le 28/10/2020 à 11:28, Rémi Denis-Courmont a écrit :
> Le keskiviikkona 28. lokakuuta 2020, 11.37.14 EET Thomas Guillem a écrit :
>> 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.
> 
> That would timeout with previous versions just the same. Not like the timeout 
> changed in recent years.
> 
> Frankly, I don't care if it's 5 or 20 seconds. But VLC has an aggressive 
> timeout there, everything else has one too, it's necessary, and it was already 
> there before the alleged breakage.

The current chromecast module is broken by design,
but also because their received app progressive download mode never
reconnects when the connection drops.

Seems it was designed to expect no timeout (or server to use TCP
keepalive), and
since most of the content is served from static files or through
multiple files (adaptive), I guess that case was never really tested.

The way the chromecast module evades pacing (to shorten buffering times,
as there's no way to parametrize the 10seconds on the default receiver
app) to try to pace by itself after buffering just amplifies the problem.

Restoring the way the httpd timeout was behaving when the chromecast
module allows to restore the functionality which is now inoperative.
That still doesn't solve the original problem which will trigger on low
bitrate content (or if the system has low timeout on sockets).

On the long term, I don't see any reliable way than using adaptive
protocols for live content or a non default receiver app.

Switching to adaptive will need a full implementation of the segments
muxing, as ffmpeg's DASH or HLS features are designed for command line
usage and implemented mostly through non exposed API.

-- 
Francois Cartegnie
VideoLAN - VLC Developer