#Miro video converter dmg update#
We expect many of these random failures will go away when the releng guys update pulseaudio on the Linux Tinderbox mochitest machines. We're still getting some random failures, but most of these are on Linux, and many of those are caused by a known bug in the version of pulseaudio running on the Tinderbox mochitest machines. Since landing on these changes Thursday PDT, we've had a lot less random orange on mozilla-central. We expect these two fixes to also reduce some random playback failures. This ensures our peak number of threads should be kept down, thus reducing peak memory usage/allocated virtual address space.Ĭoncurrently to this, Matthew Gregan identified and fixed a thread safety issue in our media decoder and another in the underlying libsydneyaudio library on Linux, which we use for audio playback.
#Miro video converter dmg plus#
I spent some time ensuring we're more proactive at shutting down the media decoder's threads (each media element requires three threads, plus one more per media element on Linux used by the sound server), and I refactored our media tests to reduce the number of tests we run in parallel. We're probably particularly vulnerable to this since we're still not doing garbage collection in xpcshell during mochitest runs. It turns out that on 32bit Linux each thread stack is assigned 10MB of virtual address space, and when you're running a lot of threads you can run out of virtual address space, causing the timeouts.
Sayrer pointed out that during some random failures in test_play_events we were timing out with mmap() faliures and almost 130 threads running. Matthew Gregan and I have taken some steps to help reduce random orange in the media mochitests. So for example, suppose you have some timeout set such as: When you set the src attribute of a media element, or add a child element to a media element, a load will be scheduled to run asynchronously as soon as the current JavaScript context exits (basically the load starts the next time we return to the browser application's main event loop). Secondly, when the load begins has changed. If you add another child element to a media element which is in networkState HTMLMediaElement.NETWORK_NO_SOURCE, it will attempt to load the resource specified by the newly added. To detect that all child elements have failed to load, check the value of the networkState attribute of the media element if its value is HTMLMediaElement.NETWORK_NO_SOURCE, you know all child elements have failed to load.
Note also that the children are loaded in the order in which they appear in the markup, and if one child successfully loads and is playable, the children after it won't be loaded.
#Miro video converter dmg mp4#
Firefox 4 does not support the playback of patent encumbered content, so you'll receive "error" events in the elements with the MP4 and 3GP resources, before the Ogg resource is loaded.
0 kommentar(er)
