Fixing the codec mimetype in P6, had the side effect of Android PDM trying to use the stagefright decoder which crashes.
MozReview-Commit-ID: 1OSGGCTdGFO
--HG--
extra : rebase_source : 232c0855dbf6a880355f975418951516b759953c
The Opus decoder will error if we feed it new data if it has seen the last packet of a stream.
MozReview-Commit-ID: Kw3cZuEKxie
--HG--
extra : rebase_source : 8758ec63304677fe8ab2eeae7fc65f46de2db701
Sync with upstream. Have been using the repack script for
that last few updates.
- New splat_rust.py script to update gecko tooltool manifests.
- Drop cargo nightly repacks in favor of stable cargo.
- Build with linux32 to i586.
- Switch linux32 back to i686 in repacks.
- Add android-x86.
MozReview-Commit-ID: 6pGq7oAZV1v
--HG--
extra : rebase_source : 8ac753ac2176de60f25a07447e3931b1e38a9fd7
The WebMDemuxer added this information in the ExtraData field. However, this is incompatible with the MSE demuxer which will override the ExtraData field under some circumstances.
It's cleaner to have a dedicated field anyway.
MozReview-Commit-ID: GadD11zzZ8f
--HG--
extra : rebase_source : 9b9018bc791b224414ef223464f8d66f63ccc817
Returning already_AddRefed is by convention preferred.
MozReview-Commit-ID: 1UyIcyBm923
--HG--
extra : rebase_source : c2896b6e7935d53eec77188d16657fbe1e925ca4
For multipart images we create a MultipartImage which contains each part. Each part in turn is a VectorImage or RasterImage. The MultipartImage and each part image all have their own ProgressTracker. The ProgressTracker for the MultipartImage observes the notifications of each part image via the IProgressObserver interface. This interfaces notably has no way to notify about an image error. So when a part image has an error it never gets propagated to the MultipartImage's ProgressTracker. This confuses our assertions about consistency of progress notifications. In this case we expect that when we get the load complete notification then we either have the size of the image or we encountered an error. So if the first part of a multipart image is broken and we are unable to get a size from it we will trigger this assertion.
There are two ways to fix this. One would be to propagate errors to the MultipartImage's ProgressTracker. This would put the ProgressTracker for the MultipartImage permanently into error state and prevent showing the images from the remaining parts if one part image had an error.
So in this patch I create a way to tell a ProgressTracker that is is for a multipart image, and use that to relax the assertions. As far as I can tell our code should be able to handle "ignoring" an error in a bad part image.
Addtionaly there is a way that an error flag can get propagated to the MultipartImage's tracker: in MultipartImage::FinishTransition we get the progress directly from the part image and notify for it. This seems like an oversight as the comment at
https://dxr.mozilla.org/mozilla-central/rev/bfa85d23df57c8a1db17c99b267667becc1c4afd/image/imgRequest.cpp#989
indicates that we don't want one bad part to prevent later parts from displaying. So we add the error flag to the ones we filter out when we propagate progress.
Phil Ringnalda
Jean-Yves Avenard
Alexandre Poirot
Emilio Cobos Álvarez
James Cheng
Ralph Giles
ffxbld
Aaron Klotz
Timothy Nikkel
Mats Palmgren
Jonathan Kew
Daniel Holbert
Shu-yu Guo
Tomislav Jurin
Tooru Fujisawa