- First audio RTP packet sent / received
- First RTP packet of the first video frame sent / received
- Last RTP packet of the first video frame sent / received
These timestamps should make it easier to measure how fast the call
becomes established from the user's perspective.
Review URL: https://codereview.webrtc.org/1765443002
Cr-Commit-Position: refs/heads/master@{#12287}
Reason for revert:
Revert because it breaks downstream code.
Original issue's description:
> Clean away use of RtpAudioFeedback interface from RTP/RTCP receiver code.
>
> BUG=webrtc:4690
>
> Committed: https://crrev.com/69a81999ace08e40e2b2ec526b0e111aa11b9538
> Cr-Commit-Position: refs/heads/master@{#12015}
TBR=henrik.lundin@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/1812453002
Cr-Commit-Position: refs/heads/master@{#12016}
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}
* Move constants into the files/functions that use them
* Declare variables in the narrowest scope possible
* Use correct (expected, actual) order for gtest macros
* Remove unused functions
* Untabify
* 80-column limit
* Avoid C-style casts
* Prefer true typed constants to "enum hack" constants
* Print size_t using the right format macro
* Shorten and simplify code
* Other random cleanup bits and style fixes
BUG=none
TEST=none
R=henrik.lundin@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/36179004
Cr-Commit-Position: refs/heads/master@{#8467}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8467 4adac7df-926f-26a2-2b94-8c16560cd09d
As far as I observe, there are several reasons for this:
1. webrtc/modules/audio_coding/neteq4/neteq_impl.cc : 870
assert(new_codec_);
This is related to webrtc/modules/audio_coding/neteq4/decision_logic_normal.cc : 81
kUndefined can happen without new_codec_ being set
2. webrtc/modules/audio_coding/neteq4/neteq_impl.cc : 745
assert(sync_buffer_->FutureLength() >= expand_->overlap_length());
3. some other assert triggered.
The above happens not very often and goes away with no assertion.
3. (most common, this CL addresses this)
webrtc/modules/rtp_rtcp/source/rtp_receiver_audio.cc : 201
payload_data_length = payload_length - rtp_header->header.paddingLength;
There are situations that
payload_length < rtp_header->header.paddingLength;
OLD ACM + NetEq3 can handle this:
a) webrtc/modules/audio_coding/main/source/acm_neteq.cc : 477
int16_t payload_length = static_cast<int16_t>(length_payload);
payload_length becomes negative in this situation
b) webrtc/modules/audio_coding/neteq/recin.c
WebRtcNetEQ_RecInInternal() handles negative payload length
I do not want to touch VoE, so I tried to let ACM2 and NetEq4 handle negative payload length.
This CL does not follow the exact way of OLD ACM + NetEq3. I stopped negative payload length at ACM and did not allow it go to NetEq4.
To try this, apply my uploaded patch : https://webrtc-codereview.appspot.com/2281004/
Let me know if you see better solutions.
R=henrik.lundin@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2292005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4860 4adac7df-926f-26a2-2b94-8c16560cd09d
The big benefit is we no longer have a circular dependency between the media receiver and the payload registry. The payload registry is starting to take a bit more place on the stage, and now knows how to do different things depending on audio or video.
BUG=
TESTED=rtp_rtcp_unittests, vie_auto_test, voe_auto_test
Review URL: https://webrtc-codereview.appspot.com/1078004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3465 4adac7df-926f-26a2-2b94-8c16560cd09d
Eliminated need for video receiver to talk to its parent. Also we will now determine if the packet is the first one already in the rtp general receiver. The possible downside would be that recovered video packets no longer can be flagged as the first packet, but I don't think that can happen. Even if it can happen, maybe the bit was set anyway at an earlier stage. The tests run fine.
BUG=
TEST=rtp_rtcp_unittests, vie_auto_test, voe_auto_test
Review URL: https://webrtc-codereview.appspot.com/1022011
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3382 4adac7df-926f-26a2-2b94-8c16560cd09d
The purpose is to make _rtpReceiver mostly agnostic to if it processes audio or video, and make its delegates responsible for that. This patch makes the actual interfaces and interactions between the classes a lot clearer which will probably help straighten out the rather convoluted business logic in here. There are a number of rough edges I hope to address in coming patches.
In particular, I think there are a lot of audio-specific hacks, especially when it comes to telephone event handling. I think we will see a lot of benefit once that stuff moves out of rtp_receiver altogether. The new strategy I introduced doesn't quite pull its own weight yet, but I think I will be able to remove a lot of that interface later once the responsibilities of the classes becomes move cohesive (e.g. that audio specific stuff actually lives in the audio class, and so on). Also I think it should be possible to extract payload type management to a helper class later on.
BUG=
TEST=vie/voe_auto_test, trybots
Review URL: https://webrtc-codereview.appspot.com/1001006
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3306 4adac7df-926f-26a2-2b94-8c16560cd09d
