Closed Bug 881954 Opened 7 years ago Closed 7 years ago

test_too_many_elements fails with WMF backend on Windows 8

Categories

(Core :: Audio/Video, defect)

x86_64
Windows 8
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla24

People

(Reporter: cpearce, Assigned: cpearce)

References

Details

Attachments

(3 files)

We can't handle having too many WMFReaders active at any one time. In particular I can't pass test_too_many_elements on Windows if I alter it to run on an M4A file (and thus use the WMFReader). The test fails because we're failing to create new decode threads. It looks like we've got too many D3D9 threads, I assume created by DXVA initialization.

Back when I did bug 830172 I had test_too_many_elements passing on Windows 8, it doesn't now, so I must have regressed this, probably when I landed DXVA.

We should change test_too_many_elements so that it tests more backends than just the Ogg backend, so that we catch regressions like this in future.
Change test_too_many_elements to run on more general types of audio files, i.e. not just Ogg, but MP3, WAV and M4A files too. We still can't pass this test with WMF on Windows 7 yet, even with my later patches, so I don't include MPEG files on Windows<8.
Attachment #761838 - Flags: review?(paul)
* Only initialize DXVA when we know we're decoding video. This means that we won't initialize D3D9 and consume GPU resources unnecessarily.
* Limit number of decoders that can use DXVA to 8. This will reduce the use of GPU resources when decoding a ridiculous number of videos.

With this patch applied, we pass test_too_many_elements with MPEG files on Windows 8 but not 7.
Attachment #761839 - Flags: review?(paul)
I noticed that we ended up with WMFByteStream's Async IO thread pool having 50-odd threads lying around while test_too_many_elements was running.

This is because the thread pool idle thread limit default is 1, so the thread pool is very proactive about shutting down threads when they're not needed. This isn't what we want, as we end up with a bunch of not-yet-destroyed threads lying around waiting for their shutdown runner to run on the main thread, whilst the thread pool goes and creates more threads to service the readers.

So here I set the WMFByteStream's thread limit and idle thread limit to 4. This means we won't be so trigger happy with shutting down idle threads, and so we won't need to create and destroy them so much. The thread pool naturally shuts down threads that have been idle for 60 seconds.
Attachment #761840 - Flags: review?(paul)
test_too_many_elements still fails on Windows 7, but I'll file a new bug to work on that so that we can land these patches sooner.
OS: Windows 7 → Windows 8
Summary: test_too_many_elements fails with WMF backend → test_too_many_elements fails with WMF backend on Windows 8
I filed bug 857424 to work on getting test_too_many_elements to pass on Win7.
Attachment #761840 - Flags: review?(paul) → review+
Attachment #761839 - Flags: review?(paul) → review+
Attachment #761838 - Flags: review?(paul) → review+
You need to log in before you can comment on or make changes to this bug.