1315973 - [MSE]: Playback stalls on seeking when segment doesn't start with keyframe and no keyframes are present at seek point.

Status: RESOLVED INVALID

(Core :: Audio/Video: Playback, defect)

Description

[jyotikadian28]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36

Steps to reproduce:

1. Let 1st and 2nd segment append creating buffered range as [0.066488 - 20.011788].
2. Then before appending 3rd segment, seek to time say, 48. So we append 5th segment at time 40 which creates buffered range as [0.066488 - 20.011788][41.732488 - 50.011966].
3. Now if I seek again to time 35. So now we append 4th segment at time 30 and buffered range is [0.066488 - 20.011788][33.399488 - 40.066488][41.732488 - 50.011966].
Note:
1. Duration of all segments is 10s and contains muxed audio and video samples.
2. If I don't seek in between then buffered range is 0.066488 - 50.011966 after appending first 5 segments.


Actual results:

After Step 3, it plays fine for sometime and then playback stucks at time 40.047369. Same issue happens if I seek to 32.
So even though we appended correctly, it looks like FireFox truncates samples encountered before first keyframe in any fragment which causes the problem. Is this intended?


Expected results:

Behaviour similar to Chrome where buffered range is [0 - 19.999488][40.007977 - 49.999488] after seeking at 48 and appending 5th segment at time 40. So no stalling is observed.

Comment 1

[Jean-Yves Avenard [:jya]]

You can only seek to a keyframe.
We don't go over 500ms data gaps

Per spec:
https://w3c.github.io/media-source/index.html#sourcebuffer-coded-frame-processing
Step 10:
"If the need random access point flag on track buffer equals true, then run the following steps:
If the coded frame is not a random access point, then drop the coded frame and jump to the top of the loop to start processing the next coded frame.
Set the need random access point flag on track buffer to false."

Need random access point flag is set to true because you appended segments out of order:
Step 6:
"If last decode timestamp for track buffer is set and decode timestamp is less than last decode timestamp:
OR
If last decode timestamp for track buffer is set and the difference between decode timestamp and last decode timestamp is greater than 2 times last frame duration:"

So you append a segment prior the last one appended. Need random access point flag is set to true. 

Because of this, you have the gap in the buffered range as required by the spec.

You get a buffered range with no gaps because Chrome buffered range calculation is buggy and use dts instead of pts. They are in the process of fixing it.

Best way to fix your problem, is to ensure that your segment are properly muxed and all start with a keyframe.