The uint8_t in the log string is interpreted as a char, causing a
character to be logged if the loss is non-zero and terminates the string
with a '\0' in the zero case.
R=sprang@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/53449004
Cr-Commit-Position: refs/heads/master@{#9242}
This will make us detect when sources are listed in GYP files that
are no longer present on disk. This check only exists for Windows
but should be enough to keep our GYP files up to date with the file
system.
R=pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/54409004
Cr-Commit-Position: refs/heads/master@{#9187}
Instead a ViECapturer object is allocated and directly operated on. This
additionally exposes ViESharedData to Call to access the module
ProcessThread, moving towards Call ownership of shared resources.
BUG=1695
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/45339004
Cr-Commit-Position: refs/heads/master@{#9119}
Replaces interface usage with direct calls on ViEEncoder removing a
layer of indirection. Also removing some methods from ViEImageProcess
that were only added for Video{Send,Receive}Stream usage.
BUG=1695
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/45319004
Cr-Commit-Position: refs/heads/master@{#9111}
ViECapturer::OnIncomingCapturedFrame can abort if two frames without a
timestamp are delivered at the same time (the same NTP timestamp is
generated). This currently causes captured_frame_ to be in a state
where timestamps (NTP time etc.) are set, but RTP timestamp is not. This
is an issue if the previous frame in captured_frame_ has yet to be
picked up by the capturer thread, as it will pick up captured_frame_ in
a state where the RTP timestamp has not been set.
BUG=chromium:480953
R=magjed@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/45299004
Cr-Commit-Position: refs/heads/master@{#9094}
Since RTCP packets are delivered to both senders and receivers that
correspond the receivers currently log that NACKed packets are missing,
since they have no direct connection to the sending side or the RTP
packet history. Also preventing triggering on SR requests and PLI/FIR.
BUG=
R=asapersson@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/45249004
Cr-Commit-Position: refs/heads/master@{#9071}
An incoming rtcp report block is inserted to both send and receive channels in Call::DeliverRtcp. The report block may also be accepted by each receive channel (in addition to the send channel) but fails to calculate the rtt (=0).
Remove registration of bandwidth observer for receive channels. Prevents multiple callbacks to the bitrate controller (and with incorrect rtt) for an incoming report block.
BUG=4546
R=mflodman@webrtc.org, pbos@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/45209004
Cr-Commit-Position: refs/heads/master@{#9055}
This implementation registers RTX-APT map inside RTP sender and receiver.
While it only generates SDP with RTX associated with VP8 to make it
compatible with previous Chrome versions.
Should add following changes after reaches stable,
* Use RTX-APT map for building and restoring RTP packets.
* Add RTX support for RED or VP9 in Video engine.
* Set RTX payload type for RED inside FecConfig in EndToEndTest.
BUG=4024
R=mflodman@webrtc.org, pbos@webrtc.org, pthatcher@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/36889004
Cr-Commit-Position: refs/heads/master@{#9040}
This reverts commit 14a97f0a9148be18a66a435a5933441eb023bc82.
Introduces a deadlock due to acquiring simulcast_rtp_rtcp_ in
ReceivedRTCPPacket.
BUG=4568, chromium:478911
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/44289004
Cr-Commit-Position: refs/heads/master@{#9039}
Without this, external encoders with internal sources (i.e. don't use the normal camera path) won't trigger ViEEncoder::DeliverFrame, so time_of_last_incoming_frame_ms_ will always be 0.
BUG=
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/44099004
Cr-Commit-Position: refs/heads/master@{#9010}
Add separate functions for returning stats from send/receive stream and updated how functions are used.
Add test implementation for histogram methods in system_wrappers/interface/metrics.h.
BUG=4519
R=pbos@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/49639004
Cr-Commit-Position: refs/heads/master@{#9009}
ViEChannels without default encoders doesn't register a receive codec by
default. This makes VideoReceiver::Decode return early, causing a
high-priority thread to effectively be busy looping. This would be
expected to wreck more havoc in a more cross-platform manner than it has
visibly done. On Windows XP however it manages to bring the whole
machine to a grinding halt forcing a reboot if CPU usage hits 100%.
BUG=chromium:470013
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/48049004
Cr-Commit-Position: refs/heads/master@{#8976}
It is just a pass through to webrtc/video_frame.h. Updated the callers
to include webrtc/video_frame.h instead and removed i420_video_frame.h.
This should fix pbos' TODO in i420_video_frame.h.
Tested on Linux with the following command lines:
$ rm -rf out/
$ ./webrtc/build/gyp_webrtc
$ ninja -C out/Debug
BUG=None
TEST=see above
R=magjed@webrtc.org, pbos@webrtc.org, tommi@webrtc.orgTBR=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/46819004
Patch from Thiago Farina <tfarina@chromium.org>.
Cr-Commit-Position: refs/heads/master@{#8973}
This CL makes ViEFrameCallback::DeliverFrame const and removes the potential frame copy in ViEFrameProviderBase by moving it to ViEEncoder::DeliverFrame instead, for clients that use the FrameCallback functionality to modify the frame content.
BUG=1128
R=mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/43949004
Cr-Commit-Position: refs/heads/master@{#8934}
RenderFrame should not modify the I420VideoFrame (and we don't).
This CL changes the declaration of RenderFrame from:
int32_t RenderFrame(const uint32_t streamId, I420VideoFrame& videoFrame)
to:
int32_t RenderFrame(const uint32_t streamId, const I420VideoFrame& videoFrame)
BUG=1128
R=mflodman@webrtc.org, perkj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/46689005
Cr-Commit-Position: refs/heads/master@{#8902}
This CL avoids changing the mentioned callbacks during a call, to avoid
a potential deadlock when acquiring _sendCritSect and calling
_mediaOpt.SetTargetRates.
Moving the critsect revealed a race for the FEC parameters in RtpVideoSender, so the CL grew a bit to avoid this. I also cleaned up some code here at the same time, but tried to keep it at a minimum since this CL had already increased a lot in size.
BUG=769
R=pbos@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/42939004
Cr-Commit-Position: refs/heads/master@{#8899}
This means all channels within the same group will share the same pacing queue and scheduler. It also means padding will be computed and sent by a single pacer. To accomplish this I also introduce a PacketRouter which finds the RTP module which owns the packet to be paced out.
BUG=4323
R=mflodman@webrtc.org, pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/45549004
Cr-Commit-Position: refs/heads/master@{#8864}
Instead of setting bitrates based on codec target settings (which may
have previously been capped by a codec max bitrate), fetch the last
bandwidth allocated for this channel. This fixes broken low start bitrates
due to QCIF being set as default codec in WebRtcVideoEngine2 which caps
the max bitrate to 200kbps.
BUG=1788
R=mflodman@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/43789004
Cr-Commit-Position: refs/heads/master@{#8780}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8780 4adac7df-926f-26a2-2b94-8c16560cd09d
Original cl description:
This removes the none const pointer entry and SwapFrame.
Since frames delivered using VideoSendStream no longer use the external capture module, VideoSendStream will not get an incoming framerate callback. VideoSendStream now uses a rtc::RateTracker.
Also, the video engine must ensure that time stamps are always increasing.
With this, time stamps (ntp, render_time and rtp timestamps ) are checked and set in ViECapturer::OnIncomingCapturedFrame
This cl was previously reverted in https://webrtc-codereview.appspot.com/46549004/.
Patchset 1 contains the original patch after rebase.
Patshet 2 fix webrtc_perf_tests reported in chromium:465306
Note that chromium:465287 is being fixed in https://webrtc-codereview.appspot.com/43829004/
BUG=1128
R=magjed@webrtc.org, mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/47629004
Cr-Commit-Position: refs/heads/master@{#8776}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8776 4adac7df-926f-26a2-2b94-8c16560cd09d
