WebRTC Code Reviews
Help | Chromium Project | Sign in
(1249)

Issue 57499004: iOS HW H264 support.

Can't Edit
Can't Publish+Mail
Start Review
Created:
3 years, 11 months ago by tkchin
Modified:
3 years, 10 months ago
CC:
webrtc-reviews_webrtc.org, tterriberry, Stefan, mflodman
Base URL:
https://chromium.googlesource.com/external/webrtc@master
Target Ref:
refs/pending/heads/master
Project:
webrtc
Visibility:
Public.

Description

iOS HW H264 support. First step towards supporting H264 on iOS. More tuning/experimentation required in future CLs. Tested using AppRTCDemo on iPhone 6 + iPad Mini + OS/X. Future work to get it working on simulator (renders black screen currently) and with the Android AppRTCDemo. Currently protected with a compile time guard. BUG=4081

Patch Set 1 : #

Total comments: 4

Patch Set 2 : Don't use import #

Total comments: 41

Patch Set 3 : CR comments #

Total comments: 76

Patch Set 4 : CR comments #

Unified diffs Side-by-side diffs Delta from patch set Stats (+1718 lines, -78 lines) Patch
M talk/app/webrtc/objc/RTCPeerConnectionFactory.mm View 1 2 2 chunks +11 lines, -2 lines 0 comments Download
A + talk/app/webrtc/objc/h264decoderfactory.h View 1 chunk +19 lines, -17 lines 0 comments Download
A + talk/app/webrtc/objc/h264decoderfactory.cc View 1 2 1 chunk +13 lines, -12 lines 0 comments Download
A + talk/app/webrtc/objc/h264encoderfactory.h View 1 2 1 chunk +19 lines, -18 lines 0 comments Download
A + talk/app/webrtc/objc/h264encoderfactory.cc View 1 2 1 chunk +40 lines, -15 lines 0 comments Download
M talk/build/common.gypi View 1 2 2 chunks +9 lines, -0 lines 0 comments Download
M talk/examples/objc/AppRTCDemo/ARDAppClient.m View 1 2 3 3 chunks +13 lines, -3 lines 0 comments Download
A + talk/examples/objc/AppRTCDemo/ARDSDPUtils.h View 1 2 3 2 chunks +9 lines, -11 lines 0 comments Download
A talk/examples/objc/AppRTCDemo/ARDSDPUtils.m View 1 2 3 1 chunk +108 lines, -0 lines 0 comments Download
M talk/libjingle.gyp View 1 2 3 1 chunk +4 lines, -0 lines 0 comments Download
M talk/libjingle_examples.gyp View 1 2 1 chunk +2 lines, -0 lines 0 comments Download
M webrtc/modules/modules.gyp View 1 2 3 1 chunk +1 line, -0 lines 0 comments Download
M webrtc/modules/video_coding/BUILD.gn View 1 2 3 2 chunks +24 lines, -0 lines 0 comments Download
A webrtc/modules/video_coding/codecs/h264/h264.gypi View 1 2 1 chunk +59 lines, -0 lines 0 comments Download
A webrtc/modules/video_coding/codecs/h264/h264.mm View 1 2 3 1 chunk +53 lines, -0 lines 0 comments Download
A webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_decoder.h View 1 2 3 1 chunk +62 lines, -0 lines 0 comments Download
A webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_decoder.mm View 1 2 3 1 chunk +271 lines, -0 lines 0 comments Download
A webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_encoder.h View 1 2 3 1 chunk +66 lines, -0 lines 0 comments Download
A webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_encoder.mm View 1 2 3 1 chunk +433 lines, -0 lines 0 comments Download
A webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_nalu.h View 1 2 1 chunk +99 lines, -0 lines 0 comments Download
A webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_nalu.mm View 1 2 3 1 chunk +356 lines, -0 lines 0 comments Download
A webrtc/modules/video_coding/codecs/h264/include/h264.h View 1 2 1 chunk +46 lines, -0 lines 0 comments Download
M webrtc/modules/video_coding/video_coding.gypi View 1 chunk +1 line, -0 lines 0 comments Download
Project "webrtc" does not have a commit queue.

Messages

Total messages: 25 (13 generated)
tkchin
3 years, 11 months ago (2015-05-28 23:43:03 UTC) #11
tkchin
+kjellander for the build file owners.
3 years, 11 months ago (2015-05-28 23:44:14 UTC) #13
noahric (chromium)
Cool beans :) I'm heading out in a sec, but I'll take a longer look ...
3 years, 11 months ago (2015-05-29 00:25:52 UTC) #14
Stefan
I have a few early comments. In general it would be nice if the codec ...
3 years, 11 months ago (2015-05-30 11:32:03 UTC) #15
kjellander
Please introduce a rtc_use_objc_h264 variable in https://chromium.googlesource.com/external/webrtc/+/master/webrtc/build/webrtc.gni and perform all .gypi changes to the BUILD.gn ...
3 years, 10 months ago (2015-06-01 08:53:15 UTC) #16
tkchin
@kjellander - afaik there isn't GN support for iOS frameworks, which means I can't put ...
3 years, 10 months ago (2015-06-11 21:26:56 UTC) #18
tkchin
ping. Would be great to get this in the next day or so to avoid ...
3 years, 10 months ago (2015-06-16 20:04:57 UTC) #19
kjellander
On 2015/06/11 21:26:56, tkchin wrote: > @kjellander - afaik there isn't GN support for iOS ...
3 years, 10 months ago (2015-06-16 20:53:48 UTC) #20
noahric (chromium)
LGTM. All nits, I don't see anything that looks wrong. My LGTM shouldn't count for ...
3 years, 10 months ago (2015-06-17 22:54:21 UTC) #21
Stefan
I'll leave the main review of this CL to pbos, who's focusing a bit more ...
3 years, 10 months ago (2015-06-18 07:47:34 UTC) #23
pbos
Some initial things in webrtc/, I really hope Chuck can help out with iOS/Mac/ObjC specifics. ...
3 years, 10 months ago (2015-06-18 12:14:23 UTC) #24
tkchin
3 years, 10 months ago (2015-06-19 00:10:10 UTC) #25
Migrating to https://codereview.webrtc.org/1187573004 since this CR tool is
becoming read-only.

https://review.webrtc.org/57499004/diff/200001/talk/examples/objc/AppRTCDemo/...
File talk/examples/objc/AppRTCDemo/ARDAppClient.m (right):

https://review.webrtc.org/57499004/diff/200001/talk/examples/objc/AppRTCDemo/...
talk/examples/objc/AppRTCDemo/ARDAppClient.m:349: RTCSessionDescription
*mangledSDP =
On 2015/06/17 22:54:20, noahric (chromium) wrote:
> Consider a name other than "mangled" :) Maybe modifiedSDP? Or
sdpPreferringH264?

Done.

https://review.webrtc.org/57499004/diff/200001/talk/examples/objc/AppRTCDemo/...
File talk/examples/objc/AppRTCDemo/ARDSDPUtils.h (right):

https://review.webrtc.org/57499004/diff/200001/talk/examples/objc/AppRTCDemo/...
talk/examples/objc/AppRTCDemo/ARDSDPUtils.h:34: // Mangles the original SDP
description to instead prefer the specified video
On 2015/06/17 22:54:20, noahric (chromium) wrote:
> "Updates" :-p

Done.

https://review.webrtc.org/57499004/diff/200001/talk/examples/objc/AppRTCDemo/...
talk/examples/objc/AppRTCDemo/ARDSDPUtils.h:39: withVideoCodec:(NSString
*)codec;
On 2015/06/17 22:54:20, noahric (chromium) wrote:
> Consider withPreferredVideoCodec: or just preferredVideoCodec: (depending on
> which style this codebase ascribes to). Something to make it more obvious from
> the call site.

Done.

https://review.webrtc.org/57499004/diff/200001/talk/examples/objc/AppRTCDemo/...
File talk/examples/objc/AppRTCDemo/ARDSDPUtils.m (right):

https://review.webrtc.org/57499004/diff/200001/talk/examples/objc/AppRTCDemo/...
talk/examples/objc/AppRTCDemo/ARDSDPUtils.m:40: // Copied from
PeerConnectionClient.java.
On 2015/06/17 22:54:20, noahric (chromium) wrote:
> I'd TODO or open a bug for this, then. It's pretty hairy code to require every
> application to duplicate in their app's language of choice, especially when
the
> outer API is relatively simple.

Done.

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
File webrtc/modules/video_coding/codecs/h264/h264.gypi (right):

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
webrtc/modules/video_coding/codecs/h264/h264.gypi:25: 'h264.mm',
On 2015/06/18 12:14:21, pbos wrote:
> Shouldn't these sources be under the ios/mac conditional?

No. See other comment.

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
webrtc/modules/video_coding/codecs/h264/h264.gypi:34: 'target_name':
'webrtc_h264_video_toolbox',
On 2015/06/18 12:14:22, pbos wrote:
> What's a toolbox here? I don't understand this target name (or why there's two
> targets, isn't webrtc_h264 enough?).

VIdeoToolbox is the name of the iOS/OSX framework (library) that handles h264
encoding/decoding.
There are two targets because I anticipate moving the Android equivalent here as
well, as opposed to having it bundled into AppRTCDemo. That will make it easier
for third party consumers to use.
People who care about h264 should add webrtc_h264 as a dependency, and based on
config we will add the correct implementation for the platform.

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
File webrtc/modules/video_coding/codecs/h264/h264.mm (right):

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
webrtc/modules/video_coding/codecs/h264/h264.mm:28: // Bail if we aren't
actually running on an iOS8 device.
On 2015/06/18 12:14:22, pbos wrote:
> Is there any other way you can check for API availability that doesn't scream
> "version number"?

No. You can compile using an iOS8 SDK and deploy on an older OS, eg iOS7. iOS8
specific method calls will then fail.

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
File webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_decoder.h
(right):

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_decoder.h:24: //
experimentation. Use at your own risk ¯\_(ツ)_/¯
On 2015/06/18 12:14:22, pbos wrote:
> Remove emojis, especially non-ascii characters.

Done.

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
File webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_decoder.mm
(right):

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_decoder.mm:14: #if
defined(WEBRTC_VIDEO_TOOLBOX_SUPPORTED)
On 2015/06/18 12:14:22, pbos wrote:
> Can this be defined/known from the gyp file so that we can remove the defines
> from the source files?

No. The value of this define is derived from an SDK include. See h264.h.

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_decoder.mm:55: //
TODO(tkchin): <b>Use a pool!</b>
On 2015/06/18 12:14:22, pbos wrote:
> Remove html tags, Use a frame-buffer pool.

Done.

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_decoder.mm:73:
LOG(LS_ERROR) << "Error converting NV12 to I420 :" << ret;
On 2015/06/17 22:54:20, noahric (chromium) wrote:
> extra space before : (but should have a space after)

Done.

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_decoder.mm:91:
LOG(LS_ERROR) << "Failed to decode frame. Status:" << status;
On 2015/06/17 22:54:20, noahric (chromium) wrote:
> space after :

Done.

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_decoder.mm:97:
webrtc::kVideoRotation_0);
On 2015/06/17 22:54:20, noahric (chromium) wrote:
> Will this break with CVO? Either way, can you enable CVO by passing rotation
> information in the last param of VTDecompressionSessionDecodeFrame?

Added a TODO to figure out how CVO works on iOS. Afaik the capturer right now
already adjusts it so nothing needs to be rotated.

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_decoder.mm:185: // We
want decoded frames to exist on GPU so that we can avoid a texture
On 2015/06/18 12:14:22, pbos wrote:
> Can you explain what you're doing rather than what you want?

This comment is actually explaining what we are doing. But you're right that you
won't understand this comment if you haven't interacted with iOS texture things
before.

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_decoder.mm:187: //
i420 frame after decode, but eventually we will be able to plumb
On 2015/06/18 12:14:22, pbos wrote:
> I420

Done.

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_decoder.mm:188: //
CVPixelBuffers directly through the engine.
On 2015/06/18 12:14:22, pbos wrote:
> directly to the renderer

Done.

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_decoder.mm:189: //
TODO(tkchin): maybe only do this if we know that we will be getting native
On 2015/06/18 12:14:22, pbos wrote:
> native handles from where? decoder? what is the "this" that we're doing?

let me know if this is still too cryptic for you.

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
File webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_encoder.h
(right):

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_encoder.h:25: //
experimentation. Use at your own risk ¯\_(ツ)_/¯
On 2015/06/18 12:14:22, pbos wrote:
> Remove emoji, also Use at your own risk, it's implied.

Done.

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
File webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_encoder.mm
(right):

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_encoder.mm:36: //
Copies characters from a CFStringRef into a std::string.
On 2015/06/18 12:14:22, pbos wrote:
> Do you benefit a lot from not copying this string? It's only used for errors,
so
> return std::string and use it?

Returning std::string is fine, I'm down with saving lines.

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_encoder.mm:38: if
(!cf_string || !std_string) {
On 2015/06/18 12:14:22, pbos wrote:
> DCHECK these?

Done.

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_encoder.mm:48: if
(!buffer) {
On 2015/06/18 12:14:22, pbos wrote:
> That doesn't happen, new doesn't return null for non-zero sizes, it throws
> exceptions (bad_alloc) if it doesn't work.

Done.

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_encoder.mm:115: // We
receive I420Frames as input, but we need to feed CVPixelBuffers into the
On 2015/06/18 12:14:22, pbos wrote:
> Should this be where we have also accept a native handle, or is that a future
> change?

Future change (the native handle == CVPixelBuffer). So need to check for native
handle and pass it along instead of copy.
Native handle bits weren't around when the CL started so I'd rather do it later.

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_encoder.mm:164:
LOG(LS_ERROR) << "H264 encoding failed.";
On 2015/06/18 12:14:22, pbos wrote:
> Should this already have logged an error (do we double-log any errors)?

No. This is the result of the encoding.

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_encoder.mm:182: //
TODO(tkchin): allocate buffers through a pool.
On 2015/06/18 12:14:22, pbos wrote:
> Allocate

Done.

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_encoder.mm:226:
width_ = codec_settings->width;
On 2015/06/17 22:54:21, noahric (chromium) wrote:
> Something to TODO to check for: assuming you're testing with a camera, you're
> probably getting nicely aligned dimensions. Depending on the usage/context,
you
> may have to enforce some kind of alignment requirement here. E.g. on Android,
> not respecting implicit alignment values will, depending on the device, (a)
> work, (b) work, but crop things in sometimes humorous ways, (c) fail to create
> the coder, or (d) crash. Hopefully not as bad here, but something to watch out
> for :)

That's good to know, thanks.

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_encoder.mm:239: const
CodecSpecificInfo* codec_specific_info,
On 2015/06/17 22:54:20, noahric (chromium) wrote:
> You should plumb this through the VTCompressionSessionEncodeFrame.
> CodecSpecificInfoH264 is blank today, but it probably won't be forever, so
it's
> not sufficient to just create an empty one on the other side.
> 
> (At least TODO this)

Makes sense, thanks.

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_encoder.mm:241: if
(input_image.IsZeroSize()) {
On 2015/06/17 22:54:21, noahric (chromium) wrote:
> That's not actually an error, so consider just OKing it optionally with an
> assert to say that it's a valid but wrong code path.
> 
> (Encoders registered with internal sources will receive zero size input image
> Encode requests as keyframe requests, because it fakes up frames to use since
> the frames aren't flowing through the normal camera pipeline. internal source
> stuff probably won't make it to webrtcvideoengine2 or at least not live long
if
> it does).

Done.

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_encoder.mm:258: //
TODO(tkchin): make sure that this drops frames but future encodes
On 2015/06/17 22:54:21, noahric (chromium) wrote:
> Can probably remove this TODO. Quick inspection should tell you one way or the
> other (I'm pretty sure I looked at this last week and the value is basically
> ignored, so only this frame is dropped).

Done.

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_encoder.mm:289:
encode_params.reset(new internal::FrameEncodeParams(callback_, width_,
On 2015/06/18 12:14:22, pbos wrote:
> Isn't all this heap allocation in an active path expensive?

No perf data as of yet. Tuning CL comes after initial impl.

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_encoder.mm:403: //
TODO(tkchin): look at entropy mode and colorspace matrices.
On 2015/06/18 12:14:22, pbos wrote:
> Look

Done.

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_encoder.mm:405: //
TODO(tkchin): investigate to see if there's any way to make this work.
On 2015/06/18 12:14:22, pbos wrote:
> Investigate, also remove /**/ comments (since // are a lot more common, just
use
> those, it's 3 lines and you can remove your added 2 lines.

Done.

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_encoder.mm:411: //
Require a keyframe every 240 frames or every 240 seconds, whichever comes
On 2015/06/18 12:14:22, pbos wrote:
> Every 240 frames sounds like a lot of keyframes (for VP8 we have 3k). There's
no
> point in emitting them in itself.

I'm fine killing this for now and tuning later.

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
File webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_nalu.mm (right):

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_nalu.mm:54:
DCHECK_EQ(nalu_header_size, (int)4);
On 2015/06/18 12:14:23, pbos wrote:
> you shouldn't need a cast here

Done.

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_nalu.mm:55:
DCHECK_EQ(param_set_count, (size_t)2);
On 2015/06/18 12:14:23, pbos wrote:
> 2u

Done.

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_nalu.mm:106:
CFRetain(contiguous_buffer);
On 2015/06/18 12:14:22, pbos wrote:
> Can you make a scoped_ptr equivalent for this CF thing? I really don't like
all
> the manual CFReleases etc. Especially since I don't know the semantics.

There's one in chromium that we can potentially rip, but I don't want to do that
in this CL.
Perhaps you should read up on the semantics then :-) It's really not so
different from regular ref counting interfaces, and it's a requisite bit of
knowledge when interacting with Core Foundation.
https://developer.apple.com/library/ios/documentation/CoreFoundation/Referenc...

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_nalu.mm:313: const
uint8_t* current = start + offset;
On 2015/06/17 22:54:21, noahric (chromium) wrote:
> We should probably find a place to share this now, at least between android
and
> ios. Not necessary for this CL.

Yeah, hopefully one day we can put everything in codecs/h264.

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
webrtc/modules/video_coding/codecs/h264/h264_video_toolbox_nalu.mm:314: const
uint8_t* const end = start + length;
On 2015/06/17 22:54:21, noahric (chromium) wrote:
> Consider subtracting off sizeof(kAnnexBHeaderBytes) here. Hopefully it'll be
> optimized to that anyways, but there's no great reason to calculate end
halfway.
> You can also add a comment if you want it clearer:
> // Stop sizeof(kAnnexBHeaderBytes) early because the loop reads that many
bytes
> at a time.

Done.

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
File webrtc/modules/video_coding/codecs/h264/include/h264.h (right):

https://review.webrtc.org/57499004/diff/200001/webrtc/modules/video_coding/co...
webrtc/modules/video_coding/codecs/h264/include/h264.h:19:
__IPHONE_OS_VERSION_MAX_ALLOWED >= __IPHONE_8_0) || \
On 2015/06/18 12:14:23, pbos wrote:
> Can this be determined from the gyp file instead?

No. Requires include of Availability.h.
Sign in to reply to this message.

Powered by Google App Engine
RSS Feeds Recent Issues | This issue
This is Rietveld 245c2c2-tainted