Closed Bug 634532 Opened 14 years ago Closed 14 years ago

Intermittent test_webgl_conformance_test_suite.html | Unexpected timeout in this test page (URL: conformance/tex-image-and-sub-image-2d-with-video.html)

Categories

(Core :: Audio/Video, defect)

Product:
Core
Component:
Audio/Video
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: philor, Assigned: wesj)

References

Details

(Keywords: intermittent-failure)

Attachments

(2 files, 1 obsolete file)

Debug info
1.91 KB, patch
dougt
: review+
Details | Diff | Splinter Review
patch v0
5.86 KB, patch
Details | Diff | Splinter Review
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1297836251.1297838383.22156.gz Rev3 Fedora 12x64 mozilla-central debug test mochitests-1/5 on 2011/02/15 22:04:11 s: talos-r3-fed64-006 WebGL mochitest: starting page conformance/tex-image-and-sub-image-2d-with-video.html ++DOMWINDOW == 18 (0x2f70bd8) [serial = 909] [outer = 0x864f2c0] [GLX] FBConfig is not double-buffered Created offscreen FBO: r: 8 g: 8 b: 8 a: 8 depth: 24 stencil: 0 --- WebGL context created: 0x5283190 35240 ERROR TEST-UNEXPECTED-FAIL | /tests/content/canvas/test/webgl/test_webgl_conformance_test_suite.html | Unexpected timeout in this test page (URL: conformance/tex-image-and-sub-image-2d-with-video.html) WebGL test error: test page timeout: conformance/tex-image-and-sub-image-2d-with-video.html
This was likely from Bug 631058. I need to look at the test again, but I suspect adding a preload attribute to the video element will fix these. Need to look a bit deeper to figure out exactly why this is happening randomly.
Ah, thanks Wesley for looking into this. If you want to look at this html file, it's at content/canvas/test/webgl/conformance/tex-image-and-sub-image-2d-with-video.html
Attached patch preload video (obsolete) — — Splinter Review
Attachment #512817 - Flags: review?(vladimir)
Attached patch Debug info — — Splinter Review
There isn't really any info printed here, so it would be nice to just see what is going on (since I can't reproduce this locally). This adds a little bit of debugging.
Attachment #512827 - Flags: review?(doug.turner)
Comment on attachment 512827 [details] [diff] [review] Debug info back out when you get more data.
Attachment #512827 - Flags: review?(doug.turner) → review+
(In reply to comment #7) > Created attachment 512817 [details] [diff] [review] > preload video This is a work around, not a fix. If you set the video to be preload=metadata and play it onloadeddata, it plays through almost immediately. It should take 5 seconds to play through. I suspect this is causing the readyState to not increase, which causes us to not dispatch the "playing" event, which the test relies upon. e.g. try loading the following markup (in the content/canvas/test/webgl/conformance/resources/ dir): <video src="red-green.webmvp8.webm" preload="metadata" controls onloadeddata="event.target.play();" width="640" height="228"></video> The video reaches the 5s mark almost instantly.
Component: Canvas: WebGL → Video/Audio
QA Contact: canvas.webgl → video.audio
Definintely a regression from bug 631058. If I replace the ResetDecode();stream->Seek(0); in the DECODING_METADATA case of nsBuiltinDecoderStateMachine::Run() with a call to |mReader->Seek(0, mStartTime, mEndTime, -1)|, it works correctly. Either nsWebMReader::ResetDecode() or the stream->Seek(0) or the combination thereof aren't behaving as expected for nsWebMReader.
Blocks: 631058
Um, yeah... not sure how I missed this during review time. I think I assumed the seek-to-zero was done via mReader->Seek, but of course you wouldn't have needed to fix mDataOffset to make that work. It's not safe to seek the stream directly because nestegg stores stream state internally. ResetDecode doesn't reset nestegg state, only nsWebMReader state. My preferred solution would be to back out the mDataOffset change and use mReader->Seek to seek the reader to the start of the media.
Attached patch patch v0 — — Splinter Review
This... but it causes test_contentDuration[3-6].html to fail.
Attachment #512817 - Attachment is obsolete: true
Attachment #512817 - Flags: review?(vladimir)
- if (NS_FAILED(stream->Seek(nsISeekableStream::NS_SEEK_SET, offset))) { + if (NS_FAILED(mReader->Seek(mStartTime, mStartTime, mEndTime, -1))) { mState = DECODER_STATE_SHUTDOWN; In the original patch, and in my patch, we need to reacquire the monitor before setting mState.
Comment on attachment 513029 [details] [diff] [review] patch v0 mState = DECODER_STATE_SHUTDOWN; Don't you need to be holding the mDecoder monitor to set this? This was a problem with the original patch in bug 631058, too, I think. Not sure if that's related to bug 634825.
Should be fixed by the backout
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Assignee: nobody → wjohnston
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: