Closed Bug 1091774 Opened 8 years ago Closed 7 years ago

currentTime can end up one or two frames behind when we stop to wait for more data in MSE


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






(Reporter: bholley, Unassigned)


(Blocks 1 open bug)


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.
Depends on: 1063323
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.
Depends on: 1115148
Bobby, is this still an issue?
Flags: needinfo?(bobbyholley)
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.
Flags: needinfo?(bobbyholley)
Blocks: 1182946
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)
Closed: 7 years ago
Depends on: 1191138
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.