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}
We should not continue the program if the user asked for help.
Tested on Linux with the following command line:
$ out/Debug/frame_analyzer --help
BUG=None
TEST=see above
R=kjellander@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/44069004
Patch from Thiago Farina <tfarina@chromium.org>.
Cr-Commit-Position: refs/heads/master@{#8961}
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}
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
Review URL: https://webrtc-codereview.appspot.com/47999004
Cr-Commit-Position: refs/heads/master@{#8951}
All RTP packets from sender side will carry the rotation info. (will file a bug to track this) On the receiving side, only packets with marker bit set will be examined.
Tests completed:
1. android standalone to android standalone
2. android standalone to chrome (with and without this change)
3. android on chrome
BUG=4145
R=glaznev@webrtc.org, mflodman@webrtc.org, perkj@webrtc.org, pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/47399004
Cr-Commit-Position: refs/heads/master@{#8905}
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}
Removes a lot of code that prevents refactoring VideoCodingModule. Tests
covering the module should be TEST_Fs, and this looks like like fairly
unused code in general.
Adds a 'rtp_player' binary which performs a small subset.
BUG=4391
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/44559004
Cr-Commit-Position: refs/heads/master@{#8787}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8787 4adac7df-926f-26a2-2b94-8c16560cd09d
CVO is, instead of rotating frame on the capture side, to have renderer rotate the frame based on a new rtp header extension.
The change includes
1. encoder side needs to pass this from raw frame to the encoded frame.
2. decoder needs to copy it from rtp packet (only the last packet of a frame has this info) to decoded frame.
R=mflodman@webrtc.orgTBR=stefan@webrtc.org
BUG=4145
Review URL: https://webrtc-codereview.appspot.com/46429006
Cr-Commit-Position: refs/heads/master@{#8767}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8767 4adac7df-926f-26a2-2b94-8c16560cd09d
Now when we don't use SwapFrame consistently anymore, we need to recycle allocations with a buffer pool instead. This CL adds a buffer pool class, and updates the vp8 decoder to use it. If this CL lands successfully I will update the other video producers as well.
BUG=1128
R=stefan@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/41189004
Cr-Commit-Position: refs/heads/master@{#8748}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8748 4adac7df-926f-26a2-2b94-8c16560cd09d
Pulls in new libvpx version that allows us to re-enable the
VideoProcessorIntegrationTest.ProcessNoLossDenoiserOnVP9
test in webrtc/modules/video_coding/codecs/test/videoprocessor_integrationtest.cc
Relevant changes:
* src/third_party/libvpx: 763fe7a..f80cf58
* src/tools/gyp: 4a9b712..d174d75
Details: 8d51d96..bd49b12/DEPS
Clang version was not updated in this roll.
BUG=4418
TBR=marpan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/41339004
Cr-Commit-Position: refs/heads/master@{#8745}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8745 4adac7df-926f-26a2-2b94-8c16560cd09d
Removes ThreadPosix::InitParams and a corresponding wait for an event.
This unblocks ThreadPosix::Start which had to wait for thread scheduling
for an event to trigger on the spawned thread, giving faster Start()
calls.
BUG=4413
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/43699004
Cr-Commit-Position: refs/heads/master@{#8709}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8709 4adac7df-926f-26a2-2b94-8c16560cd09d
> Speculative revert of 8631 "Remove lock from Bitrate() and FrameRate() in Video..."
>
> We ran into the alignment problem on Mac 10.9 debug again. This is the only CL I see in the range that adds an rtc::CriticalSection, so I'm trying out reverting it before attempting another roll.
>
> > Remove lock from Bitrate() and FrameRate() in VideoSender.
> > These methods are called on the VideoSender's construction thread, which is the same thread as modifies the value of _encoder. It's therefore safe to not require a lock to access _encoder on this thread.
> >
> > I'm making access to the rate variables from VCMGenericEncoder, thread safe, by using a lock that's not associated with the encoder. There should be little to no contention there. While modifying VCMGenericEncoder, I noticed that a couple of member variables weren't needed, so I removed them.
> >
> > The reason for this change is that getStats is currently contending with the encoder when Bitrate() is called. On my machine, this means that getStats can take about 25-30ms instead of ~1ms.
> >
> > Also adding some documentation for other methods and a suggestion for how we could avoid contention between the encoder and the network thread.
> >
> > BUG=2822
> > R=mflodman@webrtc.org
> >
> > Review URL: https://webrtc-codereview.appspot.com/43479004
>
> TBR=tommi@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/45529004TBR=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/46519004
Cr-Commit-Position: refs/heads/master@{#8645}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8645 4adac7df-926f-26a2-2b94-8c16560cd09d
We ran into the alignment problem on Mac 10.9 debug again. This is the only CL I see in the range that adds an rtc::CriticalSection, so I'm trying out reverting it before attempting another roll.
> Remove lock from Bitrate() and FrameRate() in VideoSender.
> These methods are called on the VideoSender's construction thread, which is the same thread as modifies the value of _encoder. It's therefore safe to not require a lock to access _encoder on this thread.
>
> I'm making access to the rate variables from VCMGenericEncoder, thread safe, by using a lock that's not associated with the encoder. There should be little to no contention there. While modifying VCMGenericEncoder, I noticed that a couple of member variables weren't needed, so I removed them.
>
> The reason for this change is that getStats is currently contending with the encoder when Bitrate() is called. On my machine, this means that getStats can take about 25-30ms instead of ~1ms.
>
> Also adding some documentation for other methods and a suggestion for how we could avoid contention between the encoder and the network thread.
>
> BUG=2822
> R=mflodman@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/43479004TBR=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/45529004
Cr-Commit-Position: refs/heads/master@{#8640}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8640 4adac7df-926f-26a2-2b94-8c16560cd09d
These methods are called on the VideoSender's construction thread, which is the same thread as modifies the value of _encoder. It's therefore safe to not require a lock to access _encoder on this thread.
I'm making access to the rate variables from VCMGenericEncoder, thread safe, by using a lock that's not associated with the encoder. There should be little to no contention there. While modifying VCMGenericEncoder, I noticed that a couple of member variables weren't needed, so I removed them.
The reason for this change is that getStats is currently contending with the encoder when Bitrate() is called. On my machine, this means that getStats can take about 25-30ms instead of ~1ms.
Also adding some documentation for other methods and a suggestion for how we could avoid contention between the encoder and the network thread.
BUG=2822
R=mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/43479004
Cr-Commit-Position: refs/heads/master@{#8631}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8631 4adac7df-926f-26a2-2b94-8c16560cd09d
