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

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

[softworkz]

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.
---
    avformat/hls: Revert "reduce default max reload to 3"
    
    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.

Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-51%2Fsoftworkz%2Fsubmit_hls_reload-v1
Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-51/softworkz/submit_hls_reload-v1
Pull-Request: https://github.com/ffstaging/FFmpeg/pull/51

 libavformat/hls.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index 045741c3b4..426cf30f70 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -2577,7 +2577,7 @@ static const AVOption hls_options[] = {
         {.str = "3gp,aac,avi,ac3,eac3,flac,mkv,m3u8,m4a,m4s,m4v,mpg,mov,mp2,mp3,mp4,mpeg,mpegts,ogg,ogv,oga,ts,vob,wav"},
         INT_MIN, INT_MAX, FLAGS},
     {"max_reload", "Maximum number of times a insufficient list is attempted to be reloaded",
-        OFFSET(max_reload), AV_OPT_TYPE_INT, {.i64 = 3}, 0, INT_MAX, FLAGS},
+        OFFSET(max_reload), AV_OPT_TYPE_INT, {.i64 = 1000}, 0, INT_MAX, FLAGS},
     {"m3u8_hold_counters", "The maximum number of times to load m3u8 when it refreshes without new segments",
         OFFSET(m3u8_hold_counters), AV_OPT_TYPE_INT, {.i64 = 1000}, 0, INT_MAX, FLAGS},
     {"http_persistent", "Use persistent HTTP connections",

base-commit: ced9fddec0e45e1ce1b3425a1fed66af971e934c
-- 
ffmpeg-codebot
_______________________________________________
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".

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

[Soft Works]

 
> This change has caused regressions for many users and consumers.

See:
- https://www.reddit.com/r/mpv/comments/181yu2z/problem_streaming_radio/ 
- https://github.com/mpv-player/mpv/issues/13428

In my case:
Restreaming HLS to HLS. The source provides segments of 15s length, while
output is 3/6s segments. This causes segments in the output playlist to be
added "in waves", i.e. 5 segments are added (roughly) at the same time after
which no more segments are added for the next 15s. As the HLS demuxer reloads
the playlist in intervals of the segment length, it can easily happen that
will reload the playlist more than 3 times until a new segment appears in the
playlist.

Other example:
Since the HLS demuxer uses the duration of the last segment instead of the
target duration for the reload interval, it can also happen that one segment is
comparably short (which is perfectly valid) which can cause the 3 reloads to be
done even before a regular segment duration has passed.

Example cases for why 1000 is a reasonable default:
When receiving (e.g. for recording) from an HLS service which looses its
upstream connection for whatever reason (network outage, DDOS, etc.) it might
recover after some time, delivering all segments since the start of the situation.
A TV receiver streams via HLS and reception gets interrupted due to weather 
conditions. The missed content is lost, but the HLS playlist can indicate a
discontinuity and resume serving segments.

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".

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

[Soft Works]

> -----Original Message-----
> From: softworkz <ffmpegagent@gmail.com>
> Sent: Sunday, January 19, 2025 9:53 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: softworkz <softworkz@hotmail.com>; softworkz
> <softworkz@hotmail.com>
> Subject: [PATCH] avformat/hls: Revert "reduce default max reload to
> 3"
> 
> 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.
> ---
>     avformat/hls: Revert "reduce default max reload to 3"
> 
>     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.
> 
> Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr-
> ffstaging-51%2Fsoftworkz%2Fsubmit_hls_reload-v1
> Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-
> ffstaging-51/softworkz/submit_hls_reload-v1
> Pull-Request: https://github.com/ffstaging/FFmpeg/pull/51
> 
>  libavformat/hls.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index 045741c3b4..426cf30f70 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -2577,7 +2577,7 @@ static const AVOption hls_options[] = {
>          {.str =
> "3gp,aac,avi,ac3,eac3,flac,mkv,m3u8,m4a,m4s,m4v,mpg,mov,mp2,mp3,mp4,m
> peg,mpegts,ogg,ogv,oga,ts,vob,wav"},
>          INT_MIN, INT_MAX, FLAGS},
>      {"max_reload", "Maximum number of times a insufficient list is
> attempted to be reloaded",
> -        OFFSET(max_reload), AV_OPT_TYPE_INT, {.i64 = 3}, 0, INT_MAX,
> FLAGS},
> +        OFFSET(max_reload), AV_OPT_TYPE_INT, {.i64 = 1000}, 0,
> INT_MAX, FLAGS},
>      {"m3u8_hold_counters", "The maximum number of times to load m3u8
> when it refreshes without new segments",
>          OFFSET(m3u8_hold_counters), AV_OPT_TYPE_INT, {.i64 = 1000},
> 0, INT_MAX, FLAGS},
>      {"http_persistent", "Use persistent HTTP connections",
> 
> base-commit: ced9fddec0e45e1ce1b3425a1fed66af971e934c
> --
> ffmpeg-codebot


PING - Maybe this wasn't recognizable as a patch due to the long text..

Thanks
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".

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

[Steven Liu]

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.
I have no opinion about this, lgtm

> ---
>     avformat/hls: Revert "reduce default max reload to 3"
>
>     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.
>
> Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-51%2Fsoftworkz%2Fsubmit_hls_reload-v1
> Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-51/softworkz/submit_hls_reload-v1
> Pull-Request: https://github.com/ffstaging/FFmpeg/pull/51
>
>  libavformat/hls.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index 045741c3b4..426cf30f70 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -2577,7 +2577,7 @@ static const AVOption hls_options[] = {
>          {.str = "3gp,aac,avi,ac3,eac3,flac,mkv,m3u8,m4a,m4s,m4v,mpg,mov,mp2,mp3,mp4,mpeg,mpegts,ogg,ogv,oga,ts,vob,wav"},
>          INT_MIN, INT_MAX, FLAGS},
>      {"max_reload", "Maximum number of times a insufficient list is attempted to be reloaded",
> -        OFFSET(max_reload), AV_OPT_TYPE_INT, {.i64 = 3}, 0, INT_MAX, FLAGS},
> +        OFFSET(max_reload), AV_OPT_TYPE_INT, {.i64 = 1000}, 0, INT_MAX, FLAGS},
>      {"m3u8_hold_counters", "The maximum number of times to load m3u8 when it refreshes without new segments",
>          OFFSET(m3u8_hold_counters), AV_OPT_TYPE_INT, {.i64 = 1000}, 0, INT_MAX, FLAGS},
>      {"http_persistent", "Use persistent HTTP connections",
>
> base-commit: ced9fddec0e45e1ce1b3425a1fed66af971e934c
> --
> ffmpeg-codebot
> _______________________________________________
> 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".


Thanks
Steven
_______________________________________________
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".

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

[Soft Works]

> -----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.

Thanks
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".

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

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1932 bytes --]

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

thx

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

The worst form of inequality is to try to make unequal things equal.
-- Aristotle

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

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

[Soft Works]

> -----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

😊
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".

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

[softworkz]

From: softworkz <softworkz@hotmail.com>

(setting to 100 as a reasonable compromise)

The 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.
---
    avformat/hls: Partially revert "reduce default max reload to 3"
    
    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.
    
    V2
    
     * reduced from 1000 to 100 (halfway) according to Michael's calcularion
       :-)

Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-51%2Fsoftworkz%2Fsubmit_hls_reload-v2
Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-51/softworkz/submit_hls_reload-v2
Pull-Request: https://github.com/ffstaging/FFmpeg/pull/51

Range-diff vs v1:

 1:  cc92f8691b ! 1:  e960ffab23 avformat/hls: Revert "reduce default max reload to 3"
     @@ Metadata
      Author: softworkz <softworkz@hotmail.com>
      
       ## Commit message ##
     -    avformat/hls: Revert "reduce default max reload to 3"
     +    avformat/hls: Partially revert "reduce default max reload to 3"
      
     -    This change has caused regressions for many users and consumers.
     +    (setting to 100 as a reasonable compromise)
     +
     +    The 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.
     @@ libavformat/hls.c: static const AVOption hls_options[] = {
               INT_MIN, INT_MAX, FLAGS},
           {"max_reload", "Maximum number of times a insufficient list is attempted to be reloaded",
      -        OFFSET(max_reload), AV_OPT_TYPE_INT, {.i64 = 3}, 0, INT_MAX, FLAGS},
     -+        OFFSET(max_reload), AV_OPT_TYPE_INT, {.i64 = 1000}, 0, INT_MAX, FLAGS},
     ++        OFFSET(max_reload), AV_OPT_TYPE_INT, {.i64 = 100}, 0, INT_MAX, FLAGS},
           {"m3u8_hold_counters", "The maximum number of times to load m3u8 when it refreshes without new segments",
               OFFSET(m3u8_hold_counters), AV_OPT_TYPE_INT, {.i64 = 1000}, 0, INT_MAX, FLAGS},
           {"http_persistent", "Use persistent HTTP connections",


 libavformat/hls.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index 045741c3b4..116dfcae95 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -2577,7 +2577,7 @@ static const AVOption hls_options[] = {
         {.str = "3gp,aac,avi,ac3,eac3,flac,mkv,m3u8,m4a,m4s,m4v,mpg,mov,mp2,mp3,mp4,mpeg,mpegts,ogg,ogv,oga,ts,vob,wav"},
         INT_MIN, INT_MAX, FLAGS},
     {"max_reload", "Maximum number of times a insufficient list is attempted to be reloaded",
-        OFFSET(max_reload), AV_OPT_TYPE_INT, {.i64 = 3}, 0, INT_MAX, FLAGS},
+        OFFSET(max_reload), AV_OPT_TYPE_INT, {.i64 = 100}, 0, INT_MAX, FLAGS},
     {"m3u8_hold_counters", "The maximum number of times to load m3u8 when it refreshes without new segments",
         OFFSET(m3u8_hold_counters), AV_OPT_TYPE_INT, {.i64 = 1000}, 0, INT_MAX, FLAGS},
     {"http_persistent", "Use persistent HTTP connections",

base-commit: ced9fddec0e45e1ce1b3425a1fed66af971e934c
-- 
ffmpeg-codebot
_______________________________________________
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".

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

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 3359 bytes --]

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 :)

thx

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

You can kill me, but you cannot change the truth.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

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

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1904 bytes --]

On Thu, Feb 27, 2025 at 04:36:56PM +0000, softworkz wrote:
> From: softworkz <softworkz@hotmail.com>
> 
> (setting to 100 as a reasonable compromise)
> 
> The 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.
> ---
>     avformat/hls: Partially revert "reduce default max reload to 3"
>     
>     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.
>     
>     V2
>     
>      * reduced from 1000 to 100 (halfway) according to Michael's calcularion
>        :-)
[...]
>  libavformat/hls.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will probably apply

thx

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

Some people wanted to paint the bikeshed green, some blue and some pink.
People argued and fought, when they finally agreed, only rust was left.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

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

[Soft Works]

> -----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".