From 5ae647f6275c02e770de6d82ca9ab15e31ea61a1 Mon Sep 17 00:00:00 2001 From: Paul Berberian Date: Mon, 13 Jan 2025 19:24:53 +0100 Subject: [PATCH] Fix initial period prediction in multithread mode While checking why some test on #1927 didn't pass I realized that this was due to an actual real performance issue in multithread mode in rare scenarios. Basically, the `WorkerMain` module - whose role is to setup everything worker-side in multithreaded mode - gives a hint of what could be expected to be the first Period to load in the content. However, it always gave the first Period - I guess we put a placeholder when first writing the code and forgot to replace it until now. As this is only a hint, this doesn't really led to any important issue, the only visible problem - and why some integration tests failed sometimes - were that the actual module relying on that information took some time (the next playback observation so from 0 to 1 second) before correcting the value. In very specific scenarios, this could mean loading 1 second later than usual (this wasn't really visible on initial load here but it happened in tests for RELOADING cases). --- src/core/main/worker/worker_main.ts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/core/main/worker/worker_main.ts b/src/core/main/worker/worker_main.ts index 6672776704..75003dc352 100644 --- a/src/core/main/worker/worker_main.ts +++ b/src/core/main/worker/worker_main.ts @@ -594,7 +594,7 @@ function loadOrReloadPreparedContent( ); StreamOrchestrator( - { initialPeriod: manifest.periods[0], manifest }, + { initialPeriod, manifest }, playbackObserver, representationEstimator, segmentSinksStore,