There were a couple of GN and GYP references that were incorrect in Chromium builds:
- GN references between WebRTC targets must be using relative paths, not absolute.
- GYP references between WebRTC targets must be using the <(webrtc_root)v variable
in order to be expanded to the correct path in a Chromium build.
NOTRY=True
TBR=hjon@webrtc.org, hbos@webrtc.org
Review URL: https://codereview.webrtc.org/1681493002
Cr-Commit-Position: refs/heads/master@{#11521}
Renamed the WEBRTC_THIRD_PARTY_H264 macro to WEBRTC_USE_H264 to match flag name.
The idea is to be able to turn off H264 from chromium with this function because...
1) The Chromium trybots will soon use this flag, we want to temporarily disable H264 from chromium even if flag is set in case something is broken. That way when we are ready to flip the switch the trybots will run our test code then and not after it is already enabled.
2) If feature is launched and we discover major problems we can easily disable H264 and merge with beta/stable.
3) Or, if feature is behind a *runtime* flag, this is how we would control if it is used or not.
The idea is to call DisableRtcUseH264 in chromium's PeerConnectionDependencyFactory.
BUG=chromium:500605, chromium:468365
NOTRY=True
NOPRESUBMIT=True
Review URL: https://codereview.webrtc.org/1657273002
Cr-Commit-Position: refs/heads/master@{#11474}
New flag: rtc_initialize_ffmpeg, default value = !build_with_chromium.
In WebRTC standalone we initialize FFmpeg by default, in Chromium we don't by default.
Chromium is an external project that also use FFmpeg. If both projects do FFmpeg initialization code things will break. The flag makes it possible for other external projects than chromium to decide whether or not WebRTC should initialize FFmpeg.
BUG=chromium:500605, chromium:468365, webrtc:5427
Review URL: https://codereview.webrtc.org/1639273002
Cr-Commit-Position: refs/heads/master@{#11456}
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}
The FFmpeg video decoder requires up to 8 additional bytes to be allocated for its encoded image buffer input, due to optimized byte readers over-reading on some platforms.
We plan to use FFmpeg for a soon-to-land H.264 enc/dec.
This CL adds support for padding encoded image buffers based on codec type, and makes sure calls to VCMEncodedFrame::VerifyAndAllocate use the padding.
All padding constants are 0 but making H.264 pad with 8 bytes will be a one-line change.
Also, added -framework CoreFoundation to webrtc_h264_video_toolbox which was missing.
BUG=chromium:468365
BUG=https://bugs.chromium.org/p/webrtc/issues/detail?id=5424
NOTRY=True
Review URL: https://codereview.webrtc.org/1602523004
Cr-Commit-Position: refs/heads/master@{#11337}
