Closed Bug 1347101 Opened 7 years ago Closed 7 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
https://hg.mozilla.org/mozilla-central/rev/3a43a5436e16
https://hg.mozilla.org/mozilla-central/rev/ad882b32f2d0
Status: NEW → RESOLVED
Closed: 7 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: 7 years ago7 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: