610.srt

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:00:12.046 --> 00:00:13.056 A:middle
>> Morning everyone.

00:00:14.196 --> 00:00:15.486 A:middle
Welcome to Session 610.

00:00:15.486 --> 00:00:18.286 A:middle
I'm Brad Ford, I work on the
core media engineering team.

00:00:18.616 --> 00:00:21.286 A:middle
For the next hour I'm
going to talk to you

00:00:21.286 --> 00:00:24.026 A:middle
about the most popular
camera in the world.

00:00:25.226 --> 00:00:26.376 A:middle
Actually that's inaccurate.

00:00:26.416 --> 00:00:28.526 A:middle
If you go by Flickr data,
I'm going to talk to you

00:00:28.526 --> 00:00:31.066 A:middle
about the three most popular
cameras in the world --

00:00:31.706 --> 00:00:34.756 A:middle
iPhone 4s, iPhone
5, and iPhone 4.

00:00:35.456 --> 00:00:38.676 A:middle
And we recognize that you're
a big part of that popularity.

00:00:38.966 --> 00:00:42.856 A:middle
We bring the great
hardware, we bring the camera

00:00:42.856 --> 00:00:44.146 A:middle
that people get excited about,

00:00:44.816 --> 00:00:47.786 A:middle
and we bring the framework level
support, but you bring the apps.

00:00:48.236 --> 00:00:51.976 A:middle
And we wouldn't be as popular or
as successful without your apps

00:00:51.976 --> 00:00:55.196 A:middle
that make our platform
so useful, and so fun.

00:00:55.366 --> 00:00:56.906 A:middle
So thank you for that.

00:00:57.816 --> 00:01:01.586 A:middle
Today we're going to
have a brief appetizer

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:00:57.816 --> 00:01:01.586 A:middle
Today we're going to
have a brief appetizer

00:01:01.686 --> 00:01:04.046 A:middle
of greater transparency
for users,

00:01:04.046 --> 00:01:05.786 A:middle
and then the main
course is features --

00:01:05.896 --> 00:01:08.746 A:middle
lots and lots of new features,
and then we'll follow that up

00:01:08.746 --> 00:01:12.006 A:middle
with a sample code
update for our dessert.

00:01:12.646 --> 00:01:15.736 A:middle
We're not going to spend any
time today on core media basics

00:01:15.736 --> 00:01:18.476 A:middle
or AV foundation basics,
because we just don't have time

00:01:18.476 --> 00:01:19.356 A:middle
in an hour to do that.

00:01:19.906 --> 00:01:22.756 A:middle
But lucky for you, we've
talked about them several times

00:01:22.756 --> 00:01:25.756 A:middle
in the past, and all of
these sessions are available

00:01:26.166 --> 00:01:29.236 A:middle
on your WWDC app on
your phone right now.

00:01:29.236 --> 00:01:31.306 A:middle
So you could actually call it
up, and you could be listening

00:01:31.306 --> 00:01:33.676 A:middle
to me two years ago, while
you're listening to me now.

00:01:36.026 --> 00:01:36.896 A:middle
But turn the sound down.

00:01:38.086 --> 00:01:40.146 A:middle
First upgrade for
transparency for users,

00:01:40.596 --> 00:01:45.036 A:middle
last year we introduced
some security hardening

00:01:45.036 --> 00:01:50.186 A:middle
that we introduced in iOS 6
to make it more transparent

00:01:50.186 --> 00:01:53.656 A:middle
for users when the photos and
videos were being accessed

00:01:53.656 --> 00:01:54.876 A:middle
in their photos library.

00:01:55.266 --> 00:01:56.336 A:middle
And we did that by popping

00:01:56.336 --> 00:01:59.706 A:middle
up a dialog the first time your
application tries to access --

00:01:59.706 --> 00:02:04.086 A:middle
that is read to-- read from,
or write to the assets library,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:01:59.706 --> 00:02:04.086 A:middle
that is read to-- read from,
or write to the assets library,

00:02:04.676 --> 00:02:07.396 A:middle
so that the user would have an
opportunity to opt in or out.

00:02:08.526 --> 00:02:10.826 A:middle
And we warned you that you
should start paying attention

00:02:10.826 --> 00:02:13.476 A:middle
to errors that you get back
from AL assets library.

00:02:14.426 --> 00:02:17.256 A:middle
Well this year we're hardening
things even a little bit more,

00:02:17.996 --> 00:02:19.696 A:middle
and we do this for
a couple of reasons.

00:02:20.396 --> 00:02:23.126 A:middle
You've probably noticed that
on our iOS devices we have no

00:02:23.126 --> 00:02:27.436 A:middle
hardware blinky light that
tells you that recording is

00:02:27.436 --> 00:02:30.766 A:middle
in progress, and AV foundation

00:02:30.766 --> 00:02:34.996 A:middle
as a framework does not force
you to put up a UI saying

00:02:35.116 --> 00:02:36.296 A:middle
"recording in progress".

00:02:36.926 --> 00:02:39.246 A:middle
So therefore it's possible
to do something headlessly.

00:02:39.416 --> 00:02:41.586 A:middle
And users want to trust
your app, they want to know

00:02:41.586 --> 00:02:42.536 A:middle
when things are happening.

00:02:43.116 --> 00:02:46.506 A:middle
So also in some regions
it's now required by law

00:02:47.016 --> 00:02:50.126 A:middle
to present users notice
when the microphone

00:02:50.446 --> 00:02:51.896 A:middle
or the camera is in use.

00:02:52.326 --> 00:02:55.336 A:middle
So new in iOS 7, we are going

00:02:55.336 --> 00:02:58.866 A:middle
to introduce two new dialogs the
first time your app makes use

00:02:58.866 --> 00:03:02.166 A:middle
of the microphone or the
camera to allow users to know

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:02:58.866 --> 00:03:02.166 A:middle
of the microphone or the
camera to allow users to know

00:03:02.166 --> 00:03:03.746 A:middle
about it, and to opt in or out.

00:03:04.366 --> 00:03:09.226 A:middle
Now the microphone dialog is
everywhere, that is all iPhones,

00:03:09.226 --> 00:03:10.776 A:middle
all iPads, everywhere.

00:03:11.196 --> 00:03:14.756 A:middle
The camera dialog is just in
certain regions where required

00:03:14.756 --> 00:03:16.036 A:middle
by law, such as China.

00:03:16.856 --> 00:03:19.606 A:middle
Here's how it looks in code.

00:03:20.166 --> 00:03:23.836 A:middle
The first time you create
an AV capture device input,

00:03:25.106 --> 00:03:26.466 A:middle
the dialog will be invoked.

00:03:27.746 --> 00:03:29.106 A:middle
In code it looks like this.

00:03:29.356 --> 00:03:33.126 A:middle
You call device input with
device, and pay attention

00:03:33.126 --> 00:03:35.266 A:middle
to that error, because it
might return an error now.

00:03:36.256 --> 00:03:38.836 A:middle
The very first time we need
to succeed, because we need

00:03:38.836 --> 00:03:40.366 A:middle
to return control
to you immediately,

00:03:40.366 --> 00:03:42.776 A:middle
but we actually don't know the
answer yet because the dialog is

00:03:42.776 --> 00:03:45.446 A:middle
up but the person might
not have said okay or deny.

00:03:46.146 --> 00:03:48.066 A:middle
So what do we do in the interim?

00:03:49.106 --> 00:03:51.306 A:middle
For a microphone
we produce Silence

00:03:51.506 --> 00:03:55.126 A:middle
until the user grants access,
and for the camera we spit

00:03:55.126 --> 00:03:57.656 A:middle
out black frames until
they've granted access.

00:03:58.546 --> 00:04:01.626 A:middle
If on subsequent launches we
already know what the answer is,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:03:58.546 --> 00:04:01.626 A:middle
If on subsequent launches we
already know what the answer is,

00:04:01.976 --> 00:04:04.346 A:middle
we can return an
error immediately,

00:04:04.516 --> 00:04:05.496 A:middle
and that's a new error

00:04:05.496 --> 00:04:09.346 A:middle
in AV foundation called
application is not authorized

00:04:09.346 --> 00:04:10.306 A:middle
to use device.

00:04:10.386 --> 00:04:11.486 A:middle
So pay attention to that.

00:04:11.486 --> 00:04:14.666 A:middle
That means the user is
choosing not to allow you

00:04:14.666 --> 00:04:16.036 A:middle
to use the camera or microphone.

00:04:19.216 --> 00:04:20.786 A:middle
Alright, on to features.

00:04:20.786 --> 00:04:24.286 A:middle
This is going to be the
major bulk of our talk today,

00:04:24.886 --> 00:04:27.346 A:middle
and we have a lot of
them to get through.

00:04:28.016 --> 00:04:32.776 A:middle
Five major feature areas, first
60 fps support, video zoom,

00:04:33.456 --> 00:04:36.146 A:middle
machine readable code
detection, or barcode detection,

00:04:36.716 --> 00:04:40.626 A:middle
focus enhancements, and
integration with audio session.

00:04:40.976 --> 00:04:42.656 A:middle
First up 60 fps support.

00:04:43.386 --> 00:04:45.276 A:middle
And we know a lot of you
have been waiting a long time

00:04:45.276 --> 00:04:45.786 A:middle
for this.

00:04:45.786 --> 00:04:48.906 A:middle
You've been waiting patiently,
and I think it's worth the wait.

00:04:49.166 --> 00:04:51.956 A:middle
We didn't want to unleash
this feature on all

00:04:51.956 --> 00:04:53.946 A:middle
of you before we had
really thought it through,

00:04:54.316 --> 00:04:57.356 A:middle
and given you comprehensive
support across the media stack.

00:04:57.926 --> 00:05:01.336 A:middle
So by introducing 60
frame rate movies,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:04:57.926 --> 00:05:01.336 A:middle
So by introducing 60
frame rate movies,

00:05:01.336 --> 00:05:03.626 A:middle
we wanted to make sure you
could also do interesting things

00:05:03.626 --> 00:05:05.716 A:middle
with them, as far as
playback and editing.

00:05:06.436 --> 00:05:09.546 A:middle
So we are introducing
full iOS ecosystem support

00:05:09.686 --> 00:05:10.996 A:middle
for high frame rate content.

00:05:11.346 --> 00:05:11.946 A:middle
What does that mean?

00:05:12.516 --> 00:05:15.166 A:middle
On capture we support
720p video,

00:05:15.166 --> 00:05:19.256 A:middle
up to 60 frames per second,
with video stabilization,

00:05:19.556 --> 00:05:22.206 A:middle
and we write really cool movies.

00:05:22.206 --> 00:05:25.696 A:middle
These have droppable p-frames
in them, a feature of H264,

00:05:25.696 --> 00:05:27.856 A:middle
which allows them to
play back smoothly,

00:05:27.856 --> 00:05:30.776 A:middle
even on lower powered
machines, or older machines.

00:05:31.396 --> 00:05:34.886 A:middle
On the playback front,
we've beefed up our support

00:05:34.886 --> 00:05:38.716 A:middle
for audio processing in
the time pitch domain,

00:05:38.716 --> 00:05:41.056 A:middle
so that if you want to do
effects like slow the movies

00:05:41.056 --> 00:05:43.056 A:middle
down or speed them up, you
can do interesting things

00:05:43.056 --> 00:05:43.656 A:middle
with audio.

00:05:44.926 --> 00:05:47.526 A:middle
On the editing side, we largely
already had the support there,

00:05:48.036 --> 00:05:53.186 A:middle
but we do support fully scaled
edits in mutable compositions.

00:05:53.926 --> 00:05:56.796 A:middle
And lastly, in export we
allow you to do it two ways.

00:05:56.796 --> 00:06:00.436 A:middle
You can either export such
that the high frame rate areas

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:05:56.796 --> 00:06:00.436 A:middle
You can either export such
that the high frame rate areas

00:06:00.436 --> 00:06:01.746 A:middle
of the movie are preserved,

00:06:02.306 --> 00:06:05.506 A:middle
or you can do a frame rate
conversion that will sort

00:06:05.506 --> 00:06:07.906 A:middle
of flatten it all down
to 30 frames per second,

00:06:07.906 --> 00:06:08.626 A:middle
or something else.

00:06:09.086 --> 00:06:14.976 A:middle
But enough talk,
let's do a demo.

00:06:15.996 --> 00:06:19.066 A:middle
Alright. So the first demo
app is called Slowpoke.

00:06:19.496 --> 00:06:23.896 A:middle
This is an app that showcases
all four feature areas

00:06:23.896 --> 00:06:25.536 A:middle
of 60 frames per second support.

00:06:26.366 --> 00:06:28.956 A:middle
First one is capture,
as you might expect.

00:06:29.296 --> 00:06:32.696 A:middle
Now it looks just like a regular
capture app, except I don't know

00:06:32.846 --> 00:06:35.766 A:middle
if you can tell out there, but
it's a really fast frame rate,

00:06:35.766 --> 00:06:38.846 A:middle
it's a buttery smooth 60
frames per second preview.

00:06:39.536 --> 00:06:43.116 A:middle
And it's running the
camera at 720p 60.

00:06:43.606 --> 00:06:45.936 A:middle
You can also do all the things
you'd expect, like focus,

00:06:46.656 --> 00:06:53.826 A:middle
and it writes movies that have
the proper H264 bitrate profile

00:06:53.826 --> 00:06:54.636 A:middle
level, etcetera.

00:06:55.266 --> 00:06:57.376 A:middle
Let's go over to the
more interesting part

00:06:57.376 --> 00:07:00.086 A:middle
for today's demo, which is
the playback and editing.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:06:57.376 --> 00:07:00.086 A:middle
for today's demo, which is
the playback and editing.

00:07:00.786 --> 00:07:03.306 A:middle
I recorded several
movies here previously,

00:07:03.406 --> 00:07:05.296 A:middle
they're all 60 frames
per second movies.

00:07:05.296 --> 00:07:08.436 A:middle
I'm just going to pick one
of them, and now we'll find

00:07:08.436 --> 00:07:10.806 A:middle
out why this app
got its namesake.

00:07:11.516 --> 00:07:14.736 A:middle
This is a clip of a
guitarist playing the prelude

00:07:14.736 --> 00:07:16.716 A:middle
from Bach's E Major Lute Suite,

00:07:17.416 --> 00:07:21.166 A:middle
let me play a little
bit for you.

00:07:21.166 --> 00:07:22.106 A:middle
[ Music ]

00:07:22.106 --> 00:07:24.916 A:middle
So let's say you're trying
to learn this piece yourself,

00:07:25.316 --> 00:07:28.086 A:middle
and he's going too fast,
you need to slow him down so

00:07:28.086 --> 00:07:29.066 A:middle
that you can hear it better.

00:07:29.066 --> 00:07:32.926 A:middle
I'm going to swipe to
the left to slow it down.

00:07:32.926 --> 00:07:33.136 A:middle
[ Music ]

00:07:33.136 --> 00:07:38.176 A:middle
And I'll go even slower now.

00:07:38.176 --> 00:07:38.416 A:middle
[ Music ]

00:07:38.416 --> 00:07:46.046 A:middle
So now you can really see
his fingers move well.

00:07:46.326 --> 00:07:47.666 A:middle
Alternately, you
could make him sound

00:07:47.666 --> 00:07:49.946 A:middle
like Yngwie Malmsteen,
which is my favorite.

00:07:49.946 --> 00:07:50.136 A:middle
[ Music ]

00:07:50.136 --> 00:07:53.006 A:middle
Notice how good it sounds.

00:07:53.006 --> 00:08:01.786 A:middle
We're preserving pitch here, so
that you could even export this

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:07:53.006 --> 00:08:01.786 A:middle
We're preserving pitch here, so
that you could even export this

00:08:01.786 --> 00:08:03.956 A:middle
and pass it off as him
doing the real thing.

00:08:03.956 --> 00:08:07.566 A:middle
Now he's an amazing guitarist.

00:08:08.596 --> 00:08:09.736 A:middle
Alright, let's pick another one.

00:08:09.736 --> 00:08:10.516 A:middle
[ Applause ]

00:08:10.516 --> 00:08:11.296 A:middle
Thank you.

00:08:11.296 --> 00:08:17.906 A:middle
Let's have a little fun
at my dog's expense.

00:08:18.126 --> 00:08:21.836 A:middle
This poor animal protects our
house from dangerous birds

00:08:21.836 --> 00:08:24.716 A:middle
on wires, and this is
what he sounds like.

00:08:24.716 --> 00:08:26.156 A:middle
[ Dog Barking ]

00:08:26.156 --> 00:08:30.706 A:middle
Okay, protecting our house.

00:08:30.706 --> 00:08:33.366 A:middle
Now let's have some fun speeding
him up and slowing him down,

00:08:33.366 --> 00:08:36.006 A:middle
but this time I'm going
to engage chipmunk mode.

00:08:36.226 --> 00:08:37.616 A:middle
You'll notice over in
the corner I'm going

00:08:37.616 --> 00:08:39.525 A:middle
to turn the chipmunk
button on so

00:08:39.525 --> 00:08:46.756 A:middle
that we can make him
sound like a yip-yip dog.

00:08:46.756 --> 00:08:47.336 A:middle
[ Dog Barking ]

00:08:47.336 --> 00:08:49.566 A:middle
Or, like Barry White.

00:08:49.566 --> 00:08:50.156 A:middle
[ Dog Barking ]

00:08:50.156 --> 00:08:55.296 A:middle
Or a dinosaur.

00:08:55.296 --> 00:08:55.826 A:middle
[ Dog Barking ]

00:08:55.826 --> 00:08:57.256 A:middle
Okay, enough of that.

00:08:57.256 --> 00:09:00.266 A:middle
And finally, let's go --

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:08:57.256 --> 00:09:00.266 A:middle
And finally, let's go --

00:09:00.266 --> 00:09:01.606 A:middle
[ Applause ]

00:09:01.606 --> 00:09:08.396 A:middle
Notice we have so many
frames in the movie

00:09:08.396 --> 00:09:10.576 A:middle
that it looks really good
when you slow him down.

00:09:11.286 --> 00:09:13.606 A:middle
Let's take this last one
here, this is an action shot,

00:09:14.186 --> 00:09:19.406 A:middle
kind of a frightening one of
my dog coming up towards you

00:09:19.406 --> 00:09:20.526 A:middle
at a million miles an hour.

00:09:20.526 --> 00:09:22.266 A:middle
Now let's engage
the chipmunk mode,

00:09:22.266 --> 00:09:24.936 A:middle
but let's say this time I don't
just want to mess around with it

00:09:24.936 --> 00:09:28.996 A:middle
in real time, I want to
program a slow motion part right

00:09:28.996 --> 00:09:31.366 A:middle
into the asset.

00:09:32.106 --> 00:09:34.696 A:middle
Okay, so I'll pick a point
right where he's starting

00:09:34.696 --> 00:09:35.526 A:middle
to come up the stairs.

00:09:35.526 --> 00:09:38.476 A:middle
Now I'm going to swipe down
to begin and end it, and edit.

00:09:39.096 --> 00:09:43.956 A:middle
And then I'll go to where he's
right next to me, and I'll swipe

00:09:43.956 --> 00:09:46.436 A:middle
up to end the edit, and
here I get to apply a rate.

00:09:46.996 --> 00:09:52.046 A:middle
So I'll set the rate to .25,
quarter speed, and apply it.

00:09:52.046 --> 00:09:54.836 A:middle
And you notice that the duration
just changed on this movie.

00:09:55.566 --> 00:09:58.746 A:middle
Now I can go back and play it.

00:09:59.246 --> 00:10:02.086 A:middle
[ Silence ]

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:09:59.246 --> 00:10:02.086 A:middle
[ Silence ]

00:10:02.586 --> 00:10:09.166 A:middle
Oh yeah. He's coming for you.

00:10:10.156 --> 00:10:14.776 A:middle
Okay. So -- and then of
course as you might suspect,

00:10:15.096 --> 00:10:17.576 A:middle
we would want to be able to
save these off for posterity,

00:10:17.576 --> 00:10:19.776 A:middle
so we have the export button
over here on the side,

00:10:20.276 --> 00:10:22.376 A:middle
which lets us export
to the camera roll,

00:10:22.616 --> 00:10:24.756 A:middle
either preserving the
high frame rate sections,

00:10:25.066 --> 00:10:28.526 A:middle
or going down to a constant
frame rate of say 30,

00:10:28.526 --> 00:10:29.266 A:middle
or something like that.

00:10:29.266 --> 00:10:31.116 A:middle
And that is Slowpoke.

00:10:31.116 --> 00:10:32.106 A:middle
[ Applause ]

00:10:32.106 --> 00:10:38.356 A:middle
On the playback side, AV
player does most of this

00:10:38.356 --> 00:10:39.496 A:middle
for you automatically.

00:10:40.346 --> 00:10:45.256 A:middle
If you just use player setRate,
it can select arbitrary rates

00:10:45.256 --> 00:10:47.336 A:middle
and play them back, and
do the really hard job

00:10:47.336 --> 00:10:49.516 A:middle
of keeping audio
and video in sync.

00:10:50.506 --> 00:10:53.886 A:middle
There's a new property
on the player item.

00:10:53.886 --> 00:10:56.116 A:middle
A player is composed
of player items,

00:10:56.156 --> 00:10:57.286 A:middle
because it's a queue model.

00:10:57.926 --> 00:10:59.206 A:middle
You can take the player item

00:10:59.206 --> 00:11:01.426 A:middle
and set its audio
time pitch algorithm,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:10:59.206 --> 00:11:01.426 A:middle
and set its audio
time pitch algorithm,

00:11:01.426 --> 00:11:04.426 A:middle
that's what I was using there to
either adjust the pitch higher

00:11:04.426 --> 00:11:05.786 A:middle
or lower, or keep it constant.

00:11:05.786 --> 00:11:08.946 A:middle
I was using the bottom
two constants there,

00:11:08.946 --> 00:11:12.616 A:middle
which are spectral, which keeps
it preserved, and varispeed,

00:11:12.816 --> 00:11:14.106 A:middle
which alters the pitch.

00:11:14.536 --> 00:11:16.896 A:middle
And these are very high
quality algorithms.

00:11:16.896 --> 00:11:21.456 A:middle
They can go constantly from
32x down to 1 over 32x.

00:11:21.846 --> 00:11:22.666 A:middle
And they sound great.

00:11:23.316 --> 00:11:28.906 A:middle
On the editing side, I was using
AV mutable composition to build

00:11:28.906 --> 00:11:33.216 A:middle
up those temporal edits when I
saved off that scaled section.

00:11:33.676 --> 00:11:38.836 A:middle
I did that by creating an empty
composition, inserting all

00:11:38.836 --> 00:11:41.646 A:middle
of my source asset
into that composition,

00:11:42.376 --> 00:11:44.696 A:middle
and then choosing the section
that I wanted to scale up

00:11:44.696 --> 00:11:47.196 A:middle
or down, just by
using scale time range

00:11:47.276 --> 00:11:49.116 A:middle
to duration, very simple.

00:11:50.726 --> 00:11:53.726 A:middle
See the Slowpoke sample code
where you can find out how

00:11:53.726 --> 00:11:54.816 A:middle
to do all this yourselves.

00:11:55.116 --> 00:11:58.036 A:middle
And if you're interested in
the editing aspect of this,

00:11:58.036 --> 00:12:01.006 A:middle
I invite you to come back
tomorrow at 9:00 a.m.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:11:58.036 --> 00:12:01.006 A:middle
I invite you to come back
tomorrow at 9:00 a.m.

00:12:01.136 --> 00:12:03.456 A:middle
where we're having an
advanced editing session

00:12:03.726 --> 00:12:04.696 A:middle
with AV foundation.

00:12:05.496 --> 00:12:12.296 A:middle
On the export side, I'm using AV
asset export session to flatten

00:12:12.296 --> 00:12:13.506 A:middle
that out into a new movie.

00:12:13.506 --> 00:12:16.256 A:middle
Now as I mentioned, there
are two ways to do this.

00:12:16.726 --> 00:12:20.666 A:middle
You can use the pass-through
export preset if you want

00:12:20.666 --> 00:12:22.296 A:middle
to avoid any re-encoding.

00:12:22.376 --> 00:12:23.826 A:middle
That will just retime the media,

00:12:24.176 --> 00:12:27.986 A:middle
and send it out as section
60 frames per second,

00:12:28.096 --> 00:12:29.676 A:middle
section slowed down or sped up.

00:12:30.996 --> 00:12:33.026 A:middle
Or you can do a constant
frame rate export.

00:12:33.156 --> 00:12:34.036 A:middle
You might want to do this

00:12:34.036 --> 00:12:36.386 A:middle
if you want maximum
playback compatibility.

00:12:36.996 --> 00:12:40.416 A:middle
To do this you set the video
composition's frame duration,

00:12:40.416 --> 00:12:46.046 A:middle
saying my source's composition's
frame duration is 1

00:12:46.136 --> 00:12:48.566 A:middle
over 30 frames per
second, for instance.

00:12:49.576 --> 00:12:52.006 A:middle
This gives you maximum
playback compatibility.

00:12:52.376 --> 00:12:55.876 A:middle
And you can also choose to
set the time pitch algorithm

00:12:56.096 --> 00:12:57.226 A:middle
for the export as well.

00:12:57.226 --> 00:12:59.286 A:middle
So you can use a low quality,

00:12:59.286 --> 00:13:01.906 A:middle
or a cheap expensive
one during playback,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:12:59.286 --> 00:13:01.906 A:middle
or a cheap expensive
one during playback,

00:13:01.906 --> 00:13:03.646 A:middle
and then when you export
use a high quality one.

00:13:04.376 --> 00:13:07.646 A:middle
Again, that's all in Slowpoke.

00:13:08.336 --> 00:13:10.496 A:middle
Now on to recording, which
is why we're all here.

00:13:11.436 --> 00:13:15.306 A:middle
AV capture movie file output
just works, as you might expect.

00:13:15.306 --> 00:13:20.786 A:middle
It picks for you automatically
the right H264 profile level bit

00:13:20.786 --> 00:13:22.996 A:middle
rate, and makes sure that
the movie looks great.

00:13:23.826 --> 00:13:26.966 A:middle
If you want to do stuff
with the frames yourself,

00:13:26.966 --> 00:13:28.676 A:middle
you need to use AV asset writer,

00:13:29.306 --> 00:13:31.156 A:middle
and it requires some
additional setup.

00:13:31.766 --> 00:13:34.546 A:middle
As with all real-time
use of AV asset writer,

00:13:34.826 --> 00:13:38.226 A:middle
you need to set expects media
data in real time to yes,

00:13:38.296 --> 00:13:40.446 A:middle
otherwise it won't be able to
keep up with the frame rate.

00:13:41.516 --> 00:13:43.306 A:middle
And we have a new object

00:13:43.306 --> 00:13:46.456 A:middle
that helps you create
settings dictionaries

00:13:46.456 --> 00:13:47.616 A:middle
for the AV asset writer.

00:13:47.926 --> 00:13:49.386 A:middle
An asset writer doesn't
know what kind

00:13:49.386 --> 00:13:50.786 A:middle
of output you want by default.

00:13:50.786 --> 00:13:53.356 A:middle
You have to tell it what
kind of settings to use.

00:13:53.646 --> 00:13:56.046 A:middle
And this can be complicated
with high frame rate movies,

00:13:56.046 --> 00:13:58.906 A:middle
knowing what H264
keys to use, etcetera.

00:13:59.336 --> 00:14:02.996 A:middle
So you can instantiate an AV
output settings assistant,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:13:59.336 --> 00:14:02.996 A:middle
So you can instantiate an AV
output settings assistant,

00:14:03.506 --> 00:14:05.556 A:middle
tell it what the
source video format is,

00:14:05.586 --> 00:14:09.516 A:middle
tell it what the source video
frame rate is, and then ask it

00:14:09.576 --> 00:14:11.826 A:middle
for a dictionary of
settings, and then apply

00:14:11.826 --> 00:14:13.956 A:middle
that to your asset
writer, and it just works.

00:14:14.126 --> 00:14:15.546 A:middle
It'll pick the best
settings for you.

00:14:16.146 --> 00:14:21.586 A:middle
That was the recording aspect
of 60 fps, now let's talk

00:14:21.586 --> 00:14:24.346 A:middle
about how you just configure
the session in general.

00:14:25.206 --> 00:14:28.296 A:middle
Those who've used AV
foundation's capture classes

00:14:28.296 --> 00:14:32.036 A:middle
know that we have an AV capture
session that's the center

00:14:32.036 --> 00:14:32.846 A:middle
of our universe.

00:14:33.126 --> 00:14:35.676 A:middle
And the way that you
configure it is one call.

00:14:36.356 --> 00:14:39.126 A:middle
You set the session
preset to something.

00:14:39.236 --> 00:14:44.046 A:middle
We have a set of strings
that tell you the quality

00:14:44.046 --> 00:14:47.646 A:middle
of service you're going to
get -- photo, high quality,

00:14:47.646 --> 00:14:49.166 A:middle
medium, low, etcetera.

00:14:49.736 --> 00:14:51.146 A:middle
And that does the hard job

00:14:51.146 --> 00:14:53.986 A:middle
of configuring the inputs
and outputs for you.

00:14:55.866 --> 00:14:59.346 A:middle
now we had a problem with
60 fps captures on iOS 7,

00:14:59.346 --> 00:15:03.486 A:middle
because we didn't want to try
to make new session presets

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:14:59.346 --> 00:15:03.486 A:middle
because we didn't want to try
to make new session presets

00:15:03.486 --> 00:15:07.476 A:middle
for every conceivable frame
rate and resolution combination,

00:15:07.476 --> 00:15:10.446 A:middle
because that would result
in a combinatorial explosion

00:15:10.726 --> 00:15:13.036 A:middle
of presets, and it would be
very difficult to program to.

00:15:13.596 --> 00:15:16.046 A:middle
So in iOS 7 we're
introducing a parallel

00:15:16.116 --> 00:15:17.486 A:middle
configuration mechanism.

00:15:17.696 --> 00:15:18.986 A:middle
The old one is not going away,

00:15:19.486 --> 00:15:22.366 A:middle
but this one is for
a power use case.

00:15:22.786 --> 00:15:27.576 A:middle
And that is we're now going to
allow you to inspect the format

00:15:27.846 --> 00:15:31.596 A:middle
of the AV capture device, and
set the active format directly.

00:15:32.436 --> 00:15:35.066 A:middle
And when you do this, the
session is no longer in control,

00:15:35.066 --> 00:15:38.216 A:middle
it no longer automatically
configures inputs and outputs.

00:15:38.416 --> 00:15:44.886 A:middle
720p 60 capture is supported
on iPhone 5, iPod Touch,

00:15:44.886 --> 00:15:47.276 A:middle
the tall one, and iPad Mini.

00:15:49.546 --> 00:15:52.586 A:middle
Let's review how set
session preset works.

00:15:53.796 --> 00:15:56.596 A:middle
Here's a block diagram we have

00:15:56.746 --> 00:15:59.356 A:middle
of the various pieces
in a capture session.

00:15:59.646 --> 00:16:01.806 A:middle
You have inputs, you have
outputs, you have a preview,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:15:59.646 --> 00:16:01.806 A:middle
You have inputs, you have
outputs, you have a preview,

00:16:02.426 --> 00:16:05.176 A:middle
and they're connected
via these white arrows,

00:16:05.236 --> 00:16:08.866 A:middle
which are represented in our
API as AV capture connections.

00:16:08.866 --> 00:16:12.386 A:middle
So you can see the capture
session kind of knows its inputs

00:16:12.386 --> 00:16:14.096 A:middle
and outputs, it knows
its topology.

00:16:16.106 --> 00:16:19.796 A:middle
So when you set a session
preset, let's say photo,

00:16:21.426 --> 00:16:23.256 A:middle
here's a common scenario,
you might also want

00:16:23.256 --> 00:16:27.096 A:middle
to get BGRA frames out of
your video data output instead

00:16:27.096 --> 00:16:29.546 A:middle
of the default, which is 4:2:0.

00:16:30.256 --> 00:16:31.736 A:middle
Here's what happens
under the covers.

00:16:32.306 --> 00:16:35.216 A:middle
The session goes and talks
to all of its outputs.

00:16:35.306 --> 00:16:36.486 A:middle
It says still image output,

00:16:37.096 --> 00:16:41.226 A:middle
for the photo preset what
shall -- what do you require?

00:16:41.626 --> 00:16:44.106 A:middle
And it requires full
res jpeg, so it figures

00:16:44.106 --> 00:16:47.546 A:middle
out that it should
give 3264 by 2448,

00:16:47.676 --> 00:16:48.976 A:middle
assuming this is an iPhone 5.

00:16:50.046 --> 00:16:53.876 A:middle
The video data output does
not give full res buffers

00:16:53.876 --> 00:16:56.426 A:middle
for the photo preset, it's
sort of a special case.

00:16:56.686 --> 00:16:59.156 A:middle
Instead it gives screen
sized buffers to make sure

00:16:59.156 --> 00:17:01.026 A:middle
that they're not too
large for your processing.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:16:59.156 --> 00:17:01.026 A:middle
that they're not too
large for your processing.

00:17:01.466 --> 00:17:05.156 A:middle
So it picks a screen
resolution, and chooses BGRA

00:17:05.156 --> 00:17:07.016 A:middle
because you wanted to
override the default.

00:17:07.866 --> 00:17:10.746 A:middle
The video preview layer
just wants screen size,

00:17:10.746 --> 00:17:12.935 A:middle
and it can cope with
the native format.

00:17:14.296 --> 00:17:16.336 A:middle
So knowing all of
these requirements now,

00:17:16.586 --> 00:17:20.396 A:middle
the session goes up, aggregates
all of those requirements,

00:17:20.396 --> 00:17:21.705 A:middle
goes to the AV capture device,

00:17:21.705 --> 00:17:24.496 A:middle
and says pick me
the best format.

00:17:25.326 --> 00:17:28.066 A:middle
And the AV capture device
looks through its formats,

00:17:28.666 --> 00:17:33.086 A:middle
picks the best match, and also
picks the optimal frame rates --

00:17:33.086 --> 00:17:35.856 A:middle
min and max frame rate to
satisfy all those requirements.

00:17:35.856 --> 00:17:36.886 A:middle
That's what's happening
underneath.

00:17:38.426 --> 00:17:41.596 A:middle
Now using the new configuration
mechanism, it's simple.

00:17:41.926 --> 00:17:42.756 A:middle
Just do this.

00:17:44.166 --> 00:17:47.056 A:middle
Oh let's highlight
this one at a time.

00:17:47.646 --> 00:17:51.906 A:middle
The AV capture device
now exposes an array

00:17:51.906 --> 00:17:53.586 A:middle
of natively supported formats.

00:17:53.636 --> 00:17:56.056 A:middle
Each one is an AV
capture device format.

00:17:56.526 --> 00:17:58.676 A:middle
So here I'm iterating
through them trying

00:17:58.676 --> 00:18:00.016 A:middle
to find the highest frame rate.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:17:58.676 --> 00:18:00.016 A:middle
to find the highest frame rate.

00:18:00.846 --> 00:18:02.496 A:middle
In the next little
section I look

00:18:02.496 --> 00:18:08.316 A:middle
at each format object's
supported frame rate ranges,

00:18:08.756 --> 00:18:11.526 A:middle
find the one that has the max
-- the highest max frame rate.

00:18:11.986 --> 00:18:14.816 A:middle
From that I select the
best format match based

00:18:14.816 --> 00:18:16.146 A:middle
on the highest frame rate range.

00:18:16.696 --> 00:18:19.436 A:middle
And once I have a best
format, I lock my device

00:18:19.436 --> 00:18:22.616 A:middle
for configuration,
set the active format,

00:18:22.616 --> 00:18:27.256 A:middle
and then I pin the min and
max to the highest frame rate

00:18:27.256 --> 00:18:29.956 A:middle
that I found, which is exactly
what I did in the Slowpoke app.

00:18:31.066 --> 00:18:32.536 A:middle
Always, always, always unlock

00:18:32.536 --> 00:18:34.006 A:middle
for configuration
when you're done.

00:18:35.846 --> 00:18:38.466 A:middle
A note about frame
rate selection.

00:18:38.786 --> 00:18:40.676 A:middle
Previously we've only
allowed you to do this

00:18:40.676 --> 00:18:42.956 A:middle
at the AV capture
connections, which as you know,

00:18:42.956 --> 00:18:47.896 A:middle
sit lower in the session
hierarchy than the device.

00:18:48.306 --> 00:18:50.536 A:middle
But what they're doing is
actually going and talking

00:18:50.536 --> 00:18:52.386 A:middle
to the device and setting
the active format --

00:18:52.386 --> 00:18:55.226 A:middle
or the active frame rates
on the device, and we would

00:18:55.226 --> 00:18:56.456 A:middle
like you to do now too.

00:18:56.626 --> 00:18:58.666 A:middle
This is the new preferred
mechanism

00:18:58.666 --> 00:18:59.756 A:middle
for setting frame rates.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:19:00.686 --> 00:19:03.426 A:middle
So talk to the device,
not the connections.

00:19:04.656 --> 00:19:06.986 A:middle
Frame rates can be
set at any time,

00:19:06.986 --> 00:19:09.176 A:middle
whether using the set
session preset API,

00:19:09.466 --> 00:19:11.456 A:middle
or the new set active
format API.

00:19:12.566 --> 00:19:14.796 A:middle
It's -- you can use
them at any time,

00:19:15.196 --> 00:19:21.226 A:middle
and it reconfigures the
graph without tearing down.

00:19:22.186 --> 00:19:23.416 A:middle
Sometimes you just
want to go back

00:19:23.416 --> 00:19:25.196 A:middle
to whatever the default
was supposed to be

00:19:25.196 --> 00:19:27.986 A:middle
for the given preset or active
format that you're using.

00:19:27.986 --> 00:19:29.916 A:middle
But if you don't know
what those defaults are,

00:19:30.256 --> 00:19:33.036 A:middle
you can just set the min
and max frame durations

00:19:33.036 --> 00:19:36.136 A:middle
to CM time invalid, which
will go back to the defaults.

00:19:37.646 --> 00:19:40.236 A:middle
As I mentioned, AV capture
connection's frame rate

00:19:40.236 --> 00:19:42.776 A:middle
selection, accessors
are now deprecated.

00:19:43.216 --> 00:19:45.636 A:middle
Please switch over to the
new one as soon as possible.

00:19:47.616 --> 00:19:49.746 A:middle
Okay, this slide hopefully
doesn't scare you too much.

00:19:49.746 --> 00:19:51.906 A:middle
This is a list of
supported formats

00:19:51.956 --> 00:19:54.356 A:middle
on the iPhone 5's
back facing camera.

00:19:54.416 --> 00:19:55.416 A:middle
It's a little overwhelming.

00:19:55.866 --> 00:19:57.276 A:middle
There are 10 formats here,

00:19:57.676 --> 00:19:59.086 A:middle
and actually that's
only half of them.

00:19:59.086 --> 00:20:01.416 A:middle
There are 20 formats,
but I left half of them

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:19:59.086 --> 00:20:01.416 A:middle
There are 20 formats,
but I left half of them

00:20:01.416 --> 00:20:04.636 A:middle
out because they're really just
two flavors of the same format.

00:20:04.636 --> 00:20:07.586 A:middle
There's a 420v and a 420f,

00:20:07.856 --> 00:20:10.716 A:middle
the v for video range,
the f for full range.

00:20:11.056 --> 00:20:12.426 A:middle
But if we take that
complexity out,

00:20:12.426 --> 00:20:15.576 A:middle
we're left with basically 10
formats, and as you can see,

00:20:15.796 --> 00:20:19.126 A:middle
they're sorted, ascending
by dimensions,

00:20:19.796 --> 00:20:23.136 A:middle
and the more commonly used
ones are listed first.

00:20:23.876 --> 00:20:27.446 A:middle
So let's take a look over
at the right-hand column.

00:20:27.816 --> 00:20:29.956 A:middle
You can see that most
of them are already used

00:20:29.956 --> 00:20:32.766 A:middle
by one session preset
or another.

00:20:33.216 --> 00:20:36.216 A:middle
There are, however, two new ones
that we've never exposed before

00:20:36.216 --> 00:20:42.536 A:middle
on iPhone 5, which is the 720p
60 format and one that's a 4

00:20:42.536 --> 00:20:44.286 A:middle
by 3 format, but not as big

00:20:44.286 --> 00:20:47.696 A:middle
as the absolute full
res 8 megapixel,

00:20:47.946 --> 00:20:51.026 A:middle
and that's a 5 megapixel
4 by 3, and it's not used

00:20:51.026 --> 00:20:52.196 A:middle
by any session preset.

00:20:52.676 --> 00:20:55.186 A:middle
To get at it, you have to use
the active format setters.

00:20:56.496 --> 00:20:59.076 A:middle
Here's what happens
when you use the new way

00:20:59.076 --> 00:21:01.136 A:middle
of configuring AV capture.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:20:59.076 --> 00:21:01.136 A:middle
of configuring AV capture.

00:21:02.106 --> 00:21:05.236 A:middle
Instead of talking to the
session, you talk directly

00:21:05.236 --> 00:21:06.456 A:middle
to the AV capture device.

00:21:06.456 --> 00:21:08.176 A:middle
You say I want your
active format

00:21:08.176 --> 00:21:10.536 A:middle
to be 8 megapixel, let's say.

00:21:11.566 --> 00:21:14.406 A:middle
Now when you do this, the
session is listening for that,

00:21:14.406 --> 00:21:17.236 A:middle
and the session says okay,
they are now in control,

00:21:17.236 --> 00:21:18.596 A:middle
I'm going to take hands-off.

00:21:18.936 --> 00:21:21.596 A:middle
My session preset is
now inputPriority,

00:21:21.706 --> 00:21:24.046 A:middle
which means I'm not going to
touch the inputs or the outputs,

00:21:24.046 --> 00:21:25.726 A:middle
I'm just going to let
the user be in control.

00:21:27.276 --> 00:21:29.796 A:middle
That means that the AV
capture device will now deliver

00:21:29.796 --> 00:21:32.406 A:middle
to the still image output
the full 8 megapixel.

00:21:33.556 --> 00:21:34.936 A:middle
Video preview layer
is an exception,

00:21:34.936 --> 00:21:36.886 A:middle
it still only gets screen size.

00:21:37.516 --> 00:21:39.986 A:middle
But now, new for
video data output,

00:21:39.986 --> 00:21:44.386 A:middle
you get the full 8 megapixel
buffers, not a scaled

00:21:44.386 --> 00:21:48.196 A:middle
down screen resolution
version of it.

00:21:49.226 --> 00:21:51.576 A:middle
Let's talk briefly about what is

00:21:51.626 --> 00:21:54.176 A:middle
in an AV capture
device format object.

00:21:54.486 --> 00:21:56.196 A:middle
It has a media type,
as you might expect,

00:21:56.196 --> 00:21:57.806 A:middle
so you know if it's
audio or video,

00:21:58.846 --> 00:22:00.156 A:middle
it has a format description

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:21:58.846 --> 00:22:00.156 A:middle
it has a format description

00:22:00.156 --> 00:22:02.766 A:middle
from which you can get
the pixel dimensions,

00:22:02.766 --> 00:22:09.016 A:middle
the pixel format
such as 420v, 420f.

00:22:10.416 --> 00:22:12.096 A:middle
You can also get the
video field of view.

00:22:12.186 --> 00:22:13.336 A:middle
This is a really handy one.

00:22:13.456 --> 00:22:15.846 A:middle
Previously, in order to
know what the field of view

00:22:15.846 --> 00:22:19.336 A:middle
of the sensor is, you would
have to run a video data output,

00:22:19.336 --> 00:22:21.916 A:middle
and then look through the meta
data and find the focal length

00:22:21.916 --> 00:22:24.146 A:middle
in 35-millimeter film,
and that's really hard.

00:22:24.766 --> 00:22:26.476 A:middle
Now you don't need to
run the camera at all.

00:22:26.476 --> 00:22:28.816 A:middle
You can just look through
the supported formats array,

00:22:28.816 --> 00:22:32.516 A:middle
and see what the field of
view is, and it's expressed

00:22:32.516 --> 00:22:34.916 A:middle
in degrees, and this is the
horizontal field of view.

00:22:36.366 --> 00:22:39.626 A:middle
Also it tells you whether a
given sensor format supports

00:22:39.626 --> 00:22:42.736 A:middle
video stabilization, so that
later when you enable it

00:22:42.736 --> 00:22:45.866 A:middle
on the connection, you can
know if it's going to succeed,

00:22:45.866 --> 00:22:49.156 A:middle
if it's going to turn
on stabilization or not.

00:22:49.606 --> 00:22:52.486 A:middle
You can also look through the
supported frame rate ranges,

00:22:52.486 --> 00:22:55.756 A:middle
such as I support 1 through
30 frames per second.

00:22:56.726 --> 00:22:59.896 A:middle
And there's something called
video binned, which you may

00:22:59.896 --> 00:23:00.816 A:middle
or may not have heard of.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:22:59.896 --> 00:23:00.816 A:middle
or may not have heard of.

00:23:00.876 --> 00:23:05.326 A:middle
This is sort of a
sensor-specific keyword.

00:23:05.746 --> 00:23:10.016 A:middle
And binning means taking
groups of neighboring pixels

00:23:10.016 --> 00:23:12.786 A:middle
and binning them together,
sort of averaging them.

00:23:13.086 --> 00:23:16.656 A:middle
And it's a means of
reducing the resolution,

00:23:16.656 --> 00:23:17.686 A:middle
reducing the throughput,

00:23:17.896 --> 00:23:19.476 A:middle
but without reducing
the field of view.

00:23:19.476 --> 00:23:21.866 A:middle
Let me give you an
example of it.

00:23:22.936 --> 00:23:26.986 A:middle
Going back to the iPhone 5 back
facing camera, we have two 1280

00:23:26.986 --> 00:23:29.446 A:middle
by 720 modes available.

00:23:30.006 --> 00:23:32.536 A:middle
Previously we only let you
use the 1 through 30 one.

00:23:33.196 --> 00:23:36.066 A:middle
But the 1 through 60 one has
almost an identical field

00:23:36.066 --> 00:23:40.466 A:middle
of view, so you're not really
losing any depth of field.

00:23:41.046 --> 00:23:43.946 A:middle
Instead, one of them is
binned and one is non-binned.

00:23:44.266 --> 00:23:46.176 A:middle
If you'd like to read
more about what this means

00:23:46.176 --> 00:23:48.086 A:middle
and the different image
characteristics of binned

00:23:48.086 --> 00:23:51.446 A:middle
versus non-binned, I encourage
you to go do a web search

00:23:51.446 --> 00:23:55.436 A:middle
for sensor pixel binning,
and read all about it.

00:23:55.906 --> 00:23:58.786 A:middle
So some guidance about when
to use one over the other.

00:23:59.336 --> 00:24:03.486 A:middle
The session presets setting
mechanism is not deprecated,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:23:59.336 --> 00:24:03.486 A:middle
The session presets setting
mechanism is not deprecated,

00:24:03.486 --> 00:24:04.586 A:middle
it's not going away.

00:24:04.886 --> 00:24:07.986 A:middle
It's still a good one to
use, because it knows how

00:24:07.986 --> 00:24:10.246 A:middle
to optimally configure
inputs and outputs,

00:24:10.526 --> 00:24:11.936 A:middle
so it gives you the
best bang for the buck.

00:24:11.936 --> 00:24:13.886 A:middle
It's just one call and it
does everything for you.

00:24:15.486 --> 00:24:19.006 A:middle
But you should use the new
set active format means

00:24:19.006 --> 00:24:21.806 A:middle
of configuration if you
need a specific format,

00:24:21.806 --> 00:24:25.306 A:middle
such as the 60 frames per second
format, or if you're looking

00:24:25.306 --> 00:24:26.826 A:middle
for a specific field of view,

00:24:26.826 --> 00:24:29.576 A:middle
or if you need those full
resolution video data output

00:24:29.576 --> 00:24:31.566 A:middle
buffers, this is the
only way to do that.

00:24:33.136 --> 00:24:34.616 A:middle
Alright, I think we've
talked that to death.

00:24:35.216 --> 00:24:37.926 A:middle
Let's move on to video zoom,
and to do that I'd like to bring

00:24:37.926 --> 00:24:39.416 A:middle
up Ethan Tira-Thompson.

00:24:39.786 --> 00:24:40.056 A:middle
Thank you.

00:24:40.056 --> 00:24:40.166 A:middle
[ Applause ]

00:24:40.166 --> 00:24:44.416 A:middle
>> Hi everyone.

00:24:44.916 --> 00:24:47.336 A:middle
I'm very excited to talk
to you today about zoom.

00:24:47.706 --> 00:24:48.866 A:middle
I hope that perked you up,

00:24:48.906 --> 00:24:51.696 A:middle
because we've got some exciting
stuff here, and I think a lot

00:24:51.696 --> 00:24:54.846 A:middle
of you will want to
take advantage of it.

00:24:54.846 --> 00:24:57.556 A:middle
I'd like to start by
reviewing our current API,

00:24:57.556 --> 00:24:59.536 A:middle
which is the video
scale and crop factor

00:24:59.896 --> 00:25:01.606 A:middle
of the AV capture connection.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:24:59.896 --> 00:25:01.606 A:middle
of the AV capture connection.

00:25:02.006 --> 00:25:04.386 A:middle
Apparently this only applies
to still image outputs,

00:25:04.386 --> 00:25:06.926 A:middle
so you could enlarge an image
by setting this property.

00:25:07.436 --> 00:25:10.106 A:middle
And typically then you
would also apply a transform

00:25:10.106 --> 00:25:13.126 A:middle
to the preview layer so that
the user gets some feedback

00:25:13.126 --> 00:25:14.536 A:middle
as to how much zoom
has been applied.

00:25:15.036 --> 00:25:16.496 A:middle
So that would look something

00:25:16.496 --> 00:25:17.796 A:middle
like this screenshot
on the left.

00:25:18.726 --> 00:25:20.096 A:middle
And this is not being
deprecated,

00:25:20.096 --> 00:25:21.126 A:middle
so this is still available.

00:25:21.576 --> 00:25:27.226 A:middle
However, we're introducing a
new property simply called video

00:25:27.226 --> 00:25:29.726 A:middle
zoom factor, which is on
the AV capture device.

00:25:29.726 --> 00:25:31.756 A:middle
So this is at the
root of the session,

00:25:31.756 --> 00:25:34.086 A:middle
and applies to all image
outputs, including the preview.

00:25:34.086 --> 00:25:37.056 A:middle
So by setting this one
factor, you'll get a preview,

00:25:37.056 --> 00:25:39.416 A:middle
which is enlarged,
and also much sharper.

00:25:40.626 --> 00:25:43.896 A:middle
So to look under the hood and
let you know how this works,

00:25:43.896 --> 00:25:46.806 A:middle
let's go back to our
architecture diagram,

00:25:46.806 --> 00:25:49.886 A:middle
and we have our video
scale and crop factor

00:25:49.886 --> 00:25:51.176 A:middle
on the AV capture connection.

00:25:52.106 --> 00:25:54.746 A:middle
And notice this is only applying
to the still image output,

00:25:54.746 --> 00:25:56.076 A:middle
and again this is still there.

00:25:56.726 --> 00:26:00.636 A:middle
However, our new property up on
the capture device is applying

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:25:56.726 --> 00:26:00.636 A:middle
However, our new property up on
the capture device is applying

00:26:00.636 --> 00:26:03.596 A:middle
to all the image outputs,
including some not shown here,

00:26:03.596 --> 00:26:05.926 A:middle
such as the meta data output
and movie file output.

00:26:06.436 --> 00:26:09.726 A:middle
And because this is at
the root of the session,

00:26:09.726 --> 00:26:10.846 A:middle
we can do some interesting
things

00:26:10.846 --> 00:26:11.836 A:middle
with the image processing.

00:26:12.986 --> 00:26:15.096 A:middle
Normally when we're getting
an image from the sensor,

00:26:15.096 --> 00:26:16.516 A:middle
it's at the full
photo resolution,

00:26:16.516 --> 00:26:18.116 A:middle
it's the maximum
resolution of the sensor.

00:26:18.696 --> 00:26:21.906 A:middle
However, video resolutions
that we output, like 1080p,

00:26:21.906 --> 00:26:22.936 A:middle
are a lower resolution.

00:26:22.936 --> 00:26:25.666 A:middle
So we must scale down
the image in order

00:26:25.666 --> 00:26:26.916 A:middle
to get to that resolution.

00:26:27.846 --> 00:26:29.616 A:middle
Now if we want to
enlarge the image,

00:26:29.926 --> 00:26:33.276 A:middle
instead of upscaling the
video that we're outputting,

00:26:33.736 --> 00:26:36.396 A:middle
let's just crop the image
and not downscale as much.

00:26:37.146 --> 00:26:39.066 A:middle
This means that you'll be
getting a larger output,

00:26:39.326 --> 00:26:40.316 A:middle
without actually --

00:26:40.766 --> 00:26:43.996 A:middle
with retaining the original
detail that's coming

00:26:43.996 --> 00:26:44.616 A:middle
from the sensor.

00:26:45.116 --> 00:26:48.206 A:middle
Of course we can also
crop tighter than that.

00:26:48.556 --> 00:26:51.856 A:middle
So once we are requesting
a smaller source area

00:26:51.856 --> 00:26:54.776 A:middle
than the output, then we need
to upscale, and that's fine.

00:26:55.876 --> 00:26:57.676 A:middle
We have a property to let
you know when this is going

00:26:57.676 --> 00:26:58.936 A:middle
to happen, and this
is a property

00:26:58.936 --> 00:27:01.016 A:middle
of the new AV capture
device format

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:26:58.936 --> 00:27:01.016 A:middle
of the new AV capture
device format

00:27:01.016 --> 00:27:02.396 A:middle
that Brad was just
talking about.

00:27:02.986 --> 00:27:04.466 A:middle
So you can check
for each format,

00:27:04.466 --> 00:27:07.726 A:middle
depending on the resolution
of the video that's going

00:27:07.726 --> 00:27:11.016 A:middle
to be returned, that will
adjust how much upscaling --

00:27:11.116 --> 00:27:12.936 A:middle
the threshold before
you hit upscaling.

00:27:13.766 --> 00:27:16.056 A:middle
So you can check the property
for each format and know

00:27:16.636 --> 00:27:17.896 A:middle
when you're going to
encounter this range.

00:27:18.276 --> 00:27:22.706 A:middle
To illustrate this, we have
a little animation here.

00:27:22.706 --> 00:27:25.686 A:middle
So the purple box would
be the same dimensions

00:27:25.686 --> 00:27:29.866 A:middle
as the video output, and the
red box would be the maximum say

00:27:29.866 --> 00:27:30.966 A:middle
that you want to zoom down to.

00:27:31.426 --> 00:27:34.746 A:middle
And as we increase the zoom
factor, we cross that threshold,

00:27:34.746 --> 00:27:37.186 A:middle
so now we're in the upscaling
range as zoom back out.

00:27:37.586 --> 00:27:39.546 A:middle
Now we enter the
crop zoom section,

00:27:39.546 --> 00:27:41.376 A:middle
so that's just cropping
on the sensor.

00:27:41.376 --> 00:27:43.876 A:middle
And you kind of just go back
and forth across the transition.

00:27:43.876 --> 00:27:44.756 A:middle
You don't actually need to know

00:27:44.756 --> 00:27:47.356 A:middle
where that threshold
is, but it's there.

00:27:47.956 --> 00:27:52.486 A:middle
So to talk a little bit
about the API behind this,

00:27:53.086 --> 00:27:57.296 A:middle
there's the aforementioned video
zoom factor, which is applying

00:27:57.296 --> 00:27:58.496 A:middle
to all the image outputs.

00:27:59.226 --> 00:28:01.916 A:middle
And it's up to a maximum value,
which is also a method --

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:27:59.226 --> 00:28:01.916 A:middle
And it's up to a maximum value,
which is also a method --

00:28:02.046 --> 00:28:04.816 A:middle
property of the AV
capture device format.

00:28:05.316 --> 00:28:07.286 A:middle
So if you just care
about the current format,

00:28:07.286 --> 00:28:10.606 A:middle
the active sensor format,
there's a property,

00:28:10.606 --> 00:28:12.066 A:middle
the device active format,

00:28:12.066 --> 00:28:13.746 A:middle
and then you can check
the max zoom factor

00:28:13.746 --> 00:28:14.646 A:middle
of the active format,

00:28:14.716 --> 00:28:16.886 A:middle
and that'll let you know
what the current maximum zoom

00:28:17.036 --> 00:28:18.156 A:middle
that you can use is.

00:28:18.956 --> 00:28:22.246 A:middle
The device coordinates
are a little interesting

00:28:22.246 --> 00:28:24.666 A:middle
because they are going to
stay fixed through the frame.

00:28:24.736 --> 00:28:26.656 A:middle
You can think of this as an
optical zoom at the front

00:28:26.656 --> 00:28:29.466 A:middle
of the pipeline, the rest of
the pipeline has already been --

00:28:29.466 --> 00:28:30.506 A:middle
the image has already
been cropped.

00:28:30.506 --> 00:28:32.236 A:middle
And so all the device
coordinates are going

00:28:32.236 --> 00:28:35.006 A:middle
to be applying to the
image that is being shown.

00:28:35.926 --> 00:28:40.096 A:middle
So for instance, if we
set a focus interest point

00:28:40.386 --> 00:28:42.686 A:middle
on the soccer ball in the
corner, and then we zoom in,

00:28:43.466 --> 00:28:46.016 A:middle
as the image scales, the soccer
ball will go out of the field

00:28:46.016 --> 00:28:48.376 A:middle
of view, but that focus
point's going to stay fixed

00:28:48.376 --> 00:28:49.476 A:middle
in the corner where you set it.

00:28:49.476 --> 00:28:50.606 A:middle
Those corners are static.

00:28:51.826 --> 00:28:54.986 A:middle
Similarly, if the -- if you
have face detection enabled,

00:28:55.306 --> 00:28:58.256 A:middle
the faces will be returned
as they're being displayed,

00:28:58.256 --> 00:29:00.176 A:middle
and as the face goes out
of the field of view,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:28:58.256 --> 00:29:00.176 A:middle
and as the face goes out
of the field of view,

00:29:00.626 --> 00:29:01.916 A:middle
they will stop being detected.

00:29:02.726 --> 00:29:06.106 A:middle
There's a pre-existing
transform meta data object

00:29:06.106 --> 00:29:08.466 A:middle
for meta data object, which
also helps you coordinate these,

00:29:08.466 --> 00:29:11.526 A:middle
because we return the meta
data and device coordinates,

00:29:11.526 --> 00:29:14.286 A:middle
and if you want to convert it to
the preview layer coordinates,

00:29:14.676 --> 00:29:20.306 A:middle
this pre-existing method
will do that for you.

00:29:20.306 --> 00:29:21.306 A:middle
There's an interesting --

00:29:21.416 --> 00:29:24.396 A:middle
another aspect to this in
that we are now applying zoom

00:29:24.396 --> 00:29:25.906 A:middle
to video outputs.

00:29:26.196 --> 00:29:27.526 A:middle
And there's a temporal
aspect there.

00:29:28.046 --> 00:29:31.336 A:middle
Because we don't
want you to have

00:29:31.336 --> 00:29:34.116 A:middle
to increment the zoom
factor for each frame

00:29:34.116 --> 00:29:37.426 A:middle
as it's being captured, because
you might have some threading

00:29:37.426 --> 00:29:40.186 A:middle
issues, it might be hard to time
and synchronize your threads

00:29:40.186 --> 00:29:42.576 A:middle
and updates with the
capture of frames

00:29:42.576 --> 00:29:45.716 A:middle
as they're being received,
so we can do that internally.

00:29:45.716 --> 00:29:46.836 A:middle
And we have this new method,

00:29:47.126 --> 00:29:49.006 A:middle
ramp to video zoom
factor with rate.

00:29:49.296 --> 00:29:52.886 A:middle
So you can specify the target
factor, and the rate at which

00:29:52.886 --> 00:29:57.446 A:middle
to get there, and then we will
internally increment the zoom

00:29:57.446 --> 00:30:00.596 A:middle
factor on each frame as it's
being captured in real time.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:29:57.446 --> 00:30:00.596 A:middle
factor on each frame as it's
being captured in real time.

00:30:04.016 --> 00:30:06.396 A:middle
There's another method,
cancel video zoom ramp,

00:30:06.636 --> 00:30:08.716 A:middle
so that any time you can
do this interactively.

00:30:08.716 --> 00:30:11.616 A:middle
You can either call ramp
to video zoom factor again

00:30:11.616 --> 00:30:12.936 A:middle
with a new rate or a new target,

00:30:13.286 --> 00:30:16.376 A:middle
or you can just cancel the
current one if the user has --

00:30:17.036 --> 00:30:18.706 A:middle
cancels, you know,
lets go on the button.

00:30:19.256 --> 00:30:24.336 A:middle
And then any changes in the
rate are smoothed further,

00:30:24.646 --> 00:30:28.256 A:middle
so that you don't have any jumpy
transitions within the zooms.

00:30:28.526 --> 00:30:32.956 A:middle
Now rates are a little tricky in
zoom, because the apparent speed

00:30:32.956 --> 00:30:37.266 A:middle
of a zoom is actually determined
by the multiplicative factor

00:30:37.266 --> 00:30:38.996 A:middle
that we're applying, it's
not an additive thing.

00:30:39.646 --> 00:30:42.306 A:middle
So the rate is specified
in powers of 2 per second.

00:30:42.426 --> 00:30:45.146 A:middle
So if you want a consistent
speed of doubling every second,

00:30:45.666 --> 00:30:46.876 A:middle
then you'll set a rate of 1.

00:30:47.276 --> 00:30:49.176 A:middle
When you set a rate of 2,
it'll go twice as fast,

00:30:49.176 --> 00:30:51.976 A:middle
if you set a rate of .5
it'll go half as fast.

00:30:53.216 --> 00:30:56.346 A:middle
What you see here on the right
is the graph showing a rate

00:30:56.346 --> 00:30:56.796 A:middle
of 1.

00:30:56.856 --> 00:30:59.056 A:middle
So essentially every
second we double the zoom.

00:30:59.616 --> 00:31:03.256 A:middle
And so we go from 1 to 2,
2 to 4, 4 to 8, and so on.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:30:59.616 --> 00:31:03.256 A:middle
And so we go from 1 to 2,
2 to 4, 4 to 8, and so on.

00:31:03.616 --> 00:31:06.336 A:middle
In practice you'll probably
want to stay around 1 to 3

00:31:06.336 --> 00:31:09.016 A:middle
for comfortable ranges, but
of course your app is welcome

00:31:09.016 --> 00:31:12.066 A:middle
to do whatever it wants.

00:31:12.126 --> 00:31:15.126 A:middle
To demonstrate this I'm going
to bring up Rob Simutis,

00:31:15.186 --> 00:31:18.116 A:middle
and he's going to
help me demo SoZoomy.

00:31:18.646 --> 00:31:20.746 A:middle
There we go.

00:31:21.266 --> 00:31:24.926 A:middle
Alright, so we're going to start

00:31:24.926 --> 00:31:27.186 A:middle
with a mode called
constant face size.

00:31:27.626 --> 00:31:30.146 A:middle
So there's a cinematic
effect called a dolly zoom,

00:31:30.536 --> 00:31:33.406 A:middle
where the zoom is changed

00:31:33.406 --> 00:31:37.296 A:middle
to keep a target object
a consistent size,

00:31:37.566 --> 00:31:38.806 A:middle
while the object is moving,

00:31:38.876 --> 00:31:41.706 A:middle
which causes the
background to shift.

00:31:42.136 --> 00:31:45.536 A:middle
So if I have Rob start walking
forward, tap on his face,

00:31:46.286 --> 00:31:49.206 A:middle
then if there's anything
in the background,

00:31:49.206 --> 00:31:51.236 A:middle
which it's mostly dark so
you'll have trouble seeing this,

00:31:52.486 --> 00:31:54.256 A:middle
but yeah, let's have
him try that again.

00:31:54.406 --> 00:31:57.146 A:middle
Keep backing up, and you can
kind of see -- there you go.

00:31:57.326 --> 00:31:58.256 A:middle
Let's see, I'll try again.

00:31:58.436 --> 00:31:59.326 A:middle
And we're losing the face.

00:31:59.356 --> 00:32:01.866 A:middle
But anyway, so that's
the constant face size.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:31:59.356 --> 00:32:01.866 A:middle
But anyway, so that's
the constant face size.

00:32:02.216 --> 00:32:04.736 A:middle
There's another aspect
of this demo,

00:32:04.736 --> 00:32:08.306 A:middle
which I hope you'll recognize,
if he turns around and I zoom

00:32:08.306 --> 00:32:09.976 A:middle
in a little bit,
let's get a good size.

00:32:10.706 --> 00:32:13.376 A:middle
And let's go.

00:32:13.376 --> 00:32:14.906 A:middle
[ Music ]

00:32:14.906 --> 00:32:16.436 A:middle
[ Applause ]

00:32:16.436 --> 00:32:22.646 A:middle
So I think people have
a lot of fun with that.

00:32:22.766 --> 00:32:26.296 A:middle
Let's take a look at the
code that's running in this.

00:32:26.296 --> 00:32:27.716 A:middle
First off if you
notice there's a slider,

00:32:27.716 --> 00:32:29.086 A:middle
which I was using
to adjust the zoom.

00:32:29.086 --> 00:32:31.516 A:middle
And I was actually accounting
for that exponential growth

00:32:31.516 --> 00:32:35.036 A:middle
in the zoom, and the formula
for that is there on the slide.

00:32:35.636 --> 00:32:38.856 A:middle
So what we do is you don't
want to directly take --

00:32:38.856 --> 00:32:41.406 A:middle
say your slider's going
from 0 to 1, you don't want

00:32:41.406 --> 00:32:43.506 A:middle
to directly send that
right into the zoom factor,

00:32:43.506 --> 00:32:45.996 A:middle
because that'll mean that it's
very sensitive on the wide end

00:32:45.996 --> 00:32:48.056 A:middle
of the zoom, it'll
be less sensitive

00:32:48.206 --> 00:32:49.706 A:middle
on the telephoto
end of the zoom.

00:32:50.516 --> 00:32:53.686 A:middle
By taking our maximum zoom
that you want to achieve,

00:32:54.126 --> 00:32:57.716 A:middle
and taking that to the power
of the current 0 to 1 target,

00:32:58.176 --> 00:33:00.176 A:middle
that'll give you that
exponential growth

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:32:58.176 --> 00:33:00.176 A:middle
that'll give you that
exponential growth

00:33:00.176 --> 00:33:02.426 A:middle
over the range, and so
you get a linear feel

00:33:02.426 --> 00:33:04.026 A:middle
to the actual zoom motion.

00:33:04.536 --> 00:33:09.026 A:middle
And of course remember to lock
the configuration and unlock it

00:33:09.426 --> 00:33:10.966 A:middle
when adjusting these values.

00:33:11.306 --> 00:33:16.366 A:middle
Now for speed control, such as a
jog dial, or maybe you just want

00:33:16.366 --> 00:33:18.056 A:middle
to have a button you
hold down to zoom in,

00:33:19.406 --> 00:33:22.496 A:middle
you'll typically want to set
the target either to the minimum

00:33:22.496 --> 00:33:24.726 A:middle
or maximum zoom, and
then you'll be --

00:33:24.726 --> 00:33:26.506 A:middle
the user will be interactively
controlling the rate.

00:33:27.246 --> 00:33:29.886 A:middle
So in this case, we look
to see if we're zooming in,

00:33:29.886 --> 00:33:31.086 A:middle
then we go to the maximum zoom,

00:33:31.086 --> 00:33:32.526 A:middle
otherwise we go to
the minimum zoom.

00:33:32.816 --> 00:33:35.046 A:middle
And we pass this to ramp
to video zoom factor,

00:33:35.396 --> 00:33:37.126 A:middle
and then you specify some rate.

00:33:37.686 --> 00:33:40.776 A:middle
And then at any point if
the user cancels the zoom,

00:33:41.026 --> 00:33:44.006 A:middle
then you cancel the video
zoom ramp, and we will ease

00:33:44.006 --> 00:33:46.816 A:middle
out of the ramp so that
it looks very silky.

00:33:50.136 --> 00:33:53.936 A:middle
In summary, to compare it to
the video scale and crop factor,

00:33:53.976 --> 00:33:56.476 A:middle
they both apply to
still image output,

00:33:56.606 --> 00:33:58.396 A:middle
but our new video
zoom factor applies

00:33:58.396 --> 00:33:59.686 A:middle
to all the image outputs.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:34:00.206 --> 00:34:02.296 A:middle
You can set the zoom
factor directly,

00:34:02.756 --> 00:34:05.346 A:middle
but the new video
zoom factor API

00:34:05.846 --> 00:34:08.565 A:middle
on the AV capture device lets
you set the zoom rate as well.

00:34:10.065 --> 00:34:12.266 A:middle
And this is currently
available on the iPhone 5

00:34:12.266 --> 00:34:13.956 A:middle
and iPod Touch 5th generation.

00:34:14.456 --> 00:34:17.326 A:middle
And with that I'd like
to welcome Rob back

00:34:17.326 --> 00:34:19.476 A:middle
up to present machine
readable codes.

00:34:19.476 --> 00:34:20.065 A:middle
[ Applause ]

00:34:20.065 --> 00:34:22.216 A:middle
>> Thank you, Ethan.

00:34:22.485 --> 00:34:24.206 A:middle
Hi, I'm Rob Simutis,
and I'm also

00:34:24.206 --> 00:34:25.286 A:middle
with core media engineering.

00:34:25.505 --> 00:34:26.706 A:middle
I'm here to talk to you today

00:34:26.706 --> 00:34:30.366 A:middle
about machine readable code
detection, which is a formal way

00:34:30.366 --> 00:34:31.976 A:middle
of talking about
barcode scanning.

00:34:33.396 --> 00:34:36.706 A:middle
We've introduced this in iOS 7,

00:34:36.956 --> 00:34:39.696 A:middle
but to do real-time machine
readable code detection

00:34:39.866 --> 00:34:42.016 A:middle
for one-dimensional and
two-dimensional barcodes,

00:34:42.616 --> 00:34:46.795 A:middle
up to four at a time on both
the front and back cameras

00:34:47.226 --> 00:34:51.646 A:middle
on all supported iOS 7 hardware
that has a camera on it.

00:34:52.065 --> 00:34:55.416 A:middle
You can see this in
action today in the seed

00:34:55.626 --> 00:34:57.786 A:middle
with the passbook application.

00:34:58.406 --> 00:35:01.506 A:middle
In the upper right-hand corner,
there's now a scan code button.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:34:58.406 --> 00:35:01.506 A:middle
In the upper right-hand corner,
there's now a scan code button.

00:35:01.656 --> 00:35:07.156 A:middle
So when you press that, you
get a view to scan in codes.

00:35:07.156 --> 00:35:11.506 A:middle
These are PDF417 or QR codes,
or Aztec codes that are

00:35:11.506 --> 00:35:13.436 A:middle
in the passbook format,
and they pull directly

00:35:13.436 --> 00:35:14.106 A:middle
into your passbook.

00:35:15.486 --> 00:35:18.176 A:middle
Now beyond just those types,
we actually support a number

00:35:18.176 --> 00:35:20.826 A:middle
of different types of
machine readable codes,

00:35:20.826 --> 00:35:25.276 A:middle
or symbologies -- UPC-E often
found in products in stores,

00:35:25.326 --> 00:35:30.246 A:middle
EAN-8 and 13 commonly found over
in Europe, code 39, code 93,

00:35:30.246 --> 00:35:33.376 A:middle
and code 128, some other types
of one-dimensional codes.

00:35:34.776 --> 00:35:39.006 A:middle
In the 2D space we support
three types, PDF417 often found

00:35:39.006 --> 00:35:42.686 A:middle
on airline passes, QR
codes found on buildings

00:35:42.686 --> 00:35:45.686 A:middle
and billboards, and corn
fields in some cases,

00:35:46.256 --> 00:35:49.836 A:middle
and Aztec which you often find
on packages that you ship.

00:35:51.016 --> 00:35:54.516 A:middle
So we'll demo this
in action today,

00:35:54.516 --> 00:35:56.306 A:middle
and I'll invite Ethan
to come back up.

00:35:56.306 --> 00:36:00.356 A:middle
And we have a sample
app we call QRchestra.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:35:56.306 --> 00:36:00.356 A:middle
And we have a sample
app we call QRchestra.

00:36:01.006 --> 00:36:04.206 A:middle
So Ethan has a version
of the application,

00:36:05.026 --> 00:36:07.846 A:middle
and his view has a
bunch of QR codes on it.

00:36:08.976 --> 00:36:12.746 A:middle
And each of these contains
a value that is a midi note.

00:36:13.606 --> 00:36:15.626 A:middle
And I'm just going to
have the scanner on mine,

00:36:15.626 --> 00:36:20.116 A:middle
if I can hold it steady.

00:36:20.116 --> 00:36:24.156 A:middle
[Several Beeps] So each of
the QR codes is a midi note,

00:36:24.296 --> 00:36:27.766 A:middle
and we translate that into
a string, and then we run it

00:36:27.766 --> 00:36:29.276 A:middle
through a synthesizer,
and then out.

00:36:29.996 --> 00:36:36.536 A:middle
And the detection's failing
'cause I'm shaking a little.

00:36:37.156 --> 00:36:38.146 A:middle
[Several Beeps] But
it allows you

00:36:38.146 --> 00:36:42.556 A:middle
to have a QRchestra
right in front of you.

00:36:43.506 --> 00:36:44.026 A:middle
There we go.

00:36:44.026 --> 00:36:44.093 A:middle
[ Beeping ]

00:36:44.093 --> 00:36:51.636 A:middle
Alright, there we go.

00:36:52.286 --> 00:36:52.906 A:middle
Thanks, Ethan.

00:36:53.336 --> 00:36:55.136 A:middle
So a couple of notes.

00:36:55.186 --> 00:36:57.036 A:middle
You'll be able to download
this with sample code along

00:36:57.036 --> 00:36:59.746 A:middle
with our slides and the other
demos that we have today.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:37:00.386 --> 00:37:03.256 A:middle
But those QR codes were actually
being generated on the fly,

00:37:03.256 --> 00:37:04.436 A:middle
they weren't fixed images.

00:37:04.496 --> 00:37:07.156 A:middle
And those are being done
with a new core image filter

00:37:07.156 --> 00:37:09.696 A:middle
that is available in iOS 7, so
you can go and check out how

00:37:09.696 --> 00:37:17.226 A:middle
to make your own QR
codes on the fly.

00:37:17.226 --> 00:37:17.293 A:middle
[ Applause ]

00:37:17.293 --> 00:37:19.286 A:middle
So getting into the
programming model,

00:37:19.286 --> 00:37:23.176 A:middle
in iOS 6 we introduced the AV
capture meta data output class,

00:37:23.176 --> 00:37:25.636 A:middle
and this was originally done
for face detection data.

00:37:26.036 --> 00:37:30.066 A:middle
So we've expanded that, and this
is how we get bar codes out.

00:37:30.426 --> 00:37:32.536 A:middle
Normally you add it to
your capture session,

00:37:32.536 --> 00:37:35.226 A:middle
and it has a connection
to your capture device,

00:37:35.226 --> 00:37:36.716 A:middle
and so this would be
your video device.

00:37:36.746 --> 00:37:41.166 A:middle
And then your application
implements a meta data output

00:37:41.166 --> 00:37:42.306 A:middle
objects delegate.

00:37:42.856 --> 00:37:46.536 A:middle
And as we detect barcodes,
machine readable codes,

00:37:46.626 --> 00:37:48.276 A:middle
we will then send an array

00:37:48.276 --> 00:37:51.986 A:middle
of those AV meta data
machine readable code objects

00:37:52.416 --> 00:37:53.206 A:middle
to your delegate.

00:37:54.416 --> 00:37:55.536 A:middle
We'll take a look
at this in code.

00:37:56.326 --> 00:38:00.796 A:middle
First, alloc/init your meta data
output, add it to your session,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:37:56.326 --> 00:38:00.796 A:middle
First, alloc/init your meta data
output, add it to your session,

00:38:02.176 --> 00:38:05.096 A:middle
create your meta data delegate,
along with its dispatch queue,

00:38:06.316 --> 00:38:10.196 A:middle
set it on the output, and
then configure the types

00:38:10.196 --> 00:38:12.046 A:middle
of machine readable codes
that you're interested in.

00:38:12.216 --> 00:38:14.936 A:middle
Here we've set it up to
look for Aztec codes.

00:38:16.966 --> 00:38:18.636 A:middle
Now in your meta
data output delegate,

00:38:18.636 --> 00:38:20.236 A:middle
you implement the
capture output,

00:38:20.546 --> 00:38:23.346 A:middle
didOutputMetadataObjects
fromConnection API.

00:38:24.156 --> 00:38:27.066 A:middle
And this will get
callbacks periodically,

00:38:27.066 --> 00:38:29.526 A:middle
and you'll receive an array
of AV meta data objects.

00:38:29.886 --> 00:38:32.106 A:middle
So because we're listening for
machine readable code objects,

00:38:32.426 --> 00:38:33.896 A:middle
we'll look and make
sure that they're

00:38:33.896 --> 00:38:37.126 A:middle
of the class AV meta data
machine readable code object.

00:38:37.686 --> 00:38:39.926 A:middle
And once we have one of
those, we can retain it

00:38:39.926 --> 00:38:46.066 A:middle
or use it further at that point.

00:38:46.246 --> 00:38:49.426 A:middle
So let's take a look now at
what a machine readable code

00:38:49.426 --> 00:38:50.726 A:middle
object contains.

00:38:50.886 --> 00:38:54.226 A:middle
It contains a bounds property,
the bounding rectangle

00:38:54.466 --> 00:38:57.196 A:middle
that it's sitting within,
an array of corners

00:38:57.196 --> 00:38:59.626 A:middle
which are CG points
represented as dictionaries.

00:38:59.626 --> 00:39:00.966 A:middle
We'll cover the difference
between bounds

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:38:59.626 --> 00:39:00.966 A:middle
We'll cover the difference
between bounds

00:39:00.966 --> 00:39:02.876 A:middle
and corners here
in a later slide.

00:39:03.656 --> 00:39:07.746 A:middle
It also has a type property, so
it indicates whether it's UPC-E

00:39:07.746 --> 00:39:09.756 A:middle
or QR, EAN-8, etcetera.

00:39:11.216 --> 00:39:13.236 A:middle
And then finally the most
important one is the string

00:39:13.236 --> 00:39:13.886 A:middle
value property.

00:39:14.546 --> 00:39:17.516 A:middle
This is our best effort
attempt to decode the payload

00:39:17.516 --> 00:39:18.936 A:middle
into a string that
you can make use of.

00:39:19.776 --> 00:39:21.896 A:middle
Now I say best effort,
because in certain cases

00:39:21.896 --> 00:39:26.636 A:middle
with some barcodes, maybe it's
damaged beyond recognition,

00:39:26.636 --> 00:39:30.146 A:middle
but we can still tell maybe that
it's a QR code or Aztec code.

00:39:30.606 --> 00:39:32.666 A:middle
This property might return nil,

00:39:32.756 --> 00:39:37.316 A:middle
so your code should be
prepared to handle this.

00:39:37.466 --> 00:39:38.746 A:middle
Now, bounds versus corners.

00:39:39.246 --> 00:39:41.566 A:middle
So let's say you've got
your QR code scanning app,

00:39:41.566 --> 00:39:46.146 A:middle
and your user is holding it
off center, and it's sort

00:39:46.146 --> 00:39:49.606 A:middle
of off axis, and the
bounds property's going

00:39:49.606 --> 00:39:52.266 A:middle
to come back as a CG rect.

00:39:52.266 --> 00:39:56.586 A:middle
It is a rectangle that is
axis-aligned with the image.

00:39:57.626 --> 00:40:00.156 A:middle
But your corners are going
to come back as the corners

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:39:57.626 --> 00:40:00.156 A:middle
But your corners are going
to come back as the corners

00:40:00.156 --> 00:40:02.836 A:middle
of where the barcode were
detected, and so this allows you

00:40:02.836 --> 00:40:05.006 A:middle
to draw a much tighter
fitting overlay

00:40:05.006 --> 00:40:06.536 A:middle
of where the barcode was found,

00:40:06.676 --> 00:40:08.796 A:middle
so you can give a better
representation onscreen.

00:40:09.406 --> 00:40:13.596 A:middle
So, performance considerations.

00:40:13.596 --> 00:40:16.046 A:middle
These are some things you
want to take into account

00:40:16.336 --> 00:40:18.556 A:middle
for your application to get
the best user experience.

00:40:19.936 --> 00:40:22.606 A:middle
To start off, you should
really just enable the codes

00:40:22.606 --> 00:40:24.466 A:middle
that you're interested
in finding.

00:40:24.746 --> 00:40:29.036 A:middle
You generally don't want to
turn all types of barcodes on,

00:40:29.256 --> 00:40:32.016 A:middle
because this takes more
CPU, more processing power,

00:40:32.426 --> 00:40:33.446 A:middle
and it hurts battery life.

00:40:33.446 --> 00:40:36.266 A:middle
So depending on your
application's needs,

00:40:36.266 --> 00:40:39.016 A:middle
just enable the codes
that you're interested in.

00:40:39.016 --> 00:40:44.076 A:middle
You can also make use of a new
AV capture meta data output rect

00:40:44.076 --> 00:40:44.876 A:middle
of interest property.

00:40:44.986 --> 00:40:47.026 A:middle
We've introduced this
in iOS 7, and I'll talk

00:40:47.026 --> 00:40:49.466 A:middle
about this in a little bit.

00:40:49.586 --> 00:40:51.216 A:middle
You also want to pick
the right session preset

00:40:51.216 --> 00:40:52.096 A:middle
for your use case.

00:40:52.256 --> 00:40:55.976 A:middle
Most applications can
start off with the 640

00:40:55.976 --> 00:40:57.856 A:middle
by 480 session preset.

00:40:58.406 --> 00:41:00.396 A:middle
Depending on the density of
the codes, you might want

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:40:58.406 --> 00:41:00.396 A:middle
Depending on the density of
the codes, you might want

00:41:00.396 --> 00:41:02.656 A:middle
to go higher or lower,
maybe up 720p,

00:41:02.656 --> 00:41:05.296 A:middle
or something below 640 by 480.

00:41:05.296 --> 00:41:09.926 A:middle
But you can start there, and
adjust as your testing dictates.

00:41:10.476 --> 00:41:14.376 A:middle
You could also consider using a
new auto focus range restriction

00:41:14.376 --> 00:41:18.206 A:middle
API that can help you get faster
performance for auto focus,

00:41:18.206 --> 00:41:22.416 A:middle
and Brad's going to cover
this a little bit later.

00:41:22.666 --> 00:41:24.516 A:middle
And as Ethan said, you
could also make use

00:41:24.516 --> 00:41:27.436 A:middle
of the new zoom APIs to
get the barcode right,

00:41:27.436 --> 00:41:29.506 A:middle
nice and tight in your image.

00:41:29.546 --> 00:41:33.986 A:middle
So let's talk about
requesting the codes you want.

00:41:34.576 --> 00:41:37.166 A:middle
As before in iOS 6, you make use

00:41:37.166 --> 00:41:39.826 A:middle
of the AV capture meta data
output meta data object

00:41:39.866 --> 00:41:40.596 A:middle
types property.

00:41:40.866 --> 00:41:43.726 A:middle
And this is an array of string
constants, these are defined

00:41:43.726 --> 00:41:46.566 A:middle
in AV MetadataObject.h, you
can check out that header.

00:41:47.936 --> 00:41:53.006 A:middle
Now normally you -- with
iOS 6 we had behavior

00:41:53.006 --> 00:41:56.536 A:middle
where all meta data types
would be turned on by default.

00:41:56.986 --> 00:41:58.726 A:middle
This was fine when
we just had faces,

00:41:59.096 --> 00:42:02.616 A:middle
but now we're introduced a
new type for each symbology

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:41:59.096 --> 00:42:02.616 A:middle
but now we're introduced a
new type for each symbology

00:42:02.616 --> 00:42:04.146 A:middle
of machine readable
code that we detect.

00:42:04.146 --> 00:42:06.976 A:middle
So that's really not
the ideal situation.

00:42:07.386 --> 00:42:09.986 A:middle
So in iOS 7 you need
to explicitly opt

00:42:09.986 --> 00:42:12.176 A:middle
in to all desired meta
data object types.

00:42:12.686 --> 00:42:15.526 A:middle
If your app was built and
linked prior to iOS 7,

00:42:15.766 --> 00:42:18.366 A:middle
you get the old behavior
of face data only,

00:42:19.006 --> 00:42:20.626 A:middle
if that device supports it.

00:42:22.536 --> 00:42:25.166 A:middle
So here's an example of what
you probably want to avoid.

00:42:26.006 --> 00:42:27.196 A:middle
You can make use

00:42:27.196 --> 00:42:29.526 A:middle
of the available meta
data object types method

00:42:29.646 --> 00:42:31.866 A:middle
on the meta data output,
which is the array

00:42:31.866 --> 00:42:35.056 A:middle
of all the supported types
that that device will support,

00:42:35.056 --> 00:42:36.756 A:middle
and then you set it on
the meta data output.

00:42:36.966 --> 00:42:38.406 A:middle
This would enable
everything by default.

00:42:39.456 --> 00:42:41.156 A:middle
Most apps should avoid this.

00:42:41.806 --> 00:42:46.046 A:middle
Instead, do something like
specifying your array of types,

00:42:46.236 --> 00:42:49.936 A:middle
and here we're going to look
for faces, as well as QR codes,

00:42:49.936 --> 00:42:51.916 A:middle
so this is the way we
prefer you to do it.

00:42:51.916 --> 00:42:53.416 A:middle
Specify them as you need.

00:42:54.446 --> 00:43:00.336 A:middle
So here, now I can find
faces within my QR code.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:42:54.446 --> 00:43:00.336 A:middle
So here, now I can find
faces within my QR code.

00:43:00.336 --> 00:43:03.846 A:middle
Alright, let's talk about
limiting your search area.

00:43:04.756 --> 00:43:07.176 A:middle
The new property AV capture
meta data output rect

00:43:07.176 --> 00:43:09.536 A:middle
of interest was introduced,
and this is going

00:43:09.536 --> 00:43:11.176 A:middle
to help you narrow
the search window

00:43:11.176 --> 00:43:13.536 A:middle
for where you're scanning
for your meta data.

00:43:14.466 --> 00:43:16.486 A:middle
This works on faces
as well as barcodes.

00:43:17.196 --> 00:43:20.606 A:middle
By default, it's the
entire size of the image,

00:43:20.606 --> 00:43:22.856 A:middle
but you can restrict
that to a smaller portion

00:43:23.176 --> 00:43:24.376 A:middle
as your application needs.

00:43:25.436 --> 00:43:29.886 A:middle
And as Ethan talked about, and
also as Brad discussed last year

00:43:29.886 --> 00:43:34.316 A:middle
in WWDC slides, there's some
conversion that you need to keep

00:43:34.316 --> 00:43:37.556 A:middle
in mind when going between the
different coordinate spaces.

00:43:37.836 --> 00:43:40.186 A:middle
So the meta data output
rect of interest is

00:43:40.186 --> 00:43:42.396 A:middle
in the devices coordinate
space, which is different

00:43:42.396 --> 00:43:44.766 A:middle
from your preview layer,
or your video data output

00:43:44.766 --> 00:43:45.486 A:middle
coordinate space.

00:43:45.916 --> 00:43:48.636 A:middle
So we've provided conversion
methods that help you go

00:43:48.636 --> 00:43:49.986 A:middle
between those different
coordinate spaces,

00:43:49.986 --> 00:43:50.816 A:middle
and make it really easy.

00:43:51.296 --> 00:43:54.436 A:middle
Let's look at this
and visualize it.

00:43:54.696 --> 00:43:58.636 A:middle
So here I've got an app that's
doing a scan of a barcode.

00:43:58.636 --> 00:43:59.356 A:middle
You can see the sort

00:43:59.356 --> 00:44:00.866 A:middle
of highlighted region
up near the top.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:43:59.356 --> 00:44:00.866 A:middle
of highlighted region
up near the top.

00:44:01.546 --> 00:44:03.316 A:middle
That's the rect of
interest that I would

00:44:03.316 --> 00:44:04.556 A:middle
like to have in my application.

00:44:05.306 --> 00:44:06.956 A:middle
As far as the video
preview layer's concerned,

00:44:07.656 --> 00:44:11.406 A:middle
its coordinates are
in pixel coordinates,

00:44:11.436 --> 00:44:15.056 A:middle
so the upper left is 0,0, and
the bottom right is 320, 540.

00:44:15.496 --> 00:44:19.116 A:middle
The meta data output,
however, is different.

00:44:19.116 --> 00:44:21.196 A:middle
It's actually rotated
90 degrees,

00:44:21.606 --> 00:44:24.726 A:middle
and its coordinates
are normalized.

00:44:24.726 --> 00:44:27.246 A:middle
They're in scalar
coordinates from 0 to 1,

00:44:27.246 --> 00:44:31.816 A:middle
so 0,0 is the upper left
and 1,1 in the bottom right.

00:44:31.816 --> 00:44:35.746 A:middle
So if we want our rect of
interest to be at 100 pixels

00:44:35.746 --> 00:44:40.706 A:middle
down and 320 by 540, in the meta
data outputs coordinate space

00:44:40.746 --> 00:44:45.336 A:middle
that's .1,0, and the
rectangle size is .4 by 1.0.

00:44:45.766 --> 00:44:46.686 A:middle
So you can see going back

00:44:46.686 --> 00:44:49.126 A:middle
and forth here could be a little
complicated, and it gets tricky

00:44:49.126 --> 00:44:50.856 A:middle
with mirroring and
video gravity,

00:44:50.856 --> 00:44:51.586 A:middle
and things of that nature.

00:44:51.586 --> 00:44:55.006 A:middle
So we've provided the methods
that help you go back and forth.

00:44:56.536 --> 00:44:58.536 A:middle
So when going from the
video preview layer

00:44:58.596 --> 00:45:02.216 A:middle
to the meta data output, you
use the AV capture video preview

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:44:58.596 --> 00:45:02.216 A:middle
to the meta data output, you
use the AV capture video preview

00:45:02.216 --> 00:45:05.966 A:middle
layer meta data output rect
of interest for rect method.

00:45:06.556 --> 00:45:08.726 A:middle
To go the opposite way
from the meta data output

00:45:08.726 --> 00:45:10.006 A:middle
to the video preview layer,

00:45:10.356 --> 00:45:13.696 A:middle
use rect for meta data
output rect of interest.

00:45:13.696 --> 00:45:16.686 A:middle
We'll take a look at this
in code very briefly.

00:45:17.406 --> 00:45:19.606 A:middle
So using the previous example
that I showed you visually,

00:45:20.006 --> 00:45:22.186 A:middle
if I have my CG rect
that are the bounds,

00:45:23.426 --> 00:45:26.866 A:middle
I make my rectangle
that's 100 pixels down,

00:45:26.866 --> 00:45:32.326 A:middle
and it's 150 pixels
high, and then that's

00:45:32.326 --> 00:45:33.406 A:middle
in the preview layer's
coordinates,

00:45:33.466 --> 00:45:34.506 A:middle
so let's go to the devices,

00:45:34.536 --> 00:45:36.586 A:middle
or the meta data
output's coordinates,

00:45:36.916 --> 00:45:38.356 A:middle
and use the conversion method.

00:45:38.356 --> 00:45:41.346 A:middle
And then finally, we'll
set that rect of interest

00:45:41.396 --> 00:45:42.336 A:middle
on our meta data output.

00:45:42.896 --> 00:45:45.896 A:middle
So all of these things
are good to keep in mind

00:45:45.996 --> 00:45:48.246 A:middle
to give your users the
best experience possible

00:45:48.246 --> 00:45:49.766 A:middle
when doing machine
readable code scanning.

00:45:51.546 --> 00:45:53.806 A:middle
And just to drill this
home, this is supported

00:45:53.806 --> 00:45:57.176 A:middle
on every single platform
where iOS 7 is supported.

00:45:58.026 --> 00:46:00.196 A:middle
And with that, I'm going to turn
it back over to Brad to talk

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:45:58.026 --> 00:46:00.196 A:middle
And with that, I'm going to turn
it back over to Brad to talk

00:46:00.196 --> 00:46:01.756 A:middle
about some additional
focus enhancements.

00:46:01.946 --> 00:46:02.186 A:middle
Thank you.

00:46:02.686 --> 00:46:04.946 A:middle
[ Applause ]

00:46:05.446 --> 00:46:07.016 A:middle
>> Are your brains
exploding yet?

00:46:07.886 --> 00:46:11.436 A:middle
This is a little bit of
information overload,

00:46:11.436 --> 00:46:13.596 A:middle
but I hope that if
you'll just focus with me

00:46:13.596 --> 00:46:16.126 A:middle
for a few more minutes,
all will become clear.

00:46:17.766 --> 00:46:19.146 A:middle
Alright, focus enhancements.

00:46:19.636 --> 00:46:22.016 A:middle
Focus is a hard job.

00:46:22.676 --> 00:46:24.216 A:middle
We take it for granted
because our eyes do

00:46:24.216 --> 00:46:25.186 A:middle
such a good job of it.

00:46:25.896 --> 00:46:29.446 A:middle
The eyes are the motor
that change shape

00:46:29.446 --> 00:46:31.286 A:middle
and can bring different
things into focus,

00:46:31.286 --> 00:46:32.976 A:middle
and the brain is
the engine that --

00:46:33.116 --> 00:46:36.366 A:middle
the pixel processing engine that
can determine what's supposed

00:46:36.366 --> 00:46:38.596 A:middle
to be sharp, and what
you want to focus on.

00:46:39.516 --> 00:46:41.086 A:middle
The iPhone does the same thing.

00:46:41.256 --> 00:46:45.136 A:middle
It has a physical mechanism
that can move the lens

00:46:45.136 --> 00:46:47.556 A:middle
so that it can get
it into focus,

00:46:48.016 --> 00:46:50.586 A:middle
and there's some
algorithms that have to run

00:46:50.586 --> 00:46:53.076 A:middle
to decide what should
be in focus.

00:46:53.146 --> 00:46:54.516 A:middle
But this can be a
really hard job,

00:46:54.516 --> 00:46:58.056 A:middle
because sometimes you have
ambiguous results, such as here

00:46:58.056 --> 00:47:01.106 A:middle
where we have a person looking
at a clock that's very close

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:46:58.056 --> 00:47:01.106 A:middle
where we have a person looking
at a clock that's very close

00:47:01.106 --> 00:47:03.036 A:middle
to him, and a tree that's far.

00:47:03.036 --> 00:47:07.096 A:middle
And both might be equally sharp,
and so which one do you choose?

00:47:07.096 --> 00:47:09.166 A:middle
Which one should be in focus?

00:47:09.596 --> 00:47:11.756 A:middle
Sometimes we need a little
help to get that right.

00:47:11.956 --> 00:47:13.606 A:middle
And you can make sure
that we get it right

00:47:13.606 --> 00:47:16.946 A:middle
by using the new auto focus
range restriction modifiers

00:47:16.946 --> 00:47:18.696 A:middle
to our auto focus mechanism.

00:47:19.326 --> 00:47:20.586 A:middle
Here's what it looks
like in code.

00:47:21.016 --> 00:47:24.356 A:middle
You tell the AV capture
device to set its focus range

00:47:24.596 --> 00:47:30.576 A:middle
to just near, or just far, or by
default none means the default

00:47:30.576 --> 00:47:31.906 A:middle
of search the whole range.

00:47:34.016 --> 00:47:36.656 A:middle
For machine readable code
detection, we'd recommend

00:47:36.656 --> 00:47:39.496 A:middle
that you use near, unless
again you're going to look

00:47:39.496 --> 00:47:41.246 A:middle
for barcodes that are in fields.

00:47:43.646 --> 00:47:46.056 A:middle
And these auto focus range
restrictions are supported

00:47:46.056 --> 00:47:50.576 A:middle
on all iOS devices that have
cameras, so go to town on it.

00:47:51.086 --> 00:47:54.246 A:middle
The next enhancement
is smooth auto focus.

00:47:54.546 --> 00:47:56.686 A:middle
I'm going to show you
two different videos.

00:47:56.986 --> 00:48:00.286 A:middle
The one on the left is what
I'll term fast focus --

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:47:56.986 --> 00:48:00.286 A:middle
The one on the left is what
I'll term fast focus --

00:48:00.286 --> 00:48:03.206 A:middle
this is what's shipping
today, this is our algorithm

00:48:03.206 --> 00:48:07.216 A:middle
for finding focus -- and
then what I term smooth focus

00:48:07.216 --> 00:48:09.436 A:middle
on the right.

00:48:09.476 --> 00:48:13.026 A:middle
You'll notice that it's going to
pan from one side to the other,

00:48:13.026 --> 00:48:15.596 A:middle
and then pan back, and you'll
see different characteristics

00:48:15.596 --> 00:48:16.666 A:middle
in the focus.

00:48:16.786 --> 00:48:20.446 A:middle
The one that's fast has a
tendency to sometimes pulse,

00:48:20.496 --> 00:48:22.576 A:middle
or throb a little bit,
because it's running

00:48:22.576 --> 00:48:24.846 A:middle
through the whole
range really fast,

00:48:25.456 --> 00:48:29.126 A:middle
whereas the smooth one runs
slower, takes a little more time

00:48:29.126 --> 00:48:32.486 A:middle
to do it, but doesn't
have the visual pulsing.

00:48:32.586 --> 00:48:33.916 A:middle
So here I go, 1, 2, 3.

00:48:35.356 --> 00:48:38.116 A:middle
Take a look at both sides.

00:48:38.116 --> 00:48:41.866 A:middle
You'll see the one on the left
has a tendency to just come in

00:48:41.866 --> 00:48:43.406 A:middle
and out a little
bit more noticeably.

00:48:43.896 --> 00:48:45.686 A:middle
The right one is focusing.

00:48:46.296 --> 00:48:50.106 A:middle
It's just doing it more subtly.

00:48:50.606 --> 00:48:56.156 A:middle
[ Silence ]

00:48:56.656 --> 00:48:59.246 A:middle
You'll still see
it focus from --

00:48:59.246 --> 00:49:00.826 A:middle
every once in a while
you'll see --

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:48:59.246 --> 00:49:00.826 A:middle
every once in a while
you'll see --

00:49:00.826 --> 00:49:04.996 A:middle
you can definitely see that the
smooth one is zooming it back

00:49:04.996 --> 00:49:10.736 A:middle
into focus, but the left one
tends to be much more prominent.

00:49:11.796 --> 00:49:14.356 A:middle
Okay, like I said, the
fast focus is the one

00:49:14.356 --> 00:49:15.436 A:middle
that ships today.

00:49:15.646 --> 00:49:17.376 A:middle
We're offering now
the smooth focus

00:49:17.376 --> 00:49:20.966 A:middle
as an alternative behavior
modifier to auto focus,

00:49:22.016 --> 00:49:24.386 A:middle
and you do that by telling
the AV capture device

00:49:24.386 --> 00:49:27.096 A:middle
to set smooth auto
focus enabled to yes.

00:49:29.036 --> 00:49:32.216 A:middle
Smooth auto focus just
slows the focus scan down,

00:49:32.636 --> 00:49:34.866 A:middle
so it's a little less
visually intrusive.

00:49:35.946 --> 00:49:38.736 A:middle
We recommend that you use this
if you're recording a movie.

00:49:38.836 --> 00:49:41.496 A:middle
For instance, you want
to perform a tap to focus

00:49:41.776 --> 00:49:42.966 A:middle
in the middle of a recording.

00:49:43.216 --> 00:49:44.486 A:middle
Well you don't want
to ruin your recording

00:49:44.486 --> 00:49:45.946 A:middle
with a big vwoop in the middle.

00:49:46.286 --> 00:49:50.226 A:middle
So if you use the smooth
recording it will take a little

00:49:50.226 --> 00:49:52.746 A:middle
bit longer to get there, but
the smooth focus will be less

00:49:52.746 --> 00:49:53.766 A:middle
visually intrusive.

00:49:55.166 --> 00:49:57.566 A:middle
We do recommend that you
stick with the fast focus

00:49:57.626 --> 00:50:01.566 A:middle
for still image taking, because
it's faster, and no one's going

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:49:57.626 --> 00:50:01.566 A:middle
for still image taking, because
it's faster, and no one's going

00:50:01.566 --> 00:50:05.286 A:middle
to see the pulse in the
resulting still image

00:50:05.286 --> 00:50:06.626 A:middle
if it got to focus faster.

00:50:07.876 --> 00:50:10.636 A:middle
This is supported on iPhone 5.

00:50:12.756 --> 00:50:15.646 A:middle
And Slowpoke makes use of
this when recording movies,

00:50:15.646 --> 00:50:18.166 A:middle
so you can see how it does it.

00:50:18.446 --> 00:50:21.106 A:middle
Now let's look at how you
program with these modifiers.

00:50:22.486 --> 00:50:26.366 A:middle
It's easy, just do that.

00:50:27.006 --> 00:50:30.016 A:middle
So as with all setters
on the video device,

00:50:30.016 --> 00:50:32.096 A:middle
you have to lock it for
configuration first.

00:50:32.986 --> 00:50:36.456 A:middle
If you're successful, then you
can start checking whether these

00:50:36.456 --> 00:50:37.586 A:middle
features are available.

00:50:37.936 --> 00:50:42.596 A:middle
Don't set them blindly, you'll
throw an exception on platforms

00:50:42.596 --> 00:50:44.016 A:middle
where these features
are not supported.

00:50:44.596 --> 00:50:46.546 A:middle
Auto focus range
restriction happens

00:50:46.546 --> 00:50:49.076 A:middle
to be supported everywhere,
but be safe.

00:50:49.216 --> 00:50:52.146 A:middle
So here we're going to
set it to the far range,

00:50:52.746 --> 00:50:56.056 A:middle
and then in the next block I'm
seeing whether smooth auto focus

00:50:56.056 --> 00:50:57.776 A:middle
is supported, and
I set it to yes.

00:50:57.776 --> 00:51:01.116 A:middle
And then for giggles I
threw in an extra one,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:50:57.776 --> 00:51:01.116 A:middle
And then for giggles I
threw in an extra one,

00:51:01.116 --> 00:51:02.716 A:middle
which is to set the
point of interest.

00:51:02.716 --> 00:51:05.526 A:middle
This is how you would do a tap
to focus at a particular point.

00:51:06.336 --> 00:51:08.836 A:middle
None of these actually
start a focus operation,

00:51:09.056 --> 00:51:11.656 A:middle
they're just programming
the next focus operation.

00:51:11.656 --> 00:51:14.686 A:middle
You're telling it I
want you to focus far,

00:51:14.686 --> 00:51:16.376 A:middle
I want you to focus smooth,

00:51:16.756 --> 00:51:19.276 A:middle
I want you to focus
at dead center.

00:51:19.576 --> 00:51:22.096 A:middle
And then the way that you
actually kick off the focus is

00:51:22.586 --> 00:51:27.066 A:middle
to set focus mode to auto
focus, or continuous focus,

00:51:27.206 --> 00:51:29.126 A:middle
and then unlock when
you're done.

00:51:30.916 --> 00:51:34.166 A:middle
The last bit we're going to
talk about today is integration

00:51:34.166 --> 00:51:35.886 A:middle
with application audio session.

00:51:36.436 --> 00:51:38.396 A:middle
Hopefully you've seen some
of the core audio sessions

00:51:38.396 --> 00:51:39.556 A:middle
in years past, and the one

00:51:39.556 --> 00:51:42.546 A:middle
that they just did I think it
was yesterday, where they talked

00:51:42.546 --> 00:51:44.576 A:middle
about some improvements
to AV audio session.

00:51:45.006 --> 00:51:47.916 A:middle
If you're not familiar
with it, you have one.

00:51:48.196 --> 00:51:51.006 A:middle
If you have an app, you
have an AV audio session.

00:51:51.606 --> 00:51:53.896 A:middle
It's a singleton instance
that every app gets,

00:51:53.986 --> 00:51:55.626 A:middle
whether they want it or not.

00:51:55.626 --> 00:51:58.676 A:middle
As soon as you use audio,
you have an AV audio session.

00:51:59.216 --> 00:52:02.136 A:middle
And it does important things for
you like configure the routing,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:51:59.216 --> 00:52:02.136 A:middle
And it does important things for
you like configure the routing,

00:52:02.136 --> 00:52:04.376 A:middle
for instance, whether
both the microphones

00:52:04.376 --> 00:52:07.546 A:middle
and the speakers are
active at the same time,

00:52:07.986 --> 00:52:09.666 A:middle
or just speakers only.

00:52:10.276 --> 00:52:13.186 A:middle
You can customize your
category, for instance

00:52:13.186 --> 00:52:16.856 A:middle
so that you include Bluetooth
or not, lots of goodness there.

00:52:17.496 --> 00:52:20.006 A:middle
And new in iOS 7 they have
some great new features

00:52:20.006 --> 00:52:21.846 A:middle
for microphone selection
that they talked

00:52:21.846 --> 00:52:23.196 A:middle
about in yesterday's session,

00:52:23.916 --> 00:52:28.306 A:middle
where you can select a specific
microphone, top or bottom,

00:52:28.306 --> 00:52:31.346 A:middle
back or front, and you can
even set polar patterns.

00:52:31.496 --> 00:52:34.496 A:middle
For instance, if you want
an omnidirectional pickup

00:52:34.496 --> 00:52:36.476 A:middle
as opposed to cardioid

00:52:36.476 --> 00:52:38.486 A:middle
or sub-cardioid, so
great stuff there.

00:52:40.396 --> 00:52:43.496 A:middle
Why do I bring it up here in
a video recording session?

00:52:43.546 --> 00:52:45.436 A:middle
It's because we have a situation

00:52:45.436 --> 00:52:48.906 A:middle
on our hands called
dueling audio sessions,

00:52:49.026 --> 00:52:50.396 A:middle
and let me describe it to you.

00:52:51.726 --> 00:52:55.326 A:middle
Let's say you have an app,
and it plays back audio,

00:52:56.096 --> 00:52:59.696 A:middle
and it also does some
recording with the camera

00:52:59.696 --> 00:53:00.806 A:middle
and with the microphone.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:52:59.696 --> 00:53:00.806 A:middle
and with the microphone.

00:53:01.796 --> 00:53:05.066 A:middle
Well, you're probably going to
be using an AV audio session,

00:53:05.066 --> 00:53:06.506 A:middle
because you're playing
some audio,

00:53:06.886 --> 00:53:09.246 A:middle
and you're definitely going to
be using an AV capture session,

00:53:09.246 --> 00:53:10.456 A:middle
because you have
to if you're going

00:53:10.456 --> 00:53:12.216 A:middle
to use it for camera capture.

00:53:13.426 --> 00:53:16.496 A:middle
Unbeknownst to you, AV
capture session is kind

00:53:16.496 --> 00:53:19.186 A:middle
of lousing things up, because
it has its own little private AV

00:53:19.186 --> 00:53:20.306 A:middle
audio session.

00:53:21.636 --> 00:53:25.896 A:middle
So now what happens when you
play and record, you fight.

00:53:26.656 --> 00:53:28.416 A:middle
So you get a situation
where depending

00:53:28.416 --> 00:53:30.756 A:middle
on which one you started
first, one is going

00:53:30.756 --> 00:53:31.736 A:middle
to interrupt the other.

00:53:32.276 --> 00:53:34.706 A:middle
So if you started playback first
and then you start recording,

00:53:34.986 --> 00:53:38.686 A:middle
the playback stops, or
if you do vice versa,

00:53:38.686 --> 00:53:40.096 A:middle
then you interrupt
your recording.

00:53:40.696 --> 00:53:41.816 A:middle
Not good for anyone.

00:53:42.876 --> 00:53:46.376 A:middle
So in iOS 7, we're
changing that behavior.

00:53:47.716 --> 00:53:49.796 A:middle
There were some good things
about the old behavior.

00:53:50.056 --> 00:53:52.216 A:middle
By having a private
AV audio session,

00:53:52.596 --> 00:53:55.996 A:middle
we ensured that the AV capture
session is always configured

00:53:55.996 --> 00:53:58.206 A:middle
correctly to succeed
for recording.

00:53:58.626 --> 00:54:01.986 A:middle
And your audio session is
not configured automatically

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:53:58.626 --> 00:54:01.986 A:middle
And your audio session is
not configured automatically

00:54:01.986 --> 00:54:05.146 A:middle
by default to record,
it's just for playback.

00:54:05.406 --> 00:54:06.506 A:middle
So we needed to do that.

00:54:06.506 --> 00:54:10.326 A:middle
But now we're going to help
out the interruption problem

00:54:10.676 --> 00:54:14.086 A:middle
by using your app's
audio session by default.

00:54:14.876 --> 00:54:16.296 A:middle
And we tell you that we're doing

00:54:16.296 --> 00:54:20.656 A:middle
that by accessing the session
property uses application

00:54:20.656 --> 00:54:21.566 A:middle
audio session.

00:54:21.566 --> 00:54:23.466 A:middle
And again, by default it's yes.

00:54:24.366 --> 00:54:27.186 A:middle
If your app is linked before
iOS 7 you get the old behavior.

00:54:27.186 --> 00:54:29.146 A:middle
We use our own little
private audio session,

00:54:29.146 --> 00:54:30.256 A:middle
and nothing changes.

00:54:31.886 --> 00:54:36.176 A:middle
And we still will configure your
audio session now, not ours,

00:54:36.836 --> 00:54:38.556 A:middle
so that it succeeds
for recording.

00:54:38.556 --> 00:54:40.306 A:middle
And that's the default behavior.

00:54:40.426 --> 00:54:41.846 A:middle
You can opt out of
that behavior,

00:54:42.116 --> 00:54:45.616 A:middle
and there's an accessor for that
called automatically configures

00:54:45.666 --> 00:54:47.696 A:middle
application audio session.

00:54:47.906 --> 00:54:48.956 A:middle
(We're going for length here.)

00:54:48.956 --> 00:54:53.636 A:middle
After the capture is finished,
we're not going to attempt

00:54:53.636 --> 00:54:57.776 A:middle
to clean up our mess, so we're
not going to try to preserve any

00:54:57.776 --> 00:55:00.046 A:middle
of the state that was in
your audio session before we

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:54:57.776 --> 00:55:00.046 A:middle
of the state that was in
your audio session before we

00:55:00.046 --> 00:55:01.346 A:middle
configured it to succeed.

00:55:01.686 --> 00:55:03.596 A:middle
If you want to stash off
some state you can do

00:55:03.596 --> 00:55:05.296 A:middle
that before beginning
your recording.

00:55:07.066 --> 00:55:07.846 A:middle
Be careful though.

00:55:07.846 --> 00:55:10.946 A:middle
If you opt out of the automatic
configuration that we provide,

00:55:11.376 --> 00:55:14.086 A:middle
because you are now in control
of your AV audio session,

00:55:14.146 --> 00:55:16.596 A:middle
you can pick a category that
will make recording fail.

00:55:16.756 --> 00:55:20.436 A:middle
So just be on guard there.

00:55:20.636 --> 00:55:22.976 A:middle
I mentioned earlier in the talk
that we have this great new way

00:55:22.976 --> 00:55:26.116 A:middle
of configuring AV
capture devices

00:55:26.116 --> 00:55:27.936 A:middle
by setting the active format.

00:55:28.506 --> 00:55:32.386 A:middle
This however, does not apply
to audio devices on iOS 7.

00:55:32.386 --> 00:55:36.456 A:middle
It exposes a no format array,
its format's array is nil,

00:55:36.776 --> 00:55:39.526 A:middle
and that's because we already
have a perfectly good mechanism

00:55:39.526 --> 00:55:43.356 A:middle
on iOS 7 to configure audio,
which is the AV audio session.

00:55:43.756 --> 00:55:45.536 A:middle
If you want to configure
your input,

00:55:45.896 --> 00:55:48.996 A:middle
instantiate your AV audio
session, and then go to town -

00:55:49.316 --> 00:55:52.016 A:middle
setting gain, sample
rate, whatever you want.

00:55:53.886 --> 00:55:56.686 A:middle
Best practices, we do recommend

00:55:56.686 --> 00:55:59.546 A:middle
that you let us use
your app audio session

00:55:59.546 --> 00:56:01.506 A:middle
so that we don't have
the interruption problem,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:55:59.546 --> 00:56:01.506 A:middle
so that we don't have
the interruption problem,

00:56:02.026 --> 00:56:06.916 A:middle
and we do recommend that you let
AV capture session modify your

00:56:06.916 --> 00:56:10.146 A:middle
AV audio session by default,
because it'll succeed.

00:56:11.026 --> 00:56:13.836 A:middle
The exceptions to the rule would
be if you know that it's going

00:56:13.836 --> 00:56:15.706 A:middle
to do something that
you don't want to do.

00:56:15.806 --> 00:56:18.876 A:middle
For instance, by default it
will always pick the microphone

00:56:18.876 --> 00:56:20.296 A:middle
that's pointed the
same direction

00:56:20.296 --> 00:56:21.736 A:middle
as the camera that you're using.

00:56:22.146 --> 00:56:23.936 A:middle
So if you're using the
front facing camera,

00:56:24.186 --> 00:56:26.916 A:middle
it's going to pick the
microphone that's pointed

00:56:26.996 --> 00:56:28.436 A:middle
at the person's face.

00:56:28.826 --> 00:56:31.196 A:middle
If you for instance want to
use the front facing camera,

00:56:31.196 --> 00:56:33.266 A:middle
but also record from
something in the back,

00:56:33.676 --> 00:56:36.966 A:middle
you'll need to use your own AV
audio session configuration.

00:56:38.766 --> 00:56:40.246 A:middle
Lastly, sample code update.

00:56:40.696 --> 00:56:41.446 A:middle
Here's our dessert.

00:56:42.166 --> 00:56:43.896 A:middle
Last year we talked
about Video Snake,

00:56:43.996 --> 00:56:47.176 A:middle
which was a great demo app
that incorporates a lot

00:56:47.176 --> 00:56:49.346 A:middle
of capture aspects with open GL.

00:56:49.976 --> 00:56:53.836 A:middle
We've updated it this year,
incorporated iOS 7 APIs

00:56:53.836 --> 00:56:57.706 A:middle
and best practices,
including use of clock APIs

00:56:57.706 --> 00:57:00.586 A:middle
that I have not talked about
today, but they let you know

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:56:57.706 --> 00:57:00.586 A:middle
that I have not talked about
today, but they let you know

00:57:00.586 --> 00:57:02.826 A:middle
which clock we're
using, video or audio,

00:57:03.056 --> 00:57:04.956 A:middle
which one is the master
clock for a session.

00:57:05.916 --> 00:57:08.176 A:middle
It also illustrates best
practices with respect

00:57:08.176 --> 00:57:12.296 A:middle
to integration with open GL,
and writing with asset writers.

00:57:12.296 --> 00:57:16.456 A:middle
So please download it, and
model your code after it.

00:57:17.536 --> 00:57:20.306 A:middle
If you've been watching the news
-- the Apple news, you'll --

00:57:20.306 --> 00:57:23.516 A:middle
you probably were aware that two
weeks ago we introduced a new

00:57:23.516 --> 00:57:24.336 A:middle
iPod Touch.

00:57:24.386 --> 00:57:28.686 A:middle
It's the 16 gigabyte iPod Touch,
and what's unusual about it is

00:57:28.726 --> 00:57:30.676 A:middle
that it has no back
facing camera,

00:57:30.776 --> 00:57:32.176 A:middle
it only has a front
facing camera.

00:57:32.996 --> 00:57:36.346 A:middle
Well, if you have been
following Apple's sample code,

00:57:36.746 --> 00:57:39.276 A:middle
your app still works
with this new device,

00:57:39.276 --> 00:57:41.176 A:middle
because it would have picked
the right one by default.

00:57:41.636 --> 00:57:43.236 A:middle
So sample code is your friend.

00:57:43.506 --> 00:57:44.316 A:middle
Please use it.

00:57:44.316 --> 00:57:46.836 A:middle
Please model your code
after these samples

00:57:46.836 --> 00:57:48.556 A:middle
that we spend a lot of
time putting together,

00:57:48.776 --> 00:57:50.856 A:middle
because we want to make sure
you're using best practices

00:57:50.856 --> 00:57:51.546 A:middle
in your apps.

00:57:52.886 --> 00:57:56.616 A:middle
In summary, we talked about
user consent, transparency,

00:57:57.086 --> 00:57:59.976 A:middle
then we talked about
a lot of new features,

00:57:59.976 --> 00:58:05.216 A:middle
60 frames per second, video
zoom, barcodes, app integration,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:57:59.976 --> 00:58:05.216 A:middle
60 frames per second, video
zoom, barcodes, app integration,

00:58:05.216 --> 00:58:07.806 A:middle
app audio session
integration, focus enhancements.

00:58:09.776 --> 00:58:13.326 A:middle
And all of these demos that we
showed you today are available,

00:58:13.416 --> 00:58:17.836 A:middle
so go download them and
take a look at them.

00:58:17.976 --> 00:58:22.206 A:middle
Documentation, and of
course, related sessions.

00:58:22.596 --> 00:58:25.836 A:middle
Some of these already happened,
but you can already look at them

00:58:25.866 --> 00:58:28.486 A:middle
in your WWDC app, because
they've already been posted.

00:58:28.486 --> 00:58:29.126 A:middle
They're amazing.

00:58:30.106 --> 00:58:34.726 A:middle
Thank you for coming today,
and enjoy the rest of the show.

00:58:35.226 --> 00:58:39.060 A:middle
[ Applause ]