►
From YouTube: WEBRTC WG interim 2021-11-24
Description
See also the minutes of the meeting at https://www.w3.org/2021/11/24-webrtc-minutes.html
A
Yeah,
it
doesn't
doesn't
have
to
be
very
elaborate,
just
basic
decisions
that
we
reach.
That's
about
it!
Okay,
thank
you
all
right,
so
the
code
of
conduct
we
operate
under
it,
w3c
code,
ethics
and
professional
conduct
and
we're
all
passionate
about
improving
whatever
you
see,
but
let's
try
to
keep
things
cordial
and
professional.
A
A
I
don't
think
we're
gonna
need
a
poll,
but
if
so
we
can,
we
can
use
that
all
right,
so
meeting
recording
policy.
I
did
send
a
message
to
the
list
that
we
are
recording
this
particular
meeting
and
that's
been
our
policy,
but
we
are
bringing
a
poll
to
the
list
to
decide
whether
to
continue
that
or
change
it,
and
the
options
are
to
continue
to
record
and
publish
record
but
keep
the
links
private
accessible
to
working
members
only
or
don't
record.
A
A
That
requires
a
call
for
adoption
and
editors
jeffs,
don't
necessarily
represent
working
group
consensus.
The
working
group
drafts
do,
although
now
with
the
continuous
publication
policy
they're
pretty
much
the
same
thing,
which
is
a
little
bit
confusing,
but
it
is
possible
to
merge
pr's
that
lack
consensus,
but
it's
good
to
attach
a
note
indicating
what's
controversial.
If
you
do
that,
all
right,
so
here's
what's
on
the
agenda,
we
have
media
capture,
transform
harold
and
yanivar.
A
C
C
D
All
right
cool,
so
we
had
a
meeting
with
the
wg
working
group
that
covers
the
stream
spec
and
I
think
overall
they
are
receptive
to
making
readable
stream
work
with
video
frames
and
we've
filed
various
issues
and
even
discussed
solutions
that
have
been
presented
in
those
issues
and
I'm
listing
them
here.
I
do
a
thumbs
up
to
mean
theoretically
solve.
That's,
not
that's
mostly
like
a
positive
indication
or
a
sense
of
that.
This
has
been
worked
out.
D
At
least
the
discussion
seems
to
have
landed
in
a
place
where
it
sounds
like
people
think
this
is
solvable,
and
then
I
marked
a
number
of
construction
hats
to
represent
difficulty
that,
but
this
is
just
spitfalling
here.
So,
in
order
to
stream
video
frames,
we
need
to
solve
a
couple
of
things
we
want
to
avoid
buffering
in
transforms
and
as
a
proposal
to
allow
high
water
mark
zero
in
writable
streams
and
tr
transfer
streams,
and
that
seems
fairly
simple.
D
But
the
biggest
issue
remaining
issue,
I
think,
is
around
cleanup
or
like
a
chunk
life
cycle,
as
we
often
call
it,
which
is
that
we
want
to
avoid
relying
on
garbage
collection
for
video
frames
when
chunks
are
dropped
or
when
the
stream
is
errored.
And
I
think
there
are
two
proposals
being
banded
about
there.
D
And
so
that's
a
nice
tie
in
there.
If
we
can
go
that
route,
and
so
those
are
the
main
issues
and
then
at
the
bottom,
I
put
in
the
two
issues
that
we
need
in
order
to
make
t
working,
and
that
is,
we
need
to
be
able
to
clone
chunks,
because
video
frame
requires
that
and
there's
a
simple,
structured
clone
proposal
boolean.
D
That
would
be
trivial
to
add
to
solve
that,
and
then
the
other
problem
is
to
avoid
drift,
because
two
branches
can
drift
in
time
and
the
early
idea
there
was
just
to
have
a
synchronized.
True,
even
better
would
be
to
have
a
real-time
mode
where
we
can
drop
chunks
instead,
and
that
would
be
preferable.
But
there's
some
difficulty
there
if
to
implement
that.
Well,
it
would
be
simpler
to
do
if
we
had
the
closable
web
ideal
thing.
C
C
So
from
the
last
meeting
we
had
the
comparison
between
the
the
one
that
the
proposal
that
gandiva
wrote
up
and
the
one
that
I
wrote
up
and
we've
discussed
this
a
little
in
issues
on
a
major
dream-
check:
media
stream,
midi
capture,
extensions
repo
to
see
what
we
can
come
up
with
as
possible
and
a
possible
starting
point
for
working
group.
Further
work.
C
We
document
in
the
code
that
is
in
the
web
idl
the
parts
that
have
consensus
and
we
add
notes
to
reflect
the
parts
that
don't
have
consensus,
and
we
ask
the
working
group
to
adopt
this
document.
As
a
starting
point
and
aim
for
as
little
needed
as
possible
before
we're
ready
to
call
for
a
working
group,
first
public
working
drafts
next
slide.
C
We
start
from
the
aldosterone
repo
media
capture,
transform
we
mark
all
the
generating
and
consuming
apis
disability
dedicated
worker,
because
we
all
agree
that,
no
matter
what
else
it
needs
to
be
a
dedicated
worker
and
we
modify
the
media
stream
track
generator
in
line
with
the
universe,
video
track
source
proposal,
I
mean
I
don't.
The
names
are
subject
by
blackshot,
but
the
principle
should
be
clear
because
that's
what
we
seem.
C
On
so
we'll
add
the
following
notes:
that
there
is
no
consensus
on
not
adding
window
to
this
built-in
there's
no
consensus
on
whether
or
not
audio
processing
should
be
added
and
a
note
for
backwards.
For
those
who
want
to
are
worried
about
backwards,
compatibility
that
they
think
a
media
stream
check
generator
in
the
old
name
can
be
implemented
on
top
of
the
new
api
and
will
insert
some
some
sample
code
in
the
backwards
compatibility
section
or
something
that
says.
F
But
if
it's,
if
we
have
consensus
there,
then
I
think
it's
it's
good.
The
second
thing
on
the
stream.
My
understanding
was
that
we
have
the
ear
of
the
work.
What
what?
What
program
false?
So
that's
good,
but
we
still
not
have
like
when
we
asked
the
question:
are
we?
Are
you
confident
that
we
can
solve
these
issues?
It
was
the
answer
was
we
may
be
able
to
solve
those
issues,
and
I
want
something
stronger
and
we
have
a
meeting
next
week.
F
So
maybe
next
week
we'll
make
progress,
but
I
think
that
we,
the
answer
to
the
question,
should
be
something
like
yeah
the
plan.
We
need
to
work
on
it,
but
we're
confident
that
we
will
fix
the
issues
that
you
identified
and
if
we
are
getting
there,
then
I
feel
confident
that
we
add
up
this
proposal.
E
E
E
So
I
think
really,
the
question
is:
is
there
a
path
toward
and
building
on
what
geneva
was
saying
earlier?
I
think
the
the
major
question
is
really
about
the
life
cycle
of
chunks,
and
so
once
we've
convinced
ourselves
and
ideally
convinced
the
what
with
the
editors,
but
I
just
want
to
say
that,
at
the
end
of
the
day,
first
and
foremost
ourselves
and
in
particular
the
implementers
that
this
is
manageable,
then
I
think
that's
good
enough.
E
I
would
go
even
as
far
as
saying
that,
if
the
webrtc
working
group
and
where
about
tc
implementers
wants
the
streams
to
do
these
things
and
the
pressure
on
these
things,
getting
done
is
likely
to
be
very
high.
Given
the
interest
in
the
technology
and
the
particular
piece
we're
discussing,
so
I
yeah
that's
my
assessment
of
how
we
should
make
that
evaluation.
C
C
C
G
Yeah,
maybe
this
is
the
wrong
venue
for
the
question,
but
digging
into
the
closable
thing:
what
happens
if
you
don't
close
it
like
if
it
so
you're
right?
If
I
understand
it
correctly,
you're,
adding
a
method
that
needs
to
be
called
when
you,
when
the
developer
decides
that
they
finish
with
this,
this
frame,
what
happens
if
they
don't
call
it.
C
G
So
so
I
I'm
I
mean
you
know,
forgive
me
this
is
probably
maybe
too
too
deep
into
the
weeds
here,
but
but
I
feel
like
we
should.
We
need
to
be
very
clear
about
what
the
expectations
are
on
the
developers
here
and
and
allow
them
to
be
told
that
they're
not
doing
it
right
somehow,
rather
than
just
having
kind
of
random
browser
slow
down
or
weird
behaviors,
and
I
totally
agree
that
this
is
probably
not.
D
C
C
F
Win
yeah,
my
my
understanding
is
that,
honestly,
as
long
as
we
do
not
have
a
good
life
cycle
as
long
as
we
do
not
have
a
good
api
that
says:
hey
you're,
the
owner
of
the
owner,
we
really
cannot
make
progress,
so
I
feel,
like
I
feel,
much
more
positive
now
that
it
will
be
solved,
but
definitely
we
we
need
to
have.
As
dom
said,
we
need
to
be
convinced
that
we
will
have
a
solution
there.
We,
we
cannot
like,
say
hey.
F
We
might
be
able
to
survey
in
a
year
from
now.
Let's,
let's
wait
for
somebody
to
to
do
it,
I
I
I
don't
think
we
we
should
do
that.
We
should
first
state
okay.
We
are
confident
that
we
will
solve
this
problem.
We
have
this
forward.
We
do
not
have
to
wait
for
this
path
to
actually
ship
in
the
streams
spec
to
make
progress
for
sure,
but
we
we
need
to
be
confident
that
we
will
solve
it.
D
F
So
hopefully
one
of
them
will
fair,
but
when
I,
when
I
had
the
question
at
last
meeting,
the
optimism
was
very
low
for
this
particular
issue.
And
since
then
we
filed
issues
we
discussed
and
we
started
to
make
proposals,
and
I
feel
more
confident-
and
I
want
to
validate
that.
This
optimism
that
we
seem
to
have
is
actually
shared
by
everybody.
And
if
that's
the
case,
then
that
will
unblock
a
lot
of
things.
For
me.
A
A
C
You
know
my
first
experience
with
trying
to
use
streams
for
something
I
wrote.
I
wrote
a
code
that
tried
to
transfer
to
to
detach
a
stream
from
its
sink
and
attach
it
somewhere
else,
and
that
was
after
the
spec
had
been
adopted
and
had
been
out
for
a
while,
and
they
were
said
to
be
production
codes
available.
C
F
A
Yeah,
actually
part
of
the
problem
is
that
the
samples
involve
multiple
apis,
so
they
wouldn't
just
be
there's
not
a
lot.
You
can
do
just
with
media
capture,
transform
right
you,
but
samples
showing
the
whole
pipeline,
I
think,
would
be
useful,
I'm
not
sure
where
they
ought
to
go,
but
they'd
also
involve
web
codecs
and
probably
a
web
transporter
a
whole
bunch
of
stuff
yeah.
C
A
F
A
F
A
A
A
H
Yes,
hello,
yes,
can
everybody
hear
me?
Well,
yes,
at
least
one
person
okay.
So
thank
you
very
much
for
your
time,
and
here
is
what
I'm
going
to
be
presenting
about
today.
It's
region
capture
we
discussed
this
a
few
months
ago
and
now
I'm
going
to
reintroduce
the
subject
so
imagine
that
you've
got
one
tab
running
an
application.
That's
actually
composed
of
two
composite
to
a
composite
of
two
applications.
H
For
example,
you
could
have
a
presentation
and
the
video
conferencing
application
merged
into
one
which
would
have
been
convenient,
for
example,
right
now
right.
So
in
this
case
you
would
want
the
you
would
want
to
have
a
button
share
the
presentation.
You
click
that
button
you
capture
the
current
tab,
but
then
you
don't
want
to
transmit
everything
remotely,
but
rather
you
want
to
crop
it
only
to
a
content
area
right.
So
in
the
example
that
we
have
here
on
the
left,
we've
got
the
presentation
and
you
don't
even
want
all
of
the
left
side.
H
You
want
a
subsection
of
that
because
you
might
be
you
don't
want
to
take
the
speaker
nodes,
for
example.
So
obviously
we
would
want
an
api
that
would
allow
you
to
do
that
in
as
normal.
You
would
want
to
be
able
to
do
it
performantly,
robustly
and
ergonomically,
and
robustly
note
that
the
user
might
change
the
size
of
the
window.
H
Might
scroll
might
zoom
and
things
and
there
could
be
layout
changes
and
whatever
way
you
choose
to
decide
you
choose
where
to
crop
to
that
needs
to
update
really
quickly
so
that
you
don't
miscrop
some
of
the
frames,
because,
if
the
other,
if
the
remote
users,
if
remote
users,
see
the
your
speaker
nodes
for
example-
well,
that's
that
could
be
a
bit
embarrassing
and
for
the
user
and
if
they
can
see
their
own
videos
again.
Well,
that's
embarrassing
for
the
application
for
not
having
the
appropriate
level
of
polish.
H
So
we
want
to
take
care
of
those
now
note
that
in
this
example,
it
is
not.
It
is
intentionally
unclear
whether
the
presentation
is
the
top
level
document
and
it
embeds
the
video
conference,
the
other
way
around
or
something
different
altogether,
and
I
claim
that
a
good
api
would
not
actually
care
about
that
any
kind
of
application.
Whichever
way
it
constructs
it
structures
itself
would
be
able
to
use
a
good
api
next
three.
Next.
H
Thank
you
very
much.
So
I
just
want
to
take
a
step
back
and
let's
just
remember
that
it
is
currently
possible
to
already
get
the
current
ad
right
there.
You
can
call
get
display
media,
and
if
the
user
wants
to
share
the
current
tab,
they
can
choose
the
current
tab.
You
can
also
do
that
with
an
extension
and
hopefully
in
the
somewhat
near
future,
get
viewport
media
will
be
yet
another
way
that
you
can
get
that.
H
So
we
take
this
as
an
article
of
faith
that
the
user
already
started
capturing
the
current
tab,
allow
that
or
rather
allow
the
application
to
do
that
and
when
that
happens,
the
application
gets
absolutely
all
of
the
pixels
here
right
and
we
are
just
trying
to
give
it
away
to
cut
that
to
opt
into
removing
that
next
slide.
Please,
and
maybe
one
more.
H
And
I
just
want,
because
some
people
I've
spoken
to
about
this
have
misunderstood.
I
want
to
make
it
very,
very
clear
that
I'm
not
proposing
an
api
by
which
the
the
captured
content
will
decide
will
be
able
to
censor
what
can
actually
be
captured.
The
sender,
the
captured
content
is
not
the
controller
here
and
if
anybody
wants
to
suggest
some
kind
of
mechanisms
for
for
such
control
in
the
future
be
my
guest,
but
that's
not
part
of
the
current
proposal.
Previous
slide,
please.
H
So
when
we
speak
about
this,
you
might
ask
okay,
but
why
do
we
need
a
new
api
I
mean
pixels
are
frames
frames
contain.
Pixels
frames
can
be
edited
just
do
that
by
the
application,
and
I
claim
that
this
would
not
be
nearly
as
good
first
of
all
performance.
I
hope
that
it
does
not
need
much
elaboration
to
say
that
the
browser
can
do
that
a
bit
better,
because
the
browser
can
do
that
before
it
starts
shuttling.
It.
H
You
know
from
in
the
case
of
chrome's
architecture,
from
the
browser,
processor
or
gpu
process
to
the
render
process,
and
then
you
send
smaller
frames.
You've
already
gained
some
performance,
so
that's
kind
of
a
given
and
there
could
be
other
arguments
there.
Robustness
is
the
key
point
and,
as
I
mentioned
when
you
scroll
when
you
zoom,
when
you
change
the
window
size
any
way,
if
you've
got
multi
multiple
documents
in
the
tab
from
different
origins,
they're
in
different
processes
for
them
to
start
communicating.
Oh,
I
just
got
scrolled,
so
my
new.
H
H
So
if
you
start
communicating
all
between
the
various
documents
about
every
single
frame-
and
you
delay
transmitting
it
remotely
until
you've
gained
some
kind
of
confidence
that
it
is
from
before
any
kind
of
scroll
event,
etc
happened,
maybe
you
can
work
around
this,
but
if
you
want
all
three,
the
browser
needs
to
step
in
and
ergonomics.
You
know
I've
just
spoken
about,
but
obviously
if
there
is
an
api-
and
it's
not
too
complicated
to
use
that's
easier-
that's
easy
for
the
application
next
slide
double
x,
2x!
Please,
thank
you.
So.
H
So
one
more
thing
to
to
look
at
here-
and
I
think
I've
already
mentioned-
that
is
that
we
don't
really
want
to
crop
to
an
iframe
because
you
might
want
to
crop
to
some
div
or
some
other
thing
inside
of
that
iframe.
So
whatever,
when
you
call
get
display
media
from
document
x,
you
might
want
to
actually
crop
to
something.
That's
deeply
nested
several
iframes
in
next
slide.
Please!
H
So
I
propose
this
api,
which
I
hope
is
relatively
simple
and
I
later
I
will
explain
some
of
the
key
design
decisions
here,
but
basically,
when
you
want,
let's,
when
you
want,
when
there
is
something
you
know
you
might
want
to
crop
to,
you've
got
some
kind
of
content
area.
Let's
say
that
everything
goes
in
a
div.
H
For
string
you
pass
that
on
to
whichever
you
can
post
message
it
you
can
do
whatever
or
maybe
or
even
inside
of
this
very
same
document.
You
give
it
to
whoever
has
the
track
and
they
call
crop2
on
the
track
and
give
that
id.
So
next
slide,
please
so
here
maybe
I
should
have
actually
done
this.
So
imagine
that
in
the
capture
in
the
capture
target,
so
in
our
case
it
would
be
in
the
presentation.
H
It
knows
there
is
some
main
content
area
that
does
not
contain
the
speaker
nodes,
so
it
says
okay
produce
a
crop
id
for
that,
and
then
it
just
gives
the
crop
id
to
whatever
so
send
crop
id.
The
third
line
here
it
might
just
be
a
direct
call
to
start
croptaria
capture.
If
it's
everything
is
in
the
same
document,
but
otherwise
it
could
be
a
post
message
to
a
child
iframe.
It
could
be
anything
and
then
on
the
capturing
side,
which
again
could
be
the
same
or
could
be
different.
H
You
just
call
on
the
track.
You
call
prop
to
prop
id
and
then
it
starts
cropping
and
it
keeps
on
tracking
the
size.
So
whenever
the
div
gets
relayed
out
on
stuff,
like
that,
it
just
keeps
that
and
for
every
single
frame
the
frame
is
cropped
exactly
to
those
coordinates
next
slide,
please,
so
you
might
ask
okay,
why
not
coordinates?
I
think
I've
covered
that
you
might
ask.
H
Yeah,
so
sorry
this
one,
I
think,
we've
fully
covered.
So
I
yeah
so
one
more
thing,
you
might
say:
hey
it's
really
nice,
but
you
know
who
told
you
that
whatever
your
you
called
produce
crop
id
on
is
even
rectangular,
in
which
case
I
say,
that's.
Okay,
in
that
case,
we'll
just
take
the
bounding
box
of
whatever,
and
this
is
not
really
the
intended
use
case-
applications
that
you
know
it's
a
tool
when
you
get
a
tool,
you
should
use
it
sensibly.
H
If
you
use
it
unsensibly,
there
will
be
some
kind
of
very
clear
explanation
of
what
the
browser
is
going
to
do,
but
you
do
that
at
your
own
peril
and
you're
not
really
gonna
gain
anything
from
you
know
doing
silly
things
and
good
luck.
So,
let's
for
the
rest
of
the
discussion,
I
think
that
we
can
pretend
that
the
that
we've
got
a
simple
rectangular
target
next
slide.
H
H
I
think
that
it's
much
much
better.
If
you
just
say
you
trust,
embedded
content
to
just
kind
of
hand
you
over
a
crop
id
that
would
be
meaningless
if
it's
wrong
and
if
they
happen
to
guess
it
or
you
know,
get
it,
that's
not
a
problem
right,
but
then
actually
giving
them
the
track
and
therefore
access
to
all
of
the
pixels
on
the
screen
on
the
tab.
Next
slide.
Please
and
last
there
are
two
promises.
H
H
H
So
here
we've
got
two
promises
and
I
think
that
the
second
one
should
be
relatively
simple.
When
you
call
crop2,
you
get
a
promise
that
tells
you,
okay,
when
this
promise
resolves
cropping,
is
actually
going
to
take
place
because
in
before
that,
you
might
get
a
couple
of
frames
that
are
cropped
either
uncropped
or
cropped
to
whatever
target
you
set
previously,
because
remember
that
you
could
also
change
targets
whenever
you
want
right.
So
when
this
promise
resolves,
you
know
that
cropping
has
been
updated.
H
So,
for
example,
you
might
want
to
actually
you
know
start
transmitting
frames
remotely.
Only
at
that
point
produce
crop
id
also
returns
a
promise,
and
the
reason
is
that,
basically
in
the
implementation
for
chrome,
we're
going
to
produce
those
ideas
on
the
browser
process,
not
in
the
render
process
and
that's
going
to
take
some
time
and
all
of
this
propagation
of
state
needs
to
take
some
place,
and
they
imagine
that
firefox
safari
you
might
have
similar
architectures,
where
you
would
not
want
to
promise
that
you
create
the
id
immediately.
H
F
Yeah,
so
a
couple
of
observations.
First
for
the
iframe
thing
you
can
use
message
channel,
I
mean
message
sports
to
do
transferable
and
it
should
work.
So
there's
no,
no
issue
there.
If
the
issue
about
transferable
is
that
so
you
you
call
get
display,
viewport
or
get
report
media
and
then
you're
blocked
on
a
given
element.
After
transferring
it.
H
I
know
it
was
mostly
a
joke,
so
I
would
say
first,
we
don't
want
to
only
use
this
for
get
viewport
media
get
the
opportunity,
as
stated
in
the
future,
people
are
using
get
display
media
and
we
would
like
this
to
work
with
that
as
well.
That's
number
one.
We
wanted
to
work
with
extensions,
that's
number
two!
So
all
of
this
should
work
so
changes
to
get
viewport
media
are
a
bit
out
of
scope
here.
H
H
F
I
understand
that
the
the
main
benefit
I
see
from
this
proposal
is
that
it
will.
It
would
apply
to
get
display
media
equally
to
get
report
media.
That's
that's
a
clear
advantage
and
I
haven't
thought
of
ideas
that
would
allow
to
get
to
the
same
kind
of
feature
level
by
not
your
new
music
proprieties.
Maybe
ideas
are
needed
for
that.
I
will
need
you
to
think
a
little
bit
more
there
to
know
for
sure.
E
H
Yes,
so
thank
you
for
asking
that
question,
so
I
will
answer
that
specific
question,
but
beforehand
I
will
say
that,
because
of
the
limitations
of
time,
I
have
not
presented
absolutely
everything
about
the
proposal.
There
is
a
spec
draft
on
my
own
on
my
own
github
page.
I
will
link
to
it.
Actually,
you
can
just
look
it
up,
it's
1983,
region-capture
and
all
of
the
edge
cases
I
could
think
of
are
addressed
there
and
specifically
for
this
one.
E
F
Yeah,
I
just
want
to
mention
as
well
that
adding
features
like
cropping
to
get
display
media.
We.
We
know
that
capturing
get
display.
Media
browser
tabs
is
a
very
sensitive
things
and
we
want
people
to
move
away
and
if
we
add
support,
forget
display
media,
then
we
might
stick
to
get
display
media.
While
there's
v
get
report
media
which
is
safer,
so
the
more
we
provide
benefits
in
get
viewport
media
and
the
the
letter
I
didn't
get
this
the
safer.
The
web
is
and
that's
important
to
keep
in
mind.
H
I
agree
and
thank
you,
but
I
think
that
it
has
been
around
about
one
year
since
we
first
started.
Scouting
get
viewport
media.
In
this
time
a
lot
of
people
are
using
screen
sharing
and
it
is
important
for
to
address
some
of
their
concerns
and
some
of
the
things
they
need
and
not
only
keep
the
eyes
on
the
distant
future.
D
So
I
like
that
with
solving
the
underlying
problem,
I
had
like
three
specific
asks
of
things
I
would
like
to
change
in
the
api.
I
hope
that's
not
too
going
too
deep
one
is,
I
think
we
should
avoid
the
name.
We
should
avoid
id
at
any
api
that
we
add
or
otherwise
suffer
the
wrath
of
the
ping
working
group
descending
on
us.
Could
you
say
that
again,
I'm
sorry,
I
didn't
get
that
using
the
word
id
or
exposing
an
id.
D
But
all
we
need
here
is
a
handle
that
can
be
moved
around
as
a
placeholder
for
the
element
as
a
reference
to
the
element,
but
it
doesn't
need
to
leave
the
user
agent
at
any
point.
So
having
it
it'll
be
an
interface.
Let's
say
I
produce
a
hundred
ids,
a
thousand
ids
if
they're
strings.
The
use
agent
has
no
way
to
know
when
it
can
forget
about
them,
but
if
they're
interfaces
they
can
be
garbage
collected.
H
D
H
D
D
How
does
this
cropping
interact
with
those
things
and
also
apply
constraints
returns
a
promise,
and
it
also
conveniently
is
an
api
both
on
the
track,
as
well
as
on
get
display
media
and
probably
even
the
future,
get
viewport
media,
so
it
would
be
accessible,
perhaps
where
you
could,
for
instance,
in
your
current
example,
you
have
to
you
get
the
track
and
then
you
crop
it.
So
does
that
mean
that
if
you
assign
it
to
a
source
object,
is
there
a
moment
where
it's
uncropped,
for
example?
D
H
Yeah,
that
was
my
last
point.
Well,
yes,
but
that's
why
cropped
returns
promise.
So
if
you
wanted
to
you
could
just
wait
until
you
get
it,
you
call
crop
two.
You
wait
until
the
crop
to
promise
resolves
and
then,
when
you
put
it
into
a
source
object,
it
will
never
produce
any
pre-crop
things.
It
might.
D
H
I
agree
that
the
tools
that
cannot
be
misused
are
better.
There
is
a
trade
of
their.
I
think
it's
kind
of
it's
difficult
for
me
to
imagine
a
developer
to
that
calls
crop
to
andy.
Imagine
is
that
it
just
happens
immediately,
especially
if
it
returns
a
promise,
but
we
can
discuss
that
in
terms
of
using
apply
constraints.
I
I
don't
think
that
anybody
is
happy
with
constraints.
Constraints
are
already
very,
very
complicated
and
I
don't
think
that
we
would
be
making
the
prom
problem
any
better
by
leading
more
into
it.
H
Additionally,
as
far
as
I
know,
apply
constraints,
currently
it
does
not
guarantee
that
the
promise
only
gets
resolved
when
the
constraints.
Actually,
you
know
when
frames,
all
subsequent
frames
are
guaranteed
to
be
according
to
that,
but
rather
it
just
says:
okay,
you
resolve
when
you,
when
you
know
it's
okay
right
and
we,
if
we.
E
H
The
meaning
of
the
promise
we
could
things
could
go
a
bit
unexpectedly,
and
especially
given
that
constraints
are
such
a
fast
field.
You
know
making
sure
that
absolutely
every
single
one
of
those
actually
applies
to
the
next
frames
that
might
end
up
being
a
bit
more
difficult
implementation,
wise
than
we
initially
envision.
D
But
I
I
would
you
bring
up
a
good
point
about
apply
constraints,
but
it's
also
a
promise,
and
it's
perhaps
underspecified
when
applied
constraints
should
resolve
whether
it
should
wait
to
ensure
and
provide
the
guarantee
that
effects
have
been
applied.
At
that
point,
I
think
that's
a
good
idea.
I
think
we
should
fix
supply
constraints.
Otherwise
you
end
up
with
timing
issues.
Let's
say
I
want
to
crop
to
a
different
element,
but
because,
let's
say
I'm
changing
from
cropping
element
a
to
element
b,
but
because
element,
a
and
b
are
different
sizes.
D
A
Yeah,
I
I
we
have
about
15
minutes
late
left
in
this
segment.
I'm
just
wondering
if
we
understand
what
the
action
items
are,
I
don't
want
to
go
too
deep
into
the
proposal
just
to
I
want
to
understand.
You
know
what
are
the
next
steps
forward
and
make
sure
we
get
that
into
the
minutes
and
are
clear
about
that.
Are
you
asking
for
something
the
working
group
to
do
something?
A
lot.
G
So
I
like
this,
I
I've
got
it
used
for
it
today
yesterday,
the
day
before
so
I
mean
I,
I
think
it's
a.
I
think
we
should
be
doing
this
and
we
should
be
doing
this
expeditiously.
So
I'm
kind
of
I
see
the
merit
in
potentially
not
waiting
for
other
things,
and
I
think
specifically
around
the
I
like
that.
G
I
mean
I
take
the
point
about
not
calling
it
an
id,
but
but
I
like
the
idea
of
it
having
it
being
an
opaque
token
of
some
sort,
either
interface
or
string,
because
you
can
have
multiple
of
them,
so
the
the
the
the
cr,
the
the
application
that
is
is
is
being
being
captured,
can
have,
can
offer
multiple
things
and
then
the
capturer
can
can
switch
between
them
in
a
way,
that's
convenient.
So
you
you
capture
the
whole
area,
and
then
you
say:
okay!
G
Well,
I'm
going
to
zoom
in
on
on
fred
or
I'm
going
to
zoom
in
on
the
slide,
or
I
know
and
again
in
the
application,
I'm
I'm
working
on
at
the
moment.
That
would
be
really
useful.
Okay,
I
want
to
be
able
to
crop
the
drop
things
off
and
and
move
change
things
around
and
not
having
to
round
trip
to
the
other
application.
G
To
say:
hey
would
you
mind
changing
the
stream
that
you're
sending
me,
even
though
it's
exactly
the
same,
like
it's
capturing
the
same
tab,
but
I
want
to
change
the
cropping
area
to
a
different
thing.
I
think
being
able
to
do
that
really
quickly
and
easily
is,
is
a
merit
of
this
being
an
opaque
token
rather
than
transferring
a
stream.
So
I
I
do
like
this
and
I
think
it's
a
you
know
it
could.
H
Thank
you,
tim
and
obviously,
I'm
very
happy
to
hear
that
quick
question.
If
I
understood
correctly,
you
said
that
you
were
also
in
favor
of
using
an
interface
rather
than
strings,
and
I
would
like
to
ask
both
of
you
as
well
as
yanivar.
What
are
we
trying
to
guard
against
because
it
seems
to
me
like
if
the
string
escapes
the
user
agent
and
comes
back
later
like
what
does
it
really
matter?
I
mean
the
user
agent
will
just
recognize
it
as
an
unknown
string.
I
think
I'm.
G
Yanovar
as
well
here,
which
is
that
what
we're
trying
to
avoid
is
ping
we're
trying
to
avoid
a
long
discussion
about
that.
These
these
strings
are
safe
and
we
may
be
wrong.
Okay,
we
may
think
they're
safe
and
then
you'll
find
a
a
sneaky
crypto
guru.
Who
will
tell
you
that
they're
not
for
a
reason
that
we
haven't
thought
of
so
like
if
they
can't
escape
the
browser,
then
that
conversation
doesn't
crop
up.
H
G
G
H
I
appreciate
I
appreciate
that
sentiment
and
but-
and
I
would
not
push
back
on
it
at
all-
if
not
if
it
weren't
actually
blocking
my
next
proposal,
which
would
be
okay
but
allow
this
to
also
work
when
you
capture
another
tab
and
when
I
capture
another
tab,
I
want
it
to
be
relatively
easy
or
the
other
tab
to
just
export
some
kind
of
message.
Saying:
hey
here's
an
id.
I
know
not
an
id.
H
G
H
Sure
I
would
just
mention
that
I
was
thinking
of
using
the
uuid,
which
at
least
would
have
resolved
some
compatibility
issues.
I
think,
but
if
you
think
that
using
something
completely
opaque,
okay,
I
see
a
chat
message
and
we
can
dom.
Would
you
like
to
take
grab
the
mic
and
explain
why
not
or
maybe
this
is
out
of
scope.
E
E
E
And
it
may
be
that
we
are,
you
know
over
concerned
about
this
and
you're
right,
but
I
don't
think
we
are
going
to
solve
this
and
I
don't
think
we
need
to
solve
this
for
your
purpose.
It's
I
understand
there
is
a
phase
two
that
you
are
worried
about,
but
to
team
spawn.
I
think
you
should,
let's,
let's
figure
out
phase
one
first
before.
H
Sure
I
just
want
to
give
you
the
pleasure
of
being
able
to
say
we
told
you
so
in
a
bit
and
say
that
I
would
be
surprised
if
pink
would
find
something
here,
because
this
uuid
would
be
produced
uniquely
for
the
element
and
not
outlive
the
session.
In
any
way.
If
you
reload
the
tab,
you
would
get
a
new
one,
and
you
will
tell
me
we
told
you
so
when
I
find
out
why
I
was
mistaken
and
it's
going
to
be
fun
for
everybody
involved.
F
Was
in
the
queue-
and
I
just
wanted
to
say,
if
we
go
down
with
api
talks,
I
plus
one
for
abstract
control
minus
one
for
apply
constraints.
We
should
not
go
there
and
with
regards
to
promise
to
returning
a
promise
when
the
capture
has
changed,
it's
a
difficult
topic
both
for
apply
constraints
and
for
this
particular
api.
So
the
only
thing
that
you
can
guarantee
is
that
at
the
time
the
promise
is
resolved.
E
H
So
the
intention
is
not
for
the
promise
to
say
all
of
the
previous
frames
were
cropped
this
way
or
that
way
like.
We
only
guarantee
that,
after
the
promise
resolves,
you
will
not
get
any
more
frames
that
were
cropped
to
the
old
one
right.
You
might
never
get
another
frame
ever,
but
if
you
do
get
any
one,
it
will
be
cropped
to
either
the
new
one
or
to
an
even
later
crop
target.
That's
the
promise
and.
A
C
H
My
comment,
I
agree
and
I
think
that
they
naturally
will
leave
only
like
they
are
randomly
assigned
and
then,
when
you
reload
the
page,
if
you
even
try
to
produce
the
same
one
for
the
very
same
element,
you
will
just
randomly
assign
a
different
one.
So
I
think
that
satisfied
the
condition
that
the
requirement
you've
just
cited.
A
C
E
E
A
H
H
H
D
So
yeah,
the
only
other
thing
I
would
perhaps
push
for
was
supply
constraints,
but
I
hear
un
was
not
very
fond
of
that,
so
I'll
concede
that
we
probably
won't
be
able
to
do
that.
I
have
some
concerns
with
interaction,
but
other
than
that
I
don't
see
a
reason.
We
shouldn't
try
to
resolve
that
within
github
issues.
E
E
A
All
right
so
we're
moving
on
to
the
next
work
item,
which
is
webrtc
and
the
use
cases,
so
it
seemed
apropos
to
have
a
little
quote
from
lewis
carroll
alice
asks.
Would
you
tell
me
please
which
way
I
ought
to
go
from
here,
and
that
depends
a
good
deal
on
where
you
want
to
get
to
said
the
cat?
Well,
I
don't
much
care
where
said
alex,
then
doesn't
matter
which
way
you
go.
A
So
a
little
bit
of
the
history
of
webrtc
d
use
cases.
I
looked
up.
The
first
public
working
draft
was
december,
11
2018,
and
that
was
it
seems
like
a
very
very
long
time
ago.
So,
27
months
before
the
pandemic
began
in
march
of
2020
and
28
months
before
the
first
public
working
draft
of
web
codex.
So
web
codex
was
at
that
point
still
a
gleam
in
the
eye
of
a
few
folks.
A
A
You
know
a
lot
of
musicians
haven't
been
touring
so
they're
having
live
concerts.
So
all
this
stuff
has
happened
since
we
had
a
first
public
working
draft.
So
all
this
raises
some
questions
is:
does
the
current
document
reflect
what
the
industry
cares
about?
Secondly,
does
the
document
reflect
the
current
state
of
technology?
We've
had
considerable
technology
advances
since
the
first
public
working
draft,
and
the
third
thing
is,
is
the
are
the?
A
Are
we
on
track
to
actually
enabling
the
use
cases
that
we
have,
let
alone,
perhaps
the
the
ones
that
the
industry
is
interested
in?
At
this
point,
so
I
thought
we'd
review
what
we've
got
in
the
document
just
to
refresh
everybody's
memory,
but
also
to
look
at
where
we
are
given
the
things
that
we've
got
in
the
document
and
then
asks
some
of
the
questions
again.
A
So
we
have
three
existing
use
cases
and
by
existing
what
we
mean
are
these
are
use
cases
that
were
in
the
original
webrtc
use
cases
document
that
perhaps
we
think
we
can
do
a
little
bit
better.
So
three
of
these
sections,
one
one,
two
two
one,
two
two
and
two
three
and
just
some
observations.
What
I
try
to
do
here
is
characterize
the
type
of
requirements,
I'm
not
listing
them
all,
but
one
of
the
things
is
that
there
aren't
many
api
proposals
that
actually
address
these
existing
use
cases.
A
The
other
thing
is
looking
at
these
three
existing
use
cases.
I
guess
video
conferencing
certainly
has
become
mass
market,
but
the
other
two.
You
know
a
lot
of
things
have
happened
during
a
pandemic.
I
don't
know
that
mobile
calling
services
are
or
the
next
big
thing,
or
we
certainly
have
game
streaming.
A
I
don't
know
the
multi-party
with
voice
communications,
how
big
that
is.
So
it's
a
question
about
whether
these
use
cases
are
actually
compelling.
Are
the
ice
requirements
real
like
have
the
fact
that
we've
not
done
much
on
these
ice
things?
Is
that
really
constraining
the
adoption
of
webrtc?
If
it
is,
are
those
addressed
by
the
weber,
see
ice
document
or
or
not,
and
the
other
thing
is
in
the
video
conferencing
space?
A
A
A
A
A
A
A
Looking
over
section
38,
which
is
about
video
conferencing,
there
is
some
security
requirements
which
seem
a
little
bit
out
of
date.
One
of
them
is
non-repudiation,
which
I
don't
think
s
frame
actually
provides
and
another
is
the
use
of
the
term
perfect
forward
secrecy,
and
I
think
that
term
has
gone
out
of
use
because
there's
no
such
thing
as
perfection
in
terms
of
forward
secrecy.
A
A
Does
it
reflect
the
current
state
of
technology,
in
particular
the
web
codex?
You
know
approach
to
building
apps
and
are
we
in
terms
of
whether
we're
on
track
to
enabling
these
use
cases?
I'd
have
a
couple
of
observations.
It
appears
to
me
that
no
use
cases
have
all
the
requirements
met
by
api
proposals.
So
there's,
if
you're
looking
to
implement
any
of
these
use
cases
using
the
apis
that
we've
been
proposing
the
answers
you
can't
implement
any
of
them.
A
Only
four
of
the
11
use
cases
have
any
api
proposals,
and
that
raises
the
question
you
know.
Is
it
because
we're
not
doing
what
we
said
we're
going
to
do,
or
maybe
some
of
these
use
cases
aren't
compelling
enough
or
don't
have
consensus.
So
with
respect
to
that,
we
could
call
for
a
consensus
on
some
of
the
use
cases
and
figure
out
if
anybody's
interested.
A
I
would
also
note
that
there
are
some
areas
of
recent
interest
like
media
ingestion,
that
aren't
covered.
So
maybe
we
have
use
cases
that
we
don't
care
about
and
also
there
are
use
cases
we
do
care
about
that
aren't
in
the
document,
so
that's
possible,
but
also
in
terms
of
the
biggest
gaps.
I
would
note
that
data
transport
is
mentioned
in
seven
of
the
11
use
cases,
but
there
are
very
few
proposals,
so
that
would
include
things
you
know
ways
to
solve.
A
A
The
re-transmission
and
details
like
that
and
the
last
question
is
this
document
doesn't
really
talk
about
what
the
long-term
architecture
that
we're
moving
towards
this.
So
that
goal
I
talked
about.
Where
are
we
trying
to
go?
Are
we
trying
to
extend
webrtc?
The
document
seems
heavily
oriented
towards
that,
but
you
know,
given
that
we
have
web
codecs,
are
there
alternative
ways
to
get
to
the
same
place
like?
Are
we
trying
to
do
web
codex
over
the
data
channel
or
web
transport
or
web
codex
over
rtp?
A
A
G
F
Yeah,
thanks
for
the
presentation,
bernad
one,
so
what
we're
seeing
with
web
transport
and
so
on
is
that
a
lot
of
flexibility
is
given
and
with
webrtc
it's
it's
a
really
integrated
system
which
has
benefit
in
terms
of
efficiency
and
so
on,
but
clearly
it
seems
that
people
might
have
like
requirements
and
needs
for
some
opening,
and
some
opening
has
been
done
and
in
some
cases
I
I
don't
see
the
benefit
like
replacing
codex.
I'm
not
sure.
F
E
F
Have
the
use
cases
there
and
it
would
be
great
if
we
would
have
proposals
in
that
area.
A
generation
parsing
like
why
should
ltp
header
extensions
be
implement
fully
implemented
in
browsers
for
applications
to
use
a
particular
ftp
header
extension
rtb
header
extensions
are
usually
cheap,
so
it's
not
like.
You
need
hardware,
rtp
header
extension,
implementations
for
instance,
so
that
would
be
something
that
would
be
good
to
have
with
regards
to
mobile
boards,
as
that
team
mentioned.
F
There
is
it's
very
different
and
and
that's
an
error
which
is
user
agent
specific
somehow.
But
it
would
be
good
if
we
could
like
provide
guidelines
and
progressively
align
in
those
areas,
and
maybe
there
are
other
areas
that
are
specific
to
mobile
browsers,
that
we
should
also
try
to
to
work
on
to
make
things
more
consistent
between
oasis
yeah,
between
browsers.
A
A
A
C
C
C
A
The
reason
I
mentioned
architecture-
harold,
is,
if
you're,
that
the
document
seems
created
with
the
mindset
that
we're
going
to
extend
whatever
you
see,
which
seems
to
result
in
endless
numbers
of
extension
requirements
which
don't
seem
to
be
have
generated,
motivation
on
the
browser
vendors
to
actually
do
them,
as
opposed
to
the
web
codecs
approach.
Where
the
answer
is
yes,
if
you
want
this
extension,
go
write,
it
yourself,
which
seems
much
more
likely
to
actually
happen.
A
C
Yeah,
a
lot
of
them
have
been
implemented
or,
and
the
other
way
that
extensions
get
get
proposed
is
a
browser.
Vendor
sees
a
small
need
rights,
have
a
proposal
to
satisfy
that
small
need
and
then
comes
the
working
group
to
ask
for
that
to
be
blessed
as
an
extension,
I'm
guilty
of
several
of
those,
whether
or
not
they
fit
the
architecture
or
not,
and
it's
a
way
of
bringing
the
usability
forward,
but
it
doesn't
lead
to
a
coherent
architecture
or-
and
it
especially
doesn't
lead
to
evaluation
of
basic
principles
like
do.
We
expose
rdp.
A
Yeah
and
the
other
thing
is,
it
leads
to
the
some
of
the
problems
that
tim
mentioned
with
the
mobile
devices,
because
you're
then
asking
the
mobile
to
implement
these
zillions
of
extensions
that
you're
creating
and
the
odds
that
you'll
have
them
all
seems
low,
whereas
if
you're
asking
the
mobile
device
to
do,
you
know
two
things.
I
want
webcodex
from
you
and
I
want
rtp.
I
We,
we
hope
to
have
some
results
that
we
can
share
with
you,
and
I
will
I
drop
the
link
to
the
irc
to
the
github
issues.
So
if
you
have
thoughts,
suggestions,
metrics,
we
should
track
questions
whatever.
Let
us
know
so.
I
think
it's.
This
is
an
interesting
area,
and
I
like
this,
I
this
proposal
that
you
you've
been
baking
recently
with
the
what
we
g
streams
integration.
I
D
Yeah,
just
two
comments
is
that
I
I
think,
apart
from
funny
hats,
it
seems
like
most
of
these
use
cases
have
focused
around
peer
connection,
but
with
funny
hats,
it
does
suggest
it's
also
supposed
to
cover
media
capture.
So
I
know,
for
example,
a
lot
has
proposed
a
lot
of
interesting
use
cases
in
the
screen
sharing
space,
for
example.
So
it's
definitely
I
think
it's
the
case
that
we
have
been
working
on
things
that
maybe
aren't
covered
in
this
document,
so
that
might
be
need
to
update.
D
My
other
was
more
of
an
editorial
concern
in
that
I
know,
mozilla
takes
use
cases
pretty
seriously.
So
I
see
a
couple
of
use
cases
here
have
a
note
that
says
they
have
not
completed
a
call
for
consensus,
not
just
in
the
editor's
draft,
but
also
in
a
technical
report,
because
we
do
photo
updating
now.
J
Hi,
thanks
bernard,
so
I
think
your
document
of
the
use
cases
were
very
useful
because
in
the
funny
head
section,
I
think
in
the
next
few
months
I'll
try
to
present
at
least
four
out
of
the
eight
ones
presented.
So
today
we'll
talk
about
the
phase
detection
api
we
presented
in
the
webrtc
and
we
used
cases
breakout
session
activepak
last
month.
Okay,
next
slide
yeah.
J
The
basic
ask
was
to
make
the
api
a
bit
more
general
and
forward-looking
and
not,
and
something
for
the
future,
also
as
well,
and
not
getting
fixated
on
only
what
the
present
platform
apis
are
giving.
So
I
think
now
we
have
reworked
the
api
and
it's
general
enough,
and
we
want
to
hear
what
features
can
be
marked
for
future.
Something
like
that.
So
here
we
are
with
the
reworked
version
of
the
face
detection
api.
J
Hopefully
some
of
you
folks
had
the
chance
to
look
at
the
details
I
sent
to
the
mailing
list.
Here's
the
github
page
link
next
next
slide,
so
I'll
quickly
go
over
the
stuff
in
five
minutes
so
that
we
keep
majority
time
for
discussion.
So,
in
short,
the
first
ask,
I
think
I
guess
it
was
from
harad-
was
instead
of
a
bounding
box.
Can
we
return
a
mask,
because
that
is
something
what
meat
is
doing?
J
We
tried
to
reason
a
bit
and
even
though
right
now
there's
no
platform
api
across
all
the
os
supporting
a
mosque.
We
tried
to
accommodate
this
concept
in
this
api
by
returning
returning
a
contour.
The
number
of
points
describing
the
contour
can
be
user
defined
using
a
setting.
Let's
say
you
know,
face
detection,
num,
contour
points
we
can
bike
about
naming
later
on,
but
yeah
the
and
the
implementation
wise.
What
will
happen
is
right
now
we
can
def
default
to
a
four
point
rectangle
and
maybe
in
future.
J
If
we
can
get
a
proper
outline
contour,
we
could.
You
know
this
is
sort
of
extensible,
because
what
happens
is
like
for
normal
face
detection
in
camera.
Ipos
the
code
in
the
driver
runs
a
very
efficient
algorithm,
very
fast,
quite
accurate,
no
dnn
stuff
sim,
a
very
simple
ml
classifiers
on
cpu,
using
ss
or
on
maybe
on
gpus
also
sometimes,
but
since
the
camera
stack
always
runs
this
face
detection.
Every
time
for
aaa
algorithm
optimization,
so
the
algorithms
are
usually
hard
cascade
or
mean
local
binary
pattern.
J
So
I'm
talking
about
chrome,
os
and
windows
specifically.
So
this
brings
to
my
next
point.
Also
there
was
a
comment
about
face
mesh.
I
think
tensorflow
and
other
ml
frameworks
are
returning
up.
Quite
a
good
like
high
value,
sick
468
landmark
face
mesh
well,
most
dnns
can
return
something
similar
depending
on
the
model,
but
from
a
practical
point
of
view.
J
What's
in
the
platform
today
and
what
is
going
to
come
in
the
next
next
iteration
next
one
year
and
almost
two
years
so
no
platform
apis
are
going
to
come
up
with
face
mesh
unless
you,
you
know,
use
a
neutral
network
framework.
So
this
is
not
going
to
be
implemented
in
driver
in
the
next
one
very
near
future,
so
there's
always
a
possibility
of
happening
it,
but
it's
a
bit
far
once,
but
still
for
the
sake
of
extensibility,
and
I
mean
we
have
still
kept
the
mesh
as
a
option.
J
J
So
the
extensibility
is
up
for
discussion
so
so
regarding
face
expression,
blink
and
smile
are
some
are
something
like
which
are
universally
supported
across
all
platforms,
so
but
I've
added
a
few
more
sorry
previous
slide.
Please
yeah
thanks.
So
I've
added
a
few
more
like
anger,
disgust
fear
these
kind
of
things
which
you
know
these
are
optional.
J
Why
I
added
this
is
I
could
do
these
things
without
using
dnn
stuff,
so
using
simple
classifiers
on
top
of
the
hard
cascade
or
something
like
that,
so
so
these
things
are
still
in
the
realm
of
possibility
to
be
implemented
within
drivers
in
the
near
future.
So
I
mean
we
can
restrict
them
like
every
other
enum.
We
can
restrict
them
a
bit,
but
what
we
have
tried
is
to
give
you
all
the
options
and
then
maybe
we
can
remove
something
so
that
yeah
yeah
but
yeah
I'll
open
up
for
discussions.
Now.
J
J
C
C
C
J
J
Yeah
the
background
blur
part,
maybe
in
the
early
january
I'll,
try
to
present
the
entire
background
blur
and
replacement
stuff
because
we're,
as
I
showed
you,
the
demo,
how
we
are
working
on
it,
it's
still
a
bit
of
work
in
progress.
Yes,
you.
I
understood
your
point
that
you
wanted
face
detection
and
then,
as
a
so,
you
wanted
that
when
we
do
background
blur,
you
do
the
face
detection
and
take
over
the
you
know,
value
which
phase
detection
did.
J
G
G
G
I
I'm
worried
about
them
being
either
wrong
and
possibly
were
even
more
likely
wrong
more
wrong
for
different
subgroups
population
groups.
So
you
know
that
there
are
these.
These
things
are
famously
inaccurate,
for
particular
subgroups
or
particular
use
cases,
and
so
I
I
the
more
subjective
the
the
api
point,
the
more
that
worries
me.
J
J
D
J
J
D
E
J
D
J
A
A
In
my
mind,
is
I've
got
this
video
frame,
potentially
that's
in
a
gpu
buffer,
and
I
guess
the
machine
learning
folks
will
tell
us
on
how
to
do
the
how
to
do
the
processing
quickly,
but
I'm
getting
information
here
that
would
potentially
help
feed
into
that
background
blur
model
and
help
make
it
execute
faster.
I
guess
that's
and
I
guess
my
my
question
is
you
know
the
the
information
that's
provided,
for
example,
the
contours
and,
and
so
forth.
A
Is
it's
designed
to
help
me
process
this
thing
that's
in
the
gpu
buffer
and
I
guess
one
of
my
concerns
is
particularly
in
going
effects,
see
performance
effects
that
might
be
created.
I'm
presuming
this.
These
dictionaries
are
operating
in
maine
memory
and
I've
got
this
gpu
and
switching
back
and
forth
and
validating
caches
and
stuff
like
that.
J
J
J
J
A
Question
for
the
api
shape
is
right
right
now.
It's
it's
an
extension
to
the
media
stream
track
interface,
yes,
and
what
I'm
saying
is
I'm
thinking
of
of
you
know
the
the
machine
learning
the
background
blur
and
I
it
seems
to
me
like.
I
want
this
to
work
in
fact
on
a
video
frame
right.
Basically,
what
I'm
looking
at
I'm
I've
got
this
video
frame.
That's
come
out
of
media
capture,
transform.
I
want
to
give
it
to
you
and
you
give
me
back
the
contour
and
then
I'm
going
to
go
and
use
that
in
mind.
A
J
E
A
F
Yeah
media
stream
track
only
that
was
the
point.
If
I,
if
I
may
jump
in
jump
in,
I
had
like
very
similar
feedback
to
bernard
right
to
me.
The
thing
is,
you
have
driver
data
that
you
want
to
expose
yeah,
and
the
decision
to
expose
should
be
at
mediastream
track
level
like
yeah.
I
want
to
opt
in
into
getting
this
face,
detection
from
the
driver,
so
please
generate
it
now.
The
generated
data
should
not
be
on
media
stream
track.
It
should
be
synchronized
with
video
frames.
So.
J
F
Either
you
can
get
it
from
the
video
from
itself
or
it
should
be.
You
should
be
able
to
get
it
whenever
you
get
a
new
video
frame
through
media
media
capture
transform.
So
so
this
model
makes
sense
to
me.
The
other
comment
I
had
was
that
it's
good
to
given
the
idea
is
to
expose
driver
information,
it's
good
to
to
be
as
specific
and
as
possible,
and
there
are
things
in
that
the
driver
is
already
generated
and
that's
what
we
want
to
describe
once
the
application
has
it.
F
They
can
use
like
a
generic
metadata
mechanism
like
to
attach
metadata
to
video
frames
and
pass
it
on
to
further
transformer
and
so
on,
but
we
can
separate
the
issues
and
if
we
look
only
at
the
driver's
specific
exposure,
then
we
should
be
specific
and
not,
and
we
should
not
try
to
generalize
too
much,
because
if
we
are
generalizing
too
much
it,
it
will
become
very
hard.
So
I
would
look
at
what
drivers
are
producing
now
and
try
to
describe
that
and
application
specific
will
produce
mask
or
whatever
from
it.
A
J
Well,
I
was
thinking
next
step.
I
could
show
you
some.
I
think
I
showed
you
some
demo
and
how
it
works,
or
maybe
I
can
get
some
numbers
performance
numbers
or
something
like
that,
and
I
think
what
harold
is
telling
is
use
the
face
detection
as
a
pipe
to
background
blur.
I'm
I
I
will
try
to
experiment
with
that
part
and
I
will
try
to
also
put
up
a
pure
background
blurs
and
try
to
get
some
numbers
from
there.
E
So
we
do
what
I'm
hearing
isn't
so
much
the
pipe
to
background
blur,
but
more
of
an
architectural
point
that
the
data
should
be
exposed
at
the
frame
level
that
can
then
be
repurposed
for
bargain
blur
for
any
other
kind
of
transform.
So
I
think
it's
that
seems
to
be
the
most
consistent
feedback.
I've
heard
across.
J
E
D
H
J
C
F
Okay,
but
we
can
certainly
extend
these
objects.
I
think
we
should
get
the
discussions
in
media
capture
extensions
and
try
to
precise
the
architecture
points
there
and
which
points
should
like
for
each
point.
We
should
file
another
issue
and
and
dig
into
the
house
and
so
have
you
filed.
I
I
think
you
filed
an
issue
on
on
github
media
capture
extensions
and
we
should
probably
take
the
time
to
provide
the
feedback.
We
gave
at
least
the
architecture
points
and
describe
them
properly
so
that
you
can
work
on
them.
So.