Closed Bug 673698 Opened 14 years ago Closed 14 years ago

Intermittent failure test_seek.html | split.webm (or seek.webm) seek test 1: Video currentTime should be around 0.9835: 0.000662 (seeking)

Categories

(Core :: Audio/Video, defect)

Product:
Core
Component:
Audio/Video
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla13

People

(Reporter: ttaubert, Assigned: cpearce)

References

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

Patch: don't update playback position while seeking
1.52 KB, patch
roc
: review+
Details | Diff | Splinter Review
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1311425167.1311426133.16406.gz Rev3 MacOSX Leopard 10.5.8 mozilla-central opt test mochitests-1/5 on 2011/07/23 05:46:07 s: talos-r3-leopard-055 71502 ERROR TEST-UNEXPECTED-FAIL | /tests/content/media/test/test_seek.html | split.webm seek test 1: Video currentTime should be around 0.9835: 0.000662 (seeking) 71503 ERROR TEST-UNEXPECTED-FAIL | /tests/content/media/test/test_seek.html | split.webm seek test 1: Video currentTime should be around 0.9835: 0.000662 (seeked)
Summary: Intermittent failure test_seek.html | split.webm seek test 1: Video currentTime should be around 0.9835: 0.000662 (seeking) → Intermittent failure test_seek.html | split.webm (or seek.webm) seek test 1: Video currentTime should be around 0.9835: 0.000662 (seeking)
This syndrome looks suspiciously similar to bug 682141 and should maybe be bandaided in the same fashion.
I added some debug logging, and pushed to Try: https://tbpl.mozilla.org/?tree=Try&rev=6273ba68fe87 I was able to reproduce one failure with extra logging: https://tbpl.mozilla.org/php/getParsedLog.php?id=9290862&tree=Try This implies that there's a timeupdate firing before the seeking event, and that's messing up the currentTime attribute, but the seek does appear to work, and playback continues with the correct timestamps after the seek. I will investigate further.
Assignee: nobody → cpearce
The problem here is that we're playing the media, and then seeking it in the same JS calling context. Playback is starting and the current time is advancing before the seek is running however, and that time update is running during the seek, causing the current time to be near zero (since the media had started to play at t=0). So the fix is to just not allow timeupdates during seeking. Note the seek algorithm sets the current time to the seek target, so we don't need to update the playback position during a seek. Seems to prevent the orange: https://tbpl.mozilla.org/?tree=Try&rev=24533c0090c5
Attachment #596941 - Flags: review?(roc)
https://hg.mozilla.org/mozilla-central/rev/eedec300aaf0 assuming fixed, reopen if it happens on a tree having this changeset
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla13
And that's four pushes above a bug 693021 push in https://hg.mozilla.org/integration/mozilla-inbound/rev/8706180542ed, though coincidences do happen.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
per Philor, -> kinetik since his patch https://hg.mozilla.org/integration/mozilla-inbound/rev/8706180542ed for bug 693021 removed this code. Ah, intermittent timing test failures fighting with each other :-)
Assignee: cpearce → kinetik
See bug 693031 comment 78.
Assignee: kinetik → cpearce
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: