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

Status: RESOLVED WONTFIX

Description

[Bobby Holley (:bholley)]

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.

Comment 1

[Karl Tomlinson (back June 25 :karlt)]

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.

Comment 2

[Sheila Mooney]

Bobby, is this still an issue?

Comment 3

[Bobby Holley (:bholley)]

(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.

Comment 4

[Jean-Yves Avenard [:jya]]

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)