Rename those two function to better name alignment with AddDirectListener and AddDirectTrackListener.
MozReview-Commit-ID: 6QY08oyih1X
--HG--
extra : rebase_source : e0f2ac5de75d54a870f5a99f08505e40aa0696d9
This changes the static threshold in screensharing mode and ensures that the
screensharing mode is in fact passed to the codec.
This also causes the peer connection to update the media pipelines when a track is
replaced to cause the codec to be notified that the source has changed and to
change settings appropriately. It seems to be a common use case to have a camera
track be replaced by a screenshare track during a call.
MozReview-Commit-ID: HbV14uL4kIL
--HG--
extra : rebase_source : 34d9fff2efb777bdfd5887db879184bc4ffc7442
We can avoid a struct/class mismatch in MediaExtractor.h.
TypeHelpers.h has extraneous |template<>| specializations that don't
actually specialize anything.
We had two potentials rounding issue occurring. The one causing the problem is that adding an int64 with a float is a float, and would be limited to 24bits mantissa.
The other, could be that rounding would occur if the segment duration was over 16s long, as that too would exceed the representation range as we using microseconds representation internally.
MozReview-Commit-ID: FyBTGvfg25I
--HG--
extra : transplant_source : %D0%14u%E3%1E%C6%D2%FC4%A4%2B%C0%20k%05%E8%90qz%2B
We had two potentials rounding issue occurring. The one causing the problem is that adding an int64 with a float is a float, and would be limited to 24bits mantissa.
The other, could be that rounding would occur if the segment duration was over 16s long, as that too would exceed the representation range as we using microseconds representation internally.
MozReview-Commit-ID: FyBTGvfg25I
--HG--
extra : rebase_source : bb0fff71bfdcaef8e76148bf59a73809e4737024
My guess is that the application generating those files, does a very rough estimate on what the sample table size is going to be, which allows to perform the conversion in a single pass. This allows to place the moov box at the beginning.
MozReview-Commit-ID: IGzxTho4Akk
--HG--
extra : rebase_source : b6ca711a00f8b2d7d8708acdd17f52f59b469685
Bring in updated nestegg library, the newly exposed encryption
functionality will be used to enable WebM EME.
MozReview-Commit-ID: Hv6hSFjlS5c
--HG--
extra : rebase_source : c759a702c205111d65aa2002564559210c662d5f
We think thread::spawn() may be panicking in low memory
conditions. Test this by using the fallible thread::Builder
API and converting spawn Results into an error return.
MozReview-Commit-ID: 36pDaWsR2p8
--HG--
extra : rebase_source : 058273473564fa4c3b3da4cbd231efd9003a7d05
We've audited this code, so the calls inside the closure should
be panic-free. Meanwhile the thread join() itself seems to be
panicing on windows. This will at least get us a more obvious
crash.
MozReview-Commit-ID: JXoDOOu2x0K
--HG--
extra : rebase_source : 661da4e8e8dc98e25b318a51c49a406ee86beb46
This change RTCPeerConnection.addTrack() to allow any MediaStream as argument.
The MediaStream is in the end used as an identifier of how the tracks will be
grouped together on the receiving side of the peer connection.
MozReview-Commit-ID: 9wDPOmMHYDc
--HG--
extra : rebase_source : 5fd59853c2d207cbcdaa1e4a767b3c4de20a1beb
extra : histedit_source : 2b88e899a329df07a46c1f12e449956d59645cf7
We have GetTrackById() now that does essentially the same thing.
Also, GetVideoTrackByTrackId() was too focused on the owning MediaStream and
didn't work.
MozReview-Commit-ID: 9z3rg4FI9H8
--HG--
extra : rebase_source : 7e295dc19b41b62f809977b6b73d2729f127d08a
extra : histedit_source : 39ab0f08939825c341b136150760e02c92fac970
Paul Adenot
Nils Ohlmeier [:drno]
Chris Peterson
Byron Campen [:bwc]
Munro Mengjue Chiang
Sebastian Hengst
ctai
Dan Minor
Jonathan Watt
Michael Froman
Andrea Marchesini
Nathan Froyd
Makoto Kato
Benoit Girard
Jet Villegas
Carsten "Tomcat" Book
Jean-Yves Avenard
Randell Jesup
Matthew Gregan
Kilik Kuo
Ryan VanderMeulen
Ralph Giles
Bryce Van Dyk
Jeff Muizelaar
Andreas Pehrson