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}
No need to include this header since the API is just taking a pointer to
it.
BUG=1092
TEST=./webrtc/build/gyp_webrtc && ninja -C out/Debug
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/44059004
Patch from Thiago Farina <tfarina@chromium.org>.
Cr-Commit-Position: refs/heads/master@{#8928}
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}
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}
All these tests crashed before r8811. These tests should've been with
that change but r8811 was pushed in before to make bots green.
BUG=1788, 1667
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/48669004
Cr-Commit-Position: refs/heads/master@{#8881}
Removes 'googCaptureJitterMs' and 'googCaptureQueueDelayMsPerS' from
talk/. The overuse-detection method used is based on encoding time,
so these stats aren't useful enough to warrant having them showing up in
GetStats().
BUG=
R=stefan@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/50469004
Cr-Commit-Position: refs/heads/master@{#8874}
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}
If built-in Echo Cancellation is available on a device it is automatically enabled. The reason is that it in most cases performs better than the WebRTC software echo control for mobile. The drawback is that we can not develop, test and rollout the delay agnostic AEC (DA-AEC) on Android as for desktops.
This CL includes
- adding a media constraint to enable/disable DA-AEC.
- automatically turning on echo cancellation if DA-AEC is enabled.
- a fix in the AEC that enables delay estimation when DA-AEC is enabled, but delay metrics is disabled.
- sets the Config struct ReportedDelay, which controls DA-AEC internally in the AEC.
The test code to verify that it works in AppRTCDemo can be found here:
https://webrtc-codereview.appspot.com/50479004/
BUG=4472
TESTED=locally on N7, N6, Android One
R=glaznev@webrtc.org, perkj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/48699004
Cr-Commit-Position: refs/heads/master@{#8861}
This CL deletes VideoAdapter::AdaptFrame and replaces the remaining calls with AdaptFrameResolution instead.
I do not expect this CL to fix the flaky VideoAdapterTests yet. I intend to replace FileVideoCapturer with a deterministic FakeVideoCapturer in a follow-up CL.
BUG=4317
R=pbos@webrtc.org, pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/44769004
Cr-Commit-Position: refs/heads/master@{#8848}
And add a constructor for creating an uninitialized Buffer of a
specified size.
(I intend to follow up with more Buffer changes, but since it's rather
widely used, the rename is quite noisy and works better as a separate
CL.)
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/48579004
Cr-Commit-Position: refs/heads/master@{#8841}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8841 4adac7df-926f-26a2-2b94-8c16560cd09d
I've kicked of a roll into Chromium with out the WebRtcVideoEngine2 change, to see if it was causing the roll problems, but re-landing in the meantime.
> Revert 8809 "Set WebRtcVideoEngine2 as the WebRtcMediaEngine."
> content_browsertests started failing around the time the change landed and rolls are failing now.
> I'm going to try rolling this back, start a roll, and then re-land.
>
> > Set WebRtcVideoEngine2 as the WebRtcMediaEngine.
> >
> > Removes the experiment launching WebRTC-NewVideoAPI. This field trial
> > has shown no major regressions on Chrome Canary/Dev that haven't been
> > addressed, so enabling it in time before feature freeze.
> >
> > BUG=1788
> > R=mflodman@webrtc.org
> >
> > Review URL: https://webrtc-codereview.appspot.com/44759004
>
> TBR=pbos@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/43889004TBR=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/50459004
Cr-Commit-Position: refs/heads/master@{#8817}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8817 4adac7df-926f-26a2-2b94-8c16560cd09d
content_browsertests started failing around the time the change landed and rolls are failing now.
I'm going to try rolling this back, start a roll, and then re-land.
> Set WebRtcVideoEngine2 as the WebRtcMediaEngine.
>
> Removes the experiment launching WebRTC-NewVideoAPI. This field trial
> has shown no major regressions on Chrome Canary/Dev that haven't been
> addressed, so enabling it in time before feature freeze.
>
> BUG=1788
> R=mflodman@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/44759004TBR=pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/43889004
Cr-Commit-Position: refs/heads/master@{#8816}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8816 4adac7df-926f-26a2-2b94-8c16560cd09d
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
This flag is passed to existing VieExternalCodec API (and others) to denote encoders that don't require/expect frames from the normal capture pipeline. This is the simplest way to allow camera->encoder texture support, until textures are supported through the normal camera pipeline and the lifetime issues are all figured out (I hear this is on the backlog, but not there yet).
Ideally, the flag would be on the encoder, but that doesn't work with SimulcastEncoderAdapter, since it doesn't create an encoder right away.
Note that this change only affects WebRtcVideoEngine (not WRVE2), since WRVE2 uses video_send_stream, and my hope is that by the time things have switched to WRVE2, textures will be supported with the normal camera pipeline and the dependency on internal sources can be thrown away.
BUG=
R=pbos@webrtc.org, pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/42349004
Cr-Commit-Position: refs/heads/master@{#8769}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8769 4adac7df-926f-26a2-2b94-8c16560cd09d
