MAJD BAKAR: Hi, everyone.
My name is Majd Bakar, and I run the engineering team
that's possible for Chrome Casson Cars.
And this is John Affaki, who is Engineering Manager for Google
Cast SDK.
Today we're going to talk to you a little bit about Google Cast
Evolution, and some of the things
you should expect from us in the coming years.
Nearly a year ago last July, we announced Chromecast,
the small little evolutionary device
that allows you to extend your favorite content
from your mobile device to the big screen.
Be it from a phone, tablet, or laptop to any HDTV, all
for a mere $35.
Google Cast is the technology behind Chromecast.
It allows developers to enable multi-screen experiences
straddling mobile devices and large screen displays.
And earlier this year we also released
the Google Cast SDK and the Cast Developer Program,
which now has over 6,000 developers building application
forecast around the world.
Let's talk a little bit about our vision and goals
for Google Cast.
[INAUDIBLE] the goals we're going
to see in the game in a few minutes.
First off, our goal is to redefine how people interact
with their TVs in the living room,
and offer them the most compelling experience
to bring their favorite content and application
to the large screen.
Second, we wanted to build an ecosystem
to proliferate these experiences-- an ecosystem that
brings more Cast-ready devices and more
Cast-enabled applications and services to all users.
And we want that ecosystem to be open to anyone
to participate in and be part of.
Finally, we wanted to make sure that wherever Cast is used,
it's consistent to the user and consistent for you to develop.
Users do not need to learn a new way to use their favorite app.
And you, the developer, do not need
to learn a new development for that.
Let's first dive into the interaction model.
One of the things that was obvious to us
was how hard it is to interact with the 10 foot UI.
Whether you're browsing a large media library,
trying to decide what to watch, searching for a show,
or answering credential for your favorite application,
using a traditional keypad remote or even
a full-blown keyboard from the couch,
make that experience complex.
On the other hand, technologies like gyroscope and cameras
used as remote controls resulted in a clumsy device
and still didn't solve the complexity of interaction
model.
With full experiences to control the TV
so prevalent in the marketplace, more and more content
is being consumed on small screens such as phone, tablet,
and laptops.
At the same time, the mobile interaction model
is proving to be great for navigation and control.
And while the portability of the mobile devices and the user
experience is very convenient.
The actual consumption of the video on those small screen
is subpar, particularly in shared screen scenarios
like this, where you want to show
your BFF your favorite summer vacation
or you want to share the latest biting movies.
There's no doubt that users want to consume their content
on the largest and most beautiful
screen available to them.
At the same time, rich and immersive experience
is the best way to navigate the UI.
And users are asking for such experiences.
So why not give them the best of both worlds?
The ubiquitous presence of the mobile devices in their homes
mean that you, the developer, do not
have to compromise on form or function.
Users can get the same application that they already
know and love on their phones, tablets, and laptops,
and cast to the best screen in the house,
while still using their mobile device for email, web browsing,
social activities, or the selection of the next video
they want to watch, all without skipping a beat.
Let's get to the ecosystem.
Chromecast is a tremendous success.
And it continues to exceed our expectations.
Google Cast goes beyond Chromecast,
and extends our reach to more devices.
We want the consumer to have a choice of devices
they use to consume their content
in any room in the home.
And we want developers to build their application
using a consistent model for all devices.
As you've seen from yesterday's keynote address,
in addition to Chromecast, we've announced
support for Google Cast on Android TVs, where
all the Google Cast applications already
developed for Chromecast would work seamlessly,
still using the same simple Cast interaction model.
Of course, this being Google, we wanted
to go big on the ecosystem play for developers,
making it as easy as possible to get your services
and experiences onto all Cast devices.
And give you the opportunity to reach
as many users as possible.
We started out with five applications at launch.
And today we have thousands more that integrate with Cast.
These apps are available on Android and iOS,
as well as web apps in Chrome, on Windows, Mac, and Chrome OS.
The SDK is published and available for all developers
to integrate with.
You can Cast-enable your app very easily.
All you need to do is integrate discovery and control
with the Cast SDK, and you're up and running.
We wanted to make the Cast button ubiquitous in all apps,
obviously where it makes sense.
And to make that possible, we enabled
the Cast SDK across the three most popular platforms--
Android, iOS, and Chrome.
We do believe it is critical to support
the heterogeneous mobile device ecosystem you
find in households today.
And the user's data is proving that to be a necessity.
Half of all Chromecast devices in the last month
were used with mobile devices from multiple platforms,
as you can see here.
Cross-platform support does matter,
as my wife can attest to, where she uses her iPhone along
with Chrome on Windows laptop and an Android tablet
to watch her favorite content and play
music throughout the house.
All on Chromecast.
Of course, one of our most important goals
was to keep things consistent and simple.
For users, we wanted to make sure
that everything is simple and easy to use.
And we did that by keeping the casting experience very
close to your mobile experience.
And rather than teaching users new ways to interface
with your app, we keep them in the comfort
of their familiar settings on their phones, tablets,
or laptops.
Whether they are playing back music on the phone
or through the TV speakers, using the Google Play Music
service, they do so using the same play music
app and the same interface to control that playback.
For developers we wanted to keep things simple and easy
to integrate with by using HTML5 for development
on Google Cast devices.
We harness the power of Chrome, and the ease
of JavaScript development and deployment.
We've also invested in our media player library
to make the most streaming format supported seamlessly.
And we continue to invest in this area, adding more formats
and more features that opens up the door for more content.
On the sender side, our integration
on the supported platforms is straightforward,
and integrates well with each platform development model.
And we continue to invest in adding more features as we
expand our application reach.
Also, we've introduced strong UX guidelines
to make sure that the user experience across applications
and devices, when you're interacting with the TV,
is consistent, familiar, and easy to understand by the user.
We never want to get the user lost, or in a position
where they don't know what to do next.
Let's talk a bit about what trends
we're seeing in the field.
Media applications are obviously the lion's share
of applications we're seeing.
And they straddle three main facets.
Video is the first one.
Whether it's big names, video streaming services
like Netflix, Hulu Plus, or HBO, or smaller content aggregators,
using the big screen for video has
been the obvious choice for developers.
Music is the other type of media that
is proving to be a great match for the Cast interaction model.
It's so natural to control an extensive playlist using
the phone.
And beautiful images are a perfect candidate
for the large screen.
Showing and sharing photos, whether personal,
or just beautiful pictures that make the TV contributor
to the home decor, pictures in general
make for a great living room experience.
All of this content can be served either from the Cloud,
your mobile device, or a local cloud
from other devices in the home.
And with the ability to connect multiple mobile devices
to a single session, these media apps
can bring great use cases such as party mode,
boarding, and sharing content.
And with the ease of use of mobile devices,
these use cases would truly shine.
We've talked a bit about media apps in the living room, which
begs the question-- what about games?
Obviously a big screen is better than a small one.
It's more beautiful, more immersive, and more convenient
to use.
And for multiplayer games, having your mobile device
being your controller allows for things that are just not
possible using traditional controllers.
For example, being able to hide a hand of cards
from other players in the room, or entering
text in a high-paced trivia game,
these are things that become trivially easy
in the Cast world.
An example of such games is Big Web Quiz,
where multiple players are competing with each other
using their phones to make a selection presented
by the game.
We show you here a quick video just
explaining how the thing works.
[MUSIC PLAYING]
Catchy tune, huh?
You can also go and play this game up on the third floor.
And you might even request that tune for a ring tone.
We're seeing a good number of games going live
with this model.
And there are a lot of great opportunities
here for multiplayer space.
One other great example of multi-center
is our very own home screen on Chromecast called Backdrop.
Here you see a stream of beautiful pictures
show up on the TV screen.
And everyone in the room who pulls theri phone out
to interact with the screen would
get a card describing the item on the screen.
But each person would get a different set
of actions associated with this card based
on their behavior, permission, and interest.
For example, in this particular card,
you see here a picture of Paris.
John, who loves to cook, might just
get actions related to French recipes.
I, on the hand, love art.
And Backdrop might just recommend
a virtual tour of the Louvre or a new art exhibition related
to Paris that is running nearby.
This allows for a very personalized experience
in the same app.
And now let me give the stage to John.
JOHN AFFAKI: Thanks, Majd.
Thanks everyone.
I'm John Affaki, and I manage the Google Cast SDK team.
And I'm going to talk to you a little bit about some
of the features we're currently working on.
First, I'd like to talk about a feature we touched
on in the keynote yesterday, which is the ability
to cast from the ten nearby devices
without being on the same Wi-Fi network.
One of the key things we've been striving for while developing
Google Cast is keeping things simple for users.
While casting today is an easy task, low friction once you're
properly set up, the initial step
of getting on the same Wi-Fi network
can be really complicated.
It doesn't matter if it's because you're
worried about the privacy of your network,
whether you have 14 random characters or characters that
would be really hard to describe.
Sometimes you just don't want to have your guests
on your Wi-Fi network.
And you want them to be able to just cast
by simply being in the same room.
So this new feature allows that.
It allows Google cast messages sent through the Google Cast
SDK to be sent over the Cloud between Google Cast devices
in your phones, or tablets, or laptops,
without the need to be on the same Wi-Fi network.
To enable the feature you first go to the Chromecast app
and go to your devices settings, and find the casting
from nearby device feature.
Enabling it allows your cast device
to be discoverable from nearby devices.
You only need to do this once, unless you want to turn it off,
at which point you can go back there and turn it off.
The other question everybody's asking, well, nearby devices--
my neighbors-- weird things can start happening.
But don't worry about that.
Basically, we have extra things to protect you from that.
Let's walk through an example to go
into a little bit more detail.
Let's say Majd, his phone in his pocket,
walks into my living room, where I have a Chromecast set up
with the feature enabled.
Now when Majd launches a Cast-enabled application,
since the nearby Chromecast device is detected--
and we use Android Location Services with this--
the Cast icon will appear.
And when pressed, a new route is going
to show up on his device that says, nearby devices.
As you can see right there.
When the route's selected, a PIN code
is ultrasonically played through the TV speakers,
and my Chromecast gets automatically connected.
Now the phone and Chromecast exchange
a token via the ultrasonic pairing,
and it temporarily pairs the two devices.
At that point they can talk to each other
through our cloud over a TLS channel.
If for some reason, the ultrasonic token
couldn't be exchanged, such as if the TV was off or muted,
than the PIN code could be manually entered
in that dialog to get the same effect.
Now the PIN code can be found on Backdrop.
You can see it right there.
But if Backdrop is invisible, such as, again if the TV's off,
or if you're in the middle of casting another application,
I can get the PIN for Majd by looking it up
in my Chromecast app, since I'm on the Wi-Fi network.
Now as a developer, this feature is enabled for you
without any changes needed in your app.
Any data that you send through the Google Cast SDK
will be transparently sent through this cloud channel.
But if you send other kind of data, for example, local media,
then you'll be able to opt out of this feature,
because otherwise we can't send that data
through our cloud for now.
So this feature really allows you
to build great social experiences in your apps
without much worry about what it takes to hop onto the network
and get users started.
Your users can just walk in, tap the task icon,
and enjoy your app.
Second, let's talk about some of the announcements
we made related to Cast on Android TV.
So Android TV devices have the exact same functionality
that you've come to love with Chromecast.
Every Google Cast application written for Chromecast
will work as is without any modifications for Android TVs.
Now Android TVs typically also have a remote control
along with Cast support.
And so let's walk through an example.
Let's say my daughter casts something
from her tablet to my Android TV.
And I wanted to talk to her, but I don't have my phone with me
to pause the media.
Now I can pick up the remote-- the Android TV remote--
and press a media command like Pause or Stop,
and if the receiver application was coded using the Google Cast
media name space, then the application
would seamlessly receive the message, the media messages,
exactly as if it had been sent from a phone or tablet
or laptop without any changes made to your application.
And the other thing is with more and more Google Cast devices
coming up on the market, one of the main things we wanted to do
was avoid fragmentation.
So in every Google Cast device, whether Chromecast,
or any Android TV, we're running the same Cast receiver
code which will be kept up to date with background updates
by Google, which means your users will always be running
the latest and greatest Cast receivers.
Third, we announced support for casting your Android screen
to cast devices.
Now when we first launched Chromecast,
we introduced one of the most popular features, which
was the ability to cast a tab from Chrome.
Now this provided an easy way to get all user's web content
onto Chromecast.
At the keynote yesterday, we announced
that we'll be rolling out screen casting, which
allows users to mirror their Android displays onto Google
Cast devices.
Now this means as a user, you could
project your native Android apps, which may not yet
be Cast-enabled, to the big screen
without the developer needing to do any work.
However, with some changes, you, as the developer,
can also extend your application to use multiple displays when
this is enabled with the secondary display being
mirrored onto your Google Cast device.
You could do this by opening up a presentation
display on the secondary screen when
your app is being mirrored.
Now there's a lot of applications
that benefit from screen split experiences,
and they can now take advantage of the big screen.
So for example, here you can see this
is us earlier, presentation apps with speakers notes
that could be on your phone while you're projecting
the full blown presentation on the TV.
You can also build rich dual-screen games
that take full advantage of the processing
power of your mobile device, but the beautiful display
on your wall.
Fourth, let's talk a little bit about enhancements
to media applications.
Now one of the biggest items we launched
with the release of the Google Cast SDK
was the Media Player Library, bringing easy integration
for DASH, HLS, and Smooth streaming
to media applications.
It really reduced the amount of time
it takes to build media applications
to a fraction of what it took before during the preview
phase.
Now we're making constant improvements to this library,
adding more formats and trying to make
it even easier to integrate with your apps.
Now it's because of this library that the folks
on the live stream right now are probably
ignoring us and watching the Live Stream on Chromecast
for the US World Cup game.
Now accessibility is something that we take very seriously
at Google.
And we know you guys do too.
So we're introducing full support
for closed captioning in the Google Cast SDK,
as well as in our default players.
That means that you, the developer,
don't need to build any custom UI to deal with users' caption
settings, if you don't want to.
You could, and we'll take those settings instead,
but we'll have defaults in there.
And you can use standardized messages
to manage the on/off settings.
No need to build a custom name space to deal with
closed captioning anymore.
Now your users will be able to set their caption settings
on their mobile device settings page,
and they'll be used on the Google Cast devices.
And that means that each user can have personalized caption
settings and manage their own preferences.
They'll persist, regardless of which Google Cast device
you cast to.
Now this will be rolled out over the next few weeks
as we roll out the update to the SDK.
Now there are some mobile devices
that don't support setting caption
settings for the mobile device.
And so the users will be able to go to the Chromecast app
to set defaults for the Google Cast devices.
And those will be used if the settings aren't
available on the phone.
And that'll come a little bit later this year.
Alright, let's talk about queuing.
So for most music apps and many video apps,
queuing is pretty much a prerequisite.
But there hasn't been a unified way of building queues.
Every single app that uses queuing today
builds them in their own way.
So we're working on adding a standardized queuing
API to our SDK which will handle the logistics of creating,
modifying, and managing queues of media item.
That means that you as an app developer can simply add items
to your queue, and if you're using our default players,
will automatically take care of playing them back
in the right order, and dealing with any kind of reorder.
This will be a full fledged API which
allows you to insert, remove, reorder items,
and anything you'd expect from a queue.
We're also building in full-featured media controls
onto mobile devices, allowing users
to interact with whatever's currently
playing with regards to media from any device.
Now, I'll go through an example.
If I'm playing back media from an application on my laptop,
and my wife were to pick up her tablet,
which wouldn't have the corresponding Android or iOS
app associated with that app, and she would still
be able to pause, resume, seek, and any common media
action that you'd take simply because her application was
built using the standard media name space.
Now authentication and credential exchange
is another challenge that the majority of developers
have to deal with.
We're also working on a providing
a simple, secure way to deal with the transfer
of credentials from senders to receivers,
so that your services can seamlessly
authenticate on Google Cast.
Now this will be integrated with queueing
so that if different items in your queue
require different credentials, you
could pass the token at insert time,
and you won't have to deal with it at playback time.
For example, in an app where, say Majd and I wanted
to add music to a queue, and the service required authentication
for each item, Majd could add the item
and his token would be passed along
with the item in the queue.
I would add something to the queue
and my credentials would be passed.
We could toss our phones out the window, drive over the phone,
or whatever, doesn't really matter.
And the playback would be able to go back smoothly
because the credentials were already there.
So we're adding more features to the SDK,
but another key area that we're investing in
is to make sure that your users can find your apps.
I mean APIs are key, but an app is only great
if it can reach its users.
So we're making it easier for them to find your applications.
At the keynote yesterday, we talked about the redesigned
chromecast.com/apps website, which allowed users to browse
and find apps for all of our platforms.
Now a few weeks ago, we released an updated developer console
which allowed us to gather information and assets
to use to feature your apps.
And as more and more developers enter their data
in the console, you'll see their apps show up on the site.
But that's just the beginning, and more discovery features
are coming to the website.
We're also making improvements to the Play Store
to make it even easier to search for Cast-enabled apps.
This will bring relevant recommended applications
to Cast users to the forefront.
We're also going to build in support in the Chromecast app
to surface apps that our users already have installed,
but actually don't know are cast-enabled.
So they'll be able to discover them from the Chromecast app.
Finally, I'm going to talk to you about some use cases
beyond media.
As Majd said earlier, the majority
of the apps that we're seeing are media applications.
And much of that is because we're heavily
focused on making that happen.
Now there are however, many areas
where we're seeing quite a few apps show up.
And over the next year we'll be making enhancements
to the Google Cast SDK across the board
to make it even easier for you guys to enable the scenarios.
Now the living room TV is mainly used for two reasons.
The first one is obvious, and it's media,
and we talked about that.
The second one is gaming.
Now with the number of daily active users
of mobile devices absolutely dwarfing
the overall number of active console users,
the audience for multi-screen games is huge.
Now the interaction model enabled by the devices
that users already have today allow
you to create games that simply aren't
practical to build on your platform.
With the phone for example, users have a controller,
they have a great touch screen, a beautiful display, a camera,
a microphone, a gyroscope, and an accelerometer.
And you can create multiplayer games
that anyone can join without the need
to purchase any additional custom hardware
and use all these features.
Now as a sometime lazy parent, I'm
as guilty as anyone of using the TV as a babysitter, which
gives it a really bad rap.
With Google Cast, you could build
creative educational software that
can now make me look like a smart babysitter
for using the TV.
Now with the big screen being used to watch video clips
or images, for example, the entire surface of my child's
touchscreen could be used for interactions,
either via drawing, or keyboards,
or whatever interaction model you choose to have.
Those hands may be little, but they really
need a lot more surface than ours do.
Now, another great use case would
be adding in multi-center capabilities
into those educational games.
For example, you can give the ability for a parent
to provide help or assistance to a child from a second device
while they're playing their game on the first one,
so that it doesn't interfere with your child's touch screen
experience, and builds their confidence.
Now going beyond the living room,
the usage of cast devices in classrooms
can make for a really immersive experience.
In more and more cases, students are
encouraged to use tablets or laptops for their classes.
Now whether it's for classroom presentations, real time
quizzes, or just to drill deeper into whatever
the teacher's currently presenting,
being able to interact with the classroom just
keeps students engaged.
Now Enterprise is also a space where using a Cast remote
is pretty much a daily occurrence.
For example, being able to cast a presentation-- like we're
doing today, drive a video conference--
we do that all the time, or even simple, obvious use cases
like digital signage.
There are thousands of use cases that
can be enabled by Google Cast in the Enterprise.
For example, this guy probably would have something
up on the screen if he used Google Cast.
As you can see, there's a lot of room
for innovative, fresh, impactful apps.
And we're here to help.
The main thing we want you folks to get out of this presentation
is that we're evolving the Google Cast ecosystem based off
of what you guys are telling us.
We're constantly listening to the feedback,
trolling the forums, looking at the developer community on G +.
And we were looking to see what you guys want us to improve on.
And so we want you to keep that feedback coming,
because we're really only just beginning.
So if you want to learn more about Google Cast-- well,
you're here-- you probably know much about it.
But if you want to learn more about it,
you can find more information at google.com/cast
and developer.google.com/cast.
So we're going to take the rest of the time for questions.
Thanks.
AUDIENCE: Hello.
Sasha Goldman from DistinctMEDIA.
I have two questions.
First of all, you described the new great features
that you will have in the media player extension,
like closed captions.
Does it apply to the custom receivers as well?
JOHN AFFAKI: Yeah.
So with the custom receivers, you'll be able to access,
let's take queuing for example.
You'll have a queue object, and you will get events
when an item finishes playing and there
will be hooks for you to do whatever
it is that you're doing.
So for example, if you were to not use a standard video
tag to play back, you'll get an event which will tell you,
hey, you should be playing back this item.
So there will be hooks in order for you to do that.
We just can't do full playback because we
don't know exactly what your custom application will be,
how your custom application interacts.
But yeah, all of these features will be usable by that.
They just need a little bit more work.
AUDIENCE: Thank you.
And second question, I asked that before.
And I'm wondering if anything changed
in opening your open platform to other platforms like Microsoft
on Google Cast SDK site?
MAJD BAKAR: So we evaluate the addition
of a new platform based on popularity and usage.
As other platforms become more popular,
we'll investigate that.
JOHN AFFAKI: Yeah, I mean we obviously
have support for Windows on Chrome.
And we see a lot of applications being developed there.
AUDIENCE: Yeah, Chrome's getting great.
And I remember take the Chrome notes
and embed it in your application,
which is impractical.
Question is, actually have that dot Net,
C Sharp SDK that we can integrate
in our existing lines of the products.
Right now we can't support Roku.
We can't support Xbox 1.
We cannot support Chromecast.
And we support Chromecast on any other platforms except Windows.
And basically as products from our product perspective,
we're abandoning our customers on the Windows side, which
is actually quite large by popularity
from our point of view.
That's the practicality of that question.
Thank you.
JOHN AFFAKI: Thank you.
AUDIENCE: Have you guys worked at all
with the Chrome remote desktop team?
Essentially turning Chromecast into anywhere
VPNs, to turn any screen into whatever computer
you're connecting to?
JOHN AFFAKI: We constantly are talking to the Chrome team.
One of the challenges there is how you actually
deal with the extension.
Do you mean like the ability to promote
into your desktop from say, your mobile device, and--
AUDIENCE: Yes.
So if I was to take my Chromecast,
plug it in this projector, remote into my computer
at home, and have a keyboard connected to the Chromecast
essentially turn the screen into my computer
from home streaming.
MAJD BAKAR: It's an interesting use case.
We need to discuss it with the remote staff team.
AUDIENCE: Yes.
Dell came out with a USP HDMI 6 similar to you guys
that essentially runs an entire computer on there.
So you can turn any screen into a computer.
But with Chromecast being so light,
and the Chrome remote desktop team
making such amazing advances on that side, mending the two
together could almost turn that into an anywhere platform.
MAJD BAKAR: Thanks.
AUDIENCE: You mentioned about the devices
which are not on Wi-Fi.
Will not be a discovery option if the content stream is local.
JOHN AFFAKI: Yes.
AUDIENCE: So I'm building an application which
is streaming local content now.
Do I need to make any changes to tell the casting
service that my content is local and not
coming from a foreign location?
JOHN AFFAKI: So when you talk about local content,
you mean content on your phone or on your tablet, right?
AUDIENCE: Yes.
JOHN AFFAKI: So one of the main challenges
is the Cloud messaging system is optimized for the Google Cast
SDK, which usually is somewhat short burst messages, which
is mostly about notifying your application.
And so we're not right now ready to deal with say,
a five gigabyte file that you'll be streaming through there.
Now if you were dealing with local content
say, with the ability to-- you could probably
pass a URL that may be accessible from the Cloud,
and you would be able to stream it.
But your URL, in typical cases, you'd
be opening up a local port, say 192 address space.
You wouldn't be able to stream your media that way.
But if you were to open up something
that could go through the NAT and the open internet,
then you'd be able to stream it.
We just can't send large media file.
Essentially the Google Cast SDK channels
are really meant for notifications and messages.
AUDIENCE: True, but so in that case,
how do I make sure my application
to have the opt-out option for the user.
JOHN AFFAKI: Well, we won't be able to have the option.
Essentially when we talk about opt out
of this feature, because essentially you might end up
with a somewhat broken experience, where you think
your address is 192, blah, blah, blah,
and the cast device on the other side is going to go,
yeah, it's not.
And so in the developer portal, in the developer console,
you'll be able to basically opt out
of local discovery, which means that in your application,
the user will not see the nearby devices.
AUDIENCE: Fine.
That's what I was looking for.
JOHN AFFAKI: As much as we want to make sure
that all your use cases are there,
we really want to make sure we protect the end user also.
AUDIENCE: Thank you.
AUDIENCE: Any new word on casting from your desktop,
but not using Chrome?
So if you have a DVD or a Blu-ray disc
to put in your laptop, and you want to stream it that way.
Because I know you guys are working on that,
and you're having audio problems,
from what I've looked up.
JOHN AFFAKI: Do you mean the desktop mirroring feature?
MAJD BAKAR: You are talking about mirroring, or casting?
The commanding control?
AUDIENCE: Yeah, like casting your desktop on the screen.
MAJD BAKAR: So we continue to investigate.
This is currently an experimental feature.
We're experimenting with that.
There are challenges into mirroring the full desktop.
And we're still working on that.
AUDIENCE: OK.
Thank you.
AUDIENCE: Are you guys looking into doing primitives
for images or slide shows?
JOHN AFFAKI: Do you mean like for example,
the equivalent of a default player for that?
AUDIENCE: Yeah exactly.
Like you have a media player for video.
Would you have a slide show player for images?
JOHN AFFAKI: I believe our default players actually
allow you to at least cast one image right now.
And as we'll add queuing, we'll have support for images also,
as part of those.
So you'll be able to essentially add images to a queue.
AUDIENCE: Without any other media,
and it'll cycle through them.
JOHN AFFAKI: Yeah.
AUDIENCE: OK.
Thank you.
AUDIENCE: Along those lines, we noticed a lot of apps
that you can cast photos and slide shows,
but one thing about those, to me at least,
they're boring without music.
So it would require I guess two streams,
but is there any opportunity there to be able to cast like,
photos from a source and music as well?
JOHN AFFAKI: You mean from different sources?
There's nothing today preventing any application
from playing back audio and showing photos
at the same time.
Essentially, if you think about what Chromecast is,
you've got the full power of HTML.
And as far as I know, you can actually
play back audio and video, or audio and images on the web.
Right?
I mean, obviously.
Sorry.
And so in this particular case, if you're
talking about say, being able to cast Google Play
Music while doing your photos, we
have no plans of allowing two applications
to run in parallel on that.
Mostly because the interaction model for users
might get very complicated.
AUDIENCE: That's true.
JOHN AFFAKI: But there's nothing preventing an application,
for example, from deciding to be able to play background music
or allow you to cast from audio and photos at the same time.
AUDIENCE: Is that something the Android TV would
be able to solve, if somebody wanted to cast
play music and have their photos streaming at the same time?
MAJD BAKAR: You still have the same problem with the user.
If the user is using their phone, if they want to pause,
which one do they want to pause.
So until we figure out how to do that on the sender side,
it's irrelevant of what receiver it is.
JOHN AFFAKI: It's not really a platform limitation.
We're trying to make sure that the interaction model is great.
AUDIENCE: OK.
Thanks.
AUDIENCE: What's going to be the audio and video
latency for the new mirroring feature from Android
to Chromecast?
MAJD BAKAR: We're trying to make it as low latency as possible.
We're not going to publish a number at this time.
As was announced yesterday, it's still beta feature.
AUDIENCE: So is it going to be faster
or slower than from the browser?
MAJD BAKAR: It should be faster.
I mean, lower latency.
JOHN AFFAKI: I mean, you saw the demo yesterday.
And you'll be seeing it very shortly.
I mean, we've been play testing it
with games and all sorts of things,
so it's very responsive.
AUDIENCE: Thank you.
AUDIENCE: Same question.
Thank you.
JOHN AFFAKI: Two-for.
AUDIENCE: I haven't played with this in a little bit,
so it might have gotten better.
But I remember we were working on in our office
having a bunch of default applications
running on these Chromecasts, and then we
want people to be able to put something up, and then
have that application seamlessly come back when they're done.
And I remember we were having some difficulties.
Kind of like writing our own screen saver sort of thing.
Is there any plan to put in APIs to easily support
having your own version of a screen saver
for the Chromecast?
JOHN AFFAKI: Yes and no.
Not as a complete replacement for Backdrop.
But as Rishi announced yesterday,
we're going to be talking to third party developers
to have the ability for them to add
their own feeds into Backdrop.
AUDIENCE: Thanks.
AUDIENCE: Hi.
So with the screen mirroring, is there
going to be an option for individual applications
to turn that off?
Say for example, for apps that may have the rights to display
video on the small screen, but not on the big screen?
MAJD BAKAR: So this is-- on Android,
it's a system function.
And depending on the level of security
you have in terms of content protection,
you'd be able control that.
This is all part of the presentation API in Android.
AUDIENCE: Thank you.
AUDIENCE: Since you're adding media control from the Android
TV remote to Chromecast, would it
be possible to do the same with HDMI CC on the old Chromecast?
MAJD BAKAR: It's a great feature.
We're looking into that.
AUDIENCE: Do you have any timeline as far as
when the queue API and some of the other things
that you talked about are going to be
actually live on Chromecast?
JOHN AFFAKI: So the closed captioning APIs
are essentially rolled out.
We talked about rolling out the new Google Play
Services with screen casting and closed
captioning as part of that.
So it'll be over the next few weeks.
We're talking about queuing and ID delegation.
We're currently working on that.
And it's soon.
It's going to be an upcoming release.
AUDIENCE: Yeah.
OK, thank you.
AUDIENCE: I just had a question about the video file types
that Chromecast supports.
Will there be an update to that?
Or is it a limitation to the hardware?
I know currently you can use something
like Plex or something, but you have
to run a server on a computer.
Is there going to be an update to maybe codecs?
MAJD BAKAR: On the codec itself, unfortunately it's
a hardware limitation.
But on the container and transport stream,
that we are adding as we go.
So codec, it's H.264 up to high profile as well as VP8
on video.
On audio we have a much larger list.
In terms of streaming format, we support the MP4 base
and the Impact 2TS base, but we are adding as we go.
AUDIENCE: Thank you.
AUDIENCE: When casting, I would love
to be able to put my headphones in my phone,
and then get the music from the TV.
So are you taking that into consideration?
And do you have a best practice or best approach for that?
MAJD BAKAR: The trick there is making
sure you have the synchronization right.
Over Wi-Fi, things become challenging.
But it is definitely an area of investment for us.
We still don't have an answer.
So I'm sorry.
I don't have the silver bullet here.
But we're looking into ways to make it easier.
So we provide you with some timing information,
so you can synchronize audio and video.
AUDIENCE: Romain from France, France [INAUDIBLE].
And we recently released a Chromecast enabled application
on Android, which is France 24.
And we had problems integrating the live stream
of our channel because of cross domain policies.
Do you plan on lowering restrictions or giving
guidelines for standard streaming solutions,
like for the media server?
MAJD BAKAR: Go ahead.
JOHN AFFAKI: So cross domain auth
is something that the web is dealing with, right?
And the reason the majority of apps
don't run into this on normal web,
is because most use Flash-- less and less-- but many
are using Flash.
So we want to keep the development process
as close as possible to the web development
process, which means that at least for now, cross domain
auth is staying.
I think Leon Nichols posted something
on the developer forum--
MAJD BAKAR: Guidelines.
JOHN AFFAKI: Sorry?
MAJD BAKAR: Guidelines.
JOHN AFFAKI: Yeah, some guidelines
on how to deal with it.
We know this is a challenge for many people,
particularly during development, because once you
go to production, you're a little bit more set up.
But developing from your dev machine,
it's always harder to get a live stream.
So we're looking into ways of making it easier.
But cross domain auth is here to say.
MAJD BAKAR: And also we're working with Mint player
in the industry, particular CDN providers
to find alternatives as well.
Make it easier for developers.
AUDIENCE: Thank you.
AUDIENCE: Are you looking at getting
five gigahertz or other Wi-Fi protocols like Enterprise
security supported on the hardware,
either through a Gen 2 or Android TVs?
MAJD BAKAR: So we can't talk about future hardware.
But these are stuff that are interesting for us.
AUDIENCE: Since the hardware capabilities
of Android TV and the old Chromecast
is different, especially regarding
codec supported in encryption, and so on.
Is there going to be any difference in support
of video files in Chromecast on Android TV?
MAJD BAKAR: So actually, it will be identical.
We are putting all the hardware requirements
in terms of codec, DRM, and streaming
as part of the Android TV requirement.
And whatever runs on Chromecast would run on Android TV.
AUDIENCE: So for example, if I had a 4K source,
I wouldn't be able to play through Chromecast on Android
TV?
MAJD BAKAR: No.
So this is the last question because we
are running out of time.
AUDIENCE: OK.
We are developing an app for the Kindle Fire,
and when we are using the Chromecast SDK,
it usually Google Play framework.
So is there a way to using other non Google Play--
MAJD BAKAR: Unfortunately at this moment,
that's not possible.
The SDK is part of the Google Play services,
and it's not available.
AUDIENCE: Oh, OK.
MAJD BAKAR: So I want to make one last announcement.
Before you leave, if you go at the corner there,
we're giving away free Chromecasts.
Thank you for attending.
JOHN AFFAKI: Thank you.