►
From YouTube: WebRTC Working Group Virtual Interim February 21, 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
A
A
Alright-
and
there
is
a
link
to
these
slides
on
the
working
group
wiki,
which
you
might
want
to
follow
along,
consult
likes
and
stuff,
you
could
bring
up
alright
for
today.
Here's
the
agenda,
we're
going
to
initially
talk
about
content
hints
and
we
have
with
us
some
video
coding
experts
Thomas
today
and
Moses
and
honey
was
on
at
some
point.
Then
we'll
talk
about
media
capture,
screen,
share
issues
and
then
a
little
bit
of
a
report
on
bit
statistics
from
Harold
and
in
a
few
web
RTC
issues
which,
hopefully,
we
could
clear
up
all
right.
A
So,
first
about
the
Charter
as
many
you
know,
the
current
charter
expires
in
March
and
we
have
had
a
draft
charter
out
which
extends
the
working
group
to
actually
that
should
be
2020,
because
extending
it
to
March
31st
wouldn't
help
much,
and
we
made
some
changes
based
on
feedback.
From
the
last
virtual
interim,
we
added
a
discussion
of
data
channel,
including
accessing
the
data
in
media's.
Sorry
transferring
data
between
peers,
as
well
as
access
to
raw
data,
which
is
accessing
the
data
in
the
history.
A
So
those
two
things
were
added
in
terms
of
API
functions
in
terms
of
normative
specs.
We
removed
links
to
the
web
sea
ice
and
WebRTC
quick
specs,
but
added
a
general
discussion
of
data
transfer
functions
and
that
included
those
interfaces
for
the
data
transfer
of
data
and
that
included
message
based
as
well
as
stream
based
communications
and
the
ability
to
consider
various
API
changes
for
use
of
board.
I
want
data
transport
to
support
the
data
transfer
functions.
A
A
D
Yeah
so
I
mean
I've
gone
through
that
and
I
thought
like
a
lot
of
things
that
are
really
important
to
me
about
like
how
we
were
going
to
build
on
top
of
and
bring
in
the
object
model
and
stuff
we're
all
really
clear
inspected
in
charter,
so
I
liked
it.
One
thing
is
not
a
charter
issue,
but
I
was
sort
of
like
the
CSU
is
looks
out.
It'd
be
nice
to
have
some
sort
of
face-to-face
get-together
type
meeting
where
we
could
really
dig
in.
D
D
D
A
B
Think
dome
is
not
about
that
see
the
d-plan
and
the
optimistic
plan
is
to
get
it
out
by
March.
First
Domus
already
circulated
this
proposal.
We
the
WotC
management
and
incorporated
some
comments
from
them
and
they
so
he's
pretty
optimistic.
We
can
meet
this
deadline
and
then
it
would
be
tuned
for
the
AC
review
for
four
weeks,
so
we
could
get
done
before
the
end
of
March.
Oh.
E
A
C
A
So
when
why
Betsy
why
we
have
something
called
degradation:
preference
which
is
an
enum,
that's
input
to
the
video
encoder,
and
it
includes
directives
to
maintain
resolution
maintain
framework
or
balanced.
But
the
question
has
come
up
what
about
other
things
like
audio
and
api's
other
than
WebRTC,
which
don't
have
an
equivalent
of
degradation
preference,
and
so
the
idea
advanced
by
Peter
was
have
a
Content
him
as
a
media
stream
property.
A
So
that
would
enable
usage
by
other
api's,
like
media
stream,
recorder
and
other
api's,
with
less
flexible
controls
and
also
potentially
I
guess
the
content
hint
could
inform
balanced
if
you
didn't
put
make
a
frame
rate
or
maintain
resolution
and
there's
a
demo
up
on
github.
That
shows
you
the
difference.
It
can
make
similarly
a
little
description
of
above
about
how
what
difference
it
makes
some
text
and
some
of
the
examples
of
the
hands
were
motion.
Detail:
speech
and
music,
so
Thomas
and
Mo.
F
Orders
so,
basically,
to
summarize
the
types
of
image
we
can
do,
there
are
basically
two
categories.
One
is
rate
control
hints,
which
is
what
the
current
proposal
has
in.
It
is
the
most
original
motion
versus
quality
hint
and
then
there's
also
a
encoder
format.
Specific
feature
hints
that
will
tell
you
something
usually
about
the
content
like
I
have
text
or
I.
Have
you
know
a
webcam
or
something
like
that,
and
so
those
two
things
are
not
in
the
solution,
as
it's
currently
proposed.
F
So
on
the
next
slide,
I
have
the
the
visual,
and
so
there
video
rate
control
tint,
basically
is
for
people
who
are
aren't
already
familiar
with
it.
The
idea
is
that
we
have
a
trade-off
when
we
run
out
a
bit
arm
and
we
have
you
notice.
For
example,
you
flip
between
slides
or
you
have
a
sudden
scene
change,
you're
going
to
use
a
ton
of
bits,
and
you
may
not
be
able
to
do
that.
Digital
rate
control
parameters,
so
you
have
two
choices.
One
is
you
accept?
F
You
send
the
frame
at
very
low
goal,
because
that's
all
you
can
afford-
and
you
basically
have
those
pulses-
that
the
video
quality
drops
and
mentholated
increases,
or
you
have
the
option
of
dropping
the
frame
entirely
and
sending
the
using
those
bits
towards
the
future
frame,
which
you
know,
avoids
a
drop
in
quality
but
the
whole.
F
F
So
the
does
let
50
X
1
is
very
simple,
as
they
did
easily
turn
off
features
that
would
allow
the
encoder
to
use
a
lower
quality
frame.
So
it's
more
likely
to
skip
the
open
h.264
is
a
little
more
complicated.
It
also
adjust
frame
skipping
on
it.
This
extra
suck
up
all
their
parameters
to
that
are
like
that
also
basically
effectively
control
the
same
thing,
but
there's
not
being
really
content
specific
in
there.
F
The
next
slide
has
this
quick
summary
of
some
of
the
encoder
only
features
that
we
can
do.
The
proposal
currently
kind
of
wanted
list
these,
and
especially
things
that
we're
not
hitting
one,
is
a
the
ability
to
like
the
newer
codecs
can
actually
copy
text
across
the
frame.
So
you
can
encode
repetitive
texts
and
patterns
very
well.
It's
has
a
huge
number
of
downsides
when
you
enable
that
feature.
F
So,
if
you
imagine
it
as
posting
as
a
hint
I'm
going
to
feed
him
wrong
here,
you're
going
to
destroy
the
fold
of
your
video,
so
it's
very
it's
kind
of
a
thing.
They
easily
get
run
on
the
user
side
and
likewise
there's
something
that's
you
could
hint
the
type
of
content
like
you
know,
text
like
your
image
like
and
maybe
the
viewer
distance,
and
that
lets
you
choose
some
things
like
perceptual,
optimization
and
quantization.
It's
it's.
F
You
know
getting
this
wrong,
isn't
so
bad,
but
also
is
something
that
encoder
can
choose
orally
by
itself,
so
the
benefit
is
rather
small
and
it's
also
very
codec
specific,
a
very
encoder
implementation
specific.
A
So
we're
trying
to
come
to
a
decision
on
what
to
do
about
all
of
this,
and
the
kind
of
decisions
we
could
make
is,
we
could
say
it's
out
of
the
scope
of
the
working
group
will
ignore
it.
P
proposed
solution,
namely
the
content,
hits
is
good
or
we
want
some
other
solution
or
combination
of
solutions.
G
G
There
are
some
questions
to
resolve,
particularly
as
to
where
the
hints
would
live
and
how
you
would
specify
them
whether
they
would
be
part
of
media
stream
tracks,
which
I
believe
is
a
current
proposal
on
the
table
from
people
or
whether
or
not
they
would
be
something
that
is
a
property
of
the
sinks
that
is
directly
controlled
by
the
application.
Okay,
particularly
this
there.
G
You
know
some
of
the
issues
involved
like
what
happens
when,
when
data
gets
transformed
through,
say,
Web,
Audio
or
other
things
that
that
that
transform
it
or
recreate
streams
from
previous
content
except
or
do
these
do
these
carry
across
you
have
to
patch
across
it
by
hand
all
these
sorts
of
things
you
it's
certainly
possible
to
put
this
as
an
application
put
this
attach
this
to
a
stream
or
whatever.
If
you
want
yeah
and
then
have
code
that
looks
at
the
stream
and
decides
whether
what
to
do
with
it,
so
you
can
do
that.
G
A
G
So
it's
a
sink
for
a
media
stream.
Okay,
the
media
stream
stuff
goes
in
somewhere
and
that
you
do
something
with
it,
so
that
that's
that's
where
that
so
that
would
occur
there.
The
second
question
about
this
would
be
how
you
define
what
sort
of
things
you
tag
stuff
with.
You
know
what
is
the
list
of
tags?
How
does
this
get?
What
happens
if
we
have
new
tags?
G
We
want
to
add
how
does
this
map
to
what
things
do
to
a
certain
extent,
this
is
the
the
the
job
of
the
particular
sink
to
decide
what
to
do
with
it.
Okay,
there's
another
reason
why
I
was
thinking
putting
it
on
the
sink
made.
Some
sense
so
I
know
there's
some
alternative
arguments,
so
I'll
stop
talking
for
now,
I.
C
Had
one
comment
similar
to
Randall's
in
that,
if
this
is
a
property
I'm
wondering
if
there's
a
president
in
the
web
platform
for
this,
because
this
at
the
end
of
the
day,
this
really
is
a
control
surface
and
people
are
going
to
set
these
things
and
expecting
certain
behaviors.
So
it
seems
it's
a
level
of
generality
here.
That
I'm
not
sure
is
good,
because
we're
kind
of
saying
that
all
sinks
will
want
to
set
the
same
settings
for
these
things
and.
F
F
My
recommendation
is,
you
know:
basically,
the
only
hint
you'd
want
to
use
here
would
be
the
rate
control
hint
and
it
would
be
ideal
if
not
I
know.
There's
already
is
very
similar
kind
of
hint
with
aggregation.
Preference
would
be
very
nice.
Tell
me
of
one
of
those
two
I'm
worried.
If
you
know
worse-case
have
them
have
identical
language,
so.
F
Not
right
now,
I
think
a
part
of
the
problem
is
that
those
are
all
things
that
can
I
spit
on.
It
depends
for
encoder
and
can
make
the
decision,
and
a
lot
of
those
features
are
so
new
that
we
don't
know,
as
the
encoder
can
do
it
or
not,
but
certainly
specifying
a
Content
hint
Windham
coder
can
choose
it
automatically
would
be
a
mistake,
so
I
don't
think
it's
really
wise
to
specify
Oh
since
right
now
this
is
40.
D
Is
Cullen
here
so
I
I
think
that
we
need
I
mean
I
that
the
idea
that
the
codecs
just
figure
it
out
itself,
for
particularly
the
screen
share
conned
case,
has
not
worked
well
for
us
in
the
past,
so
I
think
I
I
do
want
some
way
to
at
least
have
at
least
a
minimal
type
of
hint
to
indicate
some
information
that
is
useful
to
be
a
coder
where
we
attach
that
I,
don't
really
care
I,
don't
think
it's
all
sort
of
like
shedding
like
we
get
the
right
spot,
how
general
it
is,
doesn't
really
care.
D
D
G
D
Fine
with
all
of
that,
that's
I'm
totally
on
that
page,
you
know,
there's
only
two
browsers
and
there's
only
one
codec
they're
going
to
use
so
I
care
about.
You
know,
I
mean
I'd
like
to
you
know
and
we're
just
talking
about
taking
the
bits
from
one
place
and
feeding
them
in
so
I
think
this
will
I
think
that
all
sounds
good
I
agree
with
you
that,
like
yes,
this
is
not
a
you're
on
a
command
of
what's
happening.
This
is
information
about.
What's
coming
in,
that
might
be
useful
to
the
codec.
So.
C
G
G
D
G
H
D
H
C
I
guess
I
would
love
if
there
was
a
precedent
in
the
platform,
because
we've
gotten
into
this
problem
a
little
bit
before
in
this
working
group,
with
constraints,
for
instance,
where
constraints
were
externally
fertilized
all
requirements
on
to
the
application
to
give
implementations
free,
breathing
room
to
change
devices,
whichever
way
they
wanted
within
the
envelope
of
all
constraints.
Now.
But
when
push
comes
to
shove,
what
we
end
up
caring
about
NAND
is
distant
defaults
across
browsers,
and
that
becomes
impossible.
So
that's
what
a
good.
H
It
may
be
what
you
can
care
about,
but
I
don't
think
that
this
is
universal
at
all
and
for
an
example
of
the
same
thing
in
our
own
context.
Consider
echo
translation.
We
do
not
specify
echo
cancellation
algorithm
and
we
do
those
specify
echo
cancellation
quality.
Each
browser
does
it
by
itself.
Well,
we
actually
run
the
same
code.
Death
in.
C
On
our
plan-
and
it's
quite
difficult,
but
we
and
we
hope
to
achieve
that-
you
would
have
to
basically
have
a
pre
coded
file
of
audio
and
run
it
through
the
algorithm
with
the
flag
set
or
not
set
and
there
so
some
implementations
you
might
be
able
to
detect
that
it
effectively
works
as
a
low-pass
filter
on
most
implementations.
So,
let's.
C
H
J
K
K
C
I
think
we
talked
about
this
before
and
for
audio
I
think
we
landed
on
that
content.
Hint
was
the
the
default
default
if
there
are
no
constraints,
but
there
any
if
you
have
constraints
than
those
override
content
hits
it's.
What
I
remember
discussing
if
we're
going
to
implement
this
I
think
that's
how
we
would
handle
it
important.
K
C
Is
some
overlap
because
we're
just
going
to
discuss
later
constraints
for
screen
sharing,
for
instance?
So
if
I
share
my
200,
you
know
2880
times,
1800s
60
frames-per-second
desktop
I'm,
going
to
want
to
use
constraints
to
to
make
that
palatable
to
appear
connection
and
I'm
going
to
lower
the
framerate,
and
if
I
don't
want
to
do
video
instead
on
my
downscale
it
and
have
a
high
frame
rate,
so
there's
definitely
overlap
there.
I
think
well,.
A
A
C
G
G
So
one
of
the
points
I
was
going
to
make
when
I
came
up
on
the
list.
Was
that
inherently
I
think
if
these
are
going
to
be
hints?
These
are
your
describing
various
properties
of
the
data,
as
opposed
to
twitting
controls
on
a
directly
on
the
codec
and
if
you're
describing
properties
of
the
data
data
can
have
more
than
one
property.
G
So,
for
example,
as
something
could
be
a
screen
share,
but
not
and
be
detailed,
but
or
be
a
screen
share,
but
not
be
details,
etc.
So
I
think
anything
like
this
would
need
to
be
able
to
support
it.
Properties
that
describe
it.
Okay
and
then
the
coda
can
use
the
sink,
which
would
typically
be
a
codec,
but
not
always
like
Web
Audio
is
a
sink.
For
example,
it
can
take
it,
you
can
look
at
those
or
not
as
it
sees
fit.
That's
when
something
I
disagree
with
Varun
about
is
that
this
is
not.
G
These
are
like
I
said
these
are
hints
that
describe
the
data
and
which
could
be
useful
to
a
particular
codec
or
might
not
be
a
codec.
Might
you
could
in
making
a
strong
man,
but
you
could
have
a
codec
that
whereby
it
had
no
way
to
do
something
that
like
change,
a
resolution
or
change
the
frame
rate
and
if
so,
it
would
happily
ignore
the
hint
or
an
implementation
might
or
ignore
it?
That's
fine,
okay,
you're
trying
to
help
things
as
opposed
to
directly
control.
A
I
A
I
I
didn't
really
have
a
recommendation
at
the
time
of
the
slides,
because
I
had
to
think
about
a
little
bit
more
and
I
think
I
flipped
my
position
originally
I
was
supportive
of
the
hint
I
thought
that
it
would
help
and
the
reason
why
I
thought
it
would
help
was
because
we
actually
do
provide
a
hint
today
in
a
lot
of
common
systems.
When
we
know
that
the
content
is
synthetic,
we
provide
a
screen
hint
to
the
encoder,
so
the
encoder
could
make
a
better
decision
at
one
time
now.
I
To
summarize
the
thread
that
we
had
in
a
perfect
world,
you
wouldn't
need
any
kind
of
hid
at
all.
The
encoder
would
be
smart
enough
to
dynamically
adjust
to
any
content.
It
wouldn't
need
to
know
whether
this
is
a
screen
share,
or
this
is
a
natural
video.
It
could
dynamically
adjust
and
give
you
very
sharp
detail
when
there
is
not
much
motion
and
very
good
motion
when
there
is
motion
and
sacrificing
a
little
bit
on
the
on
the
quantization.
So
in
a
perfect
world,
no
encoder
would
need
this,
but
encoders
are
not
that
sophisticated.
I
Yet
so
these
hints
are
often
given
in
practical
systems.
What
what
I'm
afraid
about
here
is
that
I
think
here
we're
talking
about
given
an
application
which
really
may
have
very
little
knowledge
of
the
content,
giving
an
application
and
ability
to
override
what
the
browser
thinks
is
the
best
mode
of
operation.
So
I
was
confused
before
I
thought
that
we
were
talking
about
maybe
internal
api's,
so
that
the
browser
can
make
sure
that
the
encoders
for
this
track
use
the
optimal
settings
that
that
I
think
is
separate
from
what
we're
talking
about
here
here.
I
We're
talking
about
an
application
override
that
if
the
browser
gets
it
wrong,
the
browser
says
I
think
it's
a
screen
share
because
you,
you
called
you
know,
you
know,
get
screen
capture,
not
give
you
no
media
capture
and
so,
and
so
the
browser
made
a
guess
that
there's
a
screen
content,
but
it's
actually
not
good
for
screen
content
settings
of
a
typical
encoder.
You
actually
use
video
content,
settings,
cuz,
you're,
sharing
a
game
or
something
like
that.
I
think
that's
a
separate
question
and
that
override
parameter
is
a
very
very
my
new
use
case.
I
And
if
you
put
this
API
out
there
I
think
you're
going
to
have
a
lot
of
applications
that
are
confused
about
thinking
that
you
need
to
set
it
and
then
the
not.
You
know
in
the
common
cases,
they're
going
to
set
it
wrong
and
you
can
have
a
worse
user
experience
than
you
intended,
except
doesn't
be
very
careful
about
whatever
we
provide.
It
has
to
be
very
clear
that
this
is
an
override
of
a
browser
option
that
should
be.
You
know.
99%
never
touched
a.
G
Counterexample
might
be
when
you're
recording,
when
you're
sending
audio,
whether
it's
spoken
voice
or
whether
it's
music,
not
you
as
the
browser,
does
not
know
that
it
would
take
quite
a
bit
of
signal
processing
to
try
to
guess
that,
and
it
still
could
be
wrong
as
because
they
could
be
that
the
music
just
happens
to
be
in
the
background,
but
you're.
Actually
caring
about
spoken
word
in
this
particular
application.
G
So
I
do
think
there
is
a
reason
for
having
this
and
I
agree
that
it's
not
a
perfect
world,
the
Codex
and
so
forth.
Can't
know
this
for
sure,
and
the
browser
can't
know
this
for
sure,
even
if
it
knows
the
source-
and
it
doesn't
necessarily
know
that
the
like
you
said
if
something
is
setting
up
a
share
of
a
game-
yes,
you're
right,
you
have
it
best
if
it
knows
that
it's
a
game
and
not
a
slideshow
okay,.
K
G
A
smart
application
might
give
you
a
way
to
say
I'm
sharing
a
screen,
but
it's
all,
but
I
but
I
buddy,
but
it's
displaying
video
I
expect
it
to
be
displaying
video
content
because
it's
for
for
games
or
have
a
twiddle
for
the
user
to
change
it.
I
agree.
There's
no
perfect
solution
here.
I
think
this
is
better
than
having
no
solution.
However,
but.
I
Let
me
get
back
to
whether
or
not
this
has
overlap
with
constraints.
Originally
I
argued
that
it
doesn't.
This
is
a
hack,
not
a
constraint,
but
now
thinking
more
deeply
I
think
you
could
accomplish
the
exact
same
things.
For
the
video
case
for
the
motion
detail
with
the
framerate
constraint,
you
could
set
a
min
frame
rate
constraint
of
one
frame
per
second
or
screen
share,
and
the
browser
should
honor
that
and
go
down
to
a
pretty
low
frame
rate.
I
If
necessary,
you
can
set
a
min
frame
rate
of
30
if
you,
if
you
absolutely
want
motion
and
that
would
accomplish
I-
think
the
same
thing
as
the
motion
detail
sitting
and
obviate
the
need
for
the
degradation
preference
as
well
so
I
think
there
probably
are
too
many
knobs
that
applications
can
can
probably
get
wrong
and
not
fully
understand
the
interaction
between
them.
Maybe
we
already
have
right
now.
I
F
Yeah
I
think
the
more
important
thing
here
is.
We
don't
want,
like
surprising
results,
I
think
our
okay
as
long
as
they're
consistent
across
browsers.
If
we
could
surprise
any
results
that
aren't
consistent
is
the
real
danger.
F
Also
just
one
thing
is
that
I
don't
think
another
example,
but
the
speech
music
example
is
probably
not
a
very
good
example,
because
opus
actually
has
a
neural
network
based
speech,
music
detector,
that's
extremely
accurate,
and
if
we
provided,
that
would
be
an
example,
something
that,
if
the
browser
provided,
if
we
added
a
hint
and
I
was
an
implementer
I
would
actually
want
to
ignore
the
hint,
because
I
would
trust
the
neural
network
actually
far
more
than
the
user
hint.
Oh.
D
I
mean
the
opus
neural
net
detector
fails
miserably
in
many
cases,
so
I
think
that's
a
great
example
of
why
automating
this
is
very
difficult,
so
I
think
we
do
need
this,
and
no
one
has
to
use
it.
It
has
to
be
well
documented
what
it
means
and
that
perhaps
it's
an
override
and
then
it
might
be
very
unwise
to
use
it.
But
if
we
have
that
information,
we
should
just
pass
on
a
lot
of
work.
We're
talking
about
passing
on
this
bit
that
allows
an
otherwise
and
so,
where
we
attach
it.
D
D
B
H
H
C
Okay,
so
I,
actually
from
hearing
from
Moe
and
others
now
I
think
this
is
a
racking
up
a
number
of
arguments
of
why
this
is
a
terrible
API,
because
a
it's
not
normatively,
enforceable
and
testable.
It's
not
on
the
object
that
you
might
expect
to
behavior
from
it's
on
the
source.
It's
descriptive,
it's
not
mandatory
and
you
also
can
risk
losing
it
because
tracks
can
be
cloned
and
copied
and
moved
around.
C
You
have
to
make
sure
to
to
copy
the
hints
along,
and
you
have
to
do
that
in
spite
of
the
fact
that
browsers,
you
might
not
see
a
difference
on
some
browsers.
So
there's
a
lot
of
chances
for
error
here
and
also
I
think
is
we
call
it
a
hint,
but
that
assumes
that
the
browser
is
smart
enough
to
know
when
to
ignore
the.
J
C
D
C
C
D
D
Uncompressed
video,
where
obviously
the
sent,
makes
no
sense
when
you're
doing
uncompressed
video
as
your
product.
You
can't
fit
this
there's
nothing
to
do
with
this
so
and
it's
also
all
of
the
codecs
are
quality
of
implementation.
We
have
new
normative
specifications
for
how
the
quality
of
the
codecs
works
around
that
all
it
is.
Is
you
can
do
something
with
a
bit
stream?
This
is
an
input
into
that
unspecified
procedure.
Just
like
everything
else
is
unspecified
with
video.
You
know,
and
so
I'm
not
I'm,
not
seeing
strong
argument,
I'm,
not
understanding
deeply.
D
D
It
is
testable
it's
just
successful.
As
echo
cancellation,
we
can
compute
SNR's
of
the
images
and
see
if
they
went
up
or
down
will
be
specified,
as
if
you
do
a
motion
thing,
you
get
better
or
crisper
or
less
detail
or
faster
changes,
and
we
would
say
it
was
greater
than
or
equal
to
zero
type
change
so
that
it
was.
You
know
if
you
didn't
do
anything.
It
was
still
unclear
within
the
test
plan
of
the
reg.
So
it's
testable
next.
That.
D
No,
it
is,
it
is
normative
in
that
this
information
must
be
passed
to
the
codec
and
the
codec
may
use
it
in
deciding
what
it
will
do.
That
is
how
it
is
normative
and
that
I'm
not
going
to
debate
with
you,
the
word
cancer
or
not
hint,
it's
just
like
actual
cancellation
and
many
of
these
other
petia
testable.
It.
C
D
D
K
H
D
G
G
How
I
took
it
no
yeah
I
think
I
think
some
of
these
might,
if
you
didn't
specify
it
in
a
constraint,
affect
them.
For
example,
if
you
said
it
was
music
okay,
perhaps
it
would
it
wouldn't
it
would
affect
echo
cancellation
by
default
if
you
did
not
constrain
it.
Well,.
D
D
I
think
we're
getting
I
think
we're
getting
about
the
essence
of
my
confusion
and
I'm
glad
we
went
through
step
by
step
so
you're
thinking
about
the
content.
Things
like
music
and
stuff
and
I
was
thinking
about
the
ones
that
sort
of
gained
versus
PowerPoint
slides
of
that
particular
detail.
Motion
playing
for
video.
So
it's.
C
D
C
C
G
Add
you
can
add
a
million
control
surfaces
to
the
code
to
the
codec
interfaces
and
give
the
application
a
ton
of
control.
This
brings
up
what
was
described
before,
which
is,
if
applications
trying
to
control
the
critics
at
that
level,
frequently
will
have
problems
doing
so
correctly,
whereas
if
you
tell
the
system,
you
know
this
is
the
type
of
content
you're
dealing
with
that
can
be.
You
know,
you
know
the
defaults,
for
that
can
be
including
brother.
G
You
can
have
both
hints
and
direct
controls
and
I
get
no
problem
with
someone
has
an
argument
for
drug
control
being
important
like
controlling
the
maximum
frame
rate
or
whatever
had
that
being
there,
but
they
are.
They
are
fundamentally
two
different
things.
One
is
basically
information
that
helps
the
codec
make
decisions
when
it
has
options.
Okay
and
and
the
other
is
a
thou
shalt.
G
I
think
that
one
of
the
bigger
questions
would
be
whether
it
goes
on
the
tracks,
which
involves
a
lot
of
making
sure
it
gets
copied
over
and
when
things
get
transformed
by
Web,
Audio
and
so
forth,
did
the
right
things
happen
or
in
or
that
the
applications
know
they
have
to
do
it
or
where
there
goes
on
this
on
the
sinks
themselves,
which
is
my
preference,
but
that
something
can
be
discussed
over
and
decided.
I
think
the
general
idea
of
having
it
is
a
good
one.
I.
C
Well,
part
of
the
argument
I
heard
about
putting
it
on
track
was
that
it
would
automatically
apply
to
multiple
sinks
and
didn't
hear
a
good
argument
for
well.
We
thought
that
would
same
control
would
be
the
right
thing
for
every,
for
instance,
mediarecorder
versus
peerconnection
that
they
would
have
the
same
requirements
about.
G
They
would
all
they
would
all
get
the
hints,
as
you
could
provide
the
hints
to
all
of
them
and
an
application
if
it
wants
to,
can
effectively
put
it
on
the
track
list,
by
adding
the
property
to
the
track
and
doing
whatever
needed
and
then
at
each
sync
it
could.
It
can
just
look
at
the
track
and
copy.
Whatever
is
there
over
to
the
to
this
sinks?
G
I
One
thing:
I
think
that
for
the
video
case,
the
main
thing
we're
talking
about
main
use
case
is:
is
a
game
versus
normal
screen
share
right,
that's
what
the
issue
itself
raises
is
that
the
settings
for
screen
content
were
poor
for
streaming
a
game.
So
why
couldn't
the
app
just
specify
a
minimum
frame
rate,
in
that
case
the
minimum
frame
rate
20
or
30?
Why
would
that
not
solve
the
issue
for
for
that
specific
use
case
constraint.
C
I
I
G
C
D
My
mouse
is
only
updating
in
one
frame
per
second,
which
is
not
really
cool,
so
instead
you
might
set
it
it.
Well,
let's
say
if
it's
under
15
grams
per
second,
we
assume
that
it's
preferring
detail
instead
of
motion,
but,
like
lots
of
stuff,
is
going
to
be
down.
You
know
you're
trying
to
do
some
game
of
the
type
jana
bars
talking
about
it's,
not
a
first-person
shooter
at
4k
at
10
frames
per
second,
and
you
actually
prefer
motion
to
detail.
D
C
We're
trying
to
define
an
API
that
will
make
sense
to
web
developers
and
they're
going
to
expect
some.
They
don't
set
things
without
expecting
something
in
return.
So
my
concern
is
just
by
the
API:
it's
just
going
to
be
a
hint
that
could
be
ignored
it.
It
makes
it
hard
to
test
it
makes
it
hard
to
implement.
G
G
Okay!
Opus
might
be
able
to
correctly
to
figure
it
out.
We
will
wait
mistakes,
for
example,
if
there's
background
music,
where
there's
someone
talking,
however,
if
you
pass
that
to
instead
g.711
g.711
isn't
going
to
care
in
the
slightest
whether
it's
spoken
word
or
music.
Okay,
when
it
comes
to
you
certainly.
E
Well,
I
would
like
to
add
one
point
like
a
semi
weekend.
Web
developer
I
would
feel
that
having
it
as
a
hint,
it's
very
clear
for
me
that
you
know
if
the
thing
does
not
behave
as
I
expect.
I
am
fine
with
it,
but
with
something
as
constant
I
would
expect
him
to
behave.
The
way
I
stated
so
having
something
as
a
hint
as
a
web
developer
I'll
be
fine
if
it
does
not
work
as
as
its
expected,
I
think
that
should
be
okay
as
long
the
spec
says.
No,
you
set
the
hint.
E
E
Developer
or
an
or
intentionally
or
and
unintentionally
can
do
many
things
wrong.
You
know
things
as
long
as
he
said
it
and,
and
the
specification
says
the
hint
is
something
the
browser
will
try,
but
it
can
do
its
best.
It's
a
solid
you
can
expect
out
of
it.
So
we
can't
expect
web
developer
thing
to
always
be
addressed,
and
this
fits
into
the
categories
so.
C
G
C
G
G
Is
keeping
the
information
so
so
I
think?
Perhaps
we
should
consider
calling
the
question
and
moving
on
right,
but
that's
what
we
want
to
do
something
here
and
shout
the
details
in
the
in
the
in
the
in
the
you
know,
requests
and
we're
and
on
the
list
and
so
forth.
I
would
bet
place
be
in
favor
of
doing
something
here
and
we
can
I'm
happy
to
hash
out
the
details
as
to
exactly
what
that
comes
out.
Spec
wise,
probably
not
the
current
exact
PR
right.
I
Now
I'm
supportive
of
this,
if
it's
clear
that
it's
an
override
I,
don't
like
the
way,
it's
currently
worded
that
it
seems
like
the
application,
has
to
tell
the
browser
about
the
content.
That
should
not
be
the
case.
It
should
only
be
if
the
application
knows
that
it
must
override
browser
default
behavior.
It
does
this
so
calling
it
something
like
content
override
or
something
like
that,
where
it's
clear
that
this
is
only
if
you
know
better
than
the
browser
about
this
content.
Should
you
set
this
I.
B
C
I
Back
in
walk
with
Randall
do
one
thing
separate
from
this
object:
figure
that
all
the
browser
vendors
are
actually
planning
to
optimize
the
encoding.
So
whether
or
not
the
application
provides
any
override,
the
browser
itself
should
give
the
optimal
encoder
settings
whether
it's
screen
or
camera
content.
I
H
H
G
Now
we
have,
there
is
code
in
there
that
you
know
has
the
concept
of
this
is
a
screen
pair
versus
this
is
not,
and
that
can
ripple
through
part
of
the
issue
is,
for
example,
when
that
should
be
set,
and
then
the
other
side
of
it,
as
you
say,
is
exactly
what
does
that
cost
in
terms
of
kinetic
parameters,
and
that
can
be
deck?
Could
not
I
certainly
definitely
put
on
our
list
to
do
I.
I
A
A
All
right
so
we're
going
to
try
to
cover
at
least
some
screen
capture
issues.
Today
we
have
11
open
issues
in
screen
capture
and
we're
going
to
try
to
talk
about
six
of
em
and
we'll
see
how
far
we
get
okay.
So
these
are
the
screen
capture
issues
we
have
and
let's
try
to
get
through
at
least
a
few
of
them
sooo
house.
Yes,.
E
E
One
by
Martine,
if
I
remember
correctly,
this
is
like
we
was
an
application,
would
go
fullscreen
full
screen,
for
example,
if
it's
the
PowerPoint,
that
user
selected
or
it
could
be
a
slight
Google,
slide
the
tab
and
when
he
goes
to
the
full
screen.
What
should
happen?
The
current
behavior
is
that
because
the
user
has
selected
application
and
when
that
goes
to
full
screen
has
total
different
window.
The
receiver
side
or
the
screen
capture
would
basically
render
a
black
screen
and
we
wanted
to
kind
of
figure
out.
How
do
we
support
this
behavior
in.
E
A
E
So
anything
at
the
API
level.
All
we
need
to
do
is
that
we
need
to
have
an
infirm,
econo
law
state
products
tickets.
If
the
browser
knows
that
the
PowerPoint
that
user
has
selected
earlier
when
it
goes
to
for
full
screen
if
they
are
related
in
some
way,
it's
the
same
window
that
went
into
a
full
screen
we
just
need
to.
Although
we
should
let
the
UA
make
the
decision-
and
we
probably
the
spec-
should
just
say
that-
and
nothing
more
needs
to
be
done
for
this
particular
issue.
So
what
do
people
think
about
that?.
C
D
A
A
You
know,
there's
the
question
about
whether
you
want
to
show
the
window
was
just
showing
the
slides
where
there
might
be,
for
example,
a
notes
window,
so
I
mean
you
could
select
a
particular
monitor
which
would
be
showing
you
know.
Often
yeah
so
I
mean
I,
actually,
I.
Think
it's
a
little
bit
more
subtle
in
this.
You
have
to
be,
might
have
to
choose
a
monitor.
You
might
have
to
choose
one
specific
window
within
an
application.
D
I
think
that,
on
a
lot
of
the
existing
apps
today,
we
found
it
very
difficult
to
select
something
that
didn't
show
the
notes
field
to
pick
a
particular
PowerPoint
window
and
I
have
that
track
correctly
versus
other
things.
So
this
may
be
like
it's
impossible
to
actually
do
exactly
what
we'd
really
want,
but
yeah
I
agree.
C
E
Yeah
I
think
the
slight.
The
reason
why
I
added
the
mold
information
here
is
because
we
have
this
a
hierarchy
of
things
where
an
application
might
have.
Several
windows
has
been
not
pointed
out.
It
can
be
single
window
in
either
case
if
user
and
selected
a
single
window,
the
PowerPoint
window,
and
that
goes
to
full
screen
and
the
browser
knows
both
are
related
to
the
same
application.
Then
then
that
should
be
allowed.
I
think
this.
This
particular
issues
was
which
is
specific
to
that
use.
K
E
G
Thing
that
I
just
something
that
we've
run
across
in
the
past,
that
I
want
to
be
careful
about,
is
timing
of
changes
and
so
forth.
We've
seen
issues
where,
if
you're,
not
careful,
resizing
of
windows
and
other
changes
like
that
arc,
miss
aren't
necessarily
picked
up
on
instantaneously
by
things,
observing
them
and
that
can
temporarily
cause
because
it's
supposed
to
not
be
seen
to
be
seen
so
it
so.
When
you
start
talking
about
these
sort
of
AK
actions
have
to
be
careful.
G
Something
something
like
a
security
thing
that
you
have
to
be
careful,
that
that
you're
guaranteed
that
the
actual
change
has
occurred
before
you
switch,
what
you're,
capturing
and
so
forth.
So
you
don't
accidentally
capture
the
the
entire
user
screen
when
it
hasn't
got
actually
gone,
fullscreen
yet
or
vice,
or
things
like
that
excess.
D
C
E
But
we
went
when
there
is
a
PowerPoint
and
you
try
to
go
full
screen
and
answers
and
we
think
quick.
Second,
you
didn't
escape
and
try
to
click
on
some
other
thing.
Then
the
full
screen
other
the
actual
window
and
something
that
was
about
to
go,
go
to
full
screen
mode.
Basically
do
not
have
a
napping
and.
E
E
C
J
C
Applying
them
to
screen
sharing
I
think
what's
different
here.
Is
that
constraints
don't
necessarily
totally
mean
the
same
thing
in
screen
sharing
but
for
background.
Firefox
has
supported
constraints
in
the
non
speculation
of
its
screen
sharing
since
many
years
now,
and
the
reason
is
because
down
scaling
is
very
critical,
because
a
lot
of
screens
are
typically
very
high
resolution,
very
high
frame
rate,
which
is
too
much
for
WebRTC.
C
So
we
find
users
really
wanted
to
be
able
to
use
constraints,
not
to
select
different
sources
but
to
apply
down
scaling
and
decimating
frame
rates
at
the
track
level,
because
we
don't
really
have
any
good
controls
for
that
on
the
sink,
and
so
there's
a
separate
issue
here.
That's
coming
up
later,
if
the
talks
about
bringing
back
constraints
as
an
argument
to
get
display
media
to
get
display
me
a
call
so
to
separate
the
issues
this
now
we're
just
talking
about
existing
usage,
which
would
be
a
track
you
get
from
screen
sharing.
C
You
would
still
have
guest
settings
yeah
you
can
examine
and
would
have
an
applied
constraints,
function
being
a
track
that
you
could
change
some
of
these
constraints.
So
so
the
two
questions
are:
what
to
support?
Should
we
implicitly
support
all
constraints
that
are
listed
under
a
camera
capture
and
media
capture
main,
or
should
we
define
them
in
the
spec?
And
the
second
one
question
is
whether
we
should
allow
cropping
or
not
for
screen
sharing
for
camera
capture.
C
There
are
some
cameras
that
have
16
by
9
modes.
Are
the
1
7
4
by
3
and
I
think
most
of
minima
tensions
at
least
Chrome,
and
we're
still
working
on
some
cropping?
We've
come
up
with
that.
We
can't
make
sense
to
crop
cameras
to
make
16
by
9,
for
instance,
out
of
camera
that
doesn't
have
it
just
support
normalizing
video
output
for
the
six
of
conferences
and
stuff,
but
screen
sharing.
It
probably
makes
very
little
sense
to
crop
because
you
can
lose
text
on
the
edges
stuff
like
that.
C
So
for
what
it's
worth,
Firefox
implementation,
all
settings
dictionaries
in
the
algorithm
have
the
same
aspect,
meaning
you
can
you
can
reduce
the
size
of
something,
but
you
cannot
change
its
aspect,
regardless
of
so.
If
you
sharing
like
a
very
portrait
window
window,
that
will
always
be
have
a
portrait
window
just
smaller,
if
we
don't
do
cropping,
then
certain
constraints,
like
aspect
ratio
and
resize
mode,
become
redundant,
because
everything
is
always
aspect
perfect.
C
It
would
still
make
sense,
perhaps
to
have
they
said
well,
we'll
have
some
informative
value
like
it
might
be
nice
to
be
able
to
from
the
screen
share
to
read
out
from
guest
headings.
The
current
aspect,
ratio,
resize
mode-
would
probably
tell
you
that
if
you
know
only
you
have
the
original
size
with
resize
mode,
be
none.
C
So
my
my
current
proposal
here
is
that
cropping
gets
complicated
and
there's
low
value,
so
that
which
are
not
a
lot
of
cropping
and
and
I
was
proposed
that
we
have
an
explicit
list
of
constraints
that,
because
I
think
implementers
to
serve
to
know
what
they
need
to
implement
for
screen.
Sharing,
specifically
I
think
there's
a
counter
argument
that
if
another
spec
adds
like
a
color
constraint
or
something
it'd
be
nice.
If
it
automatically
applied
to
screen
sharing
without
having
to
modify
the
screen,
shake
spec,
I
think
the
opposite.
C
C
C
Great,
so
another
issue
is
screen
sharing
from
iframes.
The
our
current
get
used
me
just
back
cover
calls
its
allow
user
media
I.
Think
that's
going
to
be
usurped
by
another
respect,
the
feature
policy
spec.
That
seems
to
be
the
way
forward,
to
specify
permissions
for
iframes,
which
I
believe
is
by
default.
I,
camera
and
microphone
are
not
allowed
on
iframes
unless
sorry
sandbox
iframes.
C
Unless
someone
correct
me,
if
I'm
wrong,
unless
you
specify
allows
camera
a
lot
of
people's
microphone
or
a
lot
and
then
the
question
is,
should
we
also
have
this
allowance
of
screen
sharing,
whatever
it's
called?
C
C
C
J
E
E
Then,
then,
that
the
transitive
trust
would
let
me
share
the
screen
given,
given
that
United
store
origin,
etcetera
website
which
has
started
and
and
if,
if
we
can
get
the
trust
kind
of
established,
they
then
for
for
user,
then
is
it
really
does
not
matter
if
the
origin
changes
because
I
carried
over
the
twist
first?
But
if
that's
not,
but
there
is
no
secure
way
to
establish
that
you
know
transitive,
dress,
tanks,
transitively,
then
I
understand
completely
the
risk
that
we
have
here
and
we
need
to
think
about
it.
E
D
Yeah
yeah
I
mean
we
do.
It
would
be
good
to
hear
from
Martin
I
agree
before
inside
underfoot
and
I
lead
towards
very
much.
So
we
need
to
do
something
here
to
allow
this
in
some
form
or
or
people
will
just
do
worse
things,
but
it's
like,
but
I
think
that
the
the
intermediate
thing
of
a
lot
making
I
frame
explicitly
or
a
galvan.
You
know
the
iframe
grant
permission
basis
that
disallowed
by
default.
That
seems
like
a
good
compromise
to
make
sure
that
it
doesn't
happen
accidentally
and
that
people
are
deliberately
doing
it.
D
G
G
C
I
agree
the
reason
I'm
on
the
fence,
I'm
not
saying
we
should
always
disallow
this,
because
this
problem
already
exists
with
camera
and
microphones.
This
that
who
are
you
trusting
so
that
I
think
Martin's
point
was
that
the
risk
is
just
higher
with
with
screen
sharing
attacks.
I,
don't
know
if
that's
yeah,
I
think.
G
I
agree
and
it's
seeing
as
if
sites
need
to
do
this
like
similar
the
IT
support
thing.
If
you
block
it
by
default
in
iframes
and
give
no
way
to
override
it
in
an
iframe,
then
you
constrain
the
ability
to
design
your
web
pages,
but
more
to
the
point,
it'll
encourage
people
who
have
that
need
to
not
iframe
stuff.
That
probably
should
be
I
framed
now.
You
know
and
put
it
directly
in
their
main
page,
all
right.
Third
party
Jas.
C
A
A
C
Okay,
I'll,
try
it
yeah,
so
the
original
spectrum
get
display
media
had
constraints
just
like
eight
using
media.
We
removed
that
out
of
concern
to
prevent
websites
from
influencing
users
source
selection,
because
that
was
believed
to
be
too
too
easy
to
mount
an
attack
specifically
toward
sharing
HTML
surfaces
like
it's
talked
about
earlier,
but
we
could
have
done
that
with
prose.
C
But
it
will,
however,
downscale
or
decimate
frame
rates
of
the
end
result
and
I
think
that's
more
consistent
with
gum,
and
you
see
the
code
that
I've
written
before
and
after
there.
What
you
have
to
do
previously
today
get
display.
Media
only
allows
the
value
true
and
false,
or
where
the
constraints
go
and
get
display
media.
So
we
have
to
basically
get
the
stream
get
the
track
and
then
apply
constraints
after
the
fact
I
think.