This reduces dependency on the struct RTCPReportBlock and would allow to
delete it in favor of class ReportBlockData
Bug: None
Change-Id: Ia46a2516e26453724eed2e499f475f65df6cd3fa
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/304163
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39990}
This reduces dependency on the struct RTCPReportBlock and would allow to
delete it in favor of class ReportBlockData
Bug: None
Change-Id: I93874c4f54cf62af0c16ae26e2231b8fb49f195d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/304161
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Auto-Submit: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39985}
Per the docs, the caller is responsible for freeing the memory.
Bug: chromium:1441804
Change-Id: I9aaae493a1a86d8ab4f03930715a643a3c9fb61b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/304061
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39983}
ReportBlockData class is better documented and has wider usage.
Bug: webrtc:13757
Change-Id: Ie5f2275f2f0236267172e6dd1ce5c2dfb2193ba0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/304101
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39980}
These accessors would allow to deprecated report_block() accessor and
then would allow to remove redundant RTCPReportBlock and ReportBlock types converging on single
ReportBlockData type to pass that information across WebRTC components
helpers like fraction_lost() and jitter() would also allow to unify conversion of the rtp specific format into more common way of represent such information
Bug: None
Change-Id: I3c97f96affcf83b529095899bd63af007f8b4014
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/303880
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39975}
enable_safe_libcxx will be overridable by projects that embed Chrome's
//build using the build_overrides mechanism. All downstream projects
will need to define this new variable so Chrome can stop conditionally
defining enable_safe_libcxx upstream.
Bug: chromium:1385662
Change-Id: I62e8cf7988b76eed48c95c4993f4aea73a164bc7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/293981
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39974}
When testing manually with gstreamer and v4l2loopback, the incoming
buffer is often larger than the expected size. This change allows
such frames, while still logging the error.
Bug: webrtc:14830
Change-Id: I399aa55af6437d75b50830166a667547f6d144d4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291530
Commit-Queue: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39972}
Improves the capture latency by reducing the amount of
copying needed from the frame. We keep track of the
damaged region of previous frame and union it with
the damaged region of this frame and only copy this
union of the frame over. X11 capturer already has
such synchronization in place.
The change is beneficial especially when there are
small changes on the screen (e.g. clock ticking).
For a 4k screen with 128 cores, I observed the
capture latencies drop from 5 - 8 ms to 0 ms when the
system is left idle. This is in line with the X11
capturer.
Bug: chromium:1291247
Change-Id: Iffb441f9e1902d2658031f5f35b5372ee8e94073
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/299720
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Salman Malik <salmanmalik@chromium.org>
Cr-Commit-Position: refs/heads/main@{#39968}
This allows encoded frames to be written to any encoded insertable
streams writer without needing to somehow set valid RTP sequence
numbers. Assumes streams are using the Dependency Descriptor header ext.
A short term fix while we discuss whether we can remove the sequence
number check in RtpFrameReferenceFinder::ManageFrame.
Bug: chromium:1439799
Change-Id: I3c1d83793cd8b6cae2a8ad2129b3b6daab1d11c4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/302301
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Tony Herre <herre@google.com>
Cr-Commit-Position: refs/heads/main@{#39966}
With repeated CreateSynchronizedFrameScheduler/Stop calls, the
DecodeSynchronizer can register & keep multiple callbacks in
the metronome. Fix this to only keep at most one callback
installed.
Fixed: chromium:1434747
Change-Id: I61f67a871339dbcc7560e9d545a5217f361a9b87
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/303840
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39964}
Instead of crashing with a CHECK fail when an insertable stream of a
Video RTPSender is given a frame from an RTPReceiver's insertable
stream, construct a reasonable analogous sender frame and pass it
through to be decoded.
A small step towards removing the split we have between Sender and
Receiver implementations of TransformableFrameInterface which just
confuses users of the API.
Counterpart to https://webrtc-review.googlesource.com/c/src/+/301181 in
the opposite direction.
Bug: chromium:1250638
Change-Id: If66da7d553f14979ff1c5b4e00bff715f58cfce0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/303480
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Tony Herre <herre@google.com>
Reviewed-by: Palak Agarwal <agpalak@google.com>
Cr-Commit-Position: refs/heads/main@{#39963}
This enables clients of EglBase to keep using it but
share underlying EGLContext with other clients.
go/meet-android-eglcontext-reduction
Bug: b/225229697
Change-Id: I42719f25be7db169c39878b57a5f1487e3c1894e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/301941
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Commit-Queue: Linus Nilsson <lnilsson@webrtc.org>
Reviewed-by: Xavier Lepaul <xalep@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39961}
* retransmittedBytesReceived
* retransmittedPacketsReceived
added to the specification in
https://github.com/w3c/webrtc-stats/pull/735
BUG=webrtc:15096
Change-Id: I6770e5d8d09ac1c2693c918fd943b0ab257ec7ba
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295260
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#39959}
which gets assigned from a uint32_t VideoReceiverInfo::frames_received so should remain an unsigned type
BUG=None
Change-Id: I1db6a3f96c4ff49eee72dcce54eb6fff346c128c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/302342
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#39958}
Can be used to calculate the average delayed packet outage duration and
number of packet loss events by subtracting from concealment events.
Only used in simulations currently.
Bug: None
Change-Id: I03740a2bcb781af09e28a4d13d9e41c0f84bc506
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/303600
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39957}
This should not be relevant anymore and is causing some issues due to
SetMinimumDelay events early in the log.
Bug: None
Change-Id: Ib7e3c624608c9bceaed31bd6669db59887d24659
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/303580
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39956}
This makes the device light turn off when stopped.
Bug: webrtc:15109
Change-Id: I1deecbc2463e2e316e01ff1f061ab6b0313c1aa1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/302200
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39953}
The fixes have been default enabled, so clean up dead code.
Bug: webrtc:14334
Change-Id: I4967d5ad451ac333c54294fc14bea6c7ba1445e3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/301180
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Commit-Queue: Sameer Vijaykar <samvi@google.com>
Cr-Commit-Position: refs/heads/main@{#39949}
which only had a single member after the removal of
GICE around M42. The last downstream usage in Chromoting
was removed in
https://chromium-review.googlesource.com/c/chromium/src/+/4385113
BUG=webrtc:4299
Change-Id: Id444967822cd19b0e514ba70739a8d45a7f78fae
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/299600
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#39945}
This is in preparation of using the state that SourceTracker manages
for more things than only getContributingSources. Audio levels reported
via getStats(), aren't consistent with levels reported via getCS.
Since more operations will be derived from the ST owned data, moving
the management of it away from the audio thread, reduces the potential
of contention.
Bug: webrtc:14029, webrtc:7517, webrtc:15119
Change-Id: I553f7e473316a1c61eeb43ded905a18242a04424
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/302280
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39943}
Assuming 15Mbps video bitrate at 30fps, a single frame is 62500 bytes.
Add to that some fluctuations in encoder output rate and capture fps,
and frames can easily become larger than 64kb.
Given enough bandwidth and the bursty pacer, it will not be uncommon to
send the entire frame in one batch - and if the send buffer is at 64kb
then you will likely get packetloss already in the IPC packet socket,
even before the packet has reached the network card!
It's not entirely clear what the optimal size is, but given that the
receive buffer size was increased from 64kb to 256kb for high bandwidth
receive scenarios and had negligible negative effects I think it's
pretty safe to bump the send buffer to match.
There is a field trial available that can be used as circuit breaker
in case things turn south: WebRTC-SendBufferSizeBytes
Bug: webrtc:14780
Change-Id: I6c786d993181a882e6dce832ff56dc92d2a8a341
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290985
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39942}
