Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to update google webrtc source from upstream. #1

Open
cloudwebrtc opened this issue Aug 21, 2021 · 0 comments
Open

How to update google webrtc source from upstream. #1

cloudwebrtc opened this issue Aug 21, 2021 · 0 comments

Comments

@cloudwebrtc
Copy link
Member

cloudwebrtc commented Aug 21, 2021

Clone or fork the repo and switch to master

git clone https://github.com/webrtc-sdk/webrtc.git -b master webrtc-src
cd webrtc-src

Add upstream

git remote add upstream https://chromium.googlesource.com/external/webrtc.git
git fetch upstream

Edit the upstream .git/config to download branch-heads/* from googl webrtc.

  • add fetch = +refs/branch-heads/*:refs/remotes/upstream/branch-heads/* to .git/config
[remote "upstream"]
        url = https://chromium.googlesource.com/external/webrtc
        fetch = +refs/heads/*:refs/remotes/upstream/*
        fetch = +refs/branch-heads/*:refs/remotes/upstream/branch-heads/*
  • Pull all branches from upstream.

git fetch upstream
git branch -a

  • You can see that all branches look like this.
...
remotes/upstream/branch-heads/4006
remotes/upstream/branch-heads/4007
...

You can see the all branches in https://chromiumdash.appspot.com/branches.

for example:
Sync the m92 version to our repo.

M92 = refs/branch-heads/4515

git checkout -b branch-m92 remotes/upstream/branch-heads/4515
git push --set-upstream origin branch-m92

Now that you have an m version branch, you can add your own patches and compile them.

Cheers.

@cloudwebrtc cloudwebrtc pinned this issue Aug 21, 2021
@cloudwebrtc cloudwebrtc changed the title How to update google webrtc from upstream. How to update google webrtc source from upstream. Aug 21, 2021
@davidzhao davidzhao unpinned this issue Sep 10, 2021
@davidzhao davidzhao pinned this issue Sep 10, 2021
cloudwebrtc pushed a commit that referenced this issue Oct 27, 2021
…the tails.

(cherry picked from commit 5eb5bb5)

Bug: chromium:1249867
Change-Id: Ic469f6226fe079c306cec6f941eeb70d6d9094f3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231682
Commit-Queue: Jesus de Vicente Pena <[email protected]>
Reviewed-by: Per Åhgren <[email protected]>
Cr-Original-Commit-Position: refs/heads/main@{#34966}
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232322
Cr-Commit-Position: refs/branch-heads/4638@{#1}
Cr-Branched-From: fb50179-refs/heads/main@{#34960}
cloudwebrtc pushed a commit that referenced this issue Oct 27, 2021
When layers are activated/deactivated via UpdateActiveSimulcastLayers,
the flag wasn't being updated. This resulted in calls to Stop() getting
ignored after an implicit start via activating layers.

(cherry picked from commit 35b1cb4)

Bug: chromium:1234779
Change-Id: I4a72e624874526d27d3e97d6903112367c5e77fb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/227700
Reviewed-by: Magnus Flodman <[email protected]>
Commit-Queue: Tommi <[email protected]>
Cr-Original-Commit-Position: refs/heads/master@{#34654}
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/227965
Reviewed-by: Tommi <[email protected]>
Cr-Commit-Position: refs/branch-heads/4577@{#1}
Cr-Branched-From: 5196931-refs/heads/master@{#34463}
cloudwebrtc pushed a commit that referenced this issue Oct 27, 2021
As a first step we only want to enable frame pacing for the case
where min playout delay == 0 and max playout delay > 0.

(cherry picked from commit b2745ba)

Bug: chromium:1237402, chromium:1239469
Change-Id: Icf9641db7566083d0279135efa8618e435d881eb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228640
Commit-Queue: Johannes Kron <[email protected]>
Reviewed-by: Ilya Nikolaevskiy <[email protected]>
Cr-Original-Commit-Position: refs/heads/master@{#34752}
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/229187
Reviewed-by: Harald Alvestrand <[email protected]>
Cr-Commit-Position: refs/branch-heads/4606@{#1}
Cr-Branched-From: 8b18304-refs/heads/master@{#34737}
davidliu pushed a commit to davidliu/webrtc that referenced this issue Feb 8, 2022
This is a partial revert of commit f9e502d.

Reason for revert: Functionality turns out to be needed by some partners for some months more.

Original change's description:
> Remove enable_dtls_srtp option
>
> This is part of the removal of support for SDES.
>
> Bug: webrtc:11066
> Change-Id: I448d0e0032672c04c87b00550ab4b9d792071a0b
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/234864
> Reviewed-by: Henrik Boström <[email protected]>
> Commit-Queue: Harald Alvestrand <[email protected]>
> Cr-Commit-Position: refs/heads/main@{#35262}

No-Try: True
Bug: webrtc:11066, chromium:1271469
Change-Id: I79a90f025e53816789b391bc52a0e896b9be87e1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/238170
Reviewed-by: Henrik Boström <[email protected]>
Commit-Queue: Harald Alvestrand <[email protected]>
Cr-Original-Commit-Position: refs/heads/main@{#35378}
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/238844
Commit-Queue: Mirko Bonadei <[email protected]>
Reviewed-by: Harald Alvestrand <[email protected]>
Cr-Commit-Position: refs/branch-heads/4692@{webrtc-sdk#1}
Cr-Branched-From: c276aee-refs/heads/main@{#35313}
davidliu pushed a commit that referenced this issue Jul 17, 2022
A recent cleanup cl (r36900) had an unintended side-effect.

If the queue-time limit is expected to be hit, we adjust the pacing
bitrate up to make sure all packets are sent within the nominal time
frame.
However after that change we stopped adjusting the pacing rate back to
normal levels when queue clears - at least not until the next BWE
update (which is fairly often - but not immediate).

This CL fixes that, and also makes sure whe properly update the
adjusted media rate on enqueu, dequeue and set rate calls.

(cherry picked from commit df9e51a)

No-Try: True
Bug: webrtc:10809, chromium:1336956
Change-Id: If00dc35169f1a1347fea6eb44fdb2868282ed3b7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265387
Reviewed-by: Per Kjellander <[email protected]>
Commit-Queue: Erik Språng <[email protected]>
Cr-Original-Commit-Position: refs/heads/main@{#37178}
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/266021
Reviewed-by: Mirko Bonadei <[email protected]>
Reviewed-by: Philip Eliasson <[email protected]>
Cr-Commit-Position: refs/branch-heads/5112@{#1}
Cr-Branched-From: a976a87-refs/heads/main@{#37168}
@hiroshihorie hiroshihorie unpinned this issue Dec 1, 2022
giangndm-bluesea pushed a commit to giangndm-bluesea/webrtc that referenced this issue Jan 14, 2023
This interface will be implemented by P2PTransportChannel in a follow-up CL. It will allow an ICE controller to request actions to manipulate the connection used by the transport.

Bug: webrtc:14367, webrtc:1413
Change-Id: I5cd171bd09c8dfc88588f8fc06e87d74a90b5216
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/271290
Reviewed-by: Jonas Oreland <[email protected]>
Commit-Queue: Sameer Vijaykar <[email protected]>
Cr-Commit-Position: refs/heads/main@{#38062}
cloudwebrtc pushed a commit that referenced this issue Jan 18, 2023
When disabling a spatial layer, reconfiguration of the encoder is not
necessary (bitrate will never be assigned to the inactive layer anway).
This CL however makes sure we reconfigure the encoder when a spatial
layer is activated. Some encoder implementations may encoder the wrong
number of spatial layers if the active layers have not beens set
correctly.

(cherry picked from commit 17043b8)

Bug: webrtc:14809, b/261097903, chromium:1310794
Change-Id: I8d34aaec95eb50a9717c06ea38f25088e5a96429
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290560
Commit-Queue: Philip Eliasson <[email protected]>
Auto-Submit: Erik Språng <[email protected]>
Reviewed-by: Philip Eliasson <[email protected]>
Cr-Original-Commit-Position: refs/heads/main@{#38999}
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290780
Commit-Queue: Erik Språng <[email protected]>
Cr-Commit-Position: refs/branch-heads/5481@{#1}
Cr-Branched-From: 2e1a9a4-refs/heads/main@{#38901}
giangndm-bluesea pushed a commit to giangndm-bluesea/webrtc that referenced this issue Mar 31, 2023
This is exposing something that is already exposed in the legacy
getStats() API and is only available if the "video-timing" header
extension is used. Adding this metric here should unblock legacy
getStats() API deprecation. The follow-up to unship or standardize this
metric is tracked by https://crbug.com/webrtc/14586.

(cherry picked from commit c5f8f80)

Bug: webrtc:14587, chromium:1376604
Change-Id: Ic3d45b0558d7caf4be2856a4cd95b88db312f85e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/279860
Reviewed-by: Harald Alvestrand <[email protected]>
Commit-Queue: Henrik Boström <[email protected]>
Cr-Original-Commit-Position: refs/heads/main@{#38444}
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/279900
Cr-Commit-Position: refs/branch-heads/5359@{webrtc-sdk#1}
Cr-Branched-From: fb3bd4a-refs/heads/main@{#38387}
cloudwebrtc pushed a commit that referenced this issue Jun 5, 2023
If the caller calls RegisterObserver() on the network thread while the
state is not kOpen but there are queued received data, those received
data will be immediately delivered to the observer before the state is
transitioned to kOpen, which may break the observer's assertions and
cause problems.

The problem turns out to be that, when SctpDataChannel::RegisterObserver
calls DeliverQueuedReceivedData(), the data will be passed to the
observer without checking the |state_| first, meanwhile
SctpDataChannel::UpdateState does effectively check the state and
null-check |observer_| before delivering the received data. This CL
fixes this by simply making DeliverQueuedReceivedData() also check
`state_ == kOpen`. In case the state transitions to kOpen after
RegisterObserver() is called, the first DeliverQueuedReceivedData()
call will be no-op, while the second DeliverQueuedReceivedData() call
will do the work.

(cherry picked from commit 2083894)

No-Try: True
Bug: chromium:1442696
Change-Id: If25ce6a038d704939b1a8ae73d7ced110448b050
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/304687
Reviewed-by: Tomas Gunnarsson <[email protected]>
Commit-Queue: Tomas Gunnarsson <[email protected]>
Cr-Original-Commit-Position: refs/heads/main@{#40036}
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/305380
Reviewed-by: Mirko Bonadei <[email protected]>
Cr-Commit-Position: refs/branch-heads/5735@{#1}
Cr-Branched-From: df7df19-refs/heads/main@{#39949}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant