I moved the IgnoreErrors decl so it would come after the OOMReporter decl and I
could add the new conversion operator.
MozReview-Commit-ID: B1S6DXmZfvE
The current code is a bit of a mess. This patch does the following.
- Changes the processing from backwards to forwards. This avoids the need for
all the `found` booleans, because if a flag is present multiple times, the
last one will naturally override.
- Tightens up the checking. It now doesn't use assertions, but instead returns
false if any of the options are missing arguments, or have malformed
arguments, or any of the mandatory flags are missing. (It assumes that
-appdir and -profile are optional.)
- Renames the loop variable `idx` as `i`.
- Changes `!strcmp(...)` to `strcmp(...) == 0`, because I find that clearer.
- Avoids a redundant nsCString when handling -appdir.
The patch also tweaks GeckoChildProcessHost::mGroupId, which was buggy. It
holds the appModelUserId argument, which XRE_InitChildProcess() always expects
is present in the command. But it's only set to a non-empty value in
InitWindowsGroupID(), which is only called for plugin processes. So in lots of
cases the appModelUserId argument was missing, and a different argument would
be interpreted as the appModelUserId argument (seemingly without noticeable ill
effect).
The patch changes things to mGroupId defaults to "-", which means it's always
present in the command.
Note: all this explains why the old code for ContentProcess::Init() started
processing from argument aArgc, instead of aArgc-1 as you might expect -- it
had to read one extra arg in order to see the argument following -appdir,
because XRE_InitChildProcess() was decrementing aArgc for the appModelUserId
argument even when that argument wasn't present. The new code for
ContentProcess::Init() doesn't have to read past aArgc-1 because the mGroupId
fix ensures the appModelUserId argument is always present.
MozReview-Commit-ID: 8a8k6ABYMgo
--HG--
extra : rebase_source : 70695125ee26e67af3337119f4dfc293a0dab74c
Apple layout standard has a 1:1 equivalence with the WAVE standard. As such, any streams under 18 channels, properly defining a channel layout, should play on all platform.
Otherwise, as Opus and Vorbis, the result will be platform dependent.
MozReview-Commit-ID: ID6b9u2UNQr
Under 8 channels, the audio will be reordered so it can be playable on any platforms.
Over 8 channels, the channels will be as output by the decoder. Playing of such stream will be platform dependent as neither Opus nor Vorbis define a channel layout with more than 8 channels.
With WebAudio however, the result will be platform independent (as long as you don't attempt to play it)
MozReview-Commit-ID: 93ATiKm9y20
This will allow to create an AudioConfig with an unknown or unsupported channel layout, defaulting instead to the number of channels.
MozReview-Commit-ID: IonLuo9q2a5
If a channel layout is unsupported, the AudioConverter will instead just use the channel count information to leave the data as-is, only trimming extra channels, or inserting silence if needed.
MozReview-Commit-ID: CXOjcSRsRwI
Instead we place it at 32.
Future changes will change the meaning of this limit to when we can deal with channel layout. If outside that limit the audio will be played on a best attempt basis.
MozReview-Commit-ID: EavmmcxjLI0
Channel layout is derived by the content being played. The concept of preferred layout is meaningless. Either we have a layout defined, or we don't. There's no in-between.
So we remove it.
MozReview-Commit-ID: CSCAInNmzMS
That ChannelLayout uses an AutoTArray internally makes XPCOM report them as leaking when declared as static.
They weren't use outside of ChannelLayout anyway so they can be removed.
MozReview-Commit-ID: KVqdjzvL8pr
It makes no sense to have a case for those as the data structure used (a bitmask) do not allow to represent this channel layout (a channel can only be present once). As such it was a non-functional layout
MozReview-Commit-ID: FjA0fojFcJp
