►
From YouTube: WEBRTC WG meeting at TPAC 2021-10-28
Description
See also the minutes of the meeting https://www.w3.org/2021/10/28-webrtc-minutes.html
01:10 State of the WebRTC WG
27:39 Media Capture Transform
51:49 Wrap-up
A
Okay,
I
don't
know
that
we'll
use
polls
here,
but
we
might
just
a
reminder
just
because
a
document
is
hosted
in
wce
repo
doesn't
mean
it
implies.
Adoption
by
the
working
group.
That
requires
a
call
for
adoption
and
editor's
drafts
do
not
represent
working
group
consensus,
but
working
group,
that's
do
okay.
So
here's
the
issues
for
discussion
today,
harold
will
present
the
state
of
the
working
group
and
then
we'll
talk
about
media
caps,
transform
and
hopefully
leave
10
minutes,
we'll
wrap
up
the
next
steps.
B
B
B
Next
slide,
so
what
we
have
done
that
is
within
the
charter
work
is
that,
yes,
we
have
gotten
the
webrtc
pc
1.0
to
rec,
so
it's
a
milestone.
It's
a
status,
unfortunately,
we're
still
working
on
midi
capture
main
and
we
got
13
documents
in
the
queue
that
are,
oh
dormant,
is
probably
a
nice
width.
But
it's
I
have
a
particular
hobby
project
that
I'm
pushing
on
when
I
find
find
time
and
because
I
think
that
it
should
should
get
done,
but.
B
B
B
B
B
B
And
some
of
these
have
been
highly
controversial.
Some
of
these
have
been
a
little
bit
controversial
and
some
of
these
have
just
slid
in
so
I'm
worried
about
the
way
the
you
know.
The
group
currently
works
on
these
things
next
slide,
because
we've
had
several
discussions
across
several
github
issues.
B
B
But
so
we
have
failed
to
put
in
that
much
get
that
much
input
from
our
own
people
and
that
bad
it
might
be
because
it's
hard
to
follow
it
might
be
because
people
are
not
interested
or
it
might
be,
because
they
don't
think
that
it's
worth
a
while
to
to
comment.
But
it
makes
it
hard
to
claim
that
we're
finding
consensus-
and
that
worries
me
next
slide.
B
B
B
C
It
strikes
me
that
that
only
works
if
you
are
able
to
edit
the
source
code
of
a
major
browser
and
get
it
deployed,
but
that
that
process
is
entirely
locked
to
the
three
vendors
and
therefore
I
think
that's
how
you
get
into
the
situation
you
described.
I
mean,
I
think
gear
analysis
is
correct,
but
it's
sort
of
the
situation.
The
current
situation
is
self-reinforcing
is
the
point
I'm
trying
to
make.
I
think
you
know
making
change
is
actually
very
difficult
and
testing.
It
is
very
difficult
if
you're
not
on
the
inside.
B
Thank
you.
I
guess
sergio
yes
thank
you
sergey,
and
so
so
it's
possible
to
get
things
into
chrome,
at
least
without
being
a
googler,
but
it's
hard
it's
very
hard,
so
canon
at
least
has
had
great
success
at
getting
in
the
early
days
with
the
getting
change
change
this
to
the
spec
that
actually
got
implemented
by
yelling
at
us.
D
Yeah
so
13
documents
is
a
lot,
but
I'm
sure
like
out
of
these
30
documents,
some
of
like
already
implementations,
which
thing
of
media
recorder
or
get
display
media,
for
instance,
and,
as
I
said,
they
mostly
get
updates
when
there's
somebody
that
is
implementing
or
fixing
a
bug
in
in
a
browser
than
updating
the
the
spec.
So
somehow
there's
success
there
I
mean
media
recorder
is
shipped
and
is
being
used
and
that's
great
get
display.
D
Media
are
the
same,
so
webrt
working
group
did
a
lot
of
good
stuff
there
and
it's
just
passing
the
line
to
go
to
rec.
But
the
question
is
what
will
our
users
gain
for
going
to
rec
and
I'm
not
exactly
clear
about
the
what
benefit
we'll
get
there
so,
but
that
might
be
one
reason
why
we
have
difficulties
going
to
wreck
on
some
of
these
documents.
A
Yeah
I'd
like
to
follow
up
on
what
you
end
said,
I
think
we've
noticed,
particularly
in
the
itf
we
had
to
pare
down
the
standards
process.
There
were
too
many
stages
and
people
weren't
getting
to
the
ultimate
stage,
because
it
was
too
much
work
and
too
little
benefit,
and
I
think
the
same
thing
may
be
happening
in
the
w3c,
where
the
effort
needed
to
get
to
wreck
may
be
just
too
much.
A
B
E
F
So
I
I
want
to
talk
about
just
sort
of
two
different
things
to
sort
of
the
general
problem
you
hit
and
then
specifically
about
what
areas
we
might
want
to
look
at.
I
mean
in
in
a
very
general
sense-
and
I
this
this
isn't
something
I
think
this
working
group
can
necessarily
fix
or
anything,
but
I
think
that
when
many
of
the
people
started
webrtc,
they
saw
this
standard
of
an
api
as
a
negotiation
between
what
the
people
providing
the
api
and
what
the
people
using
the
api
needed.
F
And
if
we
could
come
to
agreement
on
that
in
the
form
of
a
spec,
then
people
would
implement
it
if
they
wanted
to
say
that
they
were
compatible
with
that
and
that
turned
out
not
to
be
true.
It
turned
out
to
be
that
the-
and
this
wasn't
you
know,
was
known
ahead
of
time.
Wasn't
like
this
big
surprise
or
something,
but
the
w3
proceed
process
gave
the
people
implementing
the
spec,
of
which
there's
really
only
you
know,
maybe
there's
two
implementations
but
many
ways.
There's
one
implementation.
It's
not.
F
Implementations
anyway,
okay,
so
there's
not
a
lot
there.
It
gave
those
people
just
a
veto
on
everything
and
that
really
changed
the
tone
of
the
conversation,
because
when
any
time
you
have
a
negotiation
where
one
per
one
group
has
ultimate
veto
of
everything,
it's
not
a
lot
of
incentive
for
the
other
group.
To
do
too
much
I
mean
they'll
do
something
I
mean
you
know
and
and
to
carol's
points
earlier,
like
lots
of
things
got
in
that
weren't,
exactly
what
maybe
one
of
the
major
browser
vendors
imagine
start
with.
F
So
I'm
not
saying
it
doesn't
didn't
work
like
we're
on
a
webrtc
call
right
now
it
worked
at
some
level,
but
when
we,
when
we
start
getting
to
you
know
I
mean
I
I
think
when
you
ask
like
why
is
this
a
one-sided
conversation?
It's
because
well
it's
a
one-sided
process
and
unless
the
browsers
are
willing
to
commit
some
resources
at
some
level
to
try
and
build
things
that
you
know
argue
hard
for
what
they
think
is
right,
but
then
build
what
we
agreed
to
versus
what
they
thought
was
right.
F
Yeah,
it's
it's
going
to
say
a
one-sided
conversation
and
a
and
again
the
w3
process
forces
it
to
be
a
one-sided
conversation.
So
we
have
to
agree
to
be
move
off
that
a
little
bit.
So
the
other
thing
that
I
want
to
hit
is
just
a
little
bit
about
what
are
the
use
cases
we
need-
and
harold
said,
like
you
know,
we're
doing
this
for
developers
and
it's
true
at
some
level,
but
we're
also
doing
it
for
internet
users.
F
F
Single
reason
why
all
of
them
push
people
off
of
that
is
because,
when
it
doesn't
work,
it's
very
hard
to
explain
to
users
what
to
do
to
fix
it.
So
I
think
we
should
look
at
some
of
the
reasons
of
like.
Why
are
people
not
using
this?
What
are
the
things
that
are
really
looking
at
and
and
not
look
at
it
from
like,
and
and
look
at
it
like
holistically
from
some
of
the
the
major
apps
which
we
would
want
to
use
it?
F
That
would
impact
you
know
millions
of
people
and
we
can
have
better
privacy
like
there's
so
many
things
we
have
better
for
them.
If
we
could,
if
they
were
using
the
web
apps
versus
the
the
you
know,
thick
versions
or
mobile
versions.
I
just
think,
though,
that
we
should
we
should
look
at.
You
know
we
just
finished
up
1.0
awesome,
you
know,
let's,
let's
go
back
and
look
at
hey.
What
are
some
of
the
things
we
got
wrong.
F
E
H
H
I
don't
agree
with
the
way
colon
represented
the
process
as
being
one-sided.
In
fact,
there
are
quite
a
few
mechanisms
for
balancing
the
conversation,
but
obviously
this
hasn't
worked
out
at
least
for
one
critical
player,
so
I
would
say
no
matter
what
the
process
allows.
The
operation
of
the
process
obviously
hasn't.
C
Yeah
so
I
kind
of
wanted
to
just
shade
what
cullen
said.
I
think
I
I
kind
of
largely
agree
with
him,
but
I
I
think
that
the
it's
kind
of
pointless
looking
backwards,
like
that,
you
know
the
the
people
we're
talking
about
who've
got
it
pushed
you
towards
the
mobile
or
the
installed
app
version
of
your.
C
We
should
be
all
over
it's
the
place
where,
like
which
needs
the
security.
It
needs
the
ease
of
use
that
webrtc
can
bring
and
and
the
zero
install
and
all
of
that
stuff
and-
and
I
there's
just
a
few
things
that
need
changing.
That
would
make
it
so
much
easier,
and
I
I
you
know
I
would
love
us
to
spend
some
time
in
that
space
and
put
some
effort
into
solving
those
few
remaining
problems
there,
mostly
around
ice.
In
my
view,.
I
Yes,
so
I
wanted
to
make
two
points.
One
is
that
I
think
companies
have
been
redirecting
from
web
to
apps
outside
of
webrtc
as
well,
especially
in
mobile,
so
sites
clearly
have
other
incentives
there
as
well,
and
I
would
say
in
webpart
you
see
having
a
web
client
is
actually
a
strength
because
you
get
a
broader
reach
of
audience
and
an
audience
typically
doesn't
want
to
install
the
software
of
the
host.
I
So
there's
that,
as
far
as
participation,
I
agree
with
everything
that's
been
said.
I
also
want
to
notice
that
it
seems
to
me
that
the
people
speaking
a
lot
have
experience
talking
in
public.
So
I
wonder,
is
the
fact
that
we're
recording
meetings
and
publishing
them
on
youtube,
discouraging
participation
in
some
way.
That's
my
comments.
A
A
Okay,
yeah
harold
pointed
out
we're
at
time
for
this
segment,
so
we'll
probably
move
on
to
the
next
part
of
the
agenda.
But
thank
you
everyone
for
comment.
I
think
this
is
probably
a
subject
which
deserves
a
little
bit
more
discussion
as
to
maybe
how
we,
how
we
change
things
or
where
we
go
from
here.
A
Okay,
so
next
segment
of
this
session
is
on
media
capture,
transform
just
like
to
recap
some
of
the
activity.
In
september
and
october,
we
had
a
call
for
consensus
for
transferable
media
stream
tracks,
which
was
successful,
and
then,
at
the
october
14th
virtual
interim,
we
had
a
discussion
of
presented
by
un
of
the
state
of
what
wg
streams,
because
there
has
been
some
issues
that
have
impacted
media
pipelines,
the
github
discussions
on
that
we're
showing
some
progress,
but
there's
no
running
code.
A
And
so
there
was
an
overall
question
about
how
we
even
coordinate
between
the
w3c
and
the.
What
wg-
and
I
think
the
outcome
of
that
and
dom
can
speak-
is
that
we
will
have
a
potential
future
meeting
with
the
what
wg
streams
editors
to
kind
of
get
a
sense
of
where
we
are
on
the
usability
of
what
wg
streams.
So
that's
a
positive.
We
also
talked
about
about
the
comparison
between
transferable
media
stream,
tracks
and
transferable,
what
wg
streams
and
basically
with
transfer
media
stream
tracks.
A
Also,
there
are
some
advantages
of
track
clone
versus
stream.t,
and
so
I
think
overall,
it
was
a
a
proposal,
at
least
that
the
transfer
media
stream
tracks
model
is
better
than
than
transferable
streams.
Although
that's,
I
think,
there's
still
some
debate
on
that.
The
other
thing
that
happened
at
the
october
14th
dinner
is
we
had
a
presentation
from
yanivar
and
harold
on
proposals
for
media
capture
transfer.
A
A
And
then
on
questions
two
and
three
somewhat
mixed
responses
on
the
issue
of
supporting
audio.
It
was
four
yes,
three,
no
one
undecided
and
one
of
the
yes
responses
was
more
like.
I
have
no
objections
to
it,
not
sure
it's
it's
a
great
idea,
but
I'm
not
gonna
object
and
then
on
question.
Three:
should
media
capture
transform
be
exposed
on
main
thread?
A
I
But
that's
not
what
happened
and
we
want.
We
went
with
promises
because
that's
the
new
higher
level
paradigm,
and
because
there
are
the
reverse
works
as
well,
meaning
callbacks
can
be
powerful
on
top
of
modern
promise.
Apis,
for
instance,
you
just
say
promise
that
then
success
callback
fail
a
callback
there's
your
callbacks.
Similarly,
if
you
want
to
use
promise
return
callbacks,
you
can
use
408
on
a
readable.
I
I
The
proposal
I
presented,
I
would
present
as
worker
first,
which
means
that
you
need
a
worker
to
access
bits
from
the
fdm
track,
but
once
you
have
your
readable,
writable
objects,
nothing
prevents
you
from
transferring
them
to
the
main
thread.
If
you
really
need
them
there
for
now.
Those
are
my
comments.
D
Yeah,
sorry,
I
was
trapped
and
I
had
to
return
so
on
this
topic.
First,
I
I
would
say
that
there
are
three
proposals
and
if
you
look
at
all
of
them,
you
will
see
that
the
universe
proposal
is
in
the
middle.
Somehow
it's
taking
like
some
bits
from
the
left
and
some
bits
from
the
right,
which
is
fine.
I
mean
that's
okay.
D
Now
I
would
say
that
it's
difficult
to
try
to
to
solve,
like
everything
and
we've
seen
that,
and
so
what
I
know
is
that
we
really
need
to
have
like
video
capture
being
like
video
transform
being
done
in
a
better
way,
and
this
is
used
and
we
need
to
solve
that,
and
that
should
be
like
the
p1.
And
if
we
look
at
that
and
just
try
to
do
that,
then
we
can.
D
A
Yeah,
I
just
have
a
comment
which
is
an
observation
on
some
of
the
things
harold
was
saying
earlier
in
the
previous
presentation,
which
is
that
one
of
the
interesting
things
about
the
new
work
we're
doing
is
it
involves
really
that
the
new,
what
I
would
call
what
people
think
of
as
webrtc
md,
is
in
fact
the
work
of
multiple
w3c
working
groups.
You
know
this
web
codex
and
the
media
working
group
there's
a
bunch
of
new
machine
learning
groups
that
have
started
up.
A
So
I
think,
there's
there's
a
there's
a
problem
here
about
overview
and
I'm
not
sure
that
any
individual
is
in
these
five
or
six
different
groups,
so
understands
all
the
interactions
and
whether
these
apis
really
are
are
coherent
and
that's
that
makes
it
very
difficult
to
answer
some
of
these
questions
and
the
answers
may
be
different
between
the
groups.
You
know
the
decisions
made
in
media
working
group
in
this
working
group,
but
the
apis
have
to
hang
together
and
I
think
that's
a
pretty
big
challenge.
B
Harold
yeah,
I
was
thinking
of
an
example
of
the
of
the
way
we
stumble
with
apis
is
that
we
managed
to
to
do
a
streams-based
api
for
insert
encoded
insertable
streams
that
used
that
didn't
quite
that
was
written
at
the
same
time
as
the
co
as
the
web
code
expect,
and
it
used
a
different
frame
frame
format,
and
it
turns
out
that
some
of
these
differences
are
actually
critical
for
making
things
work.
The
way
insertable
streams
work
now,
so
we
can't
just
say
oh
switch
formats.
B
A
A
I
I
It
only
really
indicated
major
support
for
streams
right.
It
was
pretty
lacking
in
support
for
audio
and
pretty
lacking
in
support
for
exposure
on
main
thread
so,
and
I
know
you
and
wanted
to
wait
on
the
streams
discussion,
but
as
far
as
deciding
between
these
two
proposals
that
are
they're
both
stream
based
from
my
house.
So
could
we
pare
down
the
choices,
at
least
based
on
the
decisions
on
the
cells
of
the
room
that
we
have
already
or
is
it
premature.
D
D
For
instance,
and
the
answer
to
that
is
totally
unclear
to
me
right
now
and
if
we
take
streams
right
now,
I
would
say
that
it's
causing
more
problems
than
if
we
find
if
we
design,
if,
if,
if
we,
for
instance,
take
the
api
that
I
presented
because
I
presented
that
does
not
have
all
these
issues
now.
A
future
version
of
strings
might
have
some
of
these
issues
being
solved
and
then
the
assessment
will
be
different.
D
A
Yes,
I
I
have
a
comment
on
streams,
which
is
that
the
biggest
issue
I
am
concerned
about
is
actually
none
of
the
issues
that
were
raised
in
un's
discussion,
but
the
issue
of
actually
feedback
between
the
stages.
That
is
I'm.
You
know
for
something
like
encoder
rate
control,
back
pressure
as
concept
conceptualized
in
streams
just
isn't
useful
and
that's
the
thing
you
know.
That's
the
thing
that
most
concerns
me
is:
can
we
get
good
encoder
rate
control
and
I
don't
think
that's
a
stream's
issue
per
se?
A
D
A
I
mean
I'm
happy
to
file
it,
but
I
don't
think
it's
a
stream's
issue
per
se
right.
It's
a
it's!
Just,
it's
more
of
a
feedback
thing.
It's
almost
like
I'd
almost
want
to
challenge
people
with
the
code
we
have
you
know,
can
you
actually
demonstrate
a
viable
encoder
rate
control?
I
actually
think
there.
There
may
also
be
problems
in
web
codecs,
which
may
be
more
of
an
issue
than
than
any
streams
issue
or
even
any
feedback
issue.
I
Oh
yeah,
so
I
should
say
we
didn't
have
a
conversation
with
one
of
the
editors
at
the
stream
specs
that
bernard
alluded
to
which
makes
me
quite
confident
about
the
upcoming
meeting
about
streams,
because
it
was
highlighted
that
at
least
three
of
the
issues
that
I'm
concerned
the
most
about
have
solutions
already
posted
on
github.
That
was
indicated
that
it
might
be
more
of
a
question
of
making
sure
that
those
will
have
implementations.
I
I
B
B
B
So
I
thought
then
it
because
it
would
have
stream
elements
that
were
that
were
that
either
had
to
be
understood
or
had
to
be
passed
on,
and
you
wouldn't
know
that
unless
we
know
which
one
to
do
and
unless
they're
all
fully
specified.
So
we
we
ripped
that
out,
because
we
couldn't
get
get
a
clear,
clear
consensus
on
how
what
it
should
look.
I
C
Tim
pattern-
yeah
just
just
on
that
one.
If
you
look
at
things
like
g
streamer,
the
back
channel
of
which
there
is
one
isn't
done
as
in
the
same
way
as
the
forward
channel,
it's
done
as
a
kind
of
a
like
a
a
bus,
pub
sub
type
environment,
and
so
you
can
kind
of
any
anybody
along
the
chain
can
pick
out.
Hey,
hey
this
device
is
at
this
bit
rate
or
whatever.
So
I
think
I
think
you
need
more
flexibility
for
the
back
channel
than
a
pure,
like
stacked
streams.
I
So
one
way
I
would
claim
the
current
state
we're
in
is
that
I
would
say
that
we
have
consensus
about
exposure
in
workers.
We
don't
have
consensus
about
exposure
on
main
thread.
Does
that
mean
that
we
can
proceed
since
bye,
bye,
let's
say
exposure
equals
and
then
arbitrarily
pick
window
and
dedicated
worker?