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.
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
Last Resolved: 3 years ago
Depends on: 1191138
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.