VideoDecoderParams contains the id of the receive video
stream. Motivation behind this change is to enable down
stream apps easier map raw non-decoded data to incoming
streams.
BUG=b/28636393
Review-Url: https://codereview.webrtc.org/2052233002
Cr-Commit-Position: refs/heads/master@{#13250}
Don't use VideoFrameBuffer::MutableDataY and friends, instead, use
I420Buffer::SetToBlack.
Also introduce static method I420Buffer::Create, to create an object and
return a scoped_refptr.
TBR=marpan@webrtc.org # Trivial change to video_denoiser.cc
BUG=webrtc:5921
Review-Url: https://codereview.webrtc.org/2078943002
Cr-Commit-Position: refs/heads/master@{#13212}
Removes the need to use VoEVolume::SetChannelOutputVolumeScaling().
BUG=webrtc:4690
Review-Url: https://codereview.webrtc.org/2062193002
Cr-Commit-Position: refs/heads/master@{#13194}
This change reduces the number of times the Android hardware video
encoder is reconfigured when making an outgoing call. With this change,
the encoder should only be initialized once as opposed to the ~3 times
it happens currently.
Before the fix, the following sequence of events caused the extra
reconfigurations:
1. After the SetLocalDescription call, the WebRtcVideoSendStream is created.
All frames from the camera are dropped until the corresponding
VideoSendStream is created.
2. SetRemoteDescription() triggers the VideoSendStream creation. At
this point, the encoder is configured for the first time, with the
frame dimensions set to a low resolution default (176x144).
3. When the first video frame is received from the camera after the
VideoSendStreamIsCreated, the encoder is reconfigured to the correct
dimensions. If we are using the Android hardware encoder, the default
configuration is set to encode from a memory buffer (use_surface=false).
4. When the frame is passed down to the encoder in
androidmediaencoder_jni.cc EncodeOnCodecThread(), it may be stored in
a texture instead of a memory buffer. In this case, yet another
reconfiguration takes place to enable encoding from a texture.
5. Even if the resolution and texture flag were known at the start of
the call, there would be a reconfiguration involved if the camera is
rotated (such as when making a call from a phone in portrait orientation).
The reason for that is that at construction time, WebRtcVideoEngine2
sets the VideoSinkWants structure parameter to request frames rotated
by the source; the early frames will then arrive in portrait resolution.
When the remote description is finally set, if the rotation RTP extension
is supported by the remote receiver, the source is asked to provide
non-rotated frames. The very next frame will then arrive in landscape
resolution with a non-zero rotation value to be applied by the receiver.
Since the encoder was configured with the last (portrait) frame size,
it's going to need to be reconfigured again.
The fix makes the following changes:
1. WebRtcVideoSendStream::OnFrame() now caches the last seen frame
dimensions, and whether the frame was stored in a texture.
2. When the encoder is configured the first time
(WebRtcVideoSendStream::SetCodec()) - the last seen frame dimensions
are used instead of the default dimensions.
3. A flag that indicates if encoding is to be done from a texture has
been added to the webrtc::VideoStream and webrtc::VideoCodec structs,
and it's been wired up to be passed down all the way to the JNI code in
androidmediaencoder_jni.cc.
4. MediaCodecVideoEncoder::InitEncode is now reading the is_surface
flag from the VideoCodec structure instead of guessing the default as
false. This way we end up with the correct encoder configuration the
first time around.
5. WebRtcVideoSendStream now takes an optimistic guess and requests non-
rotated frames when the supported RtpExtensions list is not available.
This makes the "early" frames arrive non-rotated, and the cached dimensions
will be correct for the common case when the rotation extension is supported.
If the other side is an older endpoint which does not support rotation,
the encoder will have to be reconfigured - but it's better to penalize the
uncommon case rather than the common one.
Review-Url: https://codereview.webrtc.org/2067103002
Cr-Commit-Position: refs/heads/master@{#13173}
Removes the need to use VoEVolume::SetInputMute()/GetInputMute().
BUG=webrtc:4690
NOTRY=true
Review-Url: https://codereview.webrtc.org/2066973002
Cr-Commit-Position: refs/heads/master@{#13172}
The function GetExecutablePath is a hack with poor portability. Delete
it and its caller GetTestFilePath. The latter was used in
videoframe_unittest.h, where it is replaced by
webrtc::test::ResourcePath.
Delete unused functions declared in base/testutils.h: ReadFile,
GetSiblingDirectory, GetGoogle3Directory, GetTalkDirectory,
CmpHelperFileEq, EXPECT_FILEEQ, ASSERT_FILEEQ.
Delete unused functions declared in media/base/testutils.h:
GetTestFilePath (see above), LoadPlanarYuvTestImage,
DumpPlanarYuvTestImage, ComputePSNR, ComputeSumSquareError.
The functions LoadPlanarYuvTestImage, DumpPlanarYuvTestImage were used
in yuvscaler_unittests.cc and planarfunctions_unittests.cc, under
webrtc/pc. However, these tests are never compiled or run, and appear
not to have been for the last few years, and are therefore deleted
rather than updated. It might make sense to check if libyuv have
comparable tests, and if not, resurrect them as part of libyuv
unittests.
BUG=
R=perkj@webrtc.org
Review URL: https://codereview.webrtc.org/2058043002 .
Cr-Commit-Position: refs/heads/master@{#13163}
The test sent a media packet, then verified it was sent by checking the
"last packet sent"'s ID. But the last packet sent may have been
a STUN packet that came *after* the media packet.
BUG=webrtc:5978
Review-Url: https://codereview.webrtc.org/2071573002
Cr-Commit-Position: refs/heads/master@{#13156}
Added the plumbing necessary to get two different lists of codecs from
WebRtcVoiceEngine up to MediaSessionDescriptionFactory.
This should be the last step in this set of CLs. Once
https://codereview.webrtc.org/1991233004/ has landed, it's possible to
implement the ReceiveCodecs getter with the info from the
AudioDecoderFactory. The factory needs to be updated to actually
produce the correct list, as well.
BUG=webrtc:5805
Review-Url: https://codereview.webrtc.org/2013053002
Cr-Commit-Position: refs/heads/master@{#13131}
CreatePeerConnectionFactory does not yet expose the ability to set the
factory from the outside.
Added notry due to android_dbg being broken.
NOTRY=True
BUG=webrtc:5805
Review-Url: https://codereview.webrtc.org/1991233004
Cr-Commit-Position: refs/heads/master@{#13112}
Introduce a new method I420Buffer::CropAndScale, and a static
convenience helper I420Buffer::CenterCropAndScale. Use them for almost
all scaling needs.
Delete the Scaler class and the cricket::VideoFrame::Stretch* methods.
BUG=webrtc:5682
R=pbos@webrtc.org, perkj@webrtc.org, stefan@webrtc.org
Review URL: https://codereview.webrtc.org/2020593002 .
Cr-Commit-Position: refs/heads/master@{#13110}
Every message will now be traced with the location from which it was
posted, including function name, file and line number.
This CL also writes a normal LOG message when the dispatch took more
than a certain amount of time (currently 50ms).
This logging should help us identify messages that are taking
longer than expected to be dispatched.
R=pthatcher@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/2019423006 .
Cr-Commit-Position: refs/heads/master@{#13104}
Instead of the default copy constructor, the Copy() method has to be used. In this CL, the number of copies has been reduced significantly in production code. One case in the video engine remains, where we need to restart a video stream. Even in that case, I'm sure we could avoid it, but for this particular CL, I decided against it to keep things simple (and it's also an edge case). Most importantly, creating copies is made harder and the interface encourages ownership transfers.
R=mflodman@webrtc.org, pbos@webrtc.org
Review URL: https://codereview.webrtc.org/2042603002 .
Cr-Commit-Position: refs/heads/master@{#13102}
Reason for revert:
Plan to reland with InitToBlack kept, to be able to update Chrome to use the new I420Buffer::SetToBlack method.
Original issue's description:
> Revert of New static method I420Buffer::SetToBlack. (patchset #4 id:60001 of https://codereview.webrtc.org/2029273004/ )
>
> Reason for revert:
> Breaks chrome, in particular, the tests in
>
> media_stream_remote_video_source_unittest.cc
>
> use the InitToBlack method which is being deleted.
>
> Original issue's description:
> > New static method I420Buffer::SetToBlack.
> >
> > Replaces cricket::VideoFrame::SetToBlack and
> > cricket::WebRtcVideoFrame::InitToBlack, which are deleted.
> >
> > Refactors the black frame logic in VideoBroadcaster, and a few of the
> > tests.
> >
> > BUG=webrtc:5682
> >
> > Committed: https://crrev.com/663f9e2ddc86e813f6db04ba2cf5ac1ed9e7ef67
> > Cr-Commit-Position: refs/heads/master@{#13063}
>
> TBR=perkj@webrtc.org,pbos@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:5682
>
> Committed: https://crrev.com/271d74078894bb24f454eb31b77e4ce38097a2fa
> Cr-Commit-Position: refs/heads/master@{#13065}
TBR=perkj@webrtc.org,pbos@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5682
Review-Url: https://codereview.webrtc.org/2049513005
Cr-Commit-Position: refs/heads/master@{#13083}
Reason for revert:
Breaks chrome, in particular, the tests in
media_stream_remote_video_source_unittest.cc
use the InitToBlack method which is being deleted.
Original issue's description:
> New static method I420Buffer::SetToBlack.
>
> Replaces cricket::VideoFrame::SetToBlack and
> cricket::WebRtcVideoFrame::InitToBlack, which are deleted.
>
> Refactors the black frame logic in VideoBroadcaster, and a few of the
> tests.
>
> BUG=webrtc:5682
>
> Committed: https://crrev.com/663f9e2ddc86e813f6db04ba2cf5ac1ed9e7ef67
> Cr-Commit-Position: refs/heads/master@{#13063}
TBR=perkj@webrtc.org,pbos@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5682
Review-Url: https://codereview.webrtc.org/2049023002
Cr-Commit-Position: refs/heads/master@{#13065}
Replaces cricket::VideoFrame::SetToBlack and
cricket::WebRtcVideoFrame::InitToBlack, which are deleted.
Refactors the black frame logic in VideoBroadcaster, and a few of the
tests.
BUG=webrtc:5682
Review-Url: https://codereview.webrtc.org/2029273004
Cr-Commit-Position: refs/heads/master@{#13063}
This CL adds support for an extension on RTP frames to allow the sender
to specify the minimum and maximum playout delay limits.
The receiver makes a best-effort attempt to keep the capture-to-render delay
within this range. This allows different types of application to specify
different end-to-end delay goals. For example gaming can support rendering
of frames as soon as received on receiver to minimize delay. A movie playback
application can specify a minimum playout delay to allow fixed buffering
in presence of network jitter.
There are no tests at this time and most of testing is done with chromium
webrtc prototype.
On chromoting performance tests, this extension helps bring down end-to-end
delay by about 150 ms on small frames.
BUG=webrtc:5895
Review-Url: https://codereview.webrtc.org/2007743003
Cr-Commit-Position: refs/heads/master@{#13059}
This means there's only one thread hop to the worker thread.
At the video engine level, SetOptions and SetSource
are combined into one method (all within the same critical section)
which ensures that no frame will be encoded while SetVideoSend
is only partially finished.
BUG=webrtc:5691
Review-Url: https://codereview.webrtc.org/1838413002
Cr-Commit-Position: refs/heads/master@{#13022}
VoEBase is plumbed to optionally take an AudioDecoderFactory, or create
a builtin factory if none is provided.
Retained the CreateChannel interfaces in Channel and ChannelManager
and added variants for injecting an AudioDecoderFactory. The
"old-style" variants call CreateBuiltinAudioDecoderFactory to get a
factory to use.
(Just realized this means each channel uses a separate factory with the
old-style calls. Probably ok.)
BUG=webrtc:5805
Review-Url: https://codereview.webrtc.org/1993783002
Cr-Commit-Position: refs/heads/master@{#12961}
Currently there are two structs that are identical and track extension details:
webrtc::RtpExtension
cricket::RtpHeaderExtension
The use of the structs is mixed in the code to track the extensions being
supported. This results in duplicate definition of
the URI constants and there is code to convert between the two structs.
Clean up to use a single RtpHeader throughout the codebase. The actual location
of RtpHeader may change in future (perhaps to be located in api/). Additionally,
this CL renames some of the constants to clarify Uri and Id use.
BUG= webrtc:5895
Review-Url: https://codereview.webrtc.org/1984983002
Cr-Commit-Position: refs/heads/master@{#12924}
This affects the webrtc::VideoFrameBuffer and cricket::VideoFrame
classes.
To make this work, VideoFrameFactory is changed to use an
I420BufferPool rather than a plain VideoFrame to cache allocated
frames.
The I420BufferPool is reorganized to return an I420Buffer,
rather than a proxy object.
BUG=webrtc:5921, webrtc:5682
Review-Url: https://codereview.webrtc.org/2009193002
Cr-Commit-Position: refs/heads/master@{#12919}
Splits VideoCapturer::OnFrameCaptured into helper methods,
which enables use of the VideoAdaptation logic without
using a frame factory.
Refactors AndroidVideoCapturer to make adaptation decision
earlier, so we can crop and rotate using
NV12ToI420Rotate.
BUG=webrtc:5682
Review-Url: https://codereview.webrtc.org/1973873003
Cr-Commit-Position: refs/heads/master@{#12895}
GetWidth and GetHeight (renamed to width and height),
GetNativeHandle (replaced by video_frame_buffer()->native_handle).
TBR=tkchin@webrtc.org (trivial changes to objc RTCVideoFrame and VideoRendererAdapter)
BUG=webrtc:5682
Review-Url: https://codereview.webrtc.org/1990063005
Cr-Commit-Position: refs/heads/master@{#12822}
Needed to avoid DrMemory warnings, if the frame is passed to libyuv
AVX assembly functions.
BUG=libyuv:377
Review-Url: https://codereview.webrtc.org/1985693002
Cr-Commit-Position: refs/heads/master@{#12765}
This is similar to how a "receive" method is used to apply
RtpParameters to an RtpReceiver in ORTC. Currently, SetParameters
doesn't allow changing the parameters, so the main use of the API is
to retrieve the set of configured codecs. But other uses will likely
be made possible in the future.
R=glaznev@webrtc.org, pthatcher@webrtc.org, tkchin@webrtc.org
Review URL: https://codereview.webrtc.org/1917193008 .
Cr-Commit-Position: refs/heads/master@{#12761}
Reason for revert:
Speculative revert to see if failures on the DrMemory bot are related to this cl. See e.g. here:
https://build.chromium.org/p/client.webrtc/builders/Win%20DrMemory%20Full/builds/4243
UNINITIALIZED READ: reading 0x04980040-0x04980060 32 byte(s) within 0x04980040-0x04980060
# 0 CopyRow_AVX
# 1 CopyPlane
# 2 I420Copy
# 3 webrtc::ExtractBuffer
# 4 cricket::WebRtcVideoCapturer::SignalFrameCapturedOnStartThread
# 5 cricket::WebRtcVideoCapturer::OnIncomingCapturedFrame
# 6 FakeWebRtcVideoCaptureModule::SendFrame
# 7 WebRtcVideoCapturerTest_TestCaptureVcm_Test::TestBody
# 8 testing::internal::HandleSehExceptionsInMethodIfSupported<>
Original issue's description:
> Reland of Delete webrtc::VideoFrame methods buffer and stride. (patchset #1 id:1 of https://codereview.webrtc.org/1935443002/ )
>
> Reason for revert:
> I plan to reland this change in a week or two, after downstream users are updated.
>
> Original issue's description:
> > Revert of Delete webrtc::VideoFrame methods buffer and stride. (patchset #14 id:250001 of https://codereview.webrtc.org/1900673002/ )
> >
> > Reason for revert:
> > Breaks chrome FYI bots.
> >
> > Original issue's description:
> > > Delete webrtc::VideoFrame methods buffer and stride.
> > >
> > > To make the HasOneRef/IsMutable hack work, also had to change the
> > > video_frame_buffer method to return a const ref to a scoped_ref_ptr,
> > > to not imply an AddRef.
> > >
> > > BUG=webrtc:5682
> >
> > TBR=perkj@webrtc.org,magjed@webrtc.org,pbos@webrtc.org,pthatcher@webrtc.org,stefan@webrtc.org
> > # Skipping CQ checks because original CL landed less than 1 days ago.
> > NOPRESUBMIT=true
> > NOTREECHECKS=true
> > NOTRY=true
> > BUG=webrtc:5682
> >
> > Committed: https://crrev.com/5b3c443d301f2c2f18dac5b02652c08b91ea3828
> > Cr-Commit-Position: refs/heads/master@{#12558}
>
> TBR=perkj@webrtc.org,magjed@webrtc.org,pbos@webrtc.org,pthatcher@webrtc.org,stefan@webrtc.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=webrtc:5682
>
> Committed: https://crrev.com/d0dc66e0ea30c8614001e425a4ae0aa7dd56c2a7
> Cr-Commit-Position: refs/heads/master@{#12721}
TBR=perkj@webrtc.org,magjed@webrtc.org,pbos@webrtc.org,pthatcher@webrtc.org,stefan@webrtc.org,nisse@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5682
Review-Url: https://codereview.webrtc.org/1983583002
Cr-Commit-Position: refs/heads/master@{#12745}
Wires up existing libvpx_build_vp9==0 GYP flag into WebRTC and makes VP9
optional. Change is GYP only for now since libvpx's GN files build VP9
unconditionally.
BUG=webrtc:5884
R=kjellander@webrtc.org
Review URL: https://codereview.webrtc.org/1970343002 .
Cr-Commit-Position: refs/heads/master@{#12741}
The caller can set a negative or zero file size to avoid using a limit.
BUG=
Review-Url: https://codereview.webrtc.org/1974453002
Cr-Commit-Position: refs/heads/master@{#12730}
