Skip to content

Commit 5ae647f

Browse files
committed
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).
1 parent bab7958 commit 5ae647f

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

src/core/main/worker/worker_main.ts

+1-1
Original file line numberDiff line numberDiff line change
@@ -594,7 +594,7 @@ function loadOrReloadPreparedContent(
594594
);
595595

596596
StreamOrchestrator(
597-
{ initialPeriod: manifest.periods[0], manifest },
597+
{ initialPeriod, manifest },
598598
playbackObserver,
599599
representationEstimator,
600600
segmentSinksStore,

0 commit comments

Comments
 (0)