Found via supersize query:
size_info.symbols.WhereFullNameMatches(r'\bk[A-Z]').WhereInSection('d')
This moves 90 symbols from .data -> .data.rel.ro (5.50kb)
BUG=chromium:747064
Review-Url: https://codereview.webrtc.org/2986163002
Cr-Commit-Position: refs/heads/master@{#19274}
Can be enabled by setting "enable_encrypted_rtp_header_extensions" in
"crypto_options" of "PeerConnectionFactoryInterface::Options" and will
only be used if both peers support it.
BUG=webrtc:3411
Review-Url: https://codereview.webrtc.org/2761143002
Cr-Commit-Position: refs/heads/master@{#18842}
Timing information is gathered in EncodedImage,
starting at encoders. Then it's sent using RTP header extension. In the
end, it's gathered at the GenericDecoder. Actual reporting and tests
will be in the next CLs.
BUG=webrtc:7594
Review-Url: https://codereview.webrtc.org/2911193002
Cr-Commit-Position: refs/heads/master@{#18659}
Reason for revert:
Breaks android buildbots.
Original issue's description:
> Reland of Add content type information to encoded images and corresponding rtp extension header (patchset #1 id:1 of https://codereview.webrtc.org/2816463002/ )
>
> Reason for revert:
> Reland with appropriate changes to API to not break depending projects.
>
> Original issue's description:
> > Revert of Add content type information to encoded images and corresponding rtp extension header (patchset #31 id:600001 of https://codereview.webrtc.org/2772033002/ )
> >
> > Reason for revert:
> > Breaks dependent projects.
> >
> > Original issue's description:
> > > Add content type information to Encoded Images and add corresponding RTP extension header.
> > > Use it to separate UMA e2e delay metric between screenshare from video.
> > > Content type extension is set based on encoder settings and processed and decoders.
> > >
> > > Also,
> > > Fix full-stack-tests to calculate RTT correctly, so new metric could be tested.
> > >
> > > BUG=webrtc:7420
> > >
> > > Review-Url: https://codereview.webrtc.org/2772033002
> > > Cr-Commit-Position: refs/heads/master@{#17640}
> > > Committed: 64e739aeae
> >
> > TBR=tommi@webrtc.org,sprang@webrtc.org,stefan@webrtc.org,nisse@webrtc.org,mflodman@webrtc.org
> > # Skipping CQ checks because original CL landed less than 1 days ago.
> > NOPRESUBMIT=true
> > NOTREECHECKS=true
> > NOTRY=true
> > BUG=webrtc:7420
> >
> > Review-Url: https://codereview.webrtc.org/2816463002
> > Cr-Commit-Position: refs/heads/master@{#17644}
> > Committed: 5721866808
>
> TBR=tommi@webrtc.org,sprang@webrtc.org,stefan@webrtc.org,nisse@webrtc.org,mflodman@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:7420
>
> Review-Url: https://codereview.webrtc.org/2812913002
> Cr-Commit-Position: refs/heads/master@{#17651}
> Committed: 774f6b4b96TBR=tommi@webrtc.org,sprang@webrtc.org,stefan@webrtc.org,nisse@webrtc.org,mflodman@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:7420
Review-Url: https://codereview.webrtc.org/2809653004
Cr-Commit-Position: refs/heads/master@{#17653}
Reason for revert:
Reland with appropriate changes to API to not break depending projects.
Original issue's description:
> Revert of Add content type information to encoded images and corresponding rtp extension header (patchset #31 id:600001 of https://codereview.webrtc.org/2772033002/ )
>
> Reason for revert:
> Breaks dependent projects.
>
> Original issue's description:
> > Add content type information to Encoded Images and add corresponding RTP extension header.
> > Use it to separate UMA e2e delay metric between screenshare from video.
> > Content type extension is set based on encoder settings and processed and decoders.
> >
> > Also,
> > Fix full-stack-tests to calculate RTT correctly, so new metric could be tested.
> >
> > BUG=webrtc:7420
> >
> > Review-Url: https://codereview.webrtc.org/2772033002
> > Cr-Commit-Position: refs/heads/master@{#17640}
> > Committed: 64e739aeae
>
> TBR=tommi@webrtc.org,sprang@webrtc.org,stefan@webrtc.org,nisse@webrtc.org,mflodman@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:7420
>
> Review-Url: https://codereview.webrtc.org/2816463002
> Cr-Commit-Position: refs/heads/master@{#17644}
> Committed: 5721866808TBR=tommi@webrtc.org,sprang@webrtc.org,stefan@webrtc.org,nisse@webrtc.org,mflodman@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:7420
Review-Url: https://codereview.webrtc.org/2812913002
Cr-Commit-Position: refs/heads/master@{#17651}
Reason for revert:
Relanded by mistake.
Original issue's description:
> Reland of Add content type information to encoded images and corresponding rtp extension header (patchset #1 id:1 of https://codereview.webrtc.org/2816463002/ )
>
> Reason for revert:
> Reland with fixes which break API
>
> Original issue's description:
> > Revert of Add content type information to encoded images and corresponding rtp extension header (patchset #31 id:600001 of https://codereview.webrtc.org/2772033002/ )
> >
> > Reason for revert:
> > Breaks dependent projects.
> >
> > Original issue's description:
> > > Add content type information to Encoded Images and add corresponding RTP extension header.
> > > Use it to separate UMA e2e delay metric between screenshare from video.
> > > Content type extension is set based on encoder settings and processed and decoders.
> > >
> > > Also,
> > > Fix full-stack-tests to calculate RTT correctly, so new metric could be tested.
> > >
> > > BUG=webrtc:7420
> > >
> > > Review-Url: https://codereview.webrtc.org/2772033002
> > > Cr-Commit-Position: refs/heads/master@{#17640}
> > > Committed: 64e739aeae
> >
> > TBR=tommi@webrtc.org,sprang@webrtc.org,stefan@webrtc.org,nisse@webrtc.org,mflodman@webrtc.org
> > # Skipping CQ checks because original CL landed less than 1 days ago.
> > NOPRESUBMIT=true
> > NOTREECHECKS=true
> > NOTRY=true
> > BUG=webrtc:7420
> >
> > Review-Url: https://codereview.webrtc.org/2816463002
> > Cr-Commit-Position: refs/heads/master@{#17644}
> > Committed: 5721866808
>
> TBR=tommi@webrtc.org,sprang@webrtc.org,stefan@webrtc.org,nisse@webrtc.org,mflodman@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:7420
>
> Review-Url: https://codereview.webrtc.org/2811963002
> Cr-Commit-Position: refs/heads/master@{#17645}
> Committed: 4fa0c4f97fTBR=tommi@webrtc.org,sprang@webrtc.org,stefan@webrtc.org,nisse@webrtc.org,mflodman@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:7420
Review-Url: https://codereview.webrtc.org/2810923004
Cr-Commit-Position: refs/heads/master@{#17648}
Reason for revert:
Reland with fixes which break API
Original issue's description:
> Revert of Add content type information to encoded images and corresponding rtp extension header (patchset #31 id:600001 of https://codereview.webrtc.org/2772033002/ )
>
> Reason for revert:
> Breaks dependent projects.
>
> Original issue's description:
> > Add content type information to Encoded Images and add corresponding RTP extension header.
> > Use it to separate UMA e2e delay metric between screenshare from video.
> > Content type extension is set based on encoder settings and processed and decoders.
> >
> > Also,
> > Fix full-stack-tests to calculate RTT correctly, so new metric could be tested.
> >
> > BUG=webrtc:7420
> >
> > Review-Url: https://codereview.webrtc.org/2772033002
> > Cr-Commit-Position: refs/heads/master@{#17640}
> > Committed: 64e739aeae
>
> TBR=tommi@webrtc.org,sprang@webrtc.org,stefan@webrtc.org,nisse@webrtc.org,mflodman@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:7420
>
> Review-Url: https://codereview.webrtc.org/2816463002
> Cr-Commit-Position: refs/heads/master@{#17644}
> Committed: 5721866808TBR=tommi@webrtc.org,sprang@webrtc.org,stefan@webrtc.org,nisse@webrtc.org,mflodman@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:7420
Review-Url: https://codereview.webrtc.org/2811963002
Cr-Commit-Position: refs/heads/master@{#17645}
Reason for revert:
Breaks dependent projects.
Original issue's description:
> Add content type information to Encoded Images and add corresponding RTP extension header.
> Use it to separate UMA e2e delay metric between screenshare from video.
> Content type extension is set based on encoder settings and processed and decoders.
>
> Also,
> Fix full-stack-tests to calculate RTT correctly, so new metric could be tested.
>
> BUG=webrtc:7420
>
> Review-Url: https://codereview.webrtc.org/2772033002
> Cr-Commit-Position: refs/heads/master@{#17640}
> Committed: 64e739aeaeTBR=tommi@webrtc.org,sprang@webrtc.org,stefan@webrtc.org,nisse@webrtc.org,mflodman@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:7420
Review-Url: https://codereview.webrtc.org/2816463002
Cr-Commit-Position: refs/heads/master@{#17644}
Use it to separate UMA e2e delay metric between screenshare from video.
Content type extension is set based on encoder settings and processed and decoders.
Also,
Fix full-stack-tests to calculate RTT correctly, so new metric could be tested.
BUG=webrtc:7420
Review-Url: https://codereview.webrtc.org/2772033002
Cr-Commit-Position: refs/heads/master@{#17640}
This CL adds the following interfaces:
* RtpTransportController
* RtpTransport
* RtpSender
* RtpReceiver
They're implemented on top of the "BaseChannel" object, which is normally used
in a PeerConnection, and roughly corresponds to an SDP "m=" section. As a result
of this, there are several limitations:
* You can only have one of each type of sender and receiver (audio/video) on top
of the same transport controller.
* The sender/receiver with the same media type must use the same RTP transport.
* You can't change the transport after creating the sender or receiver.
* Some of the parameters aren't supported.
Later, these "adapter" objects will be gradually replaced by real objects that don't
have these limitations, as "BaseChannel", "MediaChannel" and related code is
restructured. In this CL, we essentially have:
ORTC adapter objects -> BaseChannel -> Media engine
PeerConnection -> BaseChannel -> Media engine
And later we hope to have simply:
PeerConnection -> "Real" ORTC objects -> Media engine
See the linked bug for more context.
BUG=webrtc:7013
TBR=stefan@webrtc.org
Review-Url: https://codereview.webrtc.org/2675173003
Cr-Commit-Position: refs/heads/master@{#16842}
The existence of FlexfecConfig is due to a naive design. Now when it
is not used on the receiving side (see https://codereview.webrtc.org/2542413002),
it is time to remove it from the sending side as well.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2621573002
Cr-Commit-Position: refs/heads/master@{#16097}
It will be necessary to keep the H264 profile information in
VideoReceiveStream::Decoder. I think it will be easier now and for the
future to just store all of the codec parameters unmodified in
VideoReceiveStream::Decoder instead of extracting a subset of them to an
ad hoc class.
BUG=webrtc:6743,webrtc:5948
Review-Url: https://codereview.webrtc.org/2523773003
Cr-Commit-Position: refs/heads/master@{#15239}
This CL interfaces the SDP information (payload types and
SSRCs) about FlexFEC with the corresponding configs at the
Call layer. It also adds a field trial, which when active
will expose FlexFEC in the default codec list, thus showing
up in the default SDP.
BUG=webrtc:5654
R=magjed@webrtc.org, stefan@webrtc.orgCC=perkj@webrtc.org
Review-Url: https://codereview.webrtc.org/2511703002
Cr-Commit-Position: refs/heads/master@{#15184}
Reason for revert:
Relanding, now that downstream issues have been fixed.
Original issue's description:
> Revert of Declare VideoCodec.codec_specific_info private (patchset #5 id:80001 of https://codereview.webrtc.org/2452963002/ )
>
> Reason for revert:
> Broke a google3 build
>
> Original issue's description:
> > Declare VideoCodec.codec_specific_info private
> >
> > This completes the privatization of the codec specific
> > information in VideoCodec.
> >
> > BUG=webrtc:6603
> >
> > Committed: https://crrev.com/792738640234d81c916ac4458ac72286cb2548a4
> > Cr-Commit-Position: refs/heads/master@{#15013}
>
> TBR=tommi@chromium.org,magjed@chromium.org,tommi@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:6603
>
> Committed: https://crrev.com/7fe6db91d99cf6d43874651bcca56092cf869e2f
> Cr-Commit-Position: refs/heads/master@{#15027}
TBR=tommi@chromium.org,magjed@chromium.org,tommi@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6603
Review-Url: https://codereview.webrtc.org/2494683006
Cr-Commit-Position: refs/heads/master@{#15041}
Reason for revert:
Broke a google3 build
Original issue's description:
> Declare VideoCodec.codec_specific_info private
>
> This completes the privatization of the codec specific
> information in VideoCodec.
>
> BUG=webrtc:6603
>
> Committed: https://crrev.com/792738640234d81c916ac4458ac72286cb2548a4
> Cr-Commit-Position: refs/heads/master@{#15013}
TBR=tommi@chromium.org,magjed@chromium.org,tommi@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6603
Review-Url: https://codereview.webrtc.org/2491933002
Cr-Commit-Position: refs/heads/master@{#15027}
This completes the privatization of the codec specific
information in VideoCodec.
BUG=webrtc:6603
Review-Url: https://codereview.webrtc.org/2452963002
Cr-Commit-Position: refs/heads/master@{#15013}
As a side effect:
- Moved the AudioSendStream::Config::SendCodecSpec methods into the .cc.
- Which exposed an issue with event_visualizer_utils not having a dependency on api:call_api set up.
- Which further exposed clang warnings about large inlined default methods in webrtc/config.h.
BUG=webrtc:4690
Committed: https://crrev.com/1836fd6257a692959b3b49ba99ef587ad9995871
Review-Url: https://codereview.webrtc.org/2446963003
Cr-Original-Commit-Position: refs/heads/master@{#14771}
Cr-Commit-Position: refs/heads/master@{#14780}
Reason for revert:
Breaks downstream project
Original issue's description:
> Clean up logging in AudioSendStream::SetupSendCodec().
>
> As a side effect:
> - Moved the AudioSendStream::Config::SendCodecSpec methods into the .cc.
> - Which exposed an issue with event_visualizer_utils not having a dependency on api:call_api set up.
> - Which further exposed clang warnings about large inlined default methods in webrtc/config.h.
>
> BUG=webrtc:4690
>
> Committed: https://crrev.com/1836fd6257a692959b3b49ba99ef587ad9995871
> Cr-Commit-Position: refs/heads/master@{#14771}
TBR=kwiberg@webrtc.org,solenberg@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:4690
Review-Url: https://codereview.webrtc.org/2452643002
Cr-Commit-Position: refs/heads/master@{#14774}
As a side effect:
- Moved the AudioSendStream::Config::SendCodecSpec methods into the .cc.
- Which exposed an issue with event_visualizer_utils not having a dependency on api:call_api set up.
- Which further exposed clang warnings about large inlined default methods in webrtc/config.h.
BUG=webrtc:4690
Review-Url: https://codereview.webrtc.org/2446963003
Cr-Commit-Position: refs/heads/master@{#14771}
This class is logically parallel with the {Audio,Video}ReceiveStream
classes. Its purpose is to describe a receive stream of FlexFEC packets,
through the corresponding config.
Functionally, this class simply forwards the received RTP packets
to its FlexfecReceiver, which returns recovered packets to the
Call level, for appropriate demultiplexing based on SSRC.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2397843005
Cr-Commit-Position: refs/heads/master@{#14704}
Also rename some related minor methods. No functional changes
are intended/expected.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2391963002
Cr-Commit-Position: refs/heads/master@{#14513}
The original landed cl is in patchset 1.
The following patchset fix VideoQualityTest as well as fix the case where max_bitrate is set in the SendParams. A unit test is added for that as well.
Original cl description:
Let ViEEncoder handle resolution changes.
This cl move codec reconfiguration due to video frame size changes from WebRtcVideoSendStream to ViEEncoder.
With this change, many variables in WebRtcVideoSendStream no longer need to be locked.
BUG=webrtc:5687, webrtc:6371, webrtc:5332
Review-Url: https://codereview.webrtc.org/2386573002
Cr-Commit-Position: refs/heads/master@{#14467}
This cl move codec reconfiguration due to video frame size changes from WebRtcVideoSendStream to ViEEncoder.
With this change, many variables in WebRtcVideoSendStream no longer need to be locked.
BUG=webrtc:5687, webrtc:6371, webrtc:5332
Review-Url: https://codereview.webrtc.org/2351633002
Cr-Commit-Position: refs/heads/master@{#14445}
Original description:
Add proper lifetime of encoder-specific settings.
Permits passing VideoEncoderConfig between threads and not worry about
the lifetime of an underlying void pointer. Also adds type safety to
unpacking of codec-specific settings.
These settings are not yet propagating to VideoEncoder interfaces, but
the aim is to get rid of webrtc::VideoCodec for VideoEncoder.
BUG=webrtc:3424
R=perkj@webrtc.org, pbos@webrtc.orgTBR=mflodman@webrtc.org
Review-Url: https://codereview.webrtc.org/2347843002
Cr-Commit-Position: refs/heads/master@{#14396}
This change reduces the number of times the Android hardware video
encoder is reconfigured when making an outgoing call. With this change,
the encoder should only be initialized once as opposed to the ~3 times
it happens currently.
Before the fix, the following sequence of events caused the extra
reconfigurations:
1. After the SetLocalDescription call, the WebRtcVideoSendStream is created.
All frames from the camera are dropped until the corresponding
VideoSendStream is created.
2. SetRemoteDescription() triggers the VideoSendStream creation. At
this point, the encoder is configured for the first time, with the
frame dimensions set to a low resolution default (176x144).
3. When the first video frame is received from the camera after the
VideoSendStreamIsCreated, the encoder is reconfigured to the correct
dimensions. If we are using the Android hardware encoder, the default
configuration is set to encode from a memory buffer (use_surface=false).
4. When the frame is passed down to the encoder in
androidmediaencoder_jni.cc EncodeOnCodecThread(), it may be stored in
a texture instead of a memory buffer. In this case, yet another
reconfiguration takes place to enable encoding from a texture.
5. Even if the resolution and texture flag were known at the start of
the call, there would be a reconfiguration involved if the camera is
rotated (such as when making a call from a phone in portrait orientation).
The reason for that is that at construction time, WebRtcVideoEngine2
sets the VideoSinkWants structure parameter to request frames rotated
by the source; the early frames will then arrive in portrait resolution.
When the remote description is finally set, if the rotation RTP extension
is supported by the remote receiver, the source is asked to provide
non-rotated frames. The very next frame will then arrive in landscape
resolution with a non-zero rotation value to be applied by the receiver.
Since the encoder was configured with the last (portrait) frame size,
it's going to need to be reconfigured again.
The fix makes the following changes:
1. WebRtcVideoSendStream::OnFrame() now caches the last seen frame
dimensions, and whether the frame was stored in a texture.
2. When the encoder is configured the first time
(WebRtcVideoSendStream::SetCodec()) - the last seen frame dimensions
are used instead of the default dimensions.
3. A flag that indicates if encoding is to be done from a texture has
been added to the webrtc::VideoStream and webrtc::VideoCodec structs,
and it's been wired up to be passed down all the way to the JNI code in
androidmediaencoder_jni.cc.
4. MediaCodecVideoEncoder::InitEncode is now reading the is_surface
flag from the VideoCodec structure instead of guessing the default as
false. This way we end up with the correct encoder configuration the
first time around.
5. WebRtcVideoSendStream now takes an optimistic guess and requests non-
rotated frames when the supported RtpExtensions list is not available.
This makes the "early" frames arrive non-rotated, and the cached dimensions
will be correct for the common case when the rotation extension is supported.
If the other side is an older endpoint which does not support rotation,
the encoder will have to be reconfigured - but it's better to penalize the
uncommon case rather than the common one.
Review-Url: https://codereview.webrtc.org/2067103002
Cr-Commit-Position: refs/heads/master@{#13173}
This CL adds support for an extension on RTP frames to allow the sender
to specify the minimum and maximum playout delay limits.
The receiver makes a best-effort attempt to keep the capture-to-render delay
within this range. This allows different types of application to specify
different end-to-end delay goals. For example gaming can support rendering
of frames as soon as received on receiver to minimize delay. A movie playback
application can specify a minimum playout delay to allow fixed buffering
in presence of network jitter.
There are no tests at this time and most of testing is done with chromium
webrtc prototype.
On chromoting performance tests, this extension helps bring down end-to-end
delay by about 150 ms on small frames.
BUG=webrtc:5895
Review-Url: https://codereview.webrtc.org/2007743003
Cr-Commit-Position: refs/heads/master@{#13059}
Currently there are two structs that are identical and track extension details:
webrtc::RtpExtension
cricket::RtpHeaderExtension
The use of the structs is mixed in the code to track the extensions being
supported. This results in duplicate definition of
the URI constants and there is code to convert between the two structs.
Clean up to use a single RtpHeader throughout the codebase. The actual location
of RtpHeader may change in future (perhaps to be located in api/). Additionally,
this CL renames some of the constants to clarify Uri and Id use.
BUG= webrtc:5895
Review-Url: https://codereview.webrtc.org/1984983002
Cr-Commit-Position: refs/heads/master@{#12924}
Adds negotiation of rtx codecs for red and vp9. To keep backwards
compatibility with older Chrome versions, this change includes two
hacks:
1. Red packets will be retransmitted over the rtx codec associated with
vp8 if no rtx codec is associated with red. This is how Chrome does
it today and ensures that we still can send red over rtx to older
versions.
2. If rtx packets associated with the media codec (vp8/vp9 etc) are
received and red has been negotiated, we will assume that the sender
incorrectly has packetized red inside the rtx header associated with
media. We will therefore restore it with the red payload type
instead, which ensures that we can still receive rtx associated with
red from old versions.
Offering multiple rtx codecs to older versions should not be a problem
since old versions themselves only try to negotiate rtx for vp8.
R=pbos@webrtc.orgTBR=mflodman@webrtc.org
BUG=webrtc:4024
TEST=Verified by running apprtc and emulating packet loss between Chrome with and without the patch.
Review URL: https://codereview.webrtc.org/1649493004 .
Cr-Commit-Position: refs/heads/master@{#11472}
Also refactor packet router to use a map rather than iterate over all
rtp modules for each packet sent.
BUG=webrtc:4311
Review URL: https://codereview.webrtc.org/1247293002
Cr-Commit-Position: refs/heads/master@{#9670}
Mostly, it's about moving constructors and descructors to the .cc
files, so that they won't be inlined everywhere.
The reason this CL is so big is that a lot of code was using
common_types.h without declaring a dependency on webrtc_common, which
broke the build once common_types.h started to depend on
common_types.cc.
BUG=163
R=kjellander@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/26089004
Cr-Commit-Position: refs/heads/master@{#8516}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8516 4adac7df-926f-26a2-2b94-8c16560cd09d
Reasons for revert:
1. glaznev discovered potentially related problems using the Android AppRTCDemo.
2. We're trying to do an M41 webrtc roll in Chromium, and this CL is risky.
> Support associated payload type when registering Rtx payload type.
>
> Major changes include,
> - Add associated payload type for SetRtxSendPayloadType & SetRtxReceivePayloadType.
> - Receiver: Restore RTP packets by the new RTX-APT map.
> - Sender: Send RTP packets by checking RTX-APT map.
> - Add RTX payload type for RED in the default codec list.
>
> BUG=4024
> R=pbos@webrtc.org, stefan@webrtc.org
> TBR=mflodman@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/26259004
>
> Patch from Changbin Shao <changbin.shao@intel.com>.
TBR=pbos@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/33829004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8033 4adac7df-926f-26a2-2b94-8c16560cd09d
