Extracts shared members outside the two objects, removing PayloadRouter
from receivers and the VCM for ViEChannel from senders.
Removes Start/StopThreadsAndSetSharedMembers that was used to set the
shared state between them.
Also adding DCHECKs to document what's only used by the
sender/receiver side.
BUG=webrtc:5494
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1654913002 .
Cr-Commit-Position: refs/heads/master@{#11500}
Permits measuring encoding time even when performed on another thread,
typically for hardware encoding, instead of assuming that encoding is
blocking the calling thread.
Permitted encoding time is increased for hardware encoders since they
can be timed to keep 30fps, for instance, without indicating overload.
Merges EncodingTimeObserver into EncodedFrameObserver to have one post-encode
callback.
BUG=webrtc:5042, webrtc:5132
R=asapersson@webrtc.org, mflodman@webrtc.org
Review URL: https://codereview.webrtc.org/1569853002 .
Cr-Commit-Position: refs/heads/master@{#11499}
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}
Still waiting to turn on negotiation (in mediasession.cc)
until we verify it's working as expected.
BUG=webrtc:4868
Review URL: https://codereview.webrtc.org/1418123003
Cr-Commit-Position: refs/heads/master@{#10958}
This CL duplicates all the histograms in SendStatisticsProxy. Might be
overkill, but we don't know which stats will be interesting and it makes
the change easier.
BUG=
Review URL: https://codereview.webrtc.org/1433393002
Cr-Commit-Position: refs/heads/master@{#10885}
This is a step on the way to have variable bitrate for audio and is
intended to be as much of a no-op as possible.
BUG=webrtc:5079
Review URL: https://codereview.webrtc.org/1441673002
Cr-Commit-Position: refs/heads/master@{#10630}
Receiving RTCP often caused the worker thread to stall for >20 ms
(>100ms observed) due to contention on VideoSender's send_crit_ (used to
protect encoding).
This change removes an unnecessary acquire of send_crit_ and caches
encoder settings in ViEEncoder instead of acquiring them through
::SendCodec() in VCM (which is blocking).
BUG=webrtc:5106
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1433703002 .
Cr-Commit-Position: refs/heads/master@{#10582}
The defines still in use was only used in single files, so they were
moved to these specific cc-files.
Review URL: https://codereview.webrtc.org/1411573007
Cr-Commit-Position: refs/heads/master@{#10539}
This is a re-land of https://codereview.webrtc.org/1353263005/
which was reverted because of perf-regressions. Changes since that CL:
* Change LayerFilteringTransport to send a padding packet instead of
dropping it for data that should be filtered out. This prevents
confusion due to changed sequence numbers.
* Changed timing of stats poller thread in VideoAnalyzer. Startup was
racy wrt initializion of send_stream_.
* Minor formatting issues.
PERF NOTE: This change will affect some performance numbers slightly.
In particular, {encode_frame_rate, encode_time_ms,
encode_usage_percent, media_bitrate_bps} will change due to timing
of the measurements.
BUG=
R=pbos@webrtc.orgTBR=mflodman@webrtc.org
Review URL: https://codereview.webrtc.org/1412233003
Cr-Commit-Position: refs/heads/master@{#10483}
This CL changes as little as possible and I'll follow up later with
ownership of the other members in ChannelGroup.
The next step is to remove the id used for channels.
BUG=webrtc:5079
Review URL: https://codereview.webrtc.org/1411723002
Cr-Commit-Position: refs/heads/master@{#10318}
This is the first CL to get ready for adapting audio bitrate based on
BWE. I've kept this CL as small as possible and had to add a few getters
to ChannelManager. The next CL will do the same for receive ViEChannels.
The getters are a bit uggly, but is an in-between-state. Let's discuss
future ownership of the different modules and what do do with
ChannelGroup.
BUG=5079
Review URL: https://codereview.webrtc.org/1394243006
Cr-Commit-Position: refs/heads/master@{#10298}
Reason for revert:
Temporarily reverting as this causes some issues with perf tests. Especially tests with packet loss no longer works.
Original issue's description:
> Adding support for simulcast and spatial layers into VideoQualityTest
>
> The CL includes several changes:
> - Adding flags describing the streams and spatial layers.
> - Reorganizing the order of the flags, to make them easier to maintain.
> - Adding a member .params_ to VideoQualityAnalyzer.
> (instead of passing it to every member function manually)
> - Updating VideoAnalyzer to support simulcast.
> (select appropriate ssrc and fix timestamps which are sometimes increased by 1)
> - VP9EncoderImpl already had code for automatic calculation of bitrate for each layer.
> Changing to first read bitrates and resolution ratios from the flags, if specified.
> If not specified, reverting to the old code are setting the values automatically.
> - Changing the parameters in LayerFilteringTransport, replacing
> xx_discard_thresholds with selected_xx, to make it easier to use for the end user.
>
> Committed: https://crrev.com/87f83a9a27d657731ccb54025bc04ccad0da136e
> Cr-Commit-Position: refs/heads/master@{#10215}
TBR=pbos@webrtc.org,mflodman@webrtc.org,ivica@webrtc.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.webrtc.org/1397363002
Cr-Commit-Position: refs/heads/master@{#10252}
The CL includes several changes:
- Adding flags describing the streams and spatial layers.
- Reorganizing the order of the flags, to make them easier to maintain.
- Adding a member .params_ to VideoQualityAnalyzer.
(instead of passing it to every member function manually)
- Updating VideoAnalyzer to support simulcast.
(select appropriate ssrc and fix timestamps which are sometimes increased by 1)
- VP9EncoderImpl already had code for automatic calculation of bitrate for each layer.
Changing to first read bitrates and resolution ratios from the flags, if specified.
If not specified, reverting to the old code are setting the values automatically.
- Changing the parameters in LayerFilteringTransport, replacing
xx_discard_thresholds with selected_xx, to make it easier to use for the end user.
Review URL: https://codereview.webrtc.org/1353263005
Cr-Commit-Position: refs/heads/master@{#10215}
Since the pacer is always enabled, removing enable/disable which makes
all packet queueing succeed. Also renaming one of the ::SendPackets
::InsertPacket to avoid confusion.
BUG=webrtc:1695, webrtc:2629
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1392513002 .
Cr-Commit-Position: refs/heads/master@{#10211}
Also, in Sample struct, replacing double with the original type.
It makes more sense to save the original data as truthful as possible, and then
convert it to double later if necessary (in the plot script).
Review URL: https://codereview.webrtc.org/1374233002
Cr-Commit-Position: refs/heads/master@{#10184}
Starts by removing channel/engine id from ViEChannel which propagates
down to the RTP/RTCP module as well as the transport class.
IncomingVideoStream::RenderFrame() is untouched for now but receives a
fake id instead of the previous channel id. Added a TODO to remove it
later but the RenderFrame call is implemented in a lot of
platform-dependent files and should probably remove the "manager" aspect
of renderers, so preferring to do it separately
BUG=webrtc:1695
R=henrika@webrtc.org, mflodman@webrtc.org
Review URL: https://codereview.webrtc.org/1335353005 .
Cr-Commit-Position: refs/heads/master@{#9978}
We must remove dependency on Chromium, i.e. we can't use Chromium's base/logging.h. That means we need to define these macros in WebRTC also when doing Chromium builds. And this causes redefinition.
Alternative solutions:
* Check if we already have defined e.g. CHECK, and don't define them in that case. This makes us depend on include order in Chromium, which is not acceptable.
* Don't allow using the macros in WebRTC headers. Error prone since if someone adds it there by mistake it may compile fine, but later break if a header in added or order is changed in Chromium. That will be confusing and hard to enforce.
* Ensure that headers that are included by an embedder don't include our macros. This would require some heavy refactoring to be maintainable and enforcable.
* Changes in Chromium for this is obviously not an option.
BUG=chromium:468375
NOTRY=true
Review URL: https://codereview.webrtc.org/1335923002
Cr-Commit-Position: refs/heads/master@{#9964}
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}
BUG=webrtc:4690
Defined classes Stream, SendStream and ReceiveStream. Inherited existing stream classes from either SendStream or ReceiveStream.
This is a step towards having a Transport associated with streams instead of a Call. It will allow a lot of code in the Call to be media type agnostic.
R=henrika@webrtc.org, pbos@webrtc.org, stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1226123005 .
Cr-Commit-Position: refs/heads/master@{#9591}
