webrtc_m130/webrtc/media/engine/webrtcvideoengine2.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

521 lines
20 KiB
C
Raw Normal View History

/*
* Copyright (c) 2014 The WebRTC project authors. All Rights Reserved.
*
* Use of this source code is governed by a BSD-style license
* that can be found in the LICENSE file in the root of the source
* tree. An additional intellectual property rights grant can be found
* in the file PATENTS. All contributing project authors may
* be found in the AUTHORS file in the root of the source tree.
*/
#ifndef WEBRTC_MEDIA_ENGINE_WEBRTCVIDEOENGINE2_H_
#define WEBRTC_MEDIA_ENGINE_WEBRTCVIDEOENGINE2_H_
#include <map>
#include <memory>
#include <set>
#include <string>
#include <vector>
#include "webrtc/base/asyncinvoker.h"
#include "webrtc/base/criticalsection.h"
#include "webrtc/base/networkroute.h"
#include "webrtc/base/thread_annotations.h"
#include "webrtc/base/thread_checker.h"
#include "webrtc/media/base/videosinkinterface.h"
#include "webrtc/media/base/videosourceinterface.h"
#include "webrtc/call.h"
Move talk/media to webrtc/media I removed the 'libjingle' target in talk/libjingle.gyp and replaced all users of it with base/base.gyp:rtc_base. It seems the jsoncpp and expat dependencies were not used by it's previous references. The files in talk/media/testdata were uploaded to Google Storage and added .sha1 files in resources/media instead of simply moving them. The previously disabled warnings that were inherited from talk/build/common.gypi are now replaced by target-specific disabling of only the failing warnings. Additional disabling was needed since the stricter compilation warnings that applies to code in webrtc/. License headers will be updated in a follow-up CL in order to not break Git history. Other modifications: * Updated the header guards. * Sorted the includes using chromium/src/tools/sort-headers.py except for these files: talk/app/webrtc/peerconnectionendtoend_unittest.cc talk/app/webrtc/java/jni/androidmediadecoder_jni.cc talk/app/webrtc/java/jni/androidmediaencoder_jni.cc webrtc/media/devices/win32devicemanager.cc. * Unused GYP reference to libjingle_tests_additional_deps was removed. * Removed duplicated GYP entries of webrtc/base/testutils.cc webrtc/base/testutils.h The HAVE_WEBRTC_VIDEO and HAVE_WEBRTC_VOICE defines were used by only talk/media, so they were moved to the media.gyp. I also checked that none of EXPAT_RELATIVE_PATH, FEATURE_ENABLE_VOICEMAIL, GTEST_RELATIVE_PATH, JSONCPP_RELATIVE_PATH, LOGGING=1, SRTP_RELATIVE_PATH, FEATURE_ENABLE_SSL, FEATURE_ENABLE_VOICEMAIL, FEATURE_ENABLE_PSTN, HAVE_SCTP, HAVE_SRTP, are used by the talk/media code. For Chromium, the following changes will need to be applied to the roll CL that updates the DEPS for WebRTC and libjingle: https://codereview.chromium.org/1604303002/ BUG=webrtc:5420 NOPRESUBMIT=True TBR=tommi@webrtc.org Review URL: https://codereview.webrtc.org/1587193006 Cr-Commit-Position: refs/heads/master@{#11495}
2016-02-04 23:52:28 -08:00
#include "webrtc/media/base/mediaengine.h"
#include "webrtc/media/engine/webrtcvideodecoderfactory.h"
#include "webrtc/media/engine/webrtcvideoencoderfactory.h"
#include "webrtc/transport.h"
Reland of Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. (patchset #1 id:1 of https://codereview.webrtc.org/2471783002/ ) Reason for revert: Relanding after known downstream breakages have been fixed. Original issue's description: > Revert of Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. (patchset #7 id:120001 of https://codereview.webrtc.org/2383093002/ ) > > Reason for revert: > Breaks chrome, see https://build.chromium.org/p/chromium.webrtc.fyi/builders/Mac%20Builder/builds/19019/steps/compile/logs/stdio > > Analysis: Chrome uses cricket::VideoFrame, without explicitly including webrtc/media/base/videoframe.h, and breaks when that file is no longer included by any other webrtc headers. Will reland after updating Chrome. > > Original issue's description: > > Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. > > > > Replaced with webrtc::VideoFrame. > > > > TBR=mflodman@webrtc.org > > BUG=webrtc:5682 > > > > Committed: https://crrev.com/45c8b8940042bd2574c39920804ade8343cefdba > > Cr-Commit-Position: refs/heads/master@{#14885} > > TBR=perkj@webrtc.org,pthatcher@webrtc.org,tkchin@webrtc.org,mflodman@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/7341ab8e2505c9763d208e069bda269018357e7d > Cr-Commit-Position: refs/heads/master@{#14886} TBR=perkj@webrtc.org,pthatcher@webrtc.org,tkchin@webrtc.org,mflodman@webrtc.org,stefan@webrtc.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=webrtc:5682 Review-Url: https://codereview.webrtc.org/2487633002 Cr-Commit-Position: refs/heads/master@{#15039}
2016-11-11 03:55:13 -08:00
#include "webrtc/video_frame.h"
#include "webrtc/video_receive_stream.h"
#include "webrtc/video_send_stream.h"
namespace webrtc {
class VideoDecoder;
class VideoEncoder;
struct MediaConfig;
}
namespace rtc {
class Thread;
} // namespace rtc
namespace cricket {
class VideoCapturer;
class VideoProcessor;
class VideoRenderer;
class VoiceMediaChannel;
class WebRtcDecoderObserver;
class WebRtcEncoderObserver;
class WebRtcLocalStreamInfo;
class WebRtcRenderAdapter;
class WebRtcVideoChannel2;
class WebRtcVideoChannelRecvInfo;
class WebRtcVideoChannelSendInfo;
class WebRtcVoiceEngine;
class WebRtcVoiceMediaChannel;
struct Device;
class UnsignalledSsrcHandler {
public:
enum Action {
kDropPacket,
kDeliverPacket,
};
virtual Action OnUnsignalledSsrc(WebRtcVideoChannel2* channel,
uint32_t ssrc) = 0;
virtual ~UnsignalledSsrcHandler() = default;
};
// TODO(pbos): Remove, use external handlers only.
class DefaultUnsignalledSsrcHandler : public UnsignalledSsrcHandler {
public:
DefaultUnsignalledSsrcHandler();
Action OnUnsignalledSsrc(WebRtcVideoChannel2* channel,
uint32_t ssrc) override;
Reland of Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. (patchset #1 id:1 of https://codereview.webrtc.org/2471783002/ ) Reason for revert: Relanding after known downstream breakages have been fixed. Original issue's description: > Revert of Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. (patchset #7 id:120001 of https://codereview.webrtc.org/2383093002/ ) > > Reason for revert: > Breaks chrome, see https://build.chromium.org/p/chromium.webrtc.fyi/builders/Mac%20Builder/builds/19019/steps/compile/logs/stdio > > Analysis: Chrome uses cricket::VideoFrame, without explicitly including webrtc/media/base/videoframe.h, and breaks when that file is no longer included by any other webrtc headers. Will reland after updating Chrome. > > Original issue's description: > > Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. > > > > Replaced with webrtc::VideoFrame. > > > > TBR=mflodman@webrtc.org > > BUG=webrtc:5682 > > > > Committed: https://crrev.com/45c8b8940042bd2574c39920804ade8343cefdba > > Cr-Commit-Position: refs/heads/master@{#14885} > > TBR=perkj@webrtc.org,pthatcher@webrtc.org,tkchin@webrtc.org,mflodman@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/7341ab8e2505c9763d208e069bda269018357e7d > Cr-Commit-Position: refs/heads/master@{#14886} TBR=perkj@webrtc.org,pthatcher@webrtc.org,tkchin@webrtc.org,mflodman@webrtc.org,stefan@webrtc.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=webrtc:5682 Review-Url: https://codereview.webrtc.org/2487633002 Cr-Commit-Position: refs/heads/master@{#15039}
2016-11-11 03:55:13 -08:00
rtc::VideoSinkInterface<webrtc::VideoFrame>* GetDefaultSink() const;
void SetDefaultSink(VideoMediaChannel* channel,
Reland of Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. (patchset #1 id:1 of https://codereview.webrtc.org/2471783002/ ) Reason for revert: Relanding after known downstream breakages have been fixed. Original issue's description: > Revert of Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. (patchset #7 id:120001 of https://codereview.webrtc.org/2383093002/ ) > > Reason for revert: > Breaks chrome, see https://build.chromium.org/p/chromium.webrtc.fyi/builders/Mac%20Builder/builds/19019/steps/compile/logs/stdio > > Analysis: Chrome uses cricket::VideoFrame, without explicitly including webrtc/media/base/videoframe.h, and breaks when that file is no longer included by any other webrtc headers. Will reland after updating Chrome. > > Original issue's description: > > Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. > > > > Replaced with webrtc::VideoFrame. > > > > TBR=mflodman@webrtc.org > > BUG=webrtc:5682 > > > > Committed: https://crrev.com/45c8b8940042bd2574c39920804ade8343cefdba > > Cr-Commit-Position: refs/heads/master@{#14885} > > TBR=perkj@webrtc.org,pthatcher@webrtc.org,tkchin@webrtc.org,mflodman@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/7341ab8e2505c9763d208e069bda269018357e7d > Cr-Commit-Position: refs/heads/master@{#14886} TBR=perkj@webrtc.org,pthatcher@webrtc.org,tkchin@webrtc.org,mflodman@webrtc.org,stefan@webrtc.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=webrtc:5682 Review-Url: https://codereview.webrtc.org/2487633002 Cr-Commit-Position: refs/heads/master@{#15039}
2016-11-11 03:55:13 -08:00
rtc::VideoSinkInterface<webrtc::VideoFrame>* sink);
virtual ~DefaultUnsignalledSsrcHandler() = default;
private:
uint32_t default_recv_ssrc_;
Reland of Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. (patchset #1 id:1 of https://codereview.webrtc.org/2471783002/ ) Reason for revert: Relanding after known downstream breakages have been fixed. Original issue's description: > Revert of Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. (patchset #7 id:120001 of https://codereview.webrtc.org/2383093002/ ) > > Reason for revert: > Breaks chrome, see https://build.chromium.org/p/chromium.webrtc.fyi/builders/Mac%20Builder/builds/19019/steps/compile/logs/stdio > > Analysis: Chrome uses cricket::VideoFrame, without explicitly including webrtc/media/base/videoframe.h, and breaks when that file is no longer included by any other webrtc headers. Will reland after updating Chrome. > > Original issue's description: > > Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. > > > > Replaced with webrtc::VideoFrame. > > > > TBR=mflodman@webrtc.org > > BUG=webrtc:5682 > > > > Committed: https://crrev.com/45c8b8940042bd2574c39920804ade8343cefdba > > Cr-Commit-Position: refs/heads/master@{#14885} > > TBR=perkj@webrtc.org,pthatcher@webrtc.org,tkchin@webrtc.org,mflodman@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/7341ab8e2505c9763d208e069bda269018357e7d > Cr-Commit-Position: refs/heads/master@{#14886} TBR=perkj@webrtc.org,pthatcher@webrtc.org,tkchin@webrtc.org,mflodman@webrtc.org,stefan@webrtc.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=webrtc:5682 Review-Url: https://codereview.webrtc.org/2487633002 Cr-Commit-Position: refs/heads/master@{#15039}
2016-11-11 03:55:13 -08:00
rtc::VideoSinkInterface<webrtc::VideoFrame>* default_sink_;
};
// WebRtcVideoEngine2 is used for the new native WebRTC Video API (webrtc:1667).
class WebRtcVideoEngine2 {
public:
WebRtcVideoEngine2();
virtual ~WebRtcVideoEngine2();
// Basic video engine implementation.
void Init();
WebRtcVideoChannel2* CreateChannel(webrtc::Call* call,
const MediaConfig& config,
const VideoOptions& options);
std::vector<VideoCodec> codecs() const;
RtpCapabilities GetCapabilities() const;
// Set a WebRtcVideoDecoderFactory for external decoding. Video engine does
// not take the ownership of |decoder_factory|. The caller needs to make sure
// that |decoder_factory| outlives the video engine.
void SetExternalDecoderFactory(WebRtcVideoDecoderFactory* decoder_factory);
// Set a WebRtcVideoEncoderFactory for external encoding. Video engine does
// not take the ownership of |encoder_factory|. The caller needs to make sure
// that |encoder_factory| outlives the video engine.
virtual void SetExternalEncoderFactory(
WebRtcVideoEncoderFactory* encoder_factory);
private:
bool initialized_;
WebRtcVideoDecoderFactory* external_decoder_factory_;
WebRtcVideoEncoderFactory* external_encoder_factory_;
std::unique_ptr<WebRtcVideoEncoderFactory> simulcast_encoder_factory_;
};
class WebRtcVideoChannel2 : public VideoMediaChannel, public webrtc::Transport {
public:
WebRtcVideoChannel2(webrtc::Call* call,
const MediaConfig& config,
const VideoOptions& options,
WebRtcVideoEncoderFactory* external_encoder_factory,
WebRtcVideoDecoderFactory* external_decoder_factory);
~WebRtcVideoChannel2() override;
// VideoMediaChannel implementation
rtc::DiffServCodePoint PreferredDscp() const override;
bool SetSendParameters(const VideoSendParameters& params) override;
bool SetRecvParameters(const VideoRecvParameters& params) override;
webrtc::RtpParameters GetRtpSendParameters(uint32_t ssrc) const override;
bool SetRtpSendParameters(uint32_t ssrc,
const webrtc::RtpParameters& parameters) override;
webrtc::RtpParameters GetRtpReceiveParameters(uint32_t ssrc) const override;
bool SetRtpReceiveParameters(
uint32_t ssrc,
const webrtc::RtpParameters& parameters) override;
bool GetSendCodec(VideoCodec* send_codec) override;
bool SetSend(bool send) override;
bool SetVideoSend(
uint32_t ssrc,
bool enable,
const VideoOptions* options,
Reland of Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. (patchset #1 id:1 of https://codereview.webrtc.org/2471783002/ ) Reason for revert: Relanding after known downstream breakages have been fixed. Original issue's description: > Revert of Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. (patchset #7 id:120001 of https://codereview.webrtc.org/2383093002/ ) > > Reason for revert: > Breaks chrome, see https://build.chromium.org/p/chromium.webrtc.fyi/builders/Mac%20Builder/builds/19019/steps/compile/logs/stdio > > Analysis: Chrome uses cricket::VideoFrame, without explicitly including webrtc/media/base/videoframe.h, and breaks when that file is no longer included by any other webrtc headers. Will reland after updating Chrome. > > Original issue's description: > > Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. > > > > Replaced with webrtc::VideoFrame. > > > > TBR=mflodman@webrtc.org > > BUG=webrtc:5682 > > > > Committed: https://crrev.com/45c8b8940042bd2574c39920804ade8343cefdba > > Cr-Commit-Position: refs/heads/master@{#14885} > > TBR=perkj@webrtc.org,pthatcher@webrtc.org,tkchin@webrtc.org,mflodman@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/7341ab8e2505c9763d208e069bda269018357e7d > Cr-Commit-Position: refs/heads/master@{#14886} TBR=perkj@webrtc.org,pthatcher@webrtc.org,tkchin@webrtc.org,mflodman@webrtc.org,stefan@webrtc.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=webrtc:5682 Review-Url: https://codereview.webrtc.org/2487633002 Cr-Commit-Position: refs/heads/master@{#15039}
2016-11-11 03:55:13 -08:00
rtc::VideoSourceInterface<webrtc::VideoFrame>* source) override;
bool AddSendStream(const StreamParams& sp) override;
bool RemoveSendStream(uint32_t ssrc) override;
bool AddRecvStream(const StreamParams& sp) override;
bool AddRecvStream(const StreamParams& sp, bool default_stream);
bool RemoveRecvStream(uint32_t ssrc) override;
bool SetSink(uint32_t ssrc,
Reland of Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. (patchset #1 id:1 of https://codereview.webrtc.org/2471783002/ ) Reason for revert: Relanding after known downstream breakages have been fixed. Original issue's description: > Revert of Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. (patchset #7 id:120001 of https://codereview.webrtc.org/2383093002/ ) > > Reason for revert: > Breaks chrome, see https://build.chromium.org/p/chromium.webrtc.fyi/builders/Mac%20Builder/builds/19019/steps/compile/logs/stdio > > Analysis: Chrome uses cricket::VideoFrame, without explicitly including webrtc/media/base/videoframe.h, and breaks when that file is no longer included by any other webrtc headers. Will reland after updating Chrome. > > Original issue's description: > > Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. > > > > Replaced with webrtc::VideoFrame. > > > > TBR=mflodman@webrtc.org > > BUG=webrtc:5682 > > > > Committed: https://crrev.com/45c8b8940042bd2574c39920804ade8343cefdba > > Cr-Commit-Position: refs/heads/master@{#14885} > > TBR=perkj@webrtc.org,pthatcher@webrtc.org,tkchin@webrtc.org,mflodman@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/7341ab8e2505c9763d208e069bda269018357e7d > Cr-Commit-Position: refs/heads/master@{#14886} TBR=perkj@webrtc.org,pthatcher@webrtc.org,tkchin@webrtc.org,mflodman@webrtc.org,stefan@webrtc.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=webrtc:5682 Review-Url: https://codereview.webrtc.org/2487633002 Cr-Commit-Position: refs/heads/master@{#15039}
2016-11-11 03:55:13 -08:00
rtc::VideoSinkInterface<webrtc::VideoFrame>* sink) override;
bool GetStats(VideoMediaInfo* info) override;
void OnPacketReceived(rtc::CopyOnWriteBuffer* packet,
const rtc::PacketTime& packet_time) override;
void OnRtcpReceived(rtc::CopyOnWriteBuffer* packet,
const rtc::PacketTime& packet_time) override;
void OnReadyToSend(bool ready) override;
void OnNetworkRouteChanged(const std::string& transport_name,
const rtc::NetworkRoute& network_route) override;
void OnTransportOverheadChanged(int transport_overhead_per_packet) override;
void SetInterface(NetworkInterface* iface) override;
// Implemented for VideoMediaChannelTest.
bool sending() const { return sending_; }
// AdaptReason is used for expressing why a WebRtcVideoSendStream request
// a lower input frame size than the currently configured camera input frame
// size. There can be more than one reason OR:ed together.
enum AdaptReason {
ADAPTREASON_NONE = 0,
ADAPTREASON_CPU = 1,
ADAPTREASON_BANDWIDTH = 2,
};
private:
class WebRtcVideoReceiveStream;
struct VideoCodecSettings {
VideoCodecSettings();
bool operator==(const VideoCodecSettings& other) const;
bool operator!=(const VideoCodecSettings& other) const;
VideoCodec codec;
webrtc::UlpfecConfig ulpfec;
webrtc::FlexfecConfig flexfec;
int rtx_payload_type;
};
struct ChangedSendParameters {
// These optionals are unset if not changed.
rtc::Optional<VideoCodecSettings> codec;
rtc::Optional<std::vector<webrtc::RtpExtension>> rtp_header_extensions;
rtc::Optional<int> max_bandwidth_bps;
rtc::Optional<bool> conference_mode;
rtc::Optional<webrtc::RtcpMode> rtcp_mode;
};
struct ChangedRecvParameters {
// These optionals are unset if not changed.
rtc::Optional<std::vector<VideoCodecSettings>> codec_settings;
rtc::Optional<std::vector<webrtc::RtpExtension>> rtp_header_extensions;
};
bool GetChangedSendParameters(const VideoSendParameters& params,
ChangedSendParameters* changed_params) const;
bool GetChangedRecvParameters(const VideoRecvParameters& params,
ChangedRecvParameters* changed_params) const;
void SetMaxSendBandwidth(int bps);
void ConfigureReceiverRtp(webrtc::VideoReceiveStream::Config* config,
webrtc::FlexfecConfig* flexfec_config,
const StreamParams& sp) const;
bool ValidateSendSsrcAvailability(const StreamParams& sp) const
EXCLUSIVE_LOCKS_REQUIRED(stream_crit_);
bool ValidateReceiveSsrcAvailability(const StreamParams& sp) const
EXCLUSIVE_LOCKS_REQUIRED(stream_crit_);
void DeleteReceiveStream(WebRtcVideoReceiveStream* stream)
EXCLUSIVE_LOCKS_REQUIRED(stream_crit_);
static std::string CodecSettingsVectorToString(
const std::vector<VideoCodecSettings>& codecs);
// Wrapper for the sender part, this is where the source is connected and
// frames are then converted from cricket frames to webrtc frames.
class WebRtcVideoSendStream
Reland of Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. (patchset #1 id:1 of https://codereview.webrtc.org/2471783002/ ) Reason for revert: Relanding after known downstream breakages have been fixed. Original issue's description: > Revert of Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. (patchset #7 id:120001 of https://codereview.webrtc.org/2383093002/ ) > > Reason for revert: > Breaks chrome, see https://build.chromium.org/p/chromium.webrtc.fyi/builders/Mac%20Builder/builds/19019/steps/compile/logs/stdio > > Analysis: Chrome uses cricket::VideoFrame, without explicitly including webrtc/media/base/videoframe.h, and breaks when that file is no longer included by any other webrtc headers. Will reland after updating Chrome. > > Original issue's description: > > Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. > > > > Replaced with webrtc::VideoFrame. > > > > TBR=mflodman@webrtc.org > > BUG=webrtc:5682 > > > > Committed: https://crrev.com/45c8b8940042bd2574c39920804ade8343cefdba > > Cr-Commit-Position: refs/heads/master@{#14885} > > TBR=perkj@webrtc.org,pthatcher@webrtc.org,tkchin@webrtc.org,mflodman@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/7341ab8e2505c9763d208e069bda269018357e7d > Cr-Commit-Position: refs/heads/master@{#14886} TBR=perkj@webrtc.org,pthatcher@webrtc.org,tkchin@webrtc.org,mflodman@webrtc.org,stefan@webrtc.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=webrtc:5682 Review-Url: https://codereview.webrtc.org/2487633002 Cr-Commit-Position: refs/heads/master@{#15039}
2016-11-11 03:55:13 -08:00
: public rtc::VideoSinkInterface<webrtc::VideoFrame>,
public rtc::VideoSourceInterface<webrtc::VideoFrame> {
public:
WebRtcVideoSendStream(
webrtc::Call* call,
const StreamParams& sp,
webrtc::VideoSendStream::Config config,
const VideoOptions& options,
WebRtcVideoEncoderFactory* external_encoder_factory,
bool enable_cpu_overuse_detection,
int max_bitrate_bps,
const rtc::Optional<VideoCodecSettings>& codec_settings,
Avoid unnecessary HW video encoder reconfiguration 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}
2016-06-16 12:08:03 -07:00
const rtc::Optional<std::vector<webrtc::RtpExtension>>& rtp_extensions,
const VideoSendParameters& send_params);
virtual ~WebRtcVideoSendStream();
void SetSendParameters(const ChangedSendParameters& send_params);
bool SetRtpParameters(const webrtc::RtpParameters& parameters);
webrtc::RtpParameters GetRtpParameters() const;
// Implements rtc::VideoSourceInterface<webrtc::VideoFrame>.
// WebRtcVideoSendStream acts as a source to the webrtc::VideoSendStream
Reland of Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. (patchset #1 id:1 of https://codereview.webrtc.org/2471783002/ ) Reason for revert: Relanding after known downstream breakages have been fixed. Original issue's description: > Revert of Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. (patchset #7 id:120001 of https://codereview.webrtc.org/2383093002/ ) > > Reason for revert: > Breaks chrome, see https://build.chromium.org/p/chromium.webrtc.fyi/builders/Mac%20Builder/builds/19019/steps/compile/logs/stdio > > Analysis: Chrome uses cricket::VideoFrame, without explicitly including webrtc/media/base/videoframe.h, and breaks when that file is no longer included by any other webrtc headers. Will reland after updating Chrome. > > Original issue's description: > > Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. > > > > Replaced with webrtc::VideoFrame. > > > > TBR=mflodman@webrtc.org > > BUG=webrtc:5682 > > > > Committed: https://crrev.com/45c8b8940042bd2574c39920804ade8343cefdba > > Cr-Commit-Position: refs/heads/master@{#14885} > > TBR=perkj@webrtc.org,pthatcher@webrtc.org,tkchin@webrtc.org,mflodman@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/7341ab8e2505c9763d208e069bda269018357e7d > Cr-Commit-Position: refs/heads/master@{#14886} TBR=perkj@webrtc.org,pthatcher@webrtc.org,tkchin@webrtc.org,mflodman@webrtc.org,stefan@webrtc.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=webrtc:5682 Review-Url: https://codereview.webrtc.org/2487633002 Cr-Commit-Position: refs/heads/master@{#15039}
2016-11-11 03:55:13 -08:00
// in |stream_|.
// TODO(perkj, nisse): Refactor WebRtcVideoSendStream to directly connect
// the camera input |source_|
void AddOrUpdateSink(VideoSinkInterface<webrtc::VideoFrame>* sink,
const rtc::VideoSinkWants& wants) override;
void RemoveSink(VideoSinkInterface<webrtc::VideoFrame>* sink) override;
Reland of Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. (patchset #1 id:1 of https://codereview.webrtc.org/2471783002/ ) Reason for revert: Relanding after known downstream breakages have been fixed. Original issue's description: > Revert of Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. (patchset #7 id:120001 of https://codereview.webrtc.org/2383093002/ ) > > Reason for revert: > Breaks chrome, see https://build.chromium.org/p/chromium.webrtc.fyi/builders/Mac%20Builder/builds/19019/steps/compile/logs/stdio > > Analysis: Chrome uses cricket::VideoFrame, without explicitly including webrtc/media/base/videoframe.h, and breaks when that file is no longer included by any other webrtc headers. Will reland after updating Chrome. > > Original issue's description: > > Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. > > > > Replaced with webrtc::VideoFrame. > > > > TBR=mflodman@webrtc.org > > BUG=webrtc:5682 > > > > Committed: https://crrev.com/45c8b8940042bd2574c39920804ade8343cefdba > > Cr-Commit-Position: refs/heads/master@{#14885} > > TBR=perkj@webrtc.org,pthatcher@webrtc.org,tkchin@webrtc.org,mflodman@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/7341ab8e2505c9763d208e069bda269018357e7d > Cr-Commit-Position: refs/heads/master@{#14886} TBR=perkj@webrtc.org,pthatcher@webrtc.org,tkchin@webrtc.org,mflodman@webrtc.org,stefan@webrtc.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=webrtc:5682 Review-Url: https://codereview.webrtc.org/2487633002 Cr-Commit-Position: refs/heads/master@{#15039}
2016-11-11 03:55:13 -08:00
void OnFrame(const webrtc::VideoFrame& frame) override;
bool SetVideoSend(bool mute,
const VideoOptions* options,
Reland of Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. (patchset #1 id:1 of https://codereview.webrtc.org/2471783002/ ) Reason for revert: Relanding after known downstream breakages have been fixed. Original issue's description: > Revert of Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. (patchset #7 id:120001 of https://codereview.webrtc.org/2383093002/ ) > > Reason for revert: > Breaks chrome, see https://build.chromium.org/p/chromium.webrtc.fyi/builders/Mac%20Builder/builds/19019/steps/compile/logs/stdio > > Analysis: Chrome uses cricket::VideoFrame, without explicitly including webrtc/media/base/videoframe.h, and breaks when that file is no longer included by any other webrtc headers. Will reland after updating Chrome. > > Original issue's description: > > Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. > > > > Replaced with webrtc::VideoFrame. > > > > TBR=mflodman@webrtc.org > > BUG=webrtc:5682 > > > > Committed: https://crrev.com/45c8b8940042bd2574c39920804ade8343cefdba > > Cr-Commit-Position: refs/heads/master@{#14885} > > TBR=perkj@webrtc.org,pthatcher@webrtc.org,tkchin@webrtc.org,mflodman@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/7341ab8e2505c9763d208e069bda269018357e7d > Cr-Commit-Position: refs/heads/master@{#14886} TBR=perkj@webrtc.org,pthatcher@webrtc.org,tkchin@webrtc.org,mflodman@webrtc.org,stefan@webrtc.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=webrtc:5682 Review-Url: https://codereview.webrtc.org/2487633002 Cr-Commit-Position: refs/heads/master@{#15039}
2016-11-11 03:55:13 -08:00
rtc::VideoSourceInterface<webrtc::VideoFrame>* source);
void SetSend(bool send);
const std::vector<uint32_t>& GetSsrcs() const;
VideoSenderInfo GetVideoSenderInfo(bool log_stats);
void FillBandwidthEstimationInfo(BandwidthEstimationInfo* bwe_info);
private:
// Parameters needed to reconstruct the underlying stream.
// webrtc::VideoSendStream doesn't support setting a lot of options on the
// fly, so when those need to be changed we tear down and reconstruct with
// similar parameters depending on which options changed etc.
struct VideoSendStreamParameters {
VideoSendStreamParameters(
webrtc::VideoSendStream::Config config,
const VideoOptions& options,
int max_bitrate_bps,
const rtc::Optional<VideoCodecSettings>& codec_settings);
webrtc::VideoSendStream::Config config;
VideoOptions options;
int max_bitrate_bps;
bool conference_mode;
rtc::Optional<VideoCodecSettings> codec_settings;
// Sent resolutions + bitrates etc. by the underlying VideoSendStream,
// typically changes when setting a new resolution or reconfiguring
// bitrates.
webrtc::VideoEncoderConfig encoder_config;
};
struct AllocatedEncoder {
AllocatedEncoder(webrtc::VideoEncoder* encoder,
Reland of Stop using hardcoded payload types for video codecs (patchset #1 id:1 of https://codereview.webrtc.org/2513633002/ ) Reason for revert: The WebRtcBrowserTest.NegotiateUnsupportedVideoCodec test has been fixed in Chromium with the following change: function removeVideoCodec(offerSdp) { - offerSdp = offerSdp.replace('a=rtpmap:100 VP8/90000\r\n', - 'a=rtpmap:100 XVP8/90000\r\n'); + offerSdp = offerSdp.replace(/a=rtpmap:(\d+)\ VP8\/90000\r\n/, + 'a=rtpmap:$1 XVP8/90000\r\n'); return offerSdp; } Original issue's description: > Revert of Stop using hardcoded payload types for video codecs (patchset #6 id:210001 of https://codereview.webrtc.org/2493133002/ ) > > Reason for revert: > Breaks chromium.fyi test: > WebRtcBrowserTest.NegotiateUnsupportedVideoCodec > > Original issue's description: > > Stop using hardcoded payload types for video codecs > > > > This CL stops using hardcoded payload types for different video codecs > > and will dynamically assign them payload types incrementally from 96 to > > 127 instead. > > > > This CL: > > * Replaces 'std::vector<VideoCodec> DefaultVideoCodecList()' in > > webrtcvideoengine2.cc with an explicit WebRtcVideoEncoderFactory for > > internally supported software codecs instead. The purpose is to > > streamline the payload type assignment in webrtcvideoengine2.cc which > > will now have two encoder factories of the same > > WebRtcVideoEncoderFactory type; one internal and one external. > > * Removes webrtc::VideoEncoder::EncoderType and use cricket::VideoCodec > > instead. > > * Removes 'static VideoEncoder* Create(EncoderType codec_type)' and > > moves the create function to the internal encoder factory instead. > > * Removes video_encoder.cc. webrtc::VideoEncoder is now just an > > interface without any static functions. > > * The function GetSupportedCodecs in webrtcvideoengine2.cc unifies > > the internal and external codecs and assigns them payload types > > incrementally from 96 to 127. > > * Updates webrtcvideoengine2_unittest.cc and removes assumptions about > > what payload types will be used. > > > > BUG=webrtc:6677,webrtc:6705 > > R=hta@webrtc.org, ossu@webrtc.org, stefan@webrtc.org > > > > Committed: https://crrev.com/42043b95872b51321f508bf255d804ce3dff366b > > Cr-Commit-Position: refs/heads/master@{#15135} > > TBR=hta@webrtc.org,stefan@webrtc.org,ossu@webrtc.org > # Skipping CQ checks because original CL landed less than 1 days ago. > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=webrtc:6677,webrtc:6705 > > Committed: https://crrev.com/eacbaea920797ff751ca83050d140821f5055591 > Cr-Commit-Position: refs/heads/master@{#15140} TBR=hta@webrtc.org,stefan@webrtc.org,ossu@webrtc.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=webrtc:6677,webrtc:6705 Review-Url: https://codereview.webrtc.org/2511933002 Cr-Commit-Position: refs/heads/master@{#15148}
2016-11-18 01:34:11 -08:00
const cricket::VideoCodec& codec,
bool external);
webrtc::VideoEncoder* encoder;
webrtc::VideoEncoder* external_encoder;
Reland of Stop using hardcoded payload types for video codecs (patchset #1 id:1 of https://codereview.webrtc.org/2513633002/ ) Reason for revert: The WebRtcBrowserTest.NegotiateUnsupportedVideoCodec test has been fixed in Chromium with the following change: function removeVideoCodec(offerSdp) { - offerSdp = offerSdp.replace('a=rtpmap:100 VP8/90000\r\n', - 'a=rtpmap:100 XVP8/90000\r\n'); + offerSdp = offerSdp.replace(/a=rtpmap:(\d+)\ VP8\/90000\r\n/, + 'a=rtpmap:$1 XVP8/90000\r\n'); return offerSdp; } Original issue's description: > Revert of Stop using hardcoded payload types for video codecs (patchset #6 id:210001 of https://codereview.webrtc.org/2493133002/ ) > > Reason for revert: > Breaks chromium.fyi test: > WebRtcBrowserTest.NegotiateUnsupportedVideoCodec > > Original issue's description: > > Stop using hardcoded payload types for video codecs > > > > This CL stops using hardcoded payload types for different video codecs > > and will dynamically assign them payload types incrementally from 96 to > > 127 instead. > > > > This CL: > > * Replaces 'std::vector<VideoCodec> DefaultVideoCodecList()' in > > webrtcvideoengine2.cc with an explicit WebRtcVideoEncoderFactory for > > internally supported software codecs instead. The purpose is to > > streamline the payload type assignment in webrtcvideoengine2.cc which > > will now have two encoder factories of the same > > WebRtcVideoEncoderFactory type; one internal and one external. > > * Removes webrtc::VideoEncoder::EncoderType and use cricket::VideoCodec > > instead. > > * Removes 'static VideoEncoder* Create(EncoderType codec_type)' and > > moves the create function to the internal encoder factory instead. > > * Removes video_encoder.cc. webrtc::VideoEncoder is now just an > > interface without any static functions. > > * The function GetSupportedCodecs in webrtcvideoengine2.cc unifies > > the internal and external codecs and assigns them payload types > > incrementally from 96 to 127. > > * Updates webrtcvideoengine2_unittest.cc and removes assumptions about > > what payload types will be used. > > > > BUG=webrtc:6677,webrtc:6705 > > R=hta@webrtc.org, ossu@webrtc.org, stefan@webrtc.org > > > > Committed: https://crrev.com/42043b95872b51321f508bf255d804ce3dff366b > > Cr-Commit-Position: refs/heads/master@{#15135} > > TBR=hta@webrtc.org,stefan@webrtc.org,ossu@webrtc.org > # Skipping CQ checks because original CL landed less than 1 days ago. > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=webrtc:6677,webrtc:6705 > > Committed: https://crrev.com/eacbaea920797ff751ca83050d140821f5055591 > Cr-Commit-Position: refs/heads/master@{#15140} TBR=hta@webrtc.org,stefan@webrtc.org,ossu@webrtc.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=webrtc:6677,webrtc:6705 Review-Url: https://codereview.webrtc.org/2511933002 Cr-Commit-Position: refs/heads/master@{#15148}
2016-11-18 01:34:11 -08:00
cricket::VideoCodec codec;
bool external;
};
// TODO(perkj): VideoFrameInfo is currently used for sending a black frame
// when the video source is removed. Consider moving that logic to
// VieEncoder or remove it.
Avoid unnecessary HW video encoder reconfiguration 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}
2016-06-16 12:08:03 -07:00
struct VideoFrameInfo {
VideoFrameInfo()
: width(0),
height(0),
Avoid unnecessary HW video encoder reconfiguration 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}
2016-06-16 12:08:03 -07:00
rotation(webrtc::kVideoRotation_0),
is_texture(false) {}
int width;
int height;
Avoid unnecessary HW video encoder reconfiguration 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}
2016-06-16 12:08:03 -07:00
webrtc::VideoRotation rotation;
bool is_texture;
};
rtc::scoped_refptr<webrtc::VideoEncoderConfig::EncoderSpecificSettings>
ConfigureVideoEncoderSettings(const VideoCodec& codec);
AllocatedEncoder CreateVideoEncoder(const VideoCodec& codec);
void DestroyVideoEncoder(AllocatedEncoder* encoder);
void SetCodec(const VideoCodecSettings& codec);
void RecreateWebRtcStream();
webrtc::VideoEncoderConfig CreateVideoEncoderConfig(
const VideoCodec& codec) const;
void ReconfigureEncoder();
bool ValidateRtpParameters(const webrtc::RtpParameters& parameters);
// Calls Start or Stop according to whether or not |sending_| is true,
// and whether or not the encoding in |rtp_parameters_| is active.
void UpdateSendState();
rtc::ThreadChecker thread_checker_;
rtc::AsyncInvoker invoker_;
rtc::Thread* worker_thread_;
const std::vector<uint32_t> ssrcs_ ACCESS_ON(&thread_checker_);
const std::vector<SsrcGroup> ssrc_groups_ ACCESS_ON(&thread_checker_);
webrtc::Call* const call_;
const bool enable_cpu_overuse_detection_;
Reland of Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. (patchset #1 id:1 of https://codereview.webrtc.org/2471783002/ ) Reason for revert: Relanding after known downstream breakages have been fixed. Original issue's description: > Revert of Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. (patchset #7 id:120001 of https://codereview.webrtc.org/2383093002/ ) > > Reason for revert: > Breaks chrome, see https://build.chromium.org/p/chromium.webrtc.fyi/builders/Mac%20Builder/builds/19019/steps/compile/logs/stdio > > Analysis: Chrome uses cricket::VideoFrame, without explicitly including webrtc/media/base/videoframe.h, and breaks when that file is no longer included by any other webrtc headers. Will reland after updating Chrome. > > Original issue's description: > > Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. > > > > Replaced with webrtc::VideoFrame. > > > > TBR=mflodman@webrtc.org > > BUG=webrtc:5682 > > > > Committed: https://crrev.com/45c8b8940042bd2574c39920804ade8343cefdba > > Cr-Commit-Position: refs/heads/master@{#14885} > > TBR=perkj@webrtc.org,pthatcher@webrtc.org,tkchin@webrtc.org,mflodman@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/7341ab8e2505c9763d208e069bda269018357e7d > Cr-Commit-Position: refs/heads/master@{#14886} TBR=perkj@webrtc.org,pthatcher@webrtc.org,tkchin@webrtc.org,mflodman@webrtc.org,stefan@webrtc.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=webrtc:5682 Review-Url: https://codereview.webrtc.org/2487633002 Cr-Commit-Position: refs/heads/master@{#15039}
2016-11-11 03:55:13 -08:00
rtc::VideoSourceInterface<webrtc::VideoFrame>* source_
ACCESS_ON(&thread_checker_);
WebRtcVideoEncoderFactory* const external_encoder_factory_
ACCESS_ON(&thread_checker_);
rtc::CriticalSection lock_;
webrtc::VideoSendStream* stream_ ACCESS_ON(&thread_checker_);
rtc::VideoSinkInterface<webrtc::VideoFrame>* encoder_sink_
GUARDED_BY(lock_);
// Contains settings that are the same for all streams in the MediaChannel,
// such as codecs, header extensions, and the global bitrate limit for the
// entire channel.
VideoSendStreamParameters parameters_ ACCESS_ON(&thread_checker_);
// Contains settings that are unique for each stream, such as max_bitrate.
// Does *not* contain codecs, however.
// TODO(skvlad): Move ssrcs_ and ssrc_groups_ into rtp_parameters_.
// TODO(skvlad): Combine parameters_ and rtp_parameters_ once we have only
// one stream per MediaChannel.
webrtc::RtpParameters rtp_parameters_ ACCESS_ON(&thread_checker_);
AllocatedEncoder allocated_encoder_ ACCESS_ON(&thread_checker_);
Avoid unnecessary HW video encoder reconfiguration 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}
2016-06-16 12:08:03 -07:00
VideoFrameInfo last_frame_info_ GUARDED_BY(lock_);
bool sending_ ACCESS_ON(&thread_checker_);
// The timestamp of the last frame received
// Used to generate timestamp for the black frame when source is removed
int64_t last_frame_timestamp_us_ GUARDED_BY(lock_);
};
// Wrapper for the receiver part, contains configs etc. that are needed to
Reland of Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. (patchset #1 id:1 of https://codereview.webrtc.org/2471783002/ ) Reason for revert: Relanding after known downstream breakages have been fixed. Original issue's description: > Revert of Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. (patchset #7 id:120001 of https://codereview.webrtc.org/2383093002/ ) > > Reason for revert: > Breaks chrome, see https://build.chromium.org/p/chromium.webrtc.fyi/builders/Mac%20Builder/builds/19019/steps/compile/logs/stdio > > Analysis: Chrome uses cricket::VideoFrame, without explicitly including webrtc/media/base/videoframe.h, and breaks when that file is no longer included by any other webrtc headers. Will reland after updating Chrome. > > Original issue's description: > > Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. > > > > Replaced with webrtc::VideoFrame. > > > > TBR=mflodman@webrtc.org > > BUG=webrtc:5682 > > > > Committed: https://crrev.com/45c8b8940042bd2574c39920804ade8343cefdba > > Cr-Commit-Position: refs/heads/master@{#14885} > > TBR=perkj@webrtc.org,pthatcher@webrtc.org,tkchin@webrtc.org,mflodman@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/7341ab8e2505c9763d208e069bda269018357e7d > Cr-Commit-Position: refs/heads/master@{#14886} TBR=perkj@webrtc.org,pthatcher@webrtc.org,tkchin@webrtc.org,mflodman@webrtc.org,stefan@webrtc.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=webrtc:5682 Review-Url: https://codereview.webrtc.org/2487633002 Cr-Commit-Position: refs/heads/master@{#15039}
2016-11-11 03:55:13 -08:00
// reconstruct the underlying VideoReceiveStream.
class WebRtcVideoReceiveStream
: public rtc::VideoSinkInterface<webrtc::VideoFrame> {
public:
WebRtcVideoReceiveStream(
webrtc::Call* call,
const StreamParams& sp,
webrtc::VideoReceiveStream::Config config,
WebRtcVideoDecoderFactory* external_decoder_factory,
bool default_stream,
const std::vector<VideoCodecSettings>& recv_codecs,
const webrtc::FlexfecConfig& flexfec_config);
~WebRtcVideoReceiveStream();
const std::vector<uint32_t>& GetSsrcs() const;
rtc::Optional<uint32_t> GetFirstPrimarySsrc() const;
void SetLocalSsrc(uint32_t local_ssrc);
// TODO(deadbeef): Move these feedback parameters into the recv parameters.
void SetFeedbackParameters(bool nack_enabled,
bool remb_enabled,
bool transport_cc_enabled,
webrtc::RtcpMode rtcp_mode);
void SetRecvParameters(const ChangedRecvParameters& recv_params);
void OnFrame(const webrtc::VideoFrame& frame) override;
bool IsDefaultStream() const;
Reland of Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. (patchset #1 id:1 of https://codereview.webrtc.org/2471783002/ ) Reason for revert: Relanding after known downstream breakages have been fixed. Original issue's description: > Revert of Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. (patchset #7 id:120001 of https://codereview.webrtc.org/2383093002/ ) > > Reason for revert: > Breaks chrome, see https://build.chromium.org/p/chromium.webrtc.fyi/builders/Mac%20Builder/builds/19019/steps/compile/logs/stdio > > Analysis: Chrome uses cricket::VideoFrame, without explicitly including webrtc/media/base/videoframe.h, and breaks when that file is no longer included by any other webrtc headers. Will reland after updating Chrome. > > Original issue's description: > > Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. > > > > Replaced with webrtc::VideoFrame. > > > > TBR=mflodman@webrtc.org > > BUG=webrtc:5682 > > > > Committed: https://crrev.com/45c8b8940042bd2574c39920804ade8343cefdba > > Cr-Commit-Position: refs/heads/master@{#14885} > > TBR=perkj@webrtc.org,pthatcher@webrtc.org,tkchin@webrtc.org,mflodman@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/7341ab8e2505c9763d208e069bda269018357e7d > Cr-Commit-Position: refs/heads/master@{#14886} TBR=perkj@webrtc.org,pthatcher@webrtc.org,tkchin@webrtc.org,mflodman@webrtc.org,stefan@webrtc.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=webrtc:5682 Review-Url: https://codereview.webrtc.org/2487633002 Cr-Commit-Position: refs/heads/master@{#15039}
2016-11-11 03:55:13 -08:00
void SetSink(rtc::VideoSinkInterface<webrtc::VideoFrame>* sink);
VideoReceiverInfo GetVideoReceiverInfo(bool log_stats);
private:
struct AllocatedDecoder {
AllocatedDecoder(webrtc::VideoDecoder* decoder,
webrtc::VideoCodecType type,
bool external);
webrtc::VideoDecoder* decoder;
// Decoder wrapped into a fallback decoder to permit software fallback.
webrtc::VideoDecoder* external_decoder;
webrtc::VideoCodecType type;
bool external;
};
void RecreateWebRtcStream();
void ConfigureCodecs(const std::vector<VideoCodecSettings>& recv_codecs,
std::vector<AllocatedDecoder>* old_codecs);
AllocatedDecoder CreateOrReuseVideoDecoder(
std::vector<AllocatedDecoder>* old_decoder,
const VideoCodec& codec);
void ClearDecoders(std::vector<AllocatedDecoder>* allocated_decoders);
std::string GetCodecNameFromPayloadType(int payload_type);
webrtc::Call* const call_;
StreamParams stream_params_;
// Both |stream_| and |flexfec_stream_| are managed by |this|. They are
// destroyed by calling call_->DestroyVideoReceiveStream and
// call_->DestroyFlexfecReceiveStream, respectively.
webrtc::VideoReceiveStream* stream_;
const bool default_stream_;
webrtc::VideoReceiveStream::Config config_;
webrtc::FlexfecConfig flexfec_config_;
webrtc::FlexfecReceiveStream* flexfec_stream_;
WebRtcVideoDecoderFactory* const external_decoder_factory_;
std::vector<AllocatedDecoder> allocated_decoders_;
rtc::CriticalSection sink_lock_;
Reland of Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. (patchset #1 id:1 of https://codereview.webrtc.org/2471783002/ ) Reason for revert: Relanding after known downstream breakages have been fixed. Original issue's description: > Revert of Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. (patchset #7 id:120001 of https://codereview.webrtc.org/2383093002/ ) > > Reason for revert: > Breaks chrome, see https://build.chromium.org/p/chromium.webrtc.fyi/builders/Mac%20Builder/builds/19019/steps/compile/logs/stdio > > Analysis: Chrome uses cricket::VideoFrame, without explicitly including webrtc/media/base/videoframe.h, and breaks when that file is no longer included by any other webrtc headers. Will reland after updating Chrome. > > Original issue's description: > > Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. > > > > Replaced with webrtc::VideoFrame. > > > > TBR=mflodman@webrtc.org > > BUG=webrtc:5682 > > > > Committed: https://crrev.com/45c8b8940042bd2574c39920804ade8343cefdba > > Cr-Commit-Position: refs/heads/master@{#14885} > > TBR=perkj@webrtc.org,pthatcher@webrtc.org,tkchin@webrtc.org,mflodman@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/7341ab8e2505c9763d208e069bda269018357e7d > Cr-Commit-Position: refs/heads/master@{#14886} TBR=perkj@webrtc.org,pthatcher@webrtc.org,tkchin@webrtc.org,mflodman@webrtc.org,stefan@webrtc.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=webrtc:5682 Review-Url: https://codereview.webrtc.org/2487633002 Cr-Commit-Position: refs/heads/master@{#15039}
2016-11-11 03:55:13 -08:00
rtc::VideoSinkInterface<webrtc::VideoFrame>* sink_ GUARDED_BY(sink_lock_);
// Expands remote RTP timestamps to int64_t to be able to estimate how long
// the stream has been running.
rtc::TimestampWrapAroundHandler timestamp_wraparound_handler_
GUARDED_BY(sink_lock_);
int64_t first_frame_timestamp_ GUARDED_BY(sink_lock_);
// Start NTP time is estimated as current remote NTP time (estimated from
// RTCP) minus the elapsed time, as soon as remote NTP time is available.
int64_t estimated_remote_start_ntp_time_ms_ GUARDED_BY(sink_lock_);
};
void Construct(webrtc::Call* call, WebRtcVideoEngine2* engine);
bool SendRtp(const uint8_t* data,
size_t len,
const webrtc::PacketOptions& options) override;
bool SendRtcp(const uint8_t* data, size_t len) override;
static std::vector<VideoCodecSettings> MapCodecs(
const std::vector<VideoCodec>& codecs);
// Select what video codec will be used for sending, i.e. what codec is used
// for local encoding, based on supported remote codecs. The first remote
// codec that is supported locally will be selected.
rtc::Optional<VideoCodecSettings> SelectSendVideoCodec(
const std::vector<VideoCodecSettings>& remote_mapped_codecs) const;
static bool ReceiveCodecsHaveChanged(std::vector<VideoCodecSettings> before,
std::vector<VideoCodecSettings> after);
void FillSenderStats(VideoMediaInfo* info, bool log_stats);
void FillReceiverStats(VideoMediaInfo* info, bool log_stats);
void FillBandwidthEstimationStats(const webrtc::Call::Stats& stats,
VideoMediaInfo* info);
void FillSendAndReceiveCodecStats(VideoMediaInfo* video_media_info);
rtc::ThreadChecker thread_checker_;
uint32_t rtcp_receiver_report_ssrc_;
bool sending_;
webrtc::Call* const call_;
DefaultUnsignalledSsrcHandler default_unsignalled_ssrc_handler_;
UnsignalledSsrcHandler* const unsignalled_ssrc_handler_;
const MediaConfig::Video video_config_;
rtc::CriticalSection stream_crit_;
// Using primary-ssrc (first ssrc) as key.
std::map<uint32_t, WebRtcVideoSendStream*> send_streams_
GUARDED_BY(stream_crit_);
std::map<uint32_t, WebRtcVideoReceiveStream*> receive_streams_
GUARDED_BY(stream_crit_);
std::set<uint32_t> send_ssrcs_ GUARDED_BY(stream_crit_);
std::set<uint32_t> receive_ssrcs_ GUARDED_BY(stream_crit_);
rtc::Optional<VideoCodecSettings> send_codec_;
Avoid unnecessary HW video encoder reconfiguration 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}
2016-06-16 12:08:03 -07:00
rtc::Optional<std::vector<webrtc::RtpExtension>> send_rtp_extensions_;
WebRtcVideoEncoderFactory* const external_encoder_factory_;
WebRtcVideoDecoderFactory* const external_decoder_factory_;
std::vector<VideoCodecSettings> recv_codecs_;
std::vector<webrtc::RtpExtension> recv_rtp_extensions_;
webrtc::Call::Config::BitrateConfig bitrate_config_;
// TODO(deadbeef): Don't duplicate information between
// send_params/recv_params, rtp_extensions, options, etc.
VideoSendParameters send_params_;
VideoOptions default_send_options_;
VideoRecvParameters recv_params_;
int64_t last_stats_log_ms_;
};
} // namespace cricket
#endif // WEBRTC_MEDIA_ENGINE_WEBRTCVIDEOENGINE2_H_