►
From YouTube: IETF108-AVTCORE-20200730-1300
Description
AVTCORE meeting session at IETF108
2020/07/30 1300
https://datatracker.ietf.org/meeting/108/proceedings/
A
I
should
be
audible,
I
think,
and
welcome
to
avt
core.
We
are
just.
It
is
what
whatever
time
it
is.
It
is
9
a.m,
u.s,
eastern,
which
it
should
be
whatever
time.
This
is
for
everybody
else,
and
I
guess
we're
probably
ready
to
get
started,
not
that
all
our
protectors
are
here
yet,
but
hopefully
they
will
trickle
in
over
the
next
few
minutes.
Our
current
plan
is
that
I
will
run
the
queue
and
bernard
will
run
the
slides.
A
How
to
use
how
to
work
in
the
meeting
of
this
virtual
meeting?
Hopefully,
you've
been
around
this
week,
you're
somewhat
familiar
with
it,
but
if
this
is
your
first
meeting,
you
should
know
these
tips.
Importantly,
please
use
headphones
because
there's
been
a
number
of
problems
with
cancellation,
not
working
well
further,
and
it's
not
always
obvious
who's
speaking
so
please
state
your
full
name
before
speaking
I'll.
Add
to
that.
A
Please
give
make
sure
that
when
you've
already
unmuted,
your
mic
give
it
a
few
seconds
to
make
sure
that
the
audio
is
kicked
in
before
setting
your
name,
because
many
people,
they
say
their
name
but
it's
clipped
and
when
you
want
to
select
edit
the
queue
select,
audio
video
or
both
just
selecting
video,
give
you
video,
but
not
audio,
which
is
probably
not
what
you
want
all
right.
A
Next
slide,
we
have
some
notetakers
who
volunteered
we
had
stefan
volunteered
to
take
them
in
word
and
alexandra.
Who
is
not
actually
here
yet.
I
guess,
unless
he's
using
a
strange
name,
I'll
volunteer
to
take
them
in
the
cody
md,
anybody
else
can
join
the
cody
md.
A
A
A
So
we
have
a
new
person
up
at
the
virtual
front
of
the
room
today,
bernard
boba,
who's
running
the
slides
has
now
become
my
co-chair.
Thank
you
to
rachel
and
ronnie
who
have
stepped
down
rachel
because
she's
in
a
new
position
in
ronnie,
because
he's
retired.
So
congratulations
to
ronnie.
For
that.
I
don't
know
if
you'll
ever
hear
this
because
he's
not
probably
doing
any
of
this
anymore.
So
congratulations
to
him
and
enjoy
his
golf
all
right.
So
our
agenda,
we
had
one
minor
agenda,
bash.
A
Since
the
first
version
of
the
agenda
went
out,
which
is
we've
added,
a
brief
presentation
on
header
extension,
encryption,
which
there
was
a
long
side,
email
discussion
about,
wasn't
on
the
list,
but
I'll
try
to
get
it
public
now,
so
hopefully
there'll
be
enough
time
for
everything
else
anyway,
and
other
than
that
you
can
see.
What's
on
the
slide,
if
anybody
has
any
comments
on
that,
let
us
know
otherwise
we'll
just
press
on
so
the
status
of
our
documents.
A
We've
had
one
since
it's
106,
since
we
didn't
meet
at
107.,
we've
had
one
document
published
so
excellent.
We
have
a
number
of
things
in
the
queue
which
are
now
moving
forward
in
the
queue
these
are
listed
in
rough
order
of
how
far
they
are
in
the
process.
A
If
you're
an
author
of
something
else,
48,
please
do
get
your
auth
48
comments
in
and
yes,
I
know
that
includes
me
and
lrr
is
a
misrep
on
frame
marking
which
we'll
get
to
in
a
moment
all
right.
Next,
so
cc
feedback
we
did.
Publication
requests
had
an
ad
review
which
had
a
number
of
minor
comments,
all
of
which
seem
pretty
straightforward.
A
So
so
then,
hopefully
the
author
should
be
able
to
get
that
done
in
the
next
little
while
vp,
the
vp9
payload,
I
believe,
is
ready
for
working
group
last
call
if
anybody
has
oh
here's
ronnie
who
is
joined,
so
I
just
you
know
repeating
what
I
said
earlier.
A
A
Otherwise,
we'll
go
ahead
and
do
that
since
I'm
an
author
on
that
I'll,
probably
have
bernard
run
that
jpeg
xs
just
had
a
draft
come
out.
I
think
two
days
ago
I
personally
haven't
had
a
chance
to
look
at
it,
but
I
had
some
comments
on
the
previous
draft,
which
it
sounds
like
from
their
description
on
the
email
list.
They
hadn't
managed
to
they've
made
some
other
changes,
but
hadn't
managed
to
get
to
my
comments
yet
which
are
about
the
sp
negotiation
so
but
that's
easy,
making
reasonable
progress.
A
How
active
they
are,
but
we'll
let
that
continue
and
then
the
one
the
one
thing
I
did
want
to
discuss
in
some
more
depth
is
frame
marking
there
was
a
working
group
last
call.
There
was
one
comment
on
that,
but
unfortunately
the
authors
never
actually
responded
to
the
comment,
so
I'm
trying
to
figure
out
what
I
want
to
do
about
that.
It's
I
think
it's
then
I
was
mo.
B
Yes,
I
can
respond
to
it.
Jonathan,
yes,
there.
There
is
an
outstanding
update
that
we
need
to
make
for
dale's
comments,
and
you
know
sorry,
I
don't
think
any
of
the
authors
have
had
a
chance
to
complete
that
I'll
I'll
I'll
get
to
that
this
week
and
and
get
that.
So
I
mean
one
possibility
I
mean
clearly.
This
has
been.
You
know.
A
Shall
I
say
not
your
highest
priority?
Would
it
be
helpful
if
we
appointed
a
new
editor
on
this
to
take
over
these
last
processes,
so
just
to
get
it
off
your
plate?.
B
I
think
I
think
the
the
comments
from
dale
were
were
long,
but
I
think
we
had
already
had
a
pass-through.
I
forgot
whether
or
not
we
actually
discussed
it
as
a
as
a
group
of
authors,
okay,
but
I'm
pretty,
I'm
pretty
sure.
I've
already
gone
through
the
entire
list
and
there
weren't
any
substantive
changes.
But
there
was
a
lot
of
clarifications
that
we
made
to
address
dale's
comments.
B
A
A
while
so
I'd
like
to
I
mean,
if
you
can
get
that
out
today,
yeah
that'd
be
the
best,
and
then
we
can
just
go
ahead
and
republic.
I
guess
this
has
been
lingering
for
far
longer
than
it
should
have
been.
A
All
right,
okay,
so
that's
all
we
had
in
the
chair
slides,
I
think
so.
First
up
will
be.
C
Very
quickly
for
the
notes,
the
regarding
the
vp9
payload
format.
I
noted
that
no
one
voiced
a
different
opinion
regarding
your
question.
Working
with
last
call,
I.
A
Hope
that's
yeah,
so
so
I
mean
I
think,
cool
yeah,
so
I
mean
my
inclinations.
Do
work
in
group
last
call
you
know,
probably
shortly
after
the
meeting.
I
don't
know
if
we
want
to
give
it
a
little
extra
time
because
we're
going
to
hit
european
vacations,
but
then
we'll
go
ahead
and
do
that,
like
I
said
I'll
probably
have
to
run
that
run.
That
call
because
I'm
an
author
on
that
and
now
gunar
is
up
for
multi-party
real-time
text.
D
Yes,
all
right,
yeah.
I
have
two
drafts
going
in
the
rear,
multi-party,
real-time
text
area
and
you
are
handling
the
slides
so
next
slide.
Please
I'll
try
to
expand
it,
so
I
see
it
better
here.
No,
that
was
not
the
right
so
first,
why
do
we
do
with
this
multi-party
real-time
text?
And
what
is
the
requirements?
D
D
I
guess
that
was
because
there
are
already
methods
for
multi-party
in
rdp
and
you
could
use
any
of
them,
but
it's
good
to
be
a
have
an
agreement
on
both
ends.
How
to
do
it
now?
There's
an
urgent
need
to
get
this
implemented.
It's
both
push
from
next
generation
emergency
services
in
usa
and
canada,
and
it's
also
required
by
the
european
accessibility
act.
D
D
So
therefore,
we
are
now
specifying
with
a
goal
to
have
it
easily
implemented
in
existing
technologies,
because
we
have
already
requirements,
for
example
in
ims,
mobiles,
and
so
the
first
draft
I
have
is
still
a
personal
draft.
It's
called
multi-party,
rtt
solutions
and
it's
on
level
auto.
Now
it
is
an
informational
draft
used
as
background
for
specification
of
the
the
other
draft.
The
standards
track
draft,
so
it
collects
requirements,
collects
possible
transport
solutions
with
pros
and
cons.
D
So
you
can
follow
there
why
one
or
some
were
selected-
and
there
are
the
single
stream
rtp
based
multi
steam,
rtp
based
and
even
webrtc
t140
data
channel
are
mentioned
there
as
possible
solutions
and
for
the
focus
on
the
standard
track
is
on
the
single
stream
rtp
based.
So
there
we
have
a
couple
of
variants
and
in
this
overview
of
the
solutions
we
also
have
session
control
solutions
with
sdp
and
centralized
sip
conference
we
have
discussing.
D
D
D
There
is
also
brief
information
on
other
aspects
like
webrtc
transport,
in
the
just
to
become
rfc.
For
that
part,
there
are
also
a
bit
about
gateways
about
the
security
encryptions
and
so
on
and
presentation.
D
E
D
D
That
will
not
be
upgraded
to
any
aware
situation
when
this
is
first
launched,
so
that
needs
to
be
kept.
Number
two
is
mixing
with
the
current
rtp
format.
The
rfc
4103
is
the
current
transport
for
real-time
text
and
number
two
is
a
description
of
how
to
use
exactly
that
format
for
multiparty,
which
gives
you
one
source
per
packet
and
mention
the
source
in
the
csrc
list.
D
Number
three
is
a
new
text:
rex
packet
format,
where
you
can
have
many
sources
per
packet
and
therefore
increase
the
source,
switching
performance,
and
we
had
discussions
back
and
forth
between
different
methods,
and
I
just
recently
had
a
move
from
the
high
performance
solution.
Number
three,
and
also
we
discussed
multi-stream
rtp
down
to
have
a
focus
on
the
rapid
and
easy
implementation
in
current
technologies.
D
D
So
and
there
is
a
figure
requirement
for
two-party.
Real-Time
text
says
saying
that
you
could
accept
a
delay
of
one
second
from
typing
to
presentation
in
two
particles
which
is
in
f700,
and
it's
likely
that
you
have
the
same
kind
of
requirements
for
multi-party.
Even
if
I
don't
know
any
research
on
that.
If
you
want
to
follow
what
one
party
types
you
want
to
have
it
in
the
same
kind
of
short
delay
or
no
delay
as
if
you
are
in
a
two
particle.
D
So
here
is
an
overview
of
the
performance.
We
have
per
solution
number
one,
the
fallback
it
has
a
varying
delay
before
it
starts
to
present
text
from
another
simultaneous
source,
usually
many
seconds,
because
in
that
method
it
is
the
bridge
that
plants
the
the
mixing
and
it
displays
and
whole
sequences
of
text
from
one
party
until
it
finds
a
good
place
to
break
and
let
another
source
be
displayed
still.
It
can
be
quite
good
if
you
have
people
ending
their
what
they
say
with
return
and
also
between
two
users.
D
It
will
be
very
good
and
number
two
is
of
course
better.
That
is
the
one
based
on
rfc
4103
there.
You
will
have
a
jerkiness
of
about
150
milliseconds
when
you
have
two
simultaneously
sending
sources:
300
milliseconds.
If
you
have
three
sources
and
750,
if
you
have
forced
sources
while
number
three
is,
has
a
very
good
performance
it
can
it
only
delays
up
to
150
milliseconds.
D
If
you
have
up
to
15
simultaneously
sending
sources.
We
have
also
discussed
rtp
multistream,
where
you
also
get
good
performance
with
up
to
five
simultaneously
sending
sources.
But
then,
if
you
have
more
simultaneous
sources
and
you
will
get
too
many
packets
per
second,
so
you
should
avoid
having
more.
D
D
The
this.
The
view
should
be
that
you
have
similar
expectations
as
for
voice
in
a
conference.
Just
usually
just
one
is
sending
voice
in
text
you
might
be
able
to
occasionally
have
a
second
source,
sending
and
well
also
in
voice.
You
have
a
second
source
saying
yes
or
no,
or
I
agree,
or
I
want
to
comment
very
brief
comments,
but
for
text
you
might
have
someone
typing
a
bit
longer
information
streams,
while
another
one
is
typing,
for
example,
in
an
emergency
call.
D
I
can
imagine
that
you
will
have
people
getting
anxious
and
eager
to
provide
more
information,
or
so
so
they
will
type.
Yes,
I
will
clarify
something:
while
the
agent
is
also
informing
in
text
so
occasionally
too,
you
might
also
have
language
translation
sending
text,
but
then
there
will
probably
not
be
more
than
one
sending
text
continuously
and
so
very
rarely
more
than
these
two
simultaneously
sending
parties,
and
the
conclusion
is
that
good
performance
at
three
sending
sources
is
sufficient
requirement
on
this.
D
D
Number
two,
the
rfc
4103
based
it
is
easy
for
the
mixer.
It
is
easy
for
current
endpoints
to
add
this
capability.
It
is
this
same
packet
format.
As
for
rc4103,
just
a
couple
of
additions
and
an
sdp
attribute
negotiation
is
added
so
that
you
can
know
that
the
end
point
is
capable
of
presenting
it,
and
this
csrc
is
the
base
for
understanding
which
source
is
currently
represented
in
the
packet
number.
D
D
Next
slide,
please
so
there
we
are
currently-
and
I
would
like
to
have
some
comments
on
the
list
or
in
the
meeting
now,
shall
we
keep
all
these
three
solutions
or
reduce
to
two
number
one?
I
see
as
required,
it's
needed
for
current
endpoints,
but
number
two
and
three
seem
to
be
overkill
to
keep
both
in
the
current
draft.
Number
two
seems
to
be
needed
for
its
timeline,
and
I
regard
it
to
be
sufficient
in
performance.
D
Number
three
seems
to
be
not
really
needed,
it's
just
too
good
to
have
for
the
performance
beyond
the
requirements,
so
my
proposal
is
now
to
move
on
with
just
number
two
and
number
one
and
number
two
future
use
may
also
take
other
directions.
For
example,
it
may
be
more
developments
on
t140
in
webrtc
data
channel.
That
is
already
mentioned,
how
that
shall
be
multi-party
handled.
D
A
A
We
should
focus
on
that.
You
know
rather
than
something
more
complicated
which
might
not
get
uptake
so
yeah.
I
would
my
personally,
I
would
say
yes,
just
let's
just
go
with
two
and
then
knock
document,
one
as
the
compatibility
fallback.
A
A
You
know
just
getting
the
rationale
and
requirements
and
all
that
I
had
personally
thought
that
you
know
maybe
it
wasn't
necessary.
You
could
just
be
you
know
around
as
an
internet
draft,
but
I
think,
given
that
there's
been
some,
you
know
discussion.
You
know
when
people
review
the
standard
document
of.
Why
did
you
take
this
approach?
It
might
be
a
useful
thing.
So
if
anybody
has
any
comments
on
that,
that
would
be
useful
anybody.
A
A
A
Yeah,
so
I
mean
we
can
do
a
column
of
if
people
think
that
adopting
the
informational
draft
would
be
a
useful
background
for
the
for
the
standard
document
and
then
then
sort
of
timing
wise.
We
want
to
get
them
both
done
at
the
same
time,
so
it
can
be
a
stable
reference
when
we
publish
the
the
standard
one
or
if
we
want
to
try
to
get
the
standard
one
button.
First,
that's
the
other
question.
Procedurally,
any
other
comments
on
that.
A
All
right
well
we're
a
bit
over
time
anyway,
so
I
guess
in
that
case,
let's
we
will.
That
sounds
like
the
very
you
know,
loose
content,
which
is
to
say
two
people
have
said.
Yes,
nobody
else
who
said
no
is
to
go
with
just
number.
You
know,
option
number
two
one
and
two
and
two
and
we'll
do
a
call
notice
to
see
what
people
want
to
adopt
the
the
informational
document
as
a
working
group,
all
right
so
just
justin
you're
up
next.
A
All
right,
so
how
much
time
do
I
have
negative
seven
minutes
but
nominally
five
okay.
E
All
right
so
rgb
header
extension,
encryption
next
slide.
E
So
over
the
past
couple
years,
we've
accumulated
a
lot
of
rtb
header
extensions
in
use.
This
is
the
output
of
what
safari
you
know
actually
generates.
If,
if
you
just
go
and
create
an
offer,
you
can
see
that
we've
used
almost
the
entire
array
of
home
byte
extensions
and
a
number
of
these
actually
have
content.
Some
of
this
has
been
discussed
in
some
of
the
security
documents
that
you
know
has
no
sensitivity.
E
Actual
audio
levels
of
speakers
can
be
perhaps
used
for
some
at
a
minimum
analysis
of
traffic,
and
possibly
you
can
just
phonemic
direction
and
there's
some
other
ones
that
are
also
sensitive
and
even
the
ones
that
aren't
super
sensitive
in
terms
of
expecting
personal
information
at
least
make
information
about
endpoints.
What
type
of
application
is
it
streaming?
Is
it
conferencing
you
know
what
kind
of
encoder
does
it
have?
Does
it
support,
hdr,
etc?
E
So
it
seems
like
there
will
be
value
in
encrypting
this.
You
know
in
2020
next
slide
at
frozen,
there's
a
fair
amount
of
unencrypted
metadata
in
the
rtp
header.
This
is
probably
not
news
to
anyone
here,
just
sort
of
sort
of
putting
this
up
for
understanding
the
entire
problem
space.
E
You
know
beyond,
like
the
just
the
header
extensions
that's
talked
about,
even
if
you
encrypt
the
header
extensions,
you
know
the
actual
ideas
of
what
header
sentences
are
being
used.
That
stuff
is
still
there
and
context
next
slide.
E
So
what
should
we
do
about
it?
Let's
try
to
encrypt
the
stuff.
You
know.
We've
already
had
a
huge
success
from
our
from
webrtc's
use
of
dts
srtp
is
mandatory
to
implement.
You
know
all
that
traffic
now
is
fully
encrypted,
and
it's
it's
also.
You
know
any
other
sort
of
apps
that
aren't
even
used
by
rtc
are.
Actually
you
know
that
traffic
is
now
mostly
encrypted
in
the
apps
we're
using
today,
including
this
one
media
next
slide
all
right.
So
what
can
we
do?
E
Rfc
6904
exists
and
what
rfc
6904
does
is
allows.
The
use
of
you
know
the
same
srtp
keying
material
to
allow
encryption
of
the
actual
rtp
header
extension
values.
E
As
you
can
see
here,
the
things
marked
in
green
are
things
that
actually
get
encrypted
by
this,
and
while
it
does
encrypt
the
those
values
and
they
can
be
sort
of
encrypted
individually,
all
that
is
negotiated,
there's
still
a
fair
amount
of
stuff
in,
like
that
header,
that
it
is
not
encrypted
exciting.
A
On
the
top
but
sorry
bernard,
can
you
make
the
slides.
E
E
All
right
so
yeah
6904,
you
know
basically
has
this
mechanism
where
you,
in
addition
to
the
headers
extensions
that
you
send
in
sdp,
that
I
showed
on
the
first
slide.
You
also
for
each
one
of
those.
You
send
an
additional
proposed
header
extension.
E
That
basically,
is
the
encrypted
form
of
the
in
that
particular
header
extension,
and
this
provides
a
fair
amount
of
flexibility,
because
you
can
turn
you
know
each
individual
header
extension
on
or
off,
but
it's
actually
fairly
complicated,
and
you
know
all
end
points
who
support
this
that
need
to
support
this
negotiation
on
an
individual
basis
of
which
header
extensions
are
used,
and
then
once
things
are
negotiated,
then,
like
that
particular
part
of
the
rtp
packet
then
gets
encrypted.
E
We
just
recently
found
that
new
bus
r2p
had
a
serious
bug
and
its
implementation
of
header
encryption
and
the
webrtc
also
had
a
pretty
serious
bug
that
caused
the
behavior
of
hetero
encryption.
To
be
the
exact
opposite
of
what
you
wanted
that
when
you
turned
on
encryption
it
actually,
you
know
failed
to
negotiate
the
the
encryption
of
the
of
the
desired
and
header
extensions
encrypted.
The
other
ones
instead,
and
so
this
is
not
a
great
state.
E
E
There
are
also
some
technical
deficiencies:
the
16
904,
I
won't
get
into
all
the
details,
but
the
bottom
line
is
that,
due
to
the
number
of
header
extensions,
we
run
out
of
one
byte,
our
header
extensions,
and
we
would
have
to
go
to
two
byte
for
the
encrypted
ones,
which
basically
means
that
encryption
wouldn't
be
free.
We'd
have
to
accept
some
rtp
pack
upload.
If,
if
we
went
down
this
route,
trying
to
use
6904
to
do
encryption
so
next
slide.
E
All
right
could
we
find
something
that
was
simpler
in
terms
of
implementation,
complexity
and
also
perhaps
encrypted
more
stuff
in
the
packet
and
didn't
have
the
drawbacks
of
6904
and
I'm
not
going
to
try
to
get
into
solutions
here,
because
I
don't
have
a
ton
of
time.
But
if
you're
interested
in
this
we're
going
to
have
a
meeting
in
two
and
a
half
hours,
we
will
try
to
get
into
those
details.
A
Oh
yeah,
so
that
meeting
is
at
against
noon
eastern
time,
which
is
what
sixth,
whatever
time
that
is:
utc
it's
1600,
yeah
yeah,
so
yeah.
So
that's
that's
listed.
Also,
that's
been
mentioned
on
the
I
just
post,
based
in
the
chat,
the
link.
It's
also
been
on
the
avt
mailing
list
and
it's
on
the
side
meetings
wiki.
So
if
you're
interested
in
that,
please
join
us
ronnie,
I'm
letting
you
in
but
you're
gonna
also
have
to
enable
your
audio
as
well
as
your
video.
A
Oops,
actually,
I
might
have
to
mute
my
video
all
right.
Ronnie.
Are
you
trying
to
share
the
screen?
What
are
you
trying
to
do?
A
All
right,
if
not
we'll,
move
on
all
right
yeah
so
anyway,
please
join
us
in
that
meeting
at
in
two
and
a
half
hours
and
let's
move
on
to
the
next
all
right.
There
you
go
ronnie.
Are
you
trying
to
share
your
slides?
A
A
Ronnie
all
right
yeah,
so
all
right.
Let's
move
on
to
the
next
person
center,
which
should.
A
F
Okay,
all
right,
that's
great!
So
good
morning,
good
afternoon,
good
evening,
my
name
is
shui.
This
presentation
is
to
update
the
rtp
period
for
bbc
since
itf
106..
The
other
authors
is
stefan
eliago
next
slide.
Please.
F
So
a
shortage
issues
is
a
bbc
spec
update
the
the
fdis,
which
is
the
final
draft
internal
standard
has
been
out
internally
in
juventus
on
july
this
year.
It's
also
concentrated
by
itu.
That
means
his
tongue
is
approved
just
waiting
for
the
public
publication
in
the
ice
website.
F
All
right
thanks,
so
this
ietf
106,
here's,
the
following
update
that
we
have
already
had
on
the
second
draft
coding
2
is
always
already
updated.
Along
with
this
266
spec.
However,
the
the
current
draft
is
not
a
complete
finish
yet,
so
we
still
have
a
lot
of
work
to
do
to
to
implement
the
new
object
from
the
fdis,
but
I
I
can
see
that
most
stuff
is
done.
Is
there
also
based
on
the
previous
agreement
we
had
on
its
106?
F
We
had
implemented
the
following,
so
we
only
support
srst,
which
is
single
streaming
single
transport
based
on
the
feedback
we
had
lack
of
implementation
on
mrsd
and
mrt
mode.
We
also
removed
the
header
removed
into
downloading
business
signaling.
So
this
is
the
this
is
we
have
discussed
on
the
ig
106
we
have
agreed
upon
so
on
the
current
draft.
We
also
implement
the
basic
sdp
section:
it's
just
it's
only
a
skeleton
there.
We
still
need
more
work
to
be
down.
F
F
So
one
of
the
things
we
still
have
a
question
is
regarding
the
the
rtp
feedback
message,
so
we
needed
to
get
a
consensus
on
this
group
which
kind
of
mode
we
need
to
support
it.
Currently,
we
think
the
soi
and
the
rpsi
mode
might
not
be
needed
and
due
to
what
we
have
found
in
this
landmark
implementations.
F
So
this
is
one
of
the
things
that
we
probably
want
to
discuss
on
the
millionaires
to
see
what
you
guys
think
the
feedback
message
for
the
on
bbc
next
slide.
Please
so
free
marking
is
a
option.
Rtp,
a
header
extension.
We
we
think
it's
going
to
be
very
useful
for
the
bbc
payload
from
and
during
the
nature
supreme
temporal
and
special
layer
support.
F
We
have
a
currently
planned,
both
short
and
long
header
extension,
which
is
under
section
9.
I
believe
the
syntax
is
pretty
much
aligned
with
the
definition
of
the
framework
draft,
but
so
the
questions
we
still
have
is
really
do.
We
need
both
short
and
long
extensions,
so
if
it
is
a
only
base,
layer
have
been
encoded.
F
So
not
sure.
The
short
extension,
I
think
is,
is
fair
enough,
but
I
doubt
it's
for
the
bbc
cases
is
only
basically
has
been
used,
so
maybe
thinking
about
a
pure
implementation
perspective,
do
we
really
need
both
headers?
So
those
are
one
of
the
things
we
probably
discussed
on
the
middle
east
next
slide.
Please
sorry,
I
run
pretty
quickly,
since
this
is
really
obvious
things
we
discussed
course
we
can
go
back
on
the
middle
list
for
the
specific
topics.
F
So
one
of
the
things
that
we
want
to
discuss
is
really
the
we
call
reserve
bit.
Sorry,
we
call
it
reserve.
It's
really
reserved
for
us
to
discuss,
for
the
fragment
unit
is
a
one
byte,
fragmented
unit
header,
since
it's
kind
of
inherited
from
hevc,
but
bbc
only
support
a
five
bit
non-header,
it's
kind
of
similar
situation
for
abc
in.
If
it's
the
case,
it
simply
discard
the
orbit,
nothing
to
do
with
it.
It's
set
at
zero
all
the
time
for
bbc,
so
we
were
asking:
what
can
we
can?
F
The
simple
idea
we
probably
have
is
really
uses
our
ability
to
identify
the
picture
boundaries
either
said
it
is
r
one
or
two
to
identify
if
it's
beginning
the
picture
or
another
picture,
but
on
the
other
hand,
since
we
have
free
marketing
already,
since
free
marketing
is
optional
right,
if
if
free
marketing
is
implemented
and
similar
functionality
has
been
proud
by
frameworking,
but
if
it's
not
implemented
the
probably
add-on
feature
I
mean
at
the
fallback
or
something
like
that.
F
So
this
is
one
of
the
things
that
we
we
want
to
initiate
discussion,
see
what
we
agreed
upon
on
that.
So
it's
not
a
really
ideal
breaker,
but
you
know
something.
We
need
to
settle
last
slide,
please
next
one.
So
there's
still
lots
of
things
going
on.
We
still
need
to
update
this
new
draft.
The
new
coding
two
updates
from
the
fdis
draft.
Also
we
needed
to
make
decisions
on
free
marketing,
which
kind
of
model
we
needed
to
support
or
both
of
them
svs
session.
F
We
expect
we
can
get
a
revision
very
soon
after
108
reviews
on
that
will
be
much
needed
and
consideration
is
pretty
straightforward
and
at
the
end
I
think
we
target
on
milestone
end
of
2020,
which
is
like
what
five
months
six
months
left.
I
think
there's
a
reasonable
time
for
us
to
complete
the
most
work
we
discussed
here
last
one
change
history,
which
is
nothing
that's
it.
C
Just
a
little
bit
more
context
regarding
this
picture:
boundary
detection,
stuff
so
vbc
includes,
in
version
one
in
some
profiles,
scalability.
C
Now,
if
you
have
a
regular
slice
at
a
slice
boundary
regular
packet,
not
a
fragmentation
unit,
but
a
regular
packet,
you
can
of
course
always
take
a
look
at
at
the
bbc
header
structure.
So
that's
relatively
easy.
C
However,
when
you
are,
when
you
have
a
fragmentation
unit,
then
you
can't
easily
identify
the
picture
boundaries
anymore
and
when
you
lose
one
of
them,
when
you
lose
one
of
those
packets,
then
you
know
because
of
the
start
and
end
it's
in
the
fragmentation
header
that
you
lost
the
fragmentation
unit,
but
you
wouldn't
know
whether
you
have
lost
a
picture
boundary
in
between
and
then
you
know
you
you
get
into
all
kinds
of
trouble
in
identifying
what
state
you
have
with
the
on
on
the
depot
side,
whether
there
is
only
a
layer
damage
only
higher
layer
damage,
then
you
just
move
on
by
decoding,
only
the
lower
layers
and
so
on,
or
whether
you
you
would
need
to
really
basically
reset
your
decoder,
because
your
your
base
layer
features
damage
that
you
have
to
start
from
scratch
and
full
intro
and
all
that.
C
So
that's
that's
the
that's
the
rationale
they
are
behind
behind
using
this
bit
and
the
rational.
While
we
think
we
can
get
away
with
it
in
the
fragmentation
unit
header
only
and
not
in
every
single
packet,
where
we
would,
in
that
case
need
additional,
an
additional
bi-data
structure
which
we
don't
want
to
spend
now
the
so
that
that's
that's
the
rationale.
C
A
You
right
so
yeah
I
mean,
I
guess
anybody
reviewing
the
draft.
Please
keep
that
in
mind,
particularly
about
the
trying
to
figure
out
the
issues
there
with
packet
loss
and
skeletal
structures,
any
other
comments
on
that
or
can
move
on
to
if
you
see
or
kind
of
over
time,
so.
F
All
right,
it's
me
again
so
again
in
the
morning
good
afternoon
and
go
to
evening
so
maybe
good
night
for
other
people,
so
here's,
the
very
short
update
for
the
ubc
drive,
updates
basic
instruction.
So
it's
a
evc
standard
for
essential
video
coding,
similar
with
other
hybrid
coding,
like
2626466
as
a
common
coding
tools,
but
a
bit
of
different
level
of
support.
F
It
is
done
by
impact
the
final
draft
and
it's
a
it's
internally
published
on
april.
So
it's
also
down
the
existing
level
is
expected
to
provide
better
transparent
licensing
options
which
are
going
on
different
customers.
F
It
has
two
profiles
of
this
profile,
which
is
a
free
of
charge,
which
of
course,
with
the
lesser
effect
performance
main
profile,
which
is
not
free.
I
mean
with
the
monster
features,
compare
the
the
coding
efficiency
evg,
obviously
is
better
than
the
gvc,
but
you
can
look
at
all
this
status
online.
F
It
also
has
a
two
byte
header
unit
design,
similar
with
each
of
c
and
bbc.
There's
nothing
new
here.
So
one
thing
you
need
to
be
proud
of
that:
ubc
only
support
temporary
scalability.
This
might
have
a
little
bit
impacted
on
the
things
we
can
do
in
this
draft,
like
frameworking.
F
Also
similar
parameters
said
to
like
sps
aps.
So
nothing
fancy
here
as
well.
If
you
want
to
know
more
about
including
two
just
please
look
at
the
draft.
It
has
most
the
current
instructions
there
next
slide,
please.
F
So,
since
this
is
still
a
individual
draft,
the
way
we
approach,
uvc
pillow
format
is
really
following
the
the
idea
of
discussion
we
had
on
the
bbc,
which
is
only
separate
srt.
We
moved
with
and
rimadani,
but
of
course
this
is
not
being
discussed
in
the
middle
east.
Unless
everybody
has
comments,
some
stuff
need
to
support
it
for
bbc.
Please
comment
on
the
trap
next
one.
F
So
what
has
been
done
in
current
draft?
So
this
is
the
summary
basically
coding
tools,
as
I
mentioned,
is
already
we
still
needed
to
finalize,
along
with
fdis
structure
and
we
implemented
now
here,
which
is
trivial.
We
also
implemented
the
pillow
structure
as
implemented
based
on
the
fdis.
F
So
next
slide,
which
is
the
last
one.
Sorry
we'll
go
so
quickly,
as
you
guys
have
any
questions.
So
here's
the
questions.
This
opening
issue
we
want
to
discuss
if
free
marketing
is
really
needed
at
all,
so
this
is
optional,
so
we
wanted
to
ask
and
then
because
bbc
is
only
supported
temporal
scalability.
Would
that
be
overkill
right?
So
we
haven't
implemented
anything
yet,
but
this
is
something
people
can
express
their
opinions.
Similar
question
on
the
rtp
rdcp
feedback
messages,
so
we
only
please
to
put
up
the
placeholder
there.
F
We
have
it
from
anything.
I
overall,
I
think
this
traffic
is
it's
pretty
good
to
ship
at
the
basic
stuff
is
implementations
there.
So
we
would
like
to
ask
if
this
current
draft
content
will
be
accepted
as
working
group
theft.
F
The
final
target
milestone
will
be,
I
think,
early
2020
pretty
much
after
bbc
draft.
So
that's
the
physic.
Both
stack
has
been
finalized
right.
No
substantial
change
will
be
made
yeah.
So
that's
it.
A
So
I
guess
first
speaking
is
individual.
I,
this
is
entirely
in
scope
of
the
payload
stuff
and
I'd
also
say
that,
insofar
as
you
know,
the
high
level
syntax
are
the
same.
This
should
the
payload
should
ideally
be
the
same
as
vvc,
because
there's
no
reason
to
make
them
different,
they're,
obviously
related
specifications
and
they're
both
you
know
our
current
notion
of
what's
the
desirable
state
of
the
art,
anybody.
A
C
Everyone
know
how
how
wisely
frame
marking
gets
deployed
I
mean
it
was.
It
was
all
on
awoke
about
two
years
ago,
but
I
haven't
seen
many
many
frame
marking
bits
on
any
wire
anywhere.
Anyone
has
any
opinion
about
that.
That's
also
the.
C
C
G
Okay,
so
this
is
about
multiplexing
updates
for
quick.
G
G
This
has
been
proved
very
popular
in
gaming,
which
basically
wants
udp
for
the
web.
So
basically
you
can
have
web
games,
communicating
things
like
location
position,
stuff
like
that,
typically
using
the
quick
datagram
extension
to
quick
and,
of
course,
webrtc
applications.
Multiplex
srtp
srtcp
stun
dtls
on
the
same
socket
as
in
rfc
7983,.
G
So
a
little
bit
of
of
history
again,
this
was
covered
in
idf
103.,
so
colin
perkins
and
lars
first
noticed
the
incompatibility
of
quick
transport
with
rfc
7983.
In
march
of
2017,
we
had
a
presentation
at
itf
100
in
abc
core.
A
solution
was
proposed
then
and
was
merged
into
quick
transport
draft
08,
and
they
confirmed
they
wanted
to
do
this.
There
were
some
issues
found
which
were
discussed
at
itf
103.
G
G
So
here's
a
brief
summary
of
the
way
things
work
in
the
current
quick
transport
draft.
Basically,
what
you
can
see
here
is
there
are
two
types
of
quick
packets
there's,
the
short
header,
packets
and
the
long
header
packets.
The
long
header
ones
are
take
up
the
code
space
192
to
255
and
the
short
header
64
to
127.
G
G
That
was
based
on
some
javascript
apis
that
were
under
development
in
w3c,
and
at
that
time,
that
trial
was
based
on
g-quick,
which
could
not
multiplex,
but
it
did
support
the
basic
features
of
quick,
bi-directional
unidirectional
streams
as
well
as
datagrams
and
since
then,
including
in
current
versions
of
chrome
and
edge.
There
is
a
quick
transport
origin
trial
which
is
client
server.
G
This
api
has
been
updated
to
support
what
wg
streams
this
implementation
origin
trial
is
compatible
with
the
transport
29.
If
you
look
at
m85
or
later
and
aio
quick,
is
this
server
side,
so
everything
works
and
again
it's.
This
has
full
support
for
all
of
the
quick
functionality,
including
streams
and
datagrams.
G
So,
given
that
we
have
a
multiplexing
spec,
it's
implemented
in
the
well,
the
the
quick
transport
29,
which
has
it
is
out
in
the
field.
Why
can't
we
just
declare
victory
well.
G
The
problem
is
that
this
quick
multiplexing
is
not
documented
rfc
7983,
because
that
was
published
before
this
stuff
came
out
and
it's
only
documented
in
an
internet
draft,
and
history
shows
that
undocumented
agreements
have
a
low
probability
of
working
out
something's
going
to
go
wrong
because
you
don't
document
the
requirements
in
the
honor
registry,
so
you
can't
flag
the
conflicting
allocations
or
even
know
what
documents
are
applicable
and
also
I've
had
various
requests
for
developers.
Hey.
G
What's
the
multiplexing
scheme,
I
don't
see
this
in
1793,
so
you're
going
to
have
probably
interoperability
problems,
because
people
won't
understand
what
to
do
so.
We've
had
these
origin
trials,
and
so
we're
rapidly
approaching
an
inflection
point.
Quick
transport
is,
is
out
there,
it's
being
used,
it's
pretty
easy
to
implement.
G
So
at
some
point,
stuff
is
probably
gonna
ship
and
once
you
have
the
client
server
version
out
there,
it's
pretty
easy
to
to
reuse
it
for
peer-to-peer
and
a
bunch
of
people
are
doing
that
as
well,
and
then
they'll
depend
on
this
multiplexing
stuff
to
work
and
if
doesn't
work,
there
will
be
consequences.
G
So
we
want
to
avoid
that,
if
possible.
So
we
have
src
7093
this
draft
and
basically
it
has
a
couple
of
purposes.
One
is
to
update
rfc
7983,
section
7,
just
to
document
what
the
multiplexing
scheme
is
that
is
supported
in
the
transport
draft
and
also
provide
a
little
bit
of
guidance
on
overhandling
overlap
between
quick
and
turn
channels.
G
It's
not
an
issue
for
webrtc,
as
I
said,
I'm
not
sure
it's
really
an
issue
for
anybody
else,
but
I
think
it's
fairly
easy
to
handle
if
anyone
cares-
and
the
second
thing
is
just
to
update
the
dtls
content
type
field,
iana
page,
I
don't
think
any
changes
to
the
page
are
needed
in
terms
of
the
allocations,
but
it
needs
to
reference
the
right
rfc.
So
when
people
look
at
that,
they'll
they'll
know
where
to
go
to
understand
what
the
multiplexing
scheme
is.
Now
one
caveat
for
this
in
quick
transport.
G
We
did
talk
about
this
and
the
agreement
really
only
applies
to
quick
version.
One
new
versions
of
quick
are
allowed
to
change
aspects
of
the
wire
image,
so
there's
no
guarantee
that
future
versions
of
quick
will
adhere
to
this
multiflexing
scheme,
but
what's
in,
but
so
we
just
want
to
make
clear.
It
only
applies
to
version
one.
G
G
All
that
needs
to
happen
is
to
reference
7983
bis
instead
of
79.83,
so
people
can
understand
what
the
scheme
is,
but
everything
else
is
is
fine
in
terms
of
the
assignments.
A
Yeah
so,
as
mentioned
we're
over
time
and
medico
needs
to
close
the
room
so
the
next
they
can
start
streaming
the
next
session.
But
if
I
think
we
probably
it
seems
to
me,
I
will
do
a
call
on
the
list
to
ask
if
you
want
to
adopt
this,
which
also
probably
they
don't
have
a
number
of
the
key
participants
there.
We
really
need
to
get
a
few
of
them
in.
A
I
know
there's
some
discussion
whether
the
qubit
is
sticking
around,
so
we'll
do
a
call
on
the
list,
bernard's,
author
and
since
we
are
indeed
12
minutes
over
time.
That's
it
thank
everybody
for
coming
and
we
will
see
you
probably
virtually
in
virtual
bangkok.