Update our in-tree copy of the aom reference implementation
of the av1 video codec to upstream git commit id
aadbb0251996c8ebb8310567bea330ab7ae9abe4.
This picks up recent changes and addresses a build issue on win64.
MozReview-Commit-ID: 34LXXzFtEFN
--HG--
extra : rebase_source : 0face926928de6bd1c6a1726df912bd20e363e60
Two things here:
- The default stack size of the thread pool is not very big, it's better to
stick the buffer we need on the object.
- There was a unit mismatch between bytes and samples. This changes the name to
make the unit more obvious, and fixes its usage by dividing by the sample size.
MozReview-Commit-ID: 19bbS6iGvTw
--HG--
extra : rebase_source : bb5c2c074b8c1c3d69e002c8d82f4f72cc57582d
The MoofParser's used by the MP4Demuxer, can grow very large as it keeps adding new tables and is never reset.
Once we have demuxed all data present in the MP4 media segment, we no longer require the samples table for that media segment and we can drop it from the index.
Unfortunately. some websites (in particular some using live video) use media segments containing a single sample in order to (incorrectly) reduce latency. While this is a very bad approach from a performance perspective it does happen in the wild.
MozReview-Commit-ID: I66jxcScmKM
--HG--
extra : rebase_source : d0029b74df94b92dc0a115c77f6e560b30e5ed5c
Access the MediaResource through a MediaResourceIndex, which brings caching
reads (and therefore can avoid some of the repeated locking and IOs from
consecutive read operations).
MozReview-Commit-ID: Crk6ZgLWdw8
--HG--
extra : rebase_source : 9cc8c3577747829e8bd5931e9f48c782d6423fe6
Instead of asking for permission in VideoCaptureDeviceInfoAndroid.java,
we now merely check for permission there. The actual permission prompt
now happens in WebrtcUI.js, using the new
"getUserMedia:ask-device-permission" and
"getUserMedia:got-device-permission" notifications.
MozReview-Commit-ID: DSVPjjW2JNR
Currently, if permission is first denied, the list of cameras is empty.
However, if permission is later granted, the list stays empty because we
never try to refresh the list. This patch causes us to refresh the list
when necessary.
MozReview-Commit-ID: 5eodPCWVyaP
The encrypted data is nonsensical as far as the parsing of NALs is concerned.
MozReview-Commit-ID: Hm1fJf6h2S7
--HG--
extra : rebase_source : b32f56d748ad33afbd227379c1639a5aa449fb84
mfbt's Vector is actually infallible by default, so it would crash in case of
OOM. I'm switching to nsTArray, and using fallible AppendElements in
ByteWriter.
MozReview-Commit-ID: F7TBpCyIlg
--HG--
extra : rebase_source : 54f21d3c6ddb99cb8f83f86a08e2aecf7ce36a31
This applies the fix from Bug 1354207 to the libyuv moz.build.
--HG--
extra : rebase_source : 006b869166a0c361fb006226a3769fb975b3dcb7
extra : amend_source : a3f9336cd38d07e37c31ec4f3f0614dee89cb1ed
Still left TODO:
* add an aboutWebrtc.js section
* write tests
MozReview-Commit-ID: DwFxq19KWeu
--HG--
extra : rebase_source : fad3018d851316af83df48c62db16028a1a84b5c
ViERenderer is not used anywhere but has a couple calls to the obsolete
GeckoAppShell orientation listener. The entire ViERenderer.java file is
getting removed in the upcoming WebRTC update, so we should just go
ahead and remove those lines.
MozReview-Commit-ID: AwG7dBg5MV8
This fixes a quality issue with the surround-sound encoder
handling loud signals.
MozReview-Commit-ID: EkzEqs9io6N
--HG--
extra : rebase_source : 15e31af6865f0726beae0a988cb986bd182bac8e