Closed Bug 1091774 Opened 6 years ago Closed 5 years ago
Time can end up one or two frames behind when we stop to wait for more data in MSE
See bug 1063323 comment 12. When this is done, we should be able to fix up the test in test_WaitingOnMissingData.html to check for exactly 0.8 instead of 0.7.
Matthew Gregan [:kinetik] said in bug 1063323 comment #12 > Probably couple of things going on here: > > WebMReader will be blocked waiting for the next frame so it can compute the > frame duration for the frame its current decoding, which effectively causes > a 1 frame delay. For this file, I'd expect the last frame to be produced > before blocking would be t=0.733, which the reader currently trying to > decode t=0.767 and waiting for data at offset 46719..50128 to fetch the > start time of the following frame (t=0.8) to compute the frame duration. > (Related: bug 1065207, where the WebM code tries to estimate the frame > duration without requiring the following frame's start time.) > > The state machine updates currentTime to the start time of the presented > frame as we present video and audio frames (but this file has no audio), so > currentTime could only become 0.8 once the frame starting at that time is > presented. Unless I'm misremembering, there's no code to update the > currentTime to the end time of the current frame in cases where we're > waiting on an external event before we can update currentTime again. If the > last frame we can display is the last frame reported in buffered, we'll have > a mismatch between buffered and currentTime, because currentTime will report > the start time of that frame and buffered will report the end time. > > If the buffering logic is holding back frames we could present, that should > probably be changed, since it seems like draining the queue of presentable > frames before buffering is fine.
6 years ago
Priority: -- → P2
Bobby, is this still an issue?
Priority: P2 → P3
(In reply to Sheila Mooney from comment #2) > Bobby, is this still an issue? Yes, but it only affects webm, which I believe is turned off right now.
This can't be resolved as we would have to drain the decoder which we decided isn't the proper behaviour test_WaitingOnMissingData.html as such is incorrect on expecting all decoded frames to be up to a certain value, the issue is more evident on decoder that buffer an enormous amount of frames (25+) before outputting anything (bug 1191138)
Status: NEW → RESOLVED
Closed: 5 years ago
Depends on: 1191138
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.