Skip to content

Commit

Permalink
Tizen: don't directly seek over discontinuity on tizen
Browse files Browse the repository at this point in the history
We have in the RxPlayer a really reactive discontinuity-detection mechanism which seeks over seen holes in the buffer that won't be filled.

A few subset of the smaller of those holes could theoretically be already be seeked over by the browser/device logic, but to have a faster generalization, we generally seek directly and do not wait to observe what the browser or device will do.

But with Tizen (samsung TVs) this may cause sometimes problems as seeking is approximate on those devices.
We could thus seek over a discontinuity, yet have tizen seeking before it.

We already have a complex code detecting this exact scenario to avoid an infinite loop of discontinuity seeks when that happens, and it works.

Yet we have again seen scenarios when what we called "the seek-back issue" came to bite us: When the discontinuity is encountered at the exact beginning if the content, and we're unlucky enough for that seeking resulting in a 'freeze' (the playback does not advance despite playback conditions being OK), we encountered an infinite buffering on those Tizen devices.

To fix this, @Florent-Bouisset already proposed #1586 which allows to still un-freeze that post-initial-disconinuity-seek freeze by having less conditions to do so, which works, yet which needs to wait for our heuristic to detect a freeze, a rather long multiple-seconds process for now.

As a supplementary logic, I propose here to just let tizen encounter discontinuity for 1 second, before trying to do something. This means we risk to have a 1-2 seconds rebuffering time at real discontinuities, but it prevent all those seek-back issues when the discontinuity is automatically seeked over by the device.
  • Loading branch information
peaBerberian committed Oct 24, 2024
1 parent 98278b0 commit 09a5808
Showing 1 changed file with 8 additions and 1 deletion.
9 changes: 8 additions & 1 deletion src/main_thread/init/utils/rebuffering_controller.ts
Original file line number Diff line number Diff line change
Expand Up @@ -14,6 +14,7 @@
* limitations under the License.
*/

import isSeekingApproximate from "../../../compat/is_seeking_approximate";
import config from "../../../config";
import type { IBufferType } from "../../../core/types";
import { MediaError } from "../../../errors";
Expand Down Expand Up @@ -179,7 +180,11 @@ export default class RebufferingController extends EventEmitter<IRebufferingCont

playbackRateUpdater.startRebuffering();

if (this._manifest === null) {
if (
this._manifest === null ||
(isSeekingApproximate &&
getMonotonicTimeStamp() - rebuffering.timestamp <= 1000)
) {
this.trigger("stalled", stalledReason);
return;
}
Expand Down Expand Up @@ -235,6 +240,8 @@ export default class RebufferingController extends EventEmitter<IRebufferingCont
positionBlockedAt,
);
if (
(!isSeekingApproximate ||
getMonotonicTimeStamp() - rebuffering.timestamp > 1000) &&
this._speed.getValue() > 0 &&
nextBufferRangeGap < BUFFER_DISCONTINUITY_THRESHOLD
) {
Expand Down

0 comments on commit 09a5808

Please sign in to comment.