| Message ID | 20230510215832.1001-2-michael@niedermayer.cc |
|---|---|
| State | New |
| Headers | show |
| Series | [FFmpeg-devel,1/2] avformat/format: Stop reading data at EOF during probing | expand |
| Context | Check | Description |
|---|---|---|
| andriy/make_x86 | success | Make finished |
| andriy/make_fate_x86 | success | Make fate finished |
On Wed, May 10, 2023 at 11:58 PM Michael Niedermayer <michael@niedermayer.cc> wrote: > The 1000 did result in a apparent never ending reload loop > > How so? Somewhere overflow happens causing infinity? > Issue found by: Сергей Колесников > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> > --- > libavformat/hls.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavformat/hls.c b/libavformat/hls.c > index 11e345b280..77bce8fc0d 100644 > --- a/libavformat/hls.c > +++ b/libavformat/hls.c > @@ -2556,7 +2556,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 = 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", > -- > 2.17.1 > > _______________________________________________ > 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". >
On Thu, May 11, 2023 at 07:36:04PM +0200, Paul B Mahol wrote: > On Wed, May 10, 2023 at 11:58 PM Michael Niedermayer <michael@niedermayer.cc> > wrote: > > > The 1000 did result in a apparent never ending reload loop > > > > > How so? Somewhere overflow happens causing infinity? no, it was lack of patience each reload before the patches takes 50seconds with the testcase thats with one url which returns 55 bytes i didnt benchmark it but i would expect 1000 reloads to take about 14 hours after the bugfix it should be a bit less than 2 hours and with just 100 reloads its maybe 10minutes Why is the reload taking so long ? The RFC says this: "If the client reloads a Playlist file and finds that it has not changed, then it MUST wait for a period of one-half the target duration before retrying." Given that i think a default of 100 is actually still too much and something like 3 is better, so i will locally change the default to 3 thx [...]
diff --git a/libavformat/hls.c b/libavformat/hls.c index 11e345b280..77bce8fc0d 100644 --- a/libavformat/hls.c +++ b/libavformat/hls.c @@ -2556,7 +2556,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 = 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",
The 1000 did result in a apparent never ending reload loop Issue found by: Сергей Колесников Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> --- libavformat/hls.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)