Closed
Bug 1091774
Opened 7 years ago
Closed 6 years ago
currentTime can end up one or two frames behind when we stop to wait for more data in MSE
Categories
(Core :: Audio/Video, defect, P3)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: bholley, Unassigned)
References
(Blocks 1 open bug)
Details
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•7 years ago
|
||
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.
Updated•6 years ago
|
Priority: -- → P2
Comment 2•6 years ago
|
||
Bobby, is this still an issue?
Flags: needinfo?(bobbyholley)
Priority: P2 → P3
Reporter | ||
Comment 3•6 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)
Comment 4•6 years ago
|
||
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)
You need to log in
before you can comment on or make changes to this bug.
Description
•