Encoders need to be externally provided. To use software encoders they
need to be created and registered from the outside.
BUG=webrtc:1695
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1394823002 .
Cr-Commit-Position: refs/heads/master@{#10283}
In video_sender.cc, properly read the number of temporal layers for VP9 too.
Also, some cleanup in video_loopback.cc and video_quality_test.h.
Review URL: https://codereview.webrtc.org/1351693005
Cr-Commit-Position: refs/heads/master@{#10201}
Since padding is no longer sent on Encoded() callbacks, dummy callbacks
aren't required to generate padding. This skip-frame behavior can then
be removed to get rid of dummy callbacks though nothing was encoded. As
frames don't have to be generated for frames that don't have to be sent
we skip encoding frames that aren't intended to be sent either, reducing
CPU load.
BUG=
R=mflodman@webrtc.org, stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1369923005 .
Cr-Commit-Position: refs/heads/master@{#10181}
Fixes code formatting and uses size_t properly. Also makes use of
IsNewerTimestamp instead of a simple > check, which should fix an
edge-case bug.
BUG=
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1358863002
Cr-Commit-Position: refs/heads/master@{#10094}
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}
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.
* DISALLOW_ASSIGN -> RTC_DISALLOW_ASSIGN
* DISALLOW_COPY_AND_ASSIGN -> RTC_DISALLOW_COPY_AND_ASSIGN
* DISALLOW_IMPLICIT_CONSTRUCTORS -> RTC_DISALLOW_IMPLICIT_CONSTRUCTORS
Related CL: https://codereview.webrtc.org/1335923002/
BUG=chromium:468375
NOTRY=true
Review URL: https://codereview.webrtc.org/1345433002
Cr-Commit-Position: refs/heads/master@{#9953}
Handling the case when encoder drops only the higher layer.
Added options to screenshare loopback test to discard high temporal or spatial layers (to view the lower layers).
Review URL: https://codereview.webrtc.org/1287643002
Cr-Commit-Position: refs/heads/master@{#9883}
Especially the VP9 codec currently may overshoot bitrate target at sudden picture changes, resulting in frames over 800 packets.
This limit should be reduced again once the codec behaves.
BUG=webrtc:4889
Review URL: https://codereview.webrtc.org/1266353003
Cr-Commit-Position: refs/heads/master@{#9675}
Enforces previous kProtectionKeyOnLoss as the permanent method which was
the only one used in use. This simplifies SetVideoProtection and
transition over to SetReceiverRobustnessMode.
BUG=webrtc:1596
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1244753002
Cr-Commit-Position: refs/heads/master@{#9641}
These payload types aren't directly connected to any payload type, and
the payload type still has to be negotiated externally. As such these
constants are just a source of confusion.
BUG=
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1215603003
Cr-Commit-Position: refs/heads/master@{#9546}
This change includes several improvements:
* VP8 configured with new rate control
* Detection of frame dropping, with qp bump for next frame
* Increased target and TL0 bitrates
* Reworked rate control (TL allocation) in screenshare_layers
A note on performance: PSNR and SSIM is expected to get slightly worse with this cl. Frame drops and delays should however improve.
BUG=4171
R=pbos@webrtc.org, stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1193513006.
Cr-Commit-Position: refs/heads/master@{#9495}
This is just https://webrtc-codereview.appspot.com/53629004/
Remove a constructor of VCMJitterBuffer.
Remove unnecessary factory use
Comment Fix
Move frame incoming simulation to the clock
DCHECK typo fix
Coding Style Fix
Rephrased some comments, and removed some virtual for override function.
Coding Style Fix
Coding Style Fix
Add a unittest for VCMReceiver::FrameForDecoding. Mainly test the time control algorithm.
BUG=
TBR=holmer@chromium.org
Review URL: https://codereview.webrtc.org/1173253008.
Cr-Commit-Position: refs/heads/master@{#9470}
timestamp_ is only used in GenerateFrame() and its old value is
discarded. So it just needs to be a local variable in GenerateFrame().
As a result, we can remove the start_timestamp parameter from the
constructor and Init().
Also mark the GeneratePacket() method private because it is only used
internally.
R=stefan@webrtc.org
BUG=none
TEST=none
Review URL: https://webrtc-codereview.appspot.com/50149004
Cr-Commit-Position: refs/heads/master@{#9386}
Use the current parameter names in the comment for SetNackMode().
Add a warning comment about the lifetime of the return value of
GetNackList().
R=stefan@webrtc.org
BUG=none
TEST=none
Review URL: https://webrtc-codereview.appspot.com/52599004
Cr-Commit-Position: refs/heads/master@{#9321}
The most important change is to prevent a potential buffer overflow in
NackList(). It cannot happen if the |size| argument passed to NackList()
is consistent with the |max_nack_list_size| argument passed to
SetNackSettings(), and there is an assertion to check that. But it is
good to defend against this in the release build because assert() is
compiled away in the release build.
Remove the unused |master| parameter to the VCMReceiver constructor.
Remove the unused State() getter method and the corresponding state_
member.
Remove the declarations for the nonexistent GenerateReceiverId()
method and the receiver_id_counter_ member.
Remove the unneeded data_buffer_ member of TestVCMReceiver. It was
assigned to packet.dataPtr and then immediately overwritten by
stream_generator_->GetPacket() or stream_generator_->PopPacket().
R=stefan@webrtc.org
BUG=none
TEST=none
Review URL: https://webrtc-codereview.appspot.com/51119004
Cr-Commit-Position: refs/heads/master@{#9318}
uint32_t parameters don't need to be passed by reference. The
VCMJitterBuffer destructor doesn't need to be virtual because the
class has no virtual methods.
R=stefan@webrtc.org
BUG=none
Review URL: https://webrtc-codereview.appspot.com/55499004
Cr-Commit-Position: refs/heads/master@{#9288}
tl;dr - non-continuous frames (due to padding) would get stuck as incomplete if the previous complete frame arrived and was decoded before the padding arrived.This fix re-checks the incomplete frame list for continuous frames after old packets arrive.
When padding is enabled and RTX is not, padding is sent as empty RTP packets tacked onto the end of completed frames (meaning: same timestamp, but after a packet with the marker bit set). Given the following set of circumstances, codified in the new unit test method, a frame can get permanently stuck in the incomplete frames list:
- Frame A decoded (packets 94-95). Next expected sequence number is 96.
- Frame C arrives (packets 100-101) and is marked complete. It isn't continuous, since it starts at 100, so it's placed in the incomplete frame list.
- Frame B arrives (packets 96-97) and is complete, since 97 has a marker bit. Turns out that packets 98-99 are padding, but the receiver doesn't know that.
- Frame B is decoded, removed from the decodable frames list, and last decoded state is updated.
- Packets 98-99 arrive. They hit the IsOldPacket check and update the last decoded state, but they don't trigger FindAndInsertContinuousFrames.
- Further packets/frames arrive and complete, but FindAndInsertContinuousFrames only runs on frames that are newer than the newly completed frame.
In this state, Frame C is permanently stuck as incomplete, so the jitter buffer overall is stuck until max NACK age (default: 450 packets), the max NACK list size (default: 200 packets), or a keyframe arrives and IsContinuous returns true for the keyframe.
(Before the November refactoring, Frame B wouldn't have to have been decoded for the bug to trigger; just having a complete continuous frame at any time before the padding arrived would cause this state, as FindAndInsertContinuousFrames was only called when the frame originally became continuous and was inserted into the decodable frames list. Post refactoring, the frame is removed/re-added to the decodable list on every padding packet that arrives)
BUG=
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/50959004
Cr-Commit-Position: refs/heads/master@{#9264}
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}
CopyCodecSpecific nulls out the rtpheader pointer hence causing the crash downstream.
More details about the codec type enums:
There are 2 enums defined. webrtc::VideoCodecType webrtc::RtpCodecTypes and they don't match. Inside CopyCodecSpecific in generic_encoder.cc, it was converted from the first to the 2nd type. At that point, it'll be kRtpVideoNone (as the effect of memset to 0). kRtpVideoNone is a bad value as it could cause assert. Later, it'll be reset to kRtpVideoGeneric in RTPSender::SendOutgoingData so it's not a concern.
BUG=4511
R=pbos@webrtc.org, pthatcher@webrtc.org, stefan@webrtc.org
Committed: https://crrev.com/29b1a1c0c7c6f4b1ae4d63844b1dfaa7a72530a0
Cr-Commit-Position: refs/heads/master@{#8951}
Review URL: https://webrtc-codereview.appspot.com/47999004
Cr-Commit-Position: refs/heads/master@{#8955}
