Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Seeking bug in case (bufferToKeep > bufferTimeAtTopQuality) #4464

Open
windbella opened this issue Apr 18, 2024 · 0 comments
Open

Seeking bug in case (bufferToKeep > bufferTimeAtTopQuality) #4464

windbella opened this issue Apr 18, 2024 · 0 comments
Labels

Comments

@windbella
Copy link

windbella commented Apr 18, 2024

Environment
Steps to reproduce
  1. set option
var config = {
    streaming: {
        buffer: {
            stableBufferTime: 10,
            bufferTimeDefault: 10,
            bufferTimeAtTopQuality: 10,
            bufferTimeAtTopQualityLongForm: 10,
            longFormContentDurationThreshold: 6000,
            bufferToKeep: 120,
            bufferPruningInterval: 10,
        },
    }
};
  1. Load and play video
  2. Pause (0s ~ 1s)
  3. Wait for the buffer to fill up
  4. Seek to 12 ~ 118 sec
  5. It will no longer be downloading segments.
  6. Video doesn't play when you call play.
Observed behavior
// ScheduleConstroller.js, 222L
function _shouldBuffer() {
    const currentRepresentation = representationController.getCurrentRepresentation();
    if (!type || !currentRepresentation) {
        return true;
    }
    const bufferLevel = dashMetrics.getCurrentBufferLevel(type);
    return bufferLevel < getBufferTarget();
}

When this happens, the bufferLevel is large and the _shouldBuffer method is constantly false.

// StreamProcessor.js, 296L
bufferController.prepareForPlaybackSeek()
    .then(() => {
        // Clear the buffer. We need to prune everything which is not in the target interval.
        const clearRanges = bufferController.getAllRangesWithSafetyFactor(e.seekTime); // empty
        // When everything has been pruned go on
        return bufferController.clearBuffers(clearRanges);
    })
// BufferController.js, 601L
const behindPruningRange = _getRangeBehindForPruning(seekTime, ranges); // empty
const aheadPruningRange = _getRangeAheadForPruning(seekTime, ranges); // empty

For the same reason as the code above, clearRanges will be empty.

// BufferController.js, L926
function clearBuffers(ranges) {
    return new Promise((resolve, reject) => {
        if (!ranges || !sourceBufferSink || ranges.length === 0) {
            resolve();
            return;
        }

        const promises = [];
        ranges.forEach((range) => {
            promises.push(_addClearRangeWithPromise(range));
        });


        if (!isPruningInProgress) {
            clearNextRange();
        }

        Promise.all(promises)
            .then(() => {
                resolve();
            })
            .catch((e) => {
                reject(e);
            });
    });
}

If ranges is empty, clearNextRange is not called.
Then the internal _onRemoved will not be called, nor will updateBufferLevel.
Because the bufferLevel hasn't been updated, _shouldBuffer becomes false, which means we won't receive the next buffer.

// BUfferController.js, L961
function clearBuffers(ranges) {
    return new Promise((resolve, reject) => {
        if (!ranges || !sourceBufferSink || ranges.length === 0) {
            _updateBufferLevel(); // Update bufferLevel
            resolve();
            return;
        }

I think changing the code as above should fix it.
However, there may be side effects, so I'd like you to review them.

Console output
Debug.js:169 [12734][PlaybackController] Requesting seek to time: 51 
Debug.js:169 [12739][PlaybackController] Seeking to: 51 
Debug.js:169 [12739][FragmentModel][video] abort requests 
Debug.js:169 [12740][FragmentModel][audio] abort requests 
Debug.js:169 [12740][SourceBufferSink][video] Updated append window for video. Set start to 0 and end to 634.576 
Debug.js:169 [12740][SourceBufferSink][audio] Updated append window for audio. Set start to 0 and end to 634.576 
Expected behavior

I want it to work well in situations like the above.

@windbella windbella added the Bug label Apr 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant