Bug 1496245 - Part 0: web-platform-test for rollback followed by SRD with different media type.
Bug 1496245 - Part 1: Allow SRD(offer) to stomp un-negotiated level mappings on our transceivers.
Bug 1496245 - Part 2: Don't create extra datachannel transceivers, just reuse (and possibly re-enable) the one we have.
Differential Revision: https://phabricator.services.mozilla.com/D8259
--HG--
extra : moz-landing-system : lando
Bug 1495569 - Part 0: web-platform-test that verifies handling of offer without mid.
Bug 1495569 - Part 1: Ensure that answers are created with the transceiver's mid when the offer did not have a mid.
Differential Revision: https://phabricator.services.mozilla.com/D8853
--HG--
extra : moz-landing-system : lando
It's not maintained and probably does not work anymore.
Differential Revision: https://phabricator.services.mozilla.com/D5438
--HG--
extra : rebase_source : ccd622e40844dda5d16266e49991462d4ea94224
For now, the H264 decoding support is rather sturdy. It handles change of resolution and content smoothly thanks to the H264Converter.
The VP8/VP9 one however, not so much.
So we make a preference to only enable H264 for now.
Depends on D7895
Differential Revision: https://phabricator.services.mozilla.com/D7908
--HG--
extra : moz-landing-system : lando
This patch sets mDecoderStatus from the GMPThread so we can eventually report
an error back to the caller. Since this done during an asynchronous call, there
is no guarantee that the error will be associated with the correct frame, but
this workaround should eventually cause an error to be signalled, so that a
PLI can be requested and video will not freeze.
--HG--
extra : rebase_source : 2c32de4218b97ce1a47c5ec118cc864fff786060
webrtc.org is picky about resolutions for simulcasst layers.
As of current it will assert that all layers have identical aspect ratio.
We handle this by ignoring layers where the aspect ratio is not the same as
the highest layer's.
The new algorithm will, when simulcast is requested and at least one layer
is scaled to something other than 1.0, try to remedy this by:
- The highest resolution layer is cropped to 16-pixel alignment, to ensure
that scaling options exist.
- A separate VideoAdapter is used for simulcast layers, with the highest
layer's resolution as an aspect ratio requirement. This forces the
simulcast adapter to retain that aspect ratio in any scaling decisions.
This doesn't make scaling decisions spec-compliant (floor the width and
height respectively) but it does allow for control of scaling via
setParameters and keeps scaling decisions in upstream code to ensure
good compat with upstream's part of the pipe; encoders, etc.
Differential Revision: https://phabricator.services.mozilla.com/D4133
--HG--
extra : moz-landing-system : lando
A failure here typically indicates a test error, so it's useful for debugging.
Differential Revision: https://phabricator.services.mozilla.com/D4124
--HG--
extra : moz-landing-system : lando
Because all Rust crates in the tree are vendored, using the wildcard
"*" version dependency could have unintended reprecussions on
rsdparsa if another crate changes its log version dependency.
This patch, along with the others associated with this bug, upgrades
the log crate to 0.4.* throughout. This has the benefit that we
can get rid of the duplicate vendored log crates in third_party/rust.
This enables us to configure it for cropping to a certain resolution alignment in a future patch.
For instance with simulcast, so we don't have to skip a layer because it is impossible to scale
the highest layer any further without losing the aspect ratio.
--HG--
extra : rebase_source : 4560c60dfa95213b2f3357d0b279c07835402b33
extra : source : e80af22a3bf37ad8fa5762d9a16d677d2befd470
This restores the separate mediapipeline and RtpLogger lazy log modules that
were unified with the Signaling log module in Bug 1402334.
Differential Revision: https://phabricator.services.mozilla.com/D4478
--HG--
extra : moz-landing-system : lando
