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

RESOLVED WONTFIX

Status

()

P3
normal
RESOLVED WONTFIX
4 years ago
3 years ago

People

(Reporter: bholley, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
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.
(Reporter)

Updated

4 years ago
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.
Priority: -- → P2
Depends on: 1115148

Comment 2

4 years ago
Bobby, is this still an issue?
Flags: needinfo?(bobbyholley)
Priority: P2 → P3
(Reporter)

Comment 3

4 years ago
(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)

Updated

3 years ago
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)
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.