Added VideoTrackInterface::GetSink method, for use by
VideoRtpReceiver. This lets us delete FrameInput.
I realized this change doesn't depend on VideoSinkInterface changes,
so this is a more standalone version of cl
https://codereview.webrtc.org/1664773002/
BUG=webrtc:5426
Review URL: https://codereview.webrtc.org/1660103003
Cr-Commit-Position: refs/heads/master@{#11498}
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}
- Reduce maximum pending frames for H.264 decoder to 8.
- Log data for next 2 output frames every time frame drop
happens or decoder drain is triggered.
- When timeout happens for dequeueInputBuffer call try to
drain the decoder and get input buffer one more time.
- Fix PTS values overflow.
Review URL: https://codereview.webrtc.org/1661203002
Cr-Commit-Position: refs/heads/master@{#11492}
This adds negotiation of both transport sequence number and transport
feedback. Only offers transport seq num if the
WebRTC-Audio-SendSideBwe finch experiment is enabled.
TBR=mflodman@webrtc.org
BUG=webrtc:5263
Review URL: https://codereview.webrtc.org/1604563002
Cr-Commit-Position: refs/heads/master@{#11487}
Change argument type for VideoProviderInterface::SetVideoPlayout.
Replace VideoMediaChannel::SetRenderer and VideoChannel::SetRenderer
by SetSink.
Alse deleted unused member variables VideoMediaChannel::renderer_ and
VideoChannel::renderer_.
BUG=webrtc:5426
Review URL: https://codereview.webrtc.org/1668493002
Cr-Commit-Position: refs/heads/master@{#11485}
In some device (e.g. Galaxy s6), the OS returns a list of network containing
one that has empty network name or NONE connection type, which cannot be used and cause crash to the app.
BUG=
Review URL: https://codereview.webrtc.org/1655313005
Cr-Commit-Position: refs/heads/master@{#11482}
There is a use case with external codec factories that only support
encoding but not decoding for a given type. This leads to a crash
due to null being registered as codec (after a DCHECK).
This CL adds a NullVideoDecoder that is used instead of the null to
not crash but log to LS_ERROR.
BUG=webrtc:5249
Review URL: https://codereview.webrtc.org/1657023002
Cr-Commit-Position: refs/heads/master@{#11475}
Adds negotiation of rtx codecs for red and vp9. To keep backwards
compatibility with older Chrome versions, this change includes two
hacks:
1. Red packets will be retransmitted over the rtx codec associated with
vp8 if no rtx codec is associated with red. This is how Chrome does
it today and ensures that we still can send red over rtx to older
versions.
2. If rtx packets associated with the media codec (vp8/vp9 etc) are
received and red has been negotiated, we will assume that the sender
incorrectly has packetized red inside the rtx header associated with
media. We will therefore restore it with the red payload type
instead, which ensures that we can still receive rtx associated with
red from old versions.
Offering multiple rtx codecs to older versions should not be a problem
since old versions themselves only try to negotiate rtx for vp8.
R=pbos@webrtc.orgTBR=mflodman@webrtc.org
BUG=webrtc:4024
TEST=Verified by running apprtc and emulating packet loss between Chrome with and without the patch.
Review URL: https://codereview.webrtc.org/1649493004 .
Cr-Commit-Position: refs/heads/master@{#11472}
Sometimes Android OS provides unknown connection type,
causing a DCHECK failure. This CL temporarily removes that checking.
BUG=
TBR=glaznev@webrtc.org
NOTRY=true
Review URL: https://codereview.webrtc.org/1667503002
Cr-Commit-Position: refs/heads/master@{#11466}
- Add extra logging for Android HW codec corner cases
when frames are dropped or resolution is changed.
- Use presentation timestamps for decoded frame logging.
- Enable key frame sending on long frame gap for
H.264 codec.
BUG=b/26504665
Review URL: https://codereview.webrtc.org/1653523003
Cr-Commit-Position: refs/heads/master@{#11452}
including options related to experimental constraints which are
recognized but never applied.
BUG=webrtc:5426
Review URL: https://codereview.webrtc.org/1642513002
Cr-Commit-Position: refs/heads/master@{#11424}
It's never used anywhere, so it only causes confusion between
itself and SessionDescriptionInterface::candidates.
Review URL: https://codereview.webrtc.org/1642733002
Cr-Commit-Position: refs/heads/master@{#11420}
The plan is that this interface should be used by all classes which receive a stream of video frames, and replace the two generic classes webrtc::VideoRendererInterface and cricket::VideoRenderer.
And the list goes on, there's a dozen of different classes which act as video frame sinks.
At some point, we will likely add some method to handle sink properties like, e.g, maximum useful width and height. But hopefully this can be done while keeping the interface very simple.
BUG=webrtc:5426
R=perkj@webrtc.org, pthatcher@webrtc.org
Committed: https://crrev.com/a862d4563fbc26e52bed442de784094ae1dfe5ee
Cr-Commit-Position: refs/heads/master@{#11396}
Review URL: https://codereview.webrtc.org/1594973006
Cr-Commit-Position: refs/heads/master@{#11414}
This is somewhat easier than looking up the media type by iterating pc.getLocalStreams / pc.getRemoteStreams and all tracks. Temporary until stats get revamped to conform to the spec obviously.
BUG=webrtc:4117
Review URL: https://codereview.webrtc.org/1307633007
Cr-Commit-Position: refs/heads/master@{#11412}
Expose disableBuffering method on underlying log sink.
This will make every write to the stream immediately write to the disk.
Useful in crash situations so that buffered output is not lost.
BUG=
Review URL: https://codereview.webrtc.org/1638283003
Cr-Commit-Position: refs/heads/master@{#11407}
Before HW VP8 downscaling was triggered by frame drops only.
Also reset the encoder when it drops large amount of frames in a row.
BUG=b/26504665
Review URL: https://codereview.webrtc.org/1592883004
Cr-Commit-Position: refs/heads/master@{#11406}
Before this fix, it was required that the EGL context used as an argument was kept open until all PeerConnections using the context had been closed. With this fix, that is no longer required.
Also, if a released EGLContext (EGL_NO_CONTEXT) is used, harware codecs will fallback to use byte buffers for encoding and decoding.
BUG=b/26583522
R=glaznev@webrtc.org
Review URL: https://codereview.webrtc.org/1615153002 .
Cr-Commit-Position: refs/heads/master@{#11398}
Reason for revert:
Broke chrome build. Investigating.
First error relating to AddSink method in mock_peer_connection_dependency_factory.h
Original issue's description:
> New rtc::VideoSinkInterface.
>
> The plan is that this interface should be used by all classes which receive a stream of video frames, and replace the two generic classes webrtc::VideoRendererInterface and cricket::VideoRenderer.
>
> And the list goes on, there's a dozen of different classes which act as video frame sinks.
>
> At some point, we will likely add some method to handle sink properties like, e.g, maximum useful width and height. But hopefully this can be done while keeping the interface very simple.
>
> BUG=webrtc:5426
> R=perkj@webrtc.org, pthatcher@webrtc.org
>
> Committed: https://crrev.com/a862d4563fbc26e52bed442de784094ae1dfe5ee
> Cr-Commit-Position: refs/heads/master@{#11396}
TBR=pthatcher@webrtc.org,pbos@webrtc.org,perkj@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5426
Review URL: https://codereview.webrtc.org/1646463002
Cr-Commit-Position: refs/heads/master@{#11397}
The plan is that this interface should be used by all classes which receive a stream of video frames, and replace the two generic classes webrtc::VideoRendererInterface and cricket::VideoRenderer.
And the list goes on, there's a dozen of different classes which act as video frame sinks.
At some point, we will likely add some method to handle sink properties like, e.g, maximum useful width and height. But hopefully this can be done while keeping the interface very simple.
BUG=webrtc:5426
R=perkj@webrtc.org, pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1594973006 .
Cr-Commit-Position: refs/heads/master@{#11396}
It works on all platforms except Android and iOS (FFmpeg limitation).
Implemented behind compile time flags, off by default.
The plan is to have it enabled in Chrome (see bug), but not in Chromium/webrtc by default.
Flags to turn it on:
- rtc_use_h264 = true
- ffmpeg_branding = "Chrome" (or other brand that includes H.264 decoder)
Tests using H264:
- video_loopback --codec=H264
- screenshare_loopback --codec=H264
- video_engine_tests (EndToEndTest.SendsAndReceivesH264)
NOTRY=True
BUG=500605, 468365
BUG=https://bugs.chromium.org/p/webrtc/issues/detail?id=5424
Review URL: https://codereview.webrtc.org/1306813009
Cr-Commit-Position: refs/heads/master@{#11390}
This CL fixes compiler / linker errors that occur if HAVE_WEBRTC_VIDEO is
not defined and introduces a new class NullWebRtcVideoEngine to use in
that case.
BUG=
TEST=remove define HAVE_WEBRTC_VIDEO from talk/build/common.gypi, run gclient runhooks and compile
Review URL: https://codereview.webrtc.org/1621453005
Cr-Commit-Position: refs/heads/master@{#11387}
We can't assume that the audio source implementation will be our own internal one and we shouldn't apply local audio options to a remote audio track this way either.
BUG=5423
R=solenberg@webrtc.org
Review URL: https://codereview.webrtc.org/1576913002 .
Cr-Commit-Position: refs/heads/master@{#11341}
Delete methods MaybeSetRenderingSize and IsRendererRegistered, the latter replaced by std::find.
Delete return values from AddRenderer and RemoveRenderer.
BUG=webrtc:5426
Review URL: https://codereview.webrtc.org/1603423002
Cr-Commit-Position: refs/heads/master@{#11332}
