Closed Bug 634532 Opened 13 years ago Closed 13 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)


(Core :: Audio/Video, defect)

Not set





(Reporter: philor, Assigned: wesj)



(Keywords: intermittent-failure)


(2 files, 1 obsolete file)
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

Attached patch preload video (obsolete) — Splinter Review
Attachment #512817 - Flags: review?(vladimir)
Attached patch Debug infoSplinter 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=";" width="640" height="228"></video>

The video reaches the 5s mark almost instantly.
Component: Canvas: WebGL → Video/Audio
QA Contact: canvas.webgl →
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 v0Splinter 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
Closed: 13 years ago
Resolution: --- → FIXED
Assignee: nobody → wjohnston
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.