►
From YouTube: WebRTC Working Group Virtual Interim April 12, 2018
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
So
welcome
to
the
interim
meeting
of
the
w3c
web
urgency
working
group
during
this
meeting,
we're
going
to
talk
about
the
working
group
charter
and
open
to
make
progress
on
some
open
issues
in
WebRTC,
PC
and
actually
mostly
screen
sharing
and,
as
usual,
we
will
continue
to
edit.
The
draft
and
updates
will
follow
the
meeting
according
to
what
the
working
group
decides.
B
C
C
Don't
care
deeply
about
that,
but
I
think
it
would
be
reasonable
to
ask
the
question
as
part
of
the
poll
the
most
poll
of
where,
where
we
should
have
the
meeting,
because
several
people
I
talked
to
said
they
would
not
go
if
it
was
in
Europe,
which
would
include
myself
but
said
they
would
and
that's
that's
why
I
didn't
figure
out
the
poll
I
just
figured
like
hey
I,
shouldn't
vote
on
this.
If
I'm
not
going
to
go,
I
mean
what
it
would
be
reasonable
to
ask
people
about.
C
D
B
D
C
C
D
A
A
F
C
D
C
A
Yeah
I
mean
my
major
concern
here
is:
if
we
have
people
who
wouldn't
be
able
to
come,
who
still
would
want
to
be
active
or
might
even
present,
then
we'll
need
to
do
remote
participation,
and
once
we
do
that,
you
know
how
many
of
the
people
who
would
actually
travel
to
Stockholm
will
actually
do
remote.
Instead,.
B
C
I
I
will
definitely
be
remote
and
I'll
host
other
people
remote.
If
we
do,
if
we
do
Stockholm
it's
just
it's
and
it's
the
interview
is
not
the
exact
dates.
The
issue
and
look
I
understand
this
issue
going
the
other
direction
we
put
North
America
for
everyone
right,
but
it's
the
basically
taking
a
week
of
time
for
the
travel
and
the
just
sheer
number
of
trips.
C
I've
had
to
do
this
here
there,
international
trips
or
just
budget-wise,
an
issue
as
well
so
I
I,
won't
come,
but
I
understand
that
there's,
probably
somebody
who
can't
come
the
other
direction
too,
so
I
I'm
understanding
of
that
I.
Just
think
that
we
should
that
location
is
actually
really
important
when
we're
talking
about
these
things
and
we
need
to
figure
out
some
way
of
making
sure
we
do
the
right
thing
on
that.
A
A
C
The
days
they
work
for
me,
I
have
certainly
been
at
meeting
well.
I
mean
you
guys
know:
we've
been
at
meetings
where
we've
all
been
at
meetings
where
we've
attended
the
whole
thing.
Remote
and
they've
been
full
day
long
meetings,
but
I
mean
you're
right.
If
it's,
if
it's
totally
remote
like
four
or
five
hours,
seems
to
work
better
than
nine
yeah.
A
B
C
C
B
B
D
C
A
A
A
Okay,
so
about
the
Charter.
As
many
of
you
know,
the
Charter
has
been
extended
until
May,
2018,
I,
guess
we're
in
the
AC
review
phase
and
hopefully
we'll
get
to
meet
the
AC
for
a
formal
vote
pretty
soon.
The
draft
charter
itself
extends
the
Charter
to
March
31st
2020,
so
some
changes
so
many
of
the
changes
from
the
feedback
from
the
last
virtual
interim.
So
in
terms
of
liaisons,
we
added
the
ice
working
group.
A
We
add
a
data
transfer
to
the
success
criteria
for
some
reason
that
hadn't
been
in
there
before
we
clarified
the
feature,
removal
policy,
which
is
that
if
you
don't
have
features
that
aren't
implemented
by
at
least
two
browsers,
they
can
be
separated
into
an
extension
document
or
dropped,
and
then
we
clarified
the
timeline
for
both.
So.
C
B
D
C
C
D
C
A
We
have
to
open
issues
which
one
of
them
relates
to
use
cases
and
I.
Think
we
say
in
the
Charter
already
that
we
can
do
use
cases
and
I
think
the
question
is:
will
we
do
them
for
200
and
I?
Think
there's
only
some
people
want
to
do
them
and
the
other
is
when
we
start
the
web
or
to
c2o
work,
because
there
are
some
open
issues
relating
to
the
to
the
object
model
which
would
like
some
of
which
we'll
talk
about
today.
A
What's
the
other
strategy
for
it
so
on
question,
one
I'll
just
this
is
just
my
personal
opinion
here,
which
is
that
redundant
audio
coding
is
actually
superior
to
simulcast
for
audio
in
a
number
of
ways.
One
is
that
you
can
have,
and
it
is
done
for
read
you
can
have
multiple
encoding
z'
like
an
example,
is
opus
at
multiple
bid
rates.
When
you
do
that,
you
have
less
overhead
than
you
would
with
simulcast,
and
the
SFU
can
still
dig
into
the
packet
and
selectively
forward
if
it
wants
to
do
that.
A
But
the
other
thing
you
get,
which
is
actually
pretty
valuable,
is
you
can
protect
against
burst
loss
and
at
least
we've
seen
in
our
own
experiments.
This
works
a
lot
better
than
opus.
Well
pass
FPC.
Doesn't
support,
burst,
loss
protection,
so
you
can
get
that
and
that's
actually
a
pretty
pretty
big
improvement
in
audio
quality.
So
that's
kind
of
an
argument
against
requiring
simulcast,
audio
and
I
guess
so
opinions
on
the
first.
The
first
point.
C
I
The
Oliver
here,
I,
don't
think
I
was
just
I,
don't
have
a
bone
in
this
I
was
just
mainly
looking
at
the
API
in
the
IP
I
seem
to
suggest
that
browsers
must
handle
simulcast
for
audio,
yet
no
browsers
implemented.
So
just
the
sound
like
in
the
Charter,
we
were
just
talking
about
needing
to
implementations
and
we
don't
have
that
I,
don't
care
that
we
need
to
forbid,
but
the
API
I
don't
think
it's
okay
to
leave
ambiguity
in
the
API
in
order
to
we
shouldn't
have
to
do
that.
I
In
order
to
allow
future
implementations,
we
need
to
specify
what
it
takes
to
be
compliant
today
and
I'm
happy
to
have
language
that
says
we
didn't
do
some
language
that
for
any
optional
features,
we
need
to
describe
browser.
Vendors
need
to
know
how
to
handle
not
supporting
something
like.
Should
we
throw
a
not
supported
error
and
it
could
we
have
language
and
said
you
know
if
you
don't
support
this,
throw
an
error
at
this
point.
Something
like
that.
So.
D
My
take
on
this
has
been
has
been
more
or
less.
That
is
that
the
API
has
to
specify
what
happens
if
you
ask
for
more
than
more
layers
than
than
the
browser
supports,
and
if
then
it's
a
number
of
layers
that
the
browser
support
is
one,
that's
it.
That
is
a
perfectly
valid
implementation.
It's
just
not
an
implication
of
simulcast
right.
D
D
I
D
A
Well,
we
had
a
discussion
way
back
in
the
past
about
like
adding
a
capability
for
the
number
of
layers.
The
problem
was,
it
gets
a
little
complicated
because
it
could
be
likely.
You
could
support
a
different
number
of
layers
for
audio
and
for
video,
maybe
potentially
even
a
different
number
of
layers
depending
on
the
codec,
so
it
couldn't
really
come
up
with
a
very
clean
way
of
getting
capabilities.
It's
a
little
bit
easier
to
just
throw
in
an
you
know,
throw
an
error
like
you
proposed
Jana
t-bar
right.
I
And
now
an
error
isn't
great
either
because
I
could
see
people
programming
toward
one
browser
and
then
all
the
other
vendors.
You
know
it
would
throw
an
error
on
other
vendors
and
then
it
becomes
who
can
support
the
most
layers.
I,
don't
know,
I
mean
the
other
approach
would
be
best
effort
and
in
some
way
of
advertising.
What
that
is,
I
guess.
A
I
A
D
A
A
B
C
A
J
G
I
The
idea
that
if
people
can
use,
get
parameters
to
figure
out
they
can
you
set
parameters
to
say,
here's
why
what
I
would
like
to
have
happen
and
then
they
can
later
at
some
point,
that's
unclear
when
they
can
actually
get
that
they
can
get
back
well,
here's
what
actually
happened!
I
think
that's
reasonable
than.
I
A
So
how
about
an
alternative
proposal,
which
is
you
do
the
best
you
can
and
you
then
need
get
parameter?
Get
parameters
will
then
return
the
number
of
encodings
the
maximum
number
of
coatings
that
she
acceptable?
Let's
put
it
this
way.
It's
not
a
real-time
thing.
It
tells
you
exactly
what's
being
said
at
this
instance,
where.
I
I
I
A
A
I
It
seems
on
to
return
just
what
God
set.
Some
people
can
keep
modifying
it
with
potentially
modifying
things
that
won't
have
any
effect.
So,
but
at
what
point
would
the
implementation
and
I
apologize
I?
Don't
know
this
be
able
to
return
that
information
correctly.
Is
that
only
after
negotiation
was.
I
A
Well,
now,
I'm,
assuming
that,
like
you
said
it
returns,
what
was
last
set,
so
you
know
I
think
the
model,
and
this
is
a
little
bit
specular
this.
You
know,
if
you
you
couldn't
have
done
this,
what
you
would
ask
for
an
ad
transceiver,
you
get
an
error
and
then,
if
you
don't
get
an
error,
it
actually
is
considered
set
and
or
if
you
do
a
set
parameters
that
also
said
to
them
and
get
parameters
returns
that
thing,
but.
I
A
J
It's
basically
two
things
right:
it's
like
basically,
the
JavaScript
could
be
asked
to
do.
For
example,
five
layers
right
and
the
local
browser
could
say
like
hey
I
can
only
do
three
then
puts
like
three
and
offer,
and
then
it
gets
the
answer
back
and
and
learns
that
the
other
set
only
will
is
willing
to
do
two
right.
A
J
A
A
E
D
I'd
like
to
think
think
about
to
ending
this
part
of
the
conversation,
because
we
have
more
things
to
do
and
I'd
suggest
that
that
to
it
we
have
most
sympathy
for
the
for
the
case.
Where
you
don't,
okay,
you
don't
get
the
error,
you
get
the
you
get
well,
if
I
try
this,
this
is
what
what
will
happen.
Yeah.
H
I
B
A
Right,
1174
I
have
reopened
this
and
the
reason
I
reopened.
It
is
we're
hearing
from
some
SFU
vendors
that
there's
an
issue
with
Weber
to
c1
OCR.
A
Currently,
a
lot
of
the
conferencing
apps
support,
Plan
B,
and
they
do
it
by
signaling,
SSRC,
say
current
nessip
use
typically
would
ignore
the
rid
header
extensions
and,
if
they're
going
to
transition
to
heads
and
Siri
unified
plan,
they
need
some
way
to
obtain
those
SS
or
C's,
and
the
problem
we
have
is
currently
we
in
PR
or
1531.
We
removed
the
SSRC
support
from
RTC
RGB
encoding
parameters.
So
what
that
means
is
that
well
I
forget
what
it
was
Ryu's
to
be
read-only.
So
it
was
something
you
would
get
on
the
browser.
A
You
wouldn't
be
able
to
choose
the
SSR
C's,
but
we
took
it
out
and
the
question
is:
how,
then,
would
you
would
you
necessarily?
Would
you
have
that
SSRC
information,
the
people
I've
talked
to
don't
seem
to
care
whether
it
comes
from
the
epic
model
or
DSD
key
or
whatever.
They
just
need
to
somehow
know
what
SSR
sees
are
sending.
So
they
can
signal
this
to
the
SSU
and
without
it,
they're
going
to
have
problems
transitioning
to
man.
Transceiver
pleasure,
if
I
plant,
so
before,
going
and
putting
all
this
stuff
back.
A
D
K
K
A
D
The
third
way
of
doing
it
this
instead,
of
course,
but
the
thing
with
SSRC,
is
this
that
makes
it
uncomfortable
to
heaven.
Stp
only
is
that
in
theory,
as
the
piece
SSRC
it
can
change
where
SSR
sees
can
pop
up
that
didn't
occur
in
the
yes,
the
beam
and
the
reporting
of
what
they
are
and
the
place
where,
where,
where
this
reporting
on
what
the
SSRC
is
being
received
at
in
the
object
that
the
corresponds
to
the
actual
incoming
it
as
as
history
and
seems
more
logical
to
me,.
D
A
B
A
J
J
J
A
D
D
A
B
D
That
they're
already
present
in
the
steps,
but
I,
don't
like
it.
If
you
I,
don't
like
to
stick
stuff
that
this
needed
an
operation
in
terrain
in
inter
stats
in
the
earth
way
so
I
prefer
to
expose
it
I
mean
it.
It
would
have
to
be
consistent
consistent
with
what
with
the
numbers
and
stats
but
I
think
it
makes
sense
to
expose
them
separately.
Yeah.
A
G
I
A
It
might
or
may
not
get
well
currently
I,
don't
let
let
me
put
this
I
haven't
looked
at
the
road
maps
for
all
these
different
as
a
fuse,
but
the
apps
kind
of
work
with
the
SSRC
stuff
and
I,
don't
think
they're
I,
don't
think
they're
planning
on
mandating
ribs.
Let
me
put
it
this
way,
so,
even
if
these
things
ad-supported
many
of
the
apps,
wouldn't
this
really
change
right
away.
I.
I
K
I
H
K
A
J
D
A
D
A
Well,
a
number
the
SS
used
a
it
doesn't
really
matter
whether
they
use
SCP
or
not,
but
they
all
the
hang
out.
What
you've
just
been
hanging
out
steam
is
exactly
the
same
thing
I
just
heard
from
most
of
the
conferencing
brothers
and
they
different.
They
use
different
signatures
and
not
all
STP
based
so
yeah.
This
isn't
just
a
hangout
specific
request.
A
A
I
Yeah,
so
so
the
issue
here
is
that
we
have
this
rollback
mechanism,
which
you
know
briefly
explained.
Is
you
know
we
want
to
set
things
back
to
the
way
they
were
or
undo
the
last
STP.
If
you
will,
and
we
haven't
already
specified
what
happens
in
order
to
do
that?
Well,
I
mean
if
the
intent
is
to
have
things
function
normally
right
after
that,
after
rollback.
I
I
Fire
and
track,
and
even
the
track
event
on
that,
and
so
it
sounds
to
me
like
we
need
to
do
those
things
and
that
would
be
the
most
release
so
trying
to
come
up
with
the
least
surprising
API
behavior
for
applications
who
do
rollback.
The
alternative,
is
you
not
do
any
of
those
things
and
basically
say
yep
things
are
going
to
be
in
a
messed
up
state
if
you
ever
roll
back
and.
A
D
I
D
That's
required
talking
about
a
peer
connection
outside
of
its
JavaScript
context,
in
a
way
that
precluded
the
natural
idea
of
having
a
map
mapping
table
in
JavaScript
that
map's
the
identifier
of
the
of
the
peer
connection
to
something
else.
So
we
have
roughly
roughly
a
dozen
ways
that
this
can
be
done
with
by
hiding
and
identifying
various
places
that
nobody
would
really
know
this,
but
it
kind
of
seems
wrong
to
try
to
sneak
in
the
functionality.
That's
that
a
set
has
to
work
in
order
to
make
other
things
working.
D
D
We
were
suggesting
a
long
random
number,
but
just
because
that
makes
life
easier,
so
so
solve
the
problem
and
it
sold
it
sold
it
pretty
cleanly.
It
might
be
useful
for
other
things,
but
it
failed
to
reach
consensus
on
the
list,
because
people
saying
we're
saying
this
is
such
a
specific,
specific
problem.
Nobody
else
is
going
to
have
it
or
words
the
words
to
that
effect.
So
the
question
is:
what
should
we
do
now.
D
D
D
L
D
Thinking
that
it's
that
will
it's
not
unlikely
that
we
will
find
out
the
use
cases
so
far,
we
we
have
had
some
people
suggesting
that
it's
useful
for
log,
so
it's
useful
for
having
tokens
that
are
interchanged
in
as
part
of
the
identity
protocol
and
but
and
I
mean.
If
something
is
there
with
non
properties
and
someone
is
going
to
make
use
of
it.
D
L
So
it
sounds
like
the
next
step.
If
you
want,
if
we
want
the
standardize,
this
would
be
come
up
with,
with
a
least
you
know,
a
viable
use
case
or
to
wear
something
outside
of
chrome
might
need
this.
D
D
L
L
A
Okay,
1826
yan
Ivar.
A
I
So
yeah
I
was
writing
a
blog
using
transceivers
and
fiddles
and
trying
to
use
receivers
only
to
do
negotiation
on
the
answering
side
and
realizing
that
transceivers
only
let
us
answer
with
streamers
tracks,
basically
and
one
example
that
use
a
track
and
using
a
track
works.
Then
you
can
specify
that's
the
only
way
we
allowed
to
specify
stream
associations
today
and
that
works
in
the
simple
cases
where
their
transceiver
you're
dealing
with
is
the
first
unused
transceiver
in
the
cat
transceivers
order,
because
then,
as
track,
will
implicitly
attach
your
track
to
that
transceiver.
I
But
as
the
general
solution,
that's
really
no
good,
because
if
you
say
you
have
five
transceivers,
there's
no
way
to
address
the
third
one
in
that
list
within
first
mapping
stream
associations
for
the
every
transceiver
ahead
of
it
in
that
list.
So
that
seems
suboptimal
so
and
I
think
we
need
a
general
way
to
edit
open
seattle
track
with
streams
to
any
given
transceiver.
So
the
proposal
there
is
to
add-
and
the
example
here
shows
on
the
slide,
you
know
the
example
is
answering
an
incoming
STP
message.
We
set
remote
description.
F
I
We
could
make
this
work
to
do
that
as
well.
So
if
you,
if
you
were
to
call
set
streams
outside
of
negotiation
in
stable
States,
we
could,
for
instance,
trigger
negotiation
needed
focus
on
the
remote
end.
We
already
need
to
handle
changes
to
stream
associations
anyway,
for
other
reasons
and
there's
a
link
in
the
issue
to
more
details
on
them.
I
M
I
I
mean
the
one
of
the
reasons
to
pin
reprimanding
track
was
to
have
an
API
where
you
didn't
accidentally
send
the
same
tracks
the
same
bits
twice
that
for
every
add
track.
If
you
numerate
all
the
tracks,
you
have
to
deal
with
the
educator
track
being
in
two
streams
at
the
same
time
and
the
new
API
efficiently.
I
Let's
see
you
numerate
by
track,
so
you
don't
you're
not
going
to
add
it
twice.
You'll
get
an
error
if
you
had
try
to
add
the
same
track
twice,
but
then
you
need
to
specify
that
oh,
this
is
the
video
track.
That
is
in
two
streams
and
I
want
that
reflected
to
live
in
two
streams,
remotely
just
a
back
story.
There.
A
So,
okay
so
now
objections
so
bad
in
them.
Meeting
minutes.
Okay!
So
now
we're
getting
to
the
media
capture
screen
share
we're
still
in
the
meeting.
Hopefully
we
can
get
in
almost
half
an
hour
on
that
I'm,
going
to
turn
it
over
to
sue
Hoffs.
Generally,
twelve
open
issues
on
screen
capture
eight
for
discussion
today,
so
sue
house,
okay,.
M
Issue
on
the
PowerPoint
being
special,
where
the
application
or
window
capital
screen.
We
did
discuss
this
last
time
and
there
was
general
agreement
that
we
need
to
write
a
PR.
That
kind
of
explains
how
this
is
very
specific
to
the
user
agent.
As
long
as
no
user
agent
is
able
to
recommend
the
application
of
the
window
that
went
to
the
post
is
the
one
that
was
in
the
context
wind
where,
when
the
school's
full
screen
operation
was
carried
out,
so
I
have
a
PR
created
on
that
and
I
I
see.
M
F
F
M
M
B
I
We
need
to
define
a
behavior
of
existing
constraints
in
screen,
sharing,
currently
I'm
just
specified
and
I.
Think
we
agree
that,
yes,
we
do
need
to
support
down
scaling
and
it's
in
fact
critical,
because
I
by
default,
most
desktops
these
days
are
too
rich
resolution
and
frame
rate
for
most
people's
up
links.
So
the
usage
we're
discussing
in
this
slide
is,
you
know,
with
track,
get
settings
and
track
apply,
set
constraints
and
the
questions
there
is.
What
do
we
support?
B
I
And
the
other
question
is
we
allow
cropping
screen
sharing
or
do
we
prevent,
or
do
we
say
that
there's
no
propping
and
at
all,
basically
in
the
spec
language
at
all
settings
dictionaries
all
potential
outcomes
have
the
same
aspect
and
if
we
choose
no
cropping,
then
aspect
ratios
resize
mode
constraints
become
redundant,
although
they
might
still
have
informative
value.
Like
you
can
read
out
what
the
current
aspect
ratio
is
from
get
settings,
that's
quite
convenient.
You
could
also
read
out
whether
it's
currently
being
downscaled
or
not,
but
by
looking
at
the
resize
button.
I
So
my
proposal
would
be
that
cropping.
Well,
the
problems
with
cropping
is
that
I
think
it
gets
complicated
and
there's
a
low
value.
In
fact,
we
had
a
bug
recently
that
where
screen
sharing
was
cropping-
and
that's
really
what
you
want
when
you're
seeing
someone's
desktop,
especially
if
you're
viewing
a
document
or
something
like
that-
and
it's
also
easy
to
miss
that
that
there's
a
problem
so
I
think
it's
we're
better
off
and
I,
don't
see
use
cases
for
it.
I
So
I
would
propose
an
explicit
list
and
no
cropping
explicit
list,
because
I,
don't
think
I
think
it'd
be
under
specifying
I
think
browsers
need
to
implement
this
stuff.
So
at
least
we
can
do
is
put
down
what
needs
to
be
implemented
specifically
in
each
spec
and
I.
Think
cropping
is
of
low
value,
uncomplicated
and
best
avoided,
but
yeah.
I
M
A
G
D
Yep,
so
that
that's,
it
seems
like
where
we
want
to
PR
with
a
with
a
proposal
fully
fully
explicit
list
and
I,
then
we
might
might
iterator
that,
but
it's
better
to
start
off
with
a
complete
one
yep.
So
we
with
it
with
a
list
B.
These
are
mandatory
to
support,
or
these
are
the
only
ones
that
are
allowed
to
be
supported.
D
I
A
A
D
A
A
M
Remember
I
do
remember
we
spoke
about
this
last
time
and
and
also
I
had
a
chat
with
Martin
as
well.
On
this,
he
kind
of
came
to
agree
that
water,
the
feature
policy
in
a
direction
influences
this.
We
should
probably
go
with
that,
but
but
his
one
concern
is
that
we
are
kind
of
faith
shared
with
how
the
future
policies
developed
this
little
thing
or
it's
still
in
the
development
or
all
he.
He
also
thinks
this
might
be
something
we
need
aligned
with
feature
policy.
We
hopefully
find
anything
so.
I
To
clarify
to
slide,
then
the
question
here
is
really
whether
to
support
this
through
feed
through
policy
or
not
support
it
at
all
and
other
than
the
top
domain.
So
it
sounds
like
people
are
voting
or
relying
on
future
policy
there.
Well,
my
only
caution
there
would
be
in
the
screenshot
there,
its
browsers
today,
at
least
one
that
I
know.
We
have
a
really
hard
time,
communicating
well
to
the
user,
who's
really
asking
right.
K
I
D
I
I
So
hopefully,
future
policy
will
solve
this,
so
in
the
screenshot
you're
seeing
there
the
the
trick
is,
can
you
can
you
spot
that
the
domain
asking
for
your
screen
sharing
is
different
from
the
page
you're
on
and
it's
quite
subtle,
Java
jsfiddle,
yes,
I
have
a
different
domain
that
they
use
for
the
actual
third-party
code
that
anyone
can
add
all
right.
It
sounds
like
we're,
leaning
on
future
policy
here,
sort.
M
I
C
A
D
G
A
G
M
But
the
bear
is
a
PR
and
there
is
use
case
that
did
the
baby
I
think
is
something
like
this
would
be
nice
to
have.
So
Martin
was
more
on
what
I
I'm
trying
to
kind
of
sink
in
what
Martin
was
trying
to
say.
Okay,
I
might
get
it
wrong,
but
still
he
is,
he
thinks
it's
definitely
a
security
issue
or
privacy
sure
because
not
know
what
is
being
shared
in
terms
of
an
audio
guys
done,
because
it
takes
out
your
your
entire.
M
Your
advice
speaker
all
right,
but
his
thing
was:
if
there
is
a
way
in
the
UX
or
somewhere,
where
we
can
tell
what
the
risk
with
this,
then
probably
we
might
allow
basically
the
the
thing
that
he
is
talking
about
how
tab
level
mute
or
something
like
that.
So
yeah,
probably
he
might
be
a
better
person
to
say
the
registration
for
this
one,
but
at
least
he
thinks
he
shouldn't
this.
He
did
not.
He
must
not
do
this
talk.
M
M
I
B
I
So
I
think
we
had
a
agreement
on
that
and
unless
I
hear
something
we
can
move
to
the
second
slide
because
there's
a
problem
there
and
the
problem
is
that
because
the
US
can't
limit
selection-
and
this
is
why
we
did
this
in
the
first
place.
Why
was
some
before
this
is
that
you
have
a
UX
problem
where
you
still
use
min
and
Max
constraints
to
say
I'm
only
gonna,
the
delicate
script
can
say:
I
must
have
something.
That's
the
minimum
640
wide
right.
G
I
And
that's
bad
right,
so
the
solution
I
think
is
to
either
ban
or
ignore
the
min
Max
and
exact
constraints
and
get
display.
Media
and
ban
would
mean.
There
are
two
choices
we
can
ban
and
say
basically
immediately
reject
with
over
constrained
error
without
a
prompt.
That
seems
the
most
clean
way.
Maybe
push
back
medli
and
say
you
did
it
wrong
at
work
and
ignore
them
basically
ignore
min,
and
we
don't
have
to
ignore
max
I
guess,
because
we
can
always
provided
we
support
downscaling,
which
we
should.
C
C
K
I
I
meant
I
meant
what
I
mean
here,
maybe
I
phrased
it
poorly
I
meant
that
we
should
write
the
spec
so
that,
if
you
use
a
min
constraint
and
get
display
media
it
shouldn't
even
prompt
the
user.
It
should
immediately
throw
an
error
constrain
there
to
avoid
the
eventual
error
to
avoid
applications.
Try
and
specify
because
remember
the
original
intent
of
the
min
and
Max
constraints
was
to
you
get
an
error
back.
If
the
user
didn't
have
exactly
what
you
wanted,
which
leaks
information
and
it's
right.
C
I
On
selection,
by
removing
this,
we
need
to
remove
this.
It
doesn't
really
work
on
screen
sharing
to
first,
we
shouldn't
allow
websites
to
query
what
kind
of
dimensions
you
want
to
have
a
system
anyway
right
and
it's
really
be
up
to
the
user,
what
to
share,
and
then
the
website
shouldn't
try
to
mess
with
that
choice
in
any
way.
Yeah.
C
A
I
If
get
display
mania
succeeds
and
the
user
decided
to
share
their
desktop
sure,
you
can
use
constraint
of
normal
and
get
settings
and
find
out,
and
if
you,
if
you
didn't
specify
any
constraint,
learning
an
actual
dimension
of
the
users
window.
Thank
you,
but
you
could
also
find
by
like
wearing
the
the
video
element
direct.
A
D
I
B
A
M
Browser
capturing
where
the
user
would
want
and
help
option
to
select
the
current
tab
that
is
on
and
this
there
should
be
a
new
X
to
show
you
know
by
the
tab.
This
is
something
you
know
again:
I
had
a
cat
with
Martinez,
so
there
is
a
basically
two
options,
one
which
I
originally
thought
was
to
have
something
like
define:
a
new
display
capture,
surface
type,
hold
active
window
that
hooks
to
the
current
window
or
the
current
tab.
That
user
is
on
so
so
it
is
basically
selling
this
Activant.
All
this
match
to
the
tab.
B
M
Was
probably
this
is
more
like
user
user
experience
design
issue
on
which-
and
you
do
not
need
to
say
anything
in
the
spec,
the
the
user
experience
should
probably
list
all
the
tabs
the
browser
has
and
the
app.
If
you
make
sure
that
the
current
tab
is
placed
at
the
top
of
that
list,
and
that's
all
we
we
need
to
do
because
that
way
it
is
filtered
or
all
think
about
sharing
the
entire
window
and
and
the
warnings
that
comes
with
test,
and
we
don't
have
to
define
any
new
security
or
privacy
voting's
around
it.
D
I'm
not
I
was
thinking
about
back
to
where
my
love
hangout
to
experience
with
capture
sharing
shared
the
active
active
window
and
then
I
could
flip
that
between
different
tabs,
while
I
was
looking
at
Auto,
stephannie
and
other
wind
other
browser
windows
which
didn't
get
shared.
How
would
I
I'm
not
sure
that
would
work
with
current
spec.
M
I
think
this,
this
is
if,
if,
if
you
have
a
current
window
in
in
context,
say
the
current
browser
that
you're
you're
you're
on
and
if
you
do
share
the
proposal
with
options
that
you
have
all
the
tabs
in
the
current
process.
Yes,
the
current
open
window
that
step
there,
that's
in
focus
or
the
tab
for
that
window
will
be
listed
and
the
one
tab
that
you're
currently
on
will
be
on
the
top
of
that
list.
F
A
D
A
M
Is
probably
a
historical
thing
that
can
Harold
and
Mark
in
both
responded
on
the
tissue,
so
I'm
just
trying
to
paraphrase
force
being
there,
so
we
have
get
display
media
on
navigator.
So
the
question
the
issue
was:
why
can't
we
put
it
on
the
media
devices
like
what
we
have
forget
user
media
so
I
think
why?
Why
would
one
of
it
market
he
thinks
yeah?
It
should
be
possible
but
I
know
Bernard.
You
had
a
comment
on
that
face:
I
yeah.
A
A
M
F
I
I
We
needed
an
object
to
fire,
so
I
think
the
question
the
pragmatic
question:
do
we
ever
anticipate
my
media
ever
needing
to
fire
any
events?
And
if
we
do,
we
want
to
make
sure
is
this
on,
because
we
can't
fire
a
missile
navigator
so
and
I
think
it's
a
good
thing
that
we'll
never
have
a
need
to
fire.
I
As
far
as
what
what
I'm
I
think,
the
issue
that
got
raised,
the
reasoning,
the
question
from
think
tipo
and
a
issue,
one
Navigator,
because
we
also
have
the
legacy
navigator,
getusermedia
and
that
might
create
an
illusion
and
then
they
should
use
get.
You
know.
Why
is
there
a
new
method
there
and
an
old
deprecated
method
might
cause
confusion
and
lead
people
to
call
the
wrong
method?
I,
don't
know
if
that's
a
strong
argument
for
moving
it.
If
we
it's
already
shipped
an
inch,
so
I
mean.