Closed Bug 1347101 Opened 8 years ago Closed 8 years ago

dom/media/mediasource/test/test_SeekToLastFrame_mp4.html never succeeds on win8 on treeherder

Categories

(Core :: Audio/Video: Playback, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla55
Tracking Status
firefox55 --- fixed

People

(Reporter: jya, Assigned: jya)

References

Details

Attachments

(2 files)

On whatever windows 8 is running on the treeherder machine, attempting to decode just 20 frames of video always fail: https://treeherder.mozilla.org/logviewer.html#?job_id=83265118&repo=autoland&lineNumber=2949 " 09:24:57 INFO - GECKO(1780) | MEMORY STAT | vsize 1497MB | vsizeMaxContiguous 7997072MB | residentFast 33MB | heapAllocated 18MB 09:24:57 INFO - GECKO(1780) | Decoder=56c80a6c00 MediaDecoder State: channels=2 rate=22050 hasAudio=1 hasVideo=1 mPlayState=LOADING mdsm=56d2b88800 09:24:57 INFO - GECKO(1780) | reader data: 09:24:57 INFO - GECKO(1780) | Audio Decoder: wmf audio decoder 09:24:57 INFO - GECKO(1780) | Audio Frames Decoded: 5 09:24:57 INFO - GECKO(1780) | Audio State: ni=0 no=0 wp=0 demuxr=0 demuxq=0 decoder=0 tt=-1.0 tths=-1 in=5 out=4 qs=1 pending=0 wfd=0 wfk=0 sid=40 09:24:57 INFO - GECKO(1780) | Video Decoder: RemoteVideoDecoder 09:24:57 INFO - GECKO(1780) | Hardware Video Decoding: disabled 09:24:57 INFO - GECKO(1780) | Video Frames Decoded: 0 (skipped=0) 09:24:57 INFO - GECKO(1780) | Video State: ni=0 no=0 wp=0 demuxr=0 demuxq=0 decoder=0 tt=-1.0 tths=-1 in=23 out=0 qs=23 pending:0 wfd=0 wfk=0 sid=40 09:24:57 INFO - GECKO(1780) | Dumping Data for Demuxer: 56d2b4fc00 09:24:57 INFO - GECKO(1780) | Dumping Audio Track Buffer(audio/mp4a-latm): mLastAudioTime=1.625396 09:24:57 INFO - GECKO(1780) | Audio Track Buffer Details: NumSamples=35 Size=10636 Evictable=10352 NextGetSampleIndex=35 NextInsertionIndex=35 09:24:57 INFO - GECKO(1780) | Audio Track Buffered: ranges=[(0.000000, 1.625396)] 09:24:57 INFO - GECKO(1780) | Dumping Video Track Buffer(video/avc): mLastVideoTime=1.663333 09:24:57 INFO - GECKO(1780) | Video Track Buffer Details: NumSamples=48 Size=143364 Evictable=72462 NextGetSampleIndex=47 NextInsertionIndex=48 09:24:57 INFO - GECKO(1780) | Video Track Buffered: ranges=[(0.095000, 1.696666)] 09" we have 20 input but 0 output. and that's after draining the decoder. I can't reproduce it locally in a win8 VM. Im guessing the difference is having the windows 8 SP1 or not.
On the loaner machine, the video fail to intermittently with "Video can't be played because the file is corrupt" this is using a nvidia 610GT This simple test https://people-mozilla.org/~jyavenard/tests/mse_mp4/1347101/t.html shows the problem... The error is: [2956] WARNING: NS_ERROR_DOM_MEDIA_DECODE_ERR (0x806e0004) - class RefPtr<class mozilla::MozPromise<class nsTArray<class RefPtr<class mozilla::MediaData> >,class mozilla::MediaResult,1> > __cdecl mozilla::WMFMediaDataDecoder::ProcessError(long,const char *): MFTManager::Output:80004005: file c:/jya/mozilla-central/dom/media/MediaFormatReader.cpp, line 1730 this is due to a failure to allocate a D3D11 surface, the following shows on the console: "Crash Annotation GraphicsCriticalError: |[0][GFX1-]: [D3D11] 2 CreateTexture2D f ailure Size(0,0) Code: 0x80070057 (t=32.5319) |[1][GFX1-]: [D3D11] 2 CreateTextu re2D failure Size(0,0) Code: 0x80070057 (t=32.6543) |[2][GFX1-]: [D3D11] 2 Creat eTexture2D failure Size(0,0) Code: 0x80070057 (t=32.8184) |[3][GFX1-]: [D3D11] 2 CreateTexture2D failure Size(0,0) Code: 0x80070057 (t=459.181) |[4][GFX1-]: [D3 D11] 2 CreateTexture2D failure Size(0,0) Code: 0x80070057 (t=459.384) |[5][GFX1- ]: [D3D11] 2 CreateTexture2D failure Size(0,0) Code: 0x80070057 (t=459.587) |[6] [GFX1-]: [D3D11] 2 CreateTexture2D failure Size(0,0) Code: 0x80070057 (t=470.311 ) |[7][GFX1-]: [D3D11] 2 CreateTexture2D failure Size(0,0) Code: 0x80070057 (t=4 70.556) |[8][GFX1-]: [D3D11] 2 CreateTexture2D failure Size(0,0) Code: 0x8007005 7 (t=470.84) [GFX1-]: [D3D11] 2 CreateTexture2D failure Size(0,0) Code: 0x800700 57 "
Comment on attachment 8848308 [details] Bug 1347101: P2. Don't rely on MF_E_TRANSFORM_STREAM_CHANGE result. https://reviewboard.mozilla.org/r/121238/#review123294 ::: dom/media/platforms/wmf/WMFVideoMFTManager.cpp:949 (Diff revision 1) > return MF_E_TRANSFORM_NEED_MORE_INPUT; > } > + > if (hr == MF_E_TRANSFORM_STREAM_CHANGE) { > // Video stream output type change. Probably a geometric apperature > // change. Reconfigure the video geometry, so that we output the This comment should be updated. It wouldn't hurt to query the output type and assert that it hasn't changed to something unexpected.
Attachment #8848308 - Flags: review?(matt.woodrow) → review+
Comment on attachment 8848308 [details] Bug 1347101: P2. Don't rely on MF_E_TRANSFORM_STREAM_CHANGE result. I've done things in a similar fashion to what chromium is doing for video. They only use the subtype to find the matching IMFMediaType, so we do that for video while continue matching all attributes for audio...
Attachment #8848308 - Flags: review+ → review?(matt.woodrow)
Comment on attachment 8848308 [details] Bug 1347101: P2. Don't rely on MF_E_TRANSFORM_STREAM_CHANGE result. https://reviewboard.mozilla.org/r/121238/#review124674
Attachment #8848308 - Flags: review?(matt.woodrow) → review+
Pushed by jyavenard@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/3a43a5436e16 P1. Re-enable mochitest. r=gerald https://hg.mozilla.org/integration/autoland/rev/ad882b32f2d0 P2. Don't rely on MF_E_TRANSFORM_STREAM_CHANGE result. r=mattwoodrow
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
backed out the change for causing https://treeherder.mozilla.org/logviewer.html#?job_id=85906963&repo=mozilla-central after m-i merged to mozilla-central it seems https://hg.mozilla.org/mozilla-central/rev/ad882b32f2d0#l4.39 was causing this problems and so backed this out.
Status: RESOLVED → REOPENED
Flags: needinfo?(jyavenard)
Resolution: FIXED → ---
Backout by cbook@mozilla.com: https://hg.mozilla.org/mozilla-central/rev/fcfdeb52c2b2 Backed out changeset ad882b32f2d0 for merge bustage on a CLOSED TREE
Pushed by jyavenard@mozilla.com: https://hg.mozilla.org/mozilla-central/rev/439ee2e4fc4e eBug 1347101: P2. Don't rely on MF_E_TRANSFORM_STREAM_CHANGE result. r=mattwoodrow a=Tomcat
fixed the conflict, pushed straight to central as per discussion with :Tomcat on #developers remote: https://hg.mozilla.org/mozilla-central/rev/439ee2e4fc4ed4a82102608639d9751e376d5536
Status: REOPENED → RESOLVED
Closed: 8 years ago8 years ago
Flags: needinfo?(jyavenard)
Resolution: --- → FIXED
This patch is breaking video playback on a site, kicking an error about unsupported format I think, the message comes and goes too fast to read the entire message. NOTE: This is a 'sometime' NSFW' site: https://voyeur-house.tv/realm6/cam111 Tested on m-c tinderbox hourly build on win10 x64 wn32 build: b0494b853b51c13deef16cb463cb30f3e4c0e1d0 good 439ee2e4fc4ed4a82102608639d9751e376d5536 bad
Complete message from comment #20 above: The video playback was aborted due to a corruption problem or because the video used features your browser did not support.
Message in Browser Console: TypeError: asm.js type error: 'byteLength' is not a standard constant or typed array name viblast.remuxer.js:221:373 Media resource blob:https://voyeur-house.tv/e33f2346-66f6-4070-85fe-782cf0103879 could not be decoded.
(In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #22) > Message in Browser Console: > TypeError: asm.js type error: 'byteLength' is not a standard constant or > typed array name viblast.remuxer.js:221:373 > Media resource > blob:https://voyeur-house.tv/e33f2346-66f6-4070-85fe-782cf0103879 could not > be decoded. Please open a new bug. Thank you..
Hey jya, I'm having to push bug 1346463 to Aurora/Beta as well. Did we want to consider uplifting this and bug 1350148 to fix the underlying problem on those branches as well?
Flags: needinfo?(jyavenard)
I'm a bit concerned about the risks tbh. Aurora sure, that would give us some time to react if there are regressions. But I thought the mochitest was disabled on win8 due to this bug? /me checking... hmmm it appears that they are not.. Maybe we should just disable the mochitest on win8 for now
Flags: needinfo?(jyavenard)
I pushed the disabling patch to Aurora already (and will be doing the same for Beta soon). Though I just saw an instance of test_SeekToEnd_mp4.html hitting the same kind of timeout on Aurora today, so maybe disabling harder is in order.
there remain some intermittents on linux.. Those boxes are using an extremely old version of ffmpeg... It would be a pity to disable the tests on the assumption that it fails on linux. the tests are useful, and I doubt there's any people left in this world still using the same linux distribution as treeherder (with its 6+ years old Libav)
I was only referring to Win8. Sorry if that wasn't coming across clearly.
Depends on: 1397307
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: