In this bug we're moving away from monolithic JNI headers to class-specific
headers so that we don't have to rebuild the world every time we make a change
to a JNI interface.
Differential Revision: https://phabricator.services.mozilla.com/D75376
In this bug we're moving away from monolithic JNI headers to class-specific
headers so that we don't have to rebuild the world every time we make a change
to a JNI interface.
Differential Revision: https://phabricator.services.mozilla.com/D75375
The current code will only set the TranmissionOffset extension if
capture_time_ms is > 0, but when adjusting timestamps for rtx packets, it is
adjusted without first checking to see if it is valid, which will cause invalid
values of capture_time_ms to be written to TranmissionOffset, leading to assertion
failures.
This bug is still present on tip of libwebrtc, so we'll also need to prepare a
patch for upstream.
Depends on D74842
Differential Revision: https://phabricator.services.mozilla.com/D75528
This imports a few fixes from tip of libwebrtc, which now supports mid, rid
and rrid. The rtx packet is now allocated as max_packet_size_, which is
necessary to have enough capacity for the rrid. It takes the
CopyHeaderAndExtensionsToRtxPacket function from upstream, which omits
copying extensions that should not be copied over, such as rid. It is necessary
to make AllocateExtension and FindExtension public in order for this
function to work.
It then copies the rid from the source packet over to rrid in the rtx packet.
Upstream has code for this as well, but taking it would require more
extensive changes to our copy of libwebrtc. We can drop these local
modifications with the next update.
Differential Revision: https://phabricator.services.mozilla.com/D74840
In order for the SendSideCongestionController to work properly, it needs the
timestamp at which the packets were sent. This is set by calling
Call::OnSentPacket when a packet is sent. Without the sent timestamp, it drops
the estimated available bandwidth so low that only one simulcast stream will
be allocated any bandwidth.
Differential Revision: https://phabricator.services.mozilla.com/D75310
This imports a few fixes from tip of libwebrtc, which now supports mid, rid
and rrid. The rtx packet is now allocated as max_packet_size_, which is
necessary to have enough capacity for the rrid. It takes the
CopyHeaderAndExtensionsToRtxPacket function from upstream, which omits
copying extensions that should not be copied over, such as rid. It is necessary
to make AllocateExtension and FindExtension public in order for this
function to work.
It then copies the rid from the source packet over to rrid in the rtx packet.
Upstream has code for this as well, but taking it would require more
extensive changes to our copy of libwebrtc. We can drop these local
modifications with the next update.
Depends on D74839
Differential Revision: https://phabricator.services.mozilla.com/D74840
Upstream has removed the mode used when use_desktop_relative_cursor_position_
is set to false as well as the associated override of OnMouseCursorPosition,
so the next time we update libwebrtc, this is the behaviour we will have.
Enabling it now fixes cursor display on Linux, which at the moment only works
for some windows.
Depends on D71392
Differential Revision: https://phabricator.services.mozilla.com/D71394
I think inner_window_ was added to handle the fact that window_ may not be
the same as child_window which could throw off the coordinates. Since we made
these modifications, upstream has added the XTranslateCoordinates call that
handles this case, so our local modifications are no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D71392
This requires --build-peers-said-large-imports-were-ok since
third_party/rust/mp4parse/src/lib.rs is 113KB. This code is just moving from
media/mp4parse-rust to third_party/rust, so it's not really adding to net code
size.
Differential Revision: https://phabricator.services.mozilla.com/D74488
With rtx enabled, we can't just switch ssrcs when we receive a packet with an
unrecognized ssrc. This changes the ReceiveRTPPacket call to take the entire
rtp header, and then examines the payload type. If the payload type is
associated with rtx or ulpfec, the ssrc will not be changed. This is what is
done by the libwebrtc unsignaled ssrc change code, so this behaviour should
match what Chrome does.
Differential Revision: https://phabricator.services.mozilla.com/D72230
This changes the constructor to not take any parameters for consistency
with how the other parameters are handled. It also fixes serialization, the
current code will output an ascii character rather than the numeric value.
Differential Revision: https://phabricator.services.mozilla.com/D72222
We currently retry sending queries on all failures to write to the socket on
the assumption that write errors represent transient errors. With this change,
we treat EPERM has a permanent error and drop queries if we see it. This is
not a problem when sending answers, as we don't retry in case of errors there,
on the assumption that the other side will retry their query in the future.
We do have code to limit the number of times we attempt an mDNS query, but we
didn't hit it in this case, because it only counts sends that are successful.
Differential Revision: https://phabricator.services.mozilla.com/D73492