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

[Soft Works <softworkz-at-hotmail.com@ffmpeg.org>]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Michael Niedermayer
> Sent: Donnerstag, 27. Februar 2025 23:58
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] avformat/hls: Revert "reduce default
> max reload to 3"
> 
> On Wed, Feb 26, 2025 at 11:38:29PM +0000, Soft Works wrote:
> >
> >
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > > Michael Niedermayer
> > > Sent: Mittwoch, 26. Februar 2025 01:39
> > > To: FFmpeg development discussions and patches <ffmpeg-
> > > devel@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@gmail.com>
> > > > > Sent: Friday, February 7, 2025 3:24 AM
> > > > > To: FFmpeg development discussions and patches <ffmpeg-
> > > > > devel@ffmpeg.org>
> > > > > Cc: softworkz <softworkz@hotmail.com>
> > > > > Subject: Re: [FFmpeg-devel] [PATCH] avformat/hls: Revert "reduce
> > > > > default max reload to 3"
> > > > >
> > > > > softworkz <ffmpegagent@gmail.com> 于2025年1月19日周日 16:52写道
> > > ：
> > > > > >
> > > > > > From: softworkz <softworkz@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 :)


Yea, that's how I understood it. With the little Math gag, I wanted to express that I do think it's largely arbitrary - at least when the value is not very low. Today I found the words that I was missing yesterday.

We agree on the premise being to find a value that will best satisfy users. The achievable maximum is: "user doesn't encounter any issues". So, the range from there goes only downwards from there and we need to ask "What would dissatisfy a user". For the parameter in question, two possible cases exist:

1. User is dissatisfied because the media pipeline ends unexpectedly due to a max_reload value too low

For example a TV recording where a network issue occurs for 10 or 20 minutes and when user comes home, gets shocked that the recording stopped instead of waiting for the signal/stream to return 


2. User is dissatisfied because max_reload is too high

Now - which cases would that be exactly? Generally, this is all about ending the processing at some point. So, the user dissatisfaction would happen when the user expects the processing to end and it doesn't end because value too high.

But _when_ exactly would the user expect it to exit? Surely something like seconds or minutes or hours. 

And here's the point: The max_reload value doesn't really have a reliable nor predictable relation to time - very vague at best. 
It depends on so many factors - like segment/target duration, which determines the allowed reload interval. It can also be that the server is very slow and it take a minute each time to respond to a playlist request.
In turn, the max_reload interval is largely incapable to satisfy a user because it cannot provide any predictable behavior. It's simply the wrong parameter for this.


Conclusion is that we cannot make anybody more or less satisfied in case 2 - so only case 1 is relevant, case 2 is arbitrary.


(you wanted the full story 😊)
sw



_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".