[FFmpeg-devel] [PATCH] avformat/hls: Revert "reduce default max reload to 3"

[Michael Niedermayer]

On Wed, Feb 26, 2025 at 11:38:29PM +0000, Soft Works wrote:
> 
> 
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> > Michael Niedermayer
> > Sent: Mittwoch, 26. Februar 2025 01:39
> > To: FFmpeg development discussions and patches <ffmpeg-
> > devel at ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH] avformat/hls: Revert "reduce default
> > max reload to 3"
> > 
> > Hi
> > 
> > On Fri, Feb 07, 2025 at 02:39:56AM +0000, Soft Works wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Steven Liu <lingjiujianke at gmail.com>
> > > > Sent: Friday, February 7, 2025 3:24 AM
> > > > To: FFmpeg development discussions and patches <ffmpeg-
> > > > devel at ffmpeg.org>
> > > > Cc: softworkz <softworkz at hotmail.com>
> > > > Subject: Re: [FFmpeg-devel] [PATCH] avformat/hls: Revert "reduce
> > > > default max reload to 3"
> > > >
> > > > softworkz <ffmpegagent at gmail.com> 于2025年1月19日周日 16:52写道
> > ：
> > > > >
> > > > > From: softworkz <softworkz at hotmail.com>
> > > > >
> > > > > This change has caused regressions for many users and consumers.
> > > > > Playlist reloads only happen when a playlist doesn't indicate that
> > > > it
> > > > > has ended (via #EXT-X-ENDLIST), which means that the addition of
> > > > future
> > > > > segments is still expected.
> > > > > It is well possible that an HLS server is temporarily unable to
> > > > serve
> > > > > further segments but resumes after some time, either indicating a
> > > > > discontinuity or even by fully catching up.
> > > > > With a segment length of 3s, a max_reload value of 1000 corresponds
> > > > to
> > > > > a duration of 50 minutes which appears to be a reasonable default.
> > >
> > > Hi Steven,
> > >
> > > thanks for reviewing
> > >
> > > > I have no opinion about this, lgtm
> > >
> > > Neither do I. As this is a reversion, I meant to say that the original value
> > wasn't irrational as it might have  appeared when the change to 3 was made.
> > > Whether it's 100, 1000 or 10000 might be debatable, just 3 is way too low,
> > so without any strong reason towards 100 or 10000, I think that going back
> > to the original value makes the most sense.
> > 
> > If 3 is too small and 1000 is too large then try the value in the middle
> > sqrt(3*1000) = ~50
> 
> How about 
> 
> (3 + 1000) / 2 = ~501
> 
> or 
> 
> sin((asin(0.003) + asin(1)) /2) * 1000 = ~708
> 
> 😊

our goal is to bisect the space to find a point more people are happy
with

999 and 1000 differ less than 3 and 4 do, or in other words we care alot more
about +1 in the low numbers.

If we knew 900 is too small and 1000 is ok we would not test 950,
it no longer makes a difference

but if we knew 10 is too small and 100 is ok we would want to test something
between because it could reduce the time the player is stuck by 80%

based on above we should average in something like logarithmic space thus
e^ ((log(3) + log(1000))/2) which is again about 50

This detail matters here because the cost of bisecting by pushing changes
to master is bigger than a make call

my choice was not arbitrary :)

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

You can kill me, but you cannot change the truth.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20250227/aceb5446/attachment.sig>