We use Optional in our public API, so its header should be in
webrtc/api/.
BUG=webrtc:8205
Review-Url: https://codereview.webrtc.org/3011943002
Cr-Commit-Position: refs/heads/master@{#19693}
This CL encapsulates the logic for unifying the internal and external
video encoders into a helper class. The purpose is to prepare for
introducing a new video encoder factory interface that inherently
represents all encoders (i.e. both internal and external). A helper
interface EncoderFactoryAdapter is introduced that both the old
WebRtcVideoEncoderFactory and the new factory interface can implement
and serves as common point to leave the rest of the code unchanged.
BUG=webrtc:7925
Review-Url: https://codereview.webrtc.org/3006713002
Cr-Commit-Position: refs/heads/master@{#19600}
Currently, ownership of the wrapped hardware encoder is handled outside
VideoEncoderSoftwareFallbackWrapper. It's easier if
VideoEncoderSoftwareFallbackWrapper owns and relases it instead.
BUG=webrtc:7925
Review-Url: https://codereview.webrtc.org/3007683002
Cr-Commit-Position: refs/heads/master@{#19572}
Currently, webrtc::VideoEncoders are supposed to be deleted through the
factory that created them with the
WebRtcVideoEncoderFactory::DestroyVideoEncoder method. In practice,
we sometimes use this method and sometimes we just call delete on the
webrtc::VideoEncoder pointer. We want to be able to consistently use the
normal destructor of webrtc::VideoEncoder instead of having to call
DestroyVideoEncoder so that we can put webrtc::VideoEncoder inside
an std::unique_ptr and make ownership more clear. As part of webrtc:7925
we also want to make a new encoder factory class that does not have the
DestroyVideoEncoder() method, and this CL is a step in that direction.
This CL introduces a helper function CreateScopedVideoEncoder that takes
a webrtc::VideoEncoder and a WebRtcVideoEncoderFactory pointer, and
returns a new webrtc::VideoEncoder instance that can be deleted through
the regular destructor.
This CL also removes WebRtcSimulcastEncoderFactory that almost only
contains logic for handling the DestroyVideoEncoder calls that we no
longer need, and inlines the rest of the logic inside the
WebRtcVideoChannel::WebRtcVideoSendStream::CreateVideoEncoder method.
BUG=webrtc:7925
Review-Url: https://codereview.webrtc.org/3007643002
Cr-Commit-Position: refs/heads/master@{#19564}
Moved the headers video_receive_stream.h and video_send_stream.h from
webrtc/ into webrtc/call/ as part of the Slim and Modular work.
The GN target webrtc:video_stream_api has moved to
webrtc/call:video_stream_api.
There are headers left in webrtc/ with the same name including the
moved headers in webrtc/call/ for not breaking external projects
depending on WebRTC.
At the same time, some minor cleanup is done: Non-pure-virtual functions declared in the two affected headers now have definitions in the same target. After making this change, our 'chromium-style' plugin detected some style violations that have now been fixed: non-inlined constructors and destructors have been added to a number of classes, both inside the GN target of the two affected headers, and in other targets.
BUG=webrtc:8107
Review-Url: https://codereview.webrtc.org/3000253002
Cr-Commit-Position: refs/heads/master@{#19448}
In preparation of making RTP packet demuxing many-to-one (one SSRC goes to one sink, but one sink may have multiple SSRCs), we need to remove FlexFEC's dependence on being able to register itself with the demuxer. Instead, we register FlexFEC streams with the streams they protect; when those streams get packets, they'll forward them to their associated FlexFEC streams, too.
BUG=webrtc:7135
Review-Url: https://codereview.webrtc.org/2974453002
Cr-Commit-Position: refs/heads/master@{#19219}
I used a command like this to update the paths:
perl -pi -e "s/webrtc\/base/webrtc\/rtc_base/g" `find webrtc/rtc_base -name "*.cc" -o -name "*.h"`
BUG=webrtc:7634
NOPRESUBMIT=True # cpplint errors that aren't caused by this CL.
Review-Url: https://codereview.webrtc.org/2969623003
Cr-Commit-Position: refs/heads/master@{#18870}
WebRtcVideoChannel and and WebRtcVideoEngine seem to have been removed, and only WebRtcVideoChannel2 and WebRtcVideoEngine2 remain, which removes the need for the "2" postfix.
BUG=None
Review-Url: https://codereview.webrtc.org/2932073002
Cr-Commit-Position: refs/heads/master@{#18531}
