►
From YouTube: IETF-AVTCORE-20230926-1500
Description
AVTCORE interim meeting session
2023/09/26 1500
https://datatracker.ietf.org/group/avtcore/meetings/
A
A
A
So
please
make
yourself
aware
of
that
and
then
in
addition,
the
ITF
is
intended
for
professional
collaboration
networking
and
there
are
standards
of
conduct.
We
have
an
anti-harassment
policy
and
and
procedures
for
that,
and
hopefully
none
of
those
things
will
come
up
here,
but
if
they
do,
you
can
talk
to
the
Ombudsman.
A
A
D
G
A
G
F
F
A
A
F
Right
so
yeah
so
about
this
meeting,
as
mentioned,
Spencer
has
volunteered
to
take
notes,
but
he
is
also
presenting.
So
please
somebody
else
volunteer
to
write
down
any
important
action
items.
While
he
is
talking,
you
can
use
the
note
taking
tool
which
is
in
your
toolbar
in
the
upper
right.
It
looks
like
the
square
with
the
pencil
over
it.
G
F
F
Yeah,
so
if
you,
if
you
think
that
he
particularly
if
you
think
that
he
did
not
correctly
capture
what
you
said
and
do
the
one
that
what
you
said,
you
think
what
you
said
is
important.
Presumably
you
do
because
you,
otherwise,
why
would
you
have
said
it?
Please
make
sure
it
is
captured
correctly
in
the
notes.
F
F
Id,
but
what
was
it
here
so
I
can't
nag
him
and
EVC
is
an
idea
of
last
call.
Next,
we
adopted
three
drafts.
We
have
a
call
for
adoption
on
one
more
which
we're
discussing
today
and
I.
Think
there's
one
more
I
was
supposed
to
call
for
adoption
on,
but
I
forgot,
so
I
apologize
for
that,
and
but
we
will
discuss
anyway.
F
F
There
is
an
iot
iata,
mime
types
which
is
complete,
I,
think
everything
all
our
pillow
types
are
there.
The
question
is:
do
we
care
about
this,
which
is
to
say,
do
we
I
mean
I
feel
like
it
is
probably
bad
to
have
an
incomplete
registry?
The
question
is:
do
we
want
to
fix
the
registry,
or
do
we
want
to
tell
Ayanna
to
abandon
this
registry?
E
M
yeah,
the
bad
thing
about
these
two
Registries
is
that
the
yeah,
the
types
that
are
registered
in
one
are
not
necessarily
usable
in
another,
and
the
RTP
payload
types
registry
are,
is
the
ones
that
are
usable
in
RTP.
Well,
the
other
one
is
is
usable
for
basically
for
files
and
that's
kind
of
silly.
F
H
E
Well,
what
could
happen
in
theory,
at
least,
is
that
they
they
look
into
the
into
the
one
one
of
the
Registries
and
thus
don't
find
the
RFC
they're.
Looking
for
in
and
conclude
that
it's
not
registered,
it
would
actually
be
better
to
add
just
to
one
that
with
a
flag
that
says
usable
for
RTP
or
usable
for
files,
but
that's
that's
a
that,
would
involve
changing
negotiation
procedures,
damn
it.
I
J
I
F
I
G
F
G
F
F
I
Mentioned,
as
you
mentioned,
EVC
I,
don't
know
how
many
have
paid
attention
to
that,
but
that
was
the
last
call
comment
from
from
Murray
I.
Think
about
about
that.
The
that
the
registration
that
is
in
the
EVC
payload
format
is
limited
in
scope
only
to
the
to
the
use
of
RTP
and
we
had
the
same
language
in
the
VVC
payload
format,
and
that
was
to
avoid
a
discussion
whether
this
is
a
binary
format
or
not
a
binary
form
or
nerd
I.
I
Don't
know
you
know,
I
I
don't
know
about,
but
that's
no
longer
I
care
much
about
it,
but
I
I,
wonder
whether
you
know
if
we
are
boiling
the
ocean
there,
rather
than
finding
a
really
quick
and
dirty
pragmatic
solution
for
stuff,
that's
relevant
to
this
universe,
I
I,
wonder
I,
wonder
how
much
red
holding
can
happen
in
this
area.
So.
F
I
I
F
A
F
I
A
A
D
A
A
F
A
I
I
F
B
The
draft
is
pre-complete,
so
maybe
next
slide
all
right
and
on
the
call
it's
also
and
by
the
way,
these
are
our
photos
from
probably
10
years
ago,
so
and
also
on
the
call
is
David
tomman,
who
was
one
of
the
original
authors
of
jpeg
2000
and
who's?
Also
one
of
the
co-authors
of
the
proposed
payload
format
so-
and
this
is
intended
to
be
interactive,
so
feel
free
to
enter
up.
Ask
questions
next
slide,
all
right,
so
jpeg
2000
for
those
that
are
not
familiar
with
the
image
codec.
B
B
B
You
know:
satellite
archival,
cinemites
the
standard
for
Cinema
distribution,
worldwide,
Studio,
post
production
and
it's
been
essentially
continuously
maintained
and
improved
since
2001
and
David
and
I,
and
also
Mike
Smith
who's
on
the
call
have
been
particularly
active
in
a
past
couple
of
years,
making
sure
to
keep
jpeg
2000
up
to
date
and
be
responsive
to
feedback
from
users,
and
so
one
of
the
feedback
from
jpeg
2000
users,
that's
been
consistent
over
the
years
had
been
that
it's
entropy
coder
was
particularly
slow.
It
was
an
arithmetic,
coder
and
so
in
2016
or
2017.
B
So
proposing
an
alternative
to
the
original
arithmic
coder,
it's
called
an
HT
block
coder,
it's
a
much
much
higher
throughput
block.
Coder
I
mean
I
could
talk
for
hours
about
this,
but
basically
it
provides
a
increase
in
throughput
by
basically
an
order
of
magnitude.
Of
course
it
depends
on
the
bit
rate,
but
kind
of.
B
Numbers
and
order
of
magnitude
increasing
throughput
for
jpeg
2000
at
the
cost
of
about
five
percent
increased
file
size.
So
you
know
five
percent
decrease
in
coding,
efficiency,
and
that's
really.
That
was
a
new
part
of
jpeg
2000
that
was
published
in
2019,
and
this
particularly
in
a
new
part,
really
opens
the
door
to
inexpensive
and
high
quality
low
latency
streaming.
B
And
so
that's
really
was
one
of
the
motivating
factor
for
starting
work
on
proposing
this
new
RTP
payload
for
jpeg
2000
and
which
is
intended
for
streaming
of
video
signals
encoded
as
a
sequence
of
jpeg
2000
code
streams.
So
it's
not
every
frame
as
we'll
see,
is
one
code
stream
and
it's
just
a
sequence
of
code
streams
and
there's
a
existing
RTP
table
for
jpeg
2000
and
again.
So.
B
The
the
idea
here
is
to
improve
on
this
existing
payload
then,
as
we'll
see,
support
and
and
leverage
some
of
the
advances
in
jpeg
2000,
like
this
part
15.
and
we'll
go
over
some
of
those
that,
in
the
next
couple
of
slides,
so
support
sub
code
stream.
Latency
also
allow
resolution
and
quality
scalability
at
the
RTP
packet
level
and
so
forth,
and
it's
really
designed
to
meet
the
needs
of
today's
applications
like,
for
instance,
Sim
tst2110,
which
is
a
standard
for
video
streaming
well
for
audio
visual
streaming
in
professional
broadcast
applications
all
right.
B
So
pretty
straightforward,
the
payload
structure-
and
there
are
two
types
of
RTP
packets.
One
is
a
main
RTP
kit
packet
that
contains
the
code
stream,
Header
information
so
and
then
a
bunch
of
body
RTP
packets
that
contain
the
rest
of
the
jpeg
2000
code
stream.
Both
types
of
RTP
packets
have
a
64-bit,
payload,
header
and
so
next
slide.
So
nothing
exceptional
there
I
think
kind
of
high
level
basic
parameters.
B
B
The
timestamp
field
is
a
presentation
time
of
the
video
frame
or
field
to
which
the
codes
group
corresponds,
and
the
sequence
number
is
extended
by
an
extended
sequence
number,
as
in
RFC
4175,
and
that's
to
accommodate,
very
high,
very
high
throughput.
You
know
very
high
I
should
see
very
high
bit
rates
and
are
typical
in
some
of
those
high
performance
applications.
B
So
nothing
exceptional
here,
I
think
next,
one
all
right.
So
what
is
sub
code
stream?
Latency
me
I
thought
that
maybe
I
should
spend
a
slide
on
this,
because
maybe
some
not
everybody's
familiar
with
this
and
that's
the
ability
to
start
transmitting
parts
of
the
encoded
image
before
the
encoding
of
the
full
image
is
complete
and
that
makes
very
very
low.
Latency
is
possible,
you
know
so,
just
as
an
example.
B
B
Another
feature
of
this
proposed
RTP
payload
format
is
high,
Precision
clock
recovery,
so
the
RTP
timestamp
is
pretty
low
resolution
compared
to
the
RTP
packet
rate,
especially
at
hybrid
rates,
and
so
there's
a
in
in
the
payload
format.
There's
an
additional
header
field
that
indicates
a
transmission
time
of
each
RTP
packet
in
the
same
time
base
as
the
RTP
timestamp
and
then
allows
for
increased
Cloud
recovery,
speed
and
resolution
in
the
receiver
and
that's
an
optional
feature.
That's
enabled
using
a
a
bit
in
the
header
field.
B
Another
feature
is
code
block
caching,
so
jpeg
2000
can
can
be
used
or,
as
has
been
used,
to
transmit
video
content
that
consists
of
mostly
static
contents
or,
for
instance,
just
the
mod.
You
know,
screen
content
and,
of
course,
the
idea
there
is
you'd
like
to
not
have
to
retransmit
continuously
this
the
static
parts
of
the
image,
and
so
the
payload
formats
introduces
a
very
simple
code
block
caching,
which
allows
a
sender
to
only
occasionally
transmit
code
blocks
and
I'll
go
over.
B
What
code
blocks
are
but
transmit
only
occasionally
transmit
parts
of
the
image
that
are
static
and
on
the
other
side,
the
receiver
maintains
a
code
block
cache
and
that
it
uses
when
it
receives
an
empty
code
block
from
the
sender
and
just
again
for
background
in
jpeg
2000,
a
code
block
is
a
collection
of
coded
samples
that
belong
to
a
rectangular.
You
know
special
spatial
region
within
one
resolution
level
of
one
component.
B
So
again,
so
basically,
this
allows
the
sender
to
only
occasionally
send
code
black.
You
know
parts
of
the
image
that
are
static
and
the
receiver
maintains
a
very
simple
cache
where
it
fetches
from
that
cache.
When
it
receives,
you
know
an
empty
code
block
from
the
sender,
that's
okay!
So
next
step
and
I
didn't
go
over
everything.
B
So,
for
instance,
it
compared
to
especially
the
existing
RFC
for
jpeg
2000
streaming
and
also
this
pedal
format
supports
much
finer
and
much
more
detailed,
color
space,
parametrization
and
signaling
and
and
so
forth
and
anyway.
So
this
is
like
this
to
be
considered
as
a
standards
track.
Rfc
and
there's
an
ID
that's
been
posted.
Then
it's
been
revised
already
once
based
on
feedback
we
received,
and
we
really
welcome
your
feedback
and
look
forward
to
working
with
the
working
group.
Thanks.
I
Is
this
active
now
yeah,
so
I
read
this
draft
I
find
there
are
a
lot
of
good
points
here
and
I
support
the
adoption,
so
I
want
to
make
three
points.
The
first
thank
you
for
using
the
IPO
references
and
of
the
iso
references.
So
we
will
have
no
trouble
in
the
normative
referencing
citation
part
that
we
recently
had
on
the
iso
side
with
us.
I
do
recommendations
are
free
for
download,
so
so
no
issue.
I
There
second
I
find
this
idea
of
sending
the
packet
send
time
in
a
payload
head
I
find
that
intriguing
I
I
don't
know.
Has
anyone
seen
that
before
it's
it's
smart,
you
know,
buffer
management
can
can
do
really
really
good
things,
and
then
one
point
of
criticizing
is
the
way
how
you
guys
describe.
The
syntax
is
like
an
ascified
version
of
a
syntax
diagram
as
used
in
jpeg.
I
That's
not
what
we
use
here
and
that's
not
what
the
old
jpeg
2000
payload
format
used
either
I,
don't
know
whether
we
should
whether
whether
consistency
with
with
the
traditional
way
of
specifying
syntax
here
is
is
desirable.
But
my
guess
is
it's:
it's
probably
nice,
because
that
is
that's
the
way
how
how
syntax
is
described
in
in
packet
protocols
in
the
ITF
is
basically
the
same
everywhere
and
you
guys
are
not
following
that.
So
I
would
suggest
to
to
edit
that
part
of
the
draft.
That's
editorial
work,
yeah!
G
F
So
John
Lennox
somewhat
as
a
terrorism,
someone
as
an
individual
I
mean
is
it
chairs
want
to
say
I
think
there's
no
problem
with
us
doing
a
second
pillow
type,
the
same
media
type.
We've
done
that
I
think
at
least
twice
before
I
think
we
did
it
for
mp3
and
we
did
it
for
each
263.
So
that's
fine
and
the
normal
negotiation
procedures
between
them
should
work.
Fine
and
so
there's
no
issues
there.
F
F
Would
that
work
for
you
because
I
think
there's,
like
you
know
some
feedback
defined
in
relation
to
it
and
whatnot
if
it
wouldn't-
and
you
know
if
there's
Untitled
reason
that
wouldn't
work,
that's
fine,
but
I
think
you
should
at
least
take
a
look
at
that.
I
could
probably
find
the
RFC
number
for
that.
If
that.
B
B
F
F
My
question
is:
is
there
a
way
for
a
receiver
to
tell
that
it's
lost
a
packet
that
contains
a
something
that
should
have
been
cached,
because
obviously
things
would
go
badly
if,
if
it
did
you'd
get
end
up
referencing
either
having
a
cash
Miss
which
I
guess
you
could
tell,
but
you
wouldn't
know
where
what
you
missed
or
you'd,
actually
potentially
load
the
wrong
thing
from
the
cache
and
there's
various
techniques
we've
developed.
So
that
might
obviously
make
your
header
bigger,
which
you
don't
want.
B
F
F
F
B
In
more
detail-
and
you
know-
and
of
course
you
know
the
the
sender,
for
instance,
knowing
that
the
network
quality,
the
network
conditions
are
bad,
might
choose,
to
you
know
not,
you
know,
send
you
know,
send
empty
code
blocks
less
often
right.
So
so
it's
really
yeah
this
architecture.
It
gives
control
to
the
sender
to
decide.
You
know
how
often
it
does
not
send
a
code
block
that.
F
I
But
regarding
this
discussion,
this
sounds
a
little
bit
familiar
from
things
like
the
Opus
payload
and
and
places
like
that
where,
where
there
were
also
like,
like
code
books
formed
and
they
and
and
the
air
resilience
of
of
that
was
debatable,
let's
put
it
that
way:
I
don't
think
they
have
I,
don't
think
they
were
talked
into
specifically
addressing
that
and
I.
Don't
think
we
have
a
history
of
specifically
addressing
you
know
incorrect
reference
information
that
may
be
incorrect,
because
the
the
data
stream
is
is
not
good.
I
That
said
what
what
people
do
outside
of
RTP
payload
formats,
but
could
be
also
implemented
inside
of
the
prtp
payload
formats-
is
to
have
something
like
you
know:
have
I
had
a
field.
This
is
the
the
checksum
calculated
over
your
current
cash,
and
then
the
decoder
sees
that
and
if
the
Dakota
sees
that
and
it
doesn't
match
its
own
checksum
calculation,
then
at
least
it
knows
that
there's
something
wrong
and
can
do
whatever.
I
I
F
K
This
is
this
is
a
really
Base
building
upon
the
fact
that
jpeg
2000
is
both
error
resident
and
also
extremely
robust
to
just
missing
pieces.
So
this
mechanism
actually
really
just
encourages
the
missing
of
pieces
and
combines
a
default
strategy,
an
alternative
default
strategy
for
handling
missed
pieces.
F
Yeah
I
mean
that
that
I
mean
I
would
I
mean
that
makes
perfect
sense.
To
me,
I
mean
my
work
of
a
concern
is
not
you
know
a
dependent
and
I.
Don't
like
I,
don't
know
exactly
how
your
cash
strategy
Works.
What
would
happen
if
you're,
if
you,
if
you
not
that
you
cash
entry,
is
missing,
but
the
cash
entry
is
wrong
because
something
later
updated
it,
and
if
every
cache
entry
has
a
unique
ID.
K
K
I
E
F
B
A
So
next
item
is
an
atvc
profile
for
whatever
you
see
so
we
have
with
us
on
this
call
myself
as
well
as
Philip
Panky
and
some
of
the
developers
of
the
chromium
hebc
support.
John
Lin
is
here
so
we're
going
to
be
going
over
some
of
the
feedback
we
got
as
during
the
call
for
adoption
and
hopefully
solving
some
of
the
issues.
A
So
issue
two
is
about
the
out-of-band
S
prop
VPS
SPS
and
the
PBS
in
RFC
7742,
which
was
the
original
webrtc
video
RFC.
It
basically
says
that
webrtc
implementations
must
signal
this
information
in
band
and
must
not
include
in
the
STP
they
generate.
So
that's
kind
of
the
past
history,
and
this
draft
does
something
similar,
basically
saying
also
that
this
is.
It
must
be
signaled
in
band
and
not
out
of
not
in
the
STP.
A
I
Yeah
this
this
unmute
takes
a
while
here,
I'm
I'm
I'm,
willing
to
accept
this
on
a
pragmatic
basis.
I'm
the
one
who
proposed
original
layout
of
band
parameter
sets
back
in
2002,
but
it
hasn't
taken
off
in
this
environment.
So
so,
let's
just
follow
practical
implementation,
implementation
practice
rather
than
options
that
are
available
in
according
to
the
words
of
the
fact
that
thank
you.
J
A
H
Sure,
I'm
sorry
I
was
actually
waiting.
No
sorry,
thank
you,
so
I've
just
wanted
to
check
so
not
providing
them
out
of
band
or
in
the
STP
will
probably
delay
the
joining
of
the
session
for
webrtc
client.
So
how
I
mean,
in
this
case
we
probably
have
to
send
the
SPs
PPS
information
along
with
every
ID
or
frame
or
an
iframe,
so
why
we
consider
this
approach
of
not
including
them
in
the
STP,
in
specific
reasons,
for
not
allowing
this
kind
of
information
in
the
in
the
STP.
H
F
F
You
know
interactive
conversational,
video,
codex
change
resolution,
a
lot
which
is
going
to
need
a
fresh
SPS
DPS
and
if,
whereas
STP
doesn't
tend
to
update
that,
often
and
also
you
can't
necessarily
guarantee
that
an
encoder
is
going
to
pick
different,
STS,
PPS
IDs
and
trying
to
decode
with
the
wrong
EPS
Causes
Chaos,
so
right,
you're,
better
off.
So
yes,
this
does
mean
you
actually
said
FPS
PPS
with
every
IDR,
which
is
what
people
normally
do
for
yeah.
F
A
Okay
yeah,
so
we
did
have
a
PR
created
to
address
issue
two,
which
is
to
clarify
this
because,
as
Jonathan
mentioned,
some
of
the
encoders
didn't
update
the
ID,
and
there
was
some
issues
in
matching
the
in
band
sets
to
the
IDR.
So
pr10
adds
the
following
text.
Basically
to
say,
the
idea
must
be
preceded
by
the
relevant
parameter
sets
with
the
same
RTP
tabs
timestamp.
A
Ok,
okay,
all
right
issue:
three
is
about
TX
mode.
The
current
draft
didn't
cover
that
at
all,
and
then
people
said:
oh
okay.
What
what
should
we
do
here
and
so
I
created
a
pr9
to
try
to
update
this,
and
basically
the
guidance
is
to
not
include
the
parameter
within
STP
should
not,
and
if
it's
present
then,
as
the
RFC
7798
says,
a
value
of
srst
must
be
inferred.
A
A
A
D
A
D
F
F
K
C
F
D
A
Okay,
all
right
next
issue
is
Issue,
four
and
so
I
believe
John
Lin
questioned
the
usefulness
of
Max,
cpb
and
Max
dpb
and
just
to
clarify
these
are
additional
constraints
on
top
of
the
level
ID
so
they're
put
in
if
the
receiver
can't
handle
what
would
be
required
implied
by
the
level
ID,
and
that
includes
in
the
next
issue,
we'll
talk
about
if
Max,
FPS
and
Max
br.
But
so
the
proposal
here
in
pr8
is
to
remove
these
as
parameters
that
we
expect
webrtc
implementations
to
support.
F
Yeah
I
think
this
mostly
I
mean
I
will
defer
to
the
implementers
here.
If
that's
what
you
know,
people
who
are
actually
talking
to
the
actual
codecs,
you
know,
if
you
do
that,
if
the
level
IDs
are
sufficient
to
describe
what
the
Hardware
codecs
are
doing,
then
yeah.
Let's
do
this.
If
there's
like
ever
any
case
where,
like
a
Harper,
codec
is
well
I,
can't
quite
I,
think
they're
actually
above
the
level
ID,
not
other
sort
of
constraints
below
the
level
ID.
But
it's
what
I
meant
to
say.
F
A
And
we
had
some
discussion
in
the
issue.
People
were
saying
well
in
vp8
we
did
want
Max
FR
and
Max
FS,
and
that
was
an
issue
not
it
was
in.
It
was
required
in
7742
that
that
that
be
supported,
it
wasn't
supported,
and
then
there
was
an
issue
and
34
Stars,
which
meant
people
were
upset
that
it
wasn't
in
there.
But
there
is
agbc
is
different
than
vp8,
because
you
have
the
profile
tier
and
level
negotiation
and
vp8
didn't
have
that.
A
A
So
the
issue
here
is
that
in
webrc
implementations,
this
tsci
info
typically
ends
up
elsewhere
as
well,
such
as
an
RTP
header,
extensions,
I,
believe
the
overlap
is
there's
a
bunch
of
them
that
overlap,
including
the
the
frame
marking,
RTP
extension,
but
also
dependency,
descriptor
or
generic
frame.
Descriptor
have
this
kind
of
sne
kind
of
bits
bit
information.
So
the
question
is:
if
it's
negotiated
in
these
RTP
header
extensions,
what
implications
do
if
they
get
to
tsci?
F
F
A
F
It
negotiates
them,
but
then
you
know
wants
to
forward
the
packets
on
to
other
receivers,
and
then
I
mean
I'm
worried
about
the
case
with
where
the
sender
would
just
not
bother
to
put
them
in
into
the
payload
payload
format.
If
it's
negotiated
the
headers,
which
actually
happens
with
vp8
on
Chrome,
oh.
F
F
D
F
D
D
L
A
A
A
F
G
A
A
Yeah,
okay,
thank
you,
I
I
will
I
will
modify
the
pr
and
we'll
talk
about
it
in
the
GitHub
all
right.
So
last
issue
relates
to
rpsi
and
I
think
more
generally
to
alternative
reference
frames
and
references
in
general.
So
basically
the
question
was:
should
should
this
hvc
information
support
rpsi
and
it
also
got
into
how
the
references
are
handled
Etc
but
I.
Think
the
looking
over
the
rfcs,
the
sections
are
fairly
clear,
so
RC
7798,
section
83
defines
how
to
support
rpsi
and
hebc.
A
F
My
I
would
suspect,
I
mean
my
suspicion.
Is
that,
given
that
the
this
is
entirely
targeted
towards
hardware,
implementations
and
I
suspect
the
hardware
implementations
generally
don't
support
any
kind
of
reference
picture
selection
at
least
most
of
them.
Don't
it
seems
I'm,
not
sure
that
this
is
useful,
you
know
would
actually
be
implementable,
even
if.
A
I
I
I
So
on
on
this
one
I'm
tempted
to
to
recommend
to
at
least
at
least
leave
the
door
open
because
it
it
solves
a
real
problem
and
I
I
wouldn't
rule
it
out,
but
that
reasonably
smart
people
would
Implement
that
in
in
the
foreseeable
future,
and
if
you
provide
now
guidance
not
to
do
it,
that's
you
know
it
it
would.
It
would
probably
just
just
trip
the
the
the
implementer
community
away
from
from
something
that's
actually
useful
and
works
so.
A
A
J
A
E
A
G
A
D
D
A
Okay,
so
how
about
this
proposal
basically
keep
with
the
existing
rfcs
recommend
the
support
for
rpsi,
maybe
quote
the
other
rfcs
and
then
try
to
try
to
land
the
CL
and
make
it
happen,
and
if
we
have
other
issues,
we
can
come
back
to
the
working
group.
Does
that
seem
like
a
reasonable
resolution
of
this?
A
F
F
J
Yeah,
this
is
Dan,
so
next
slide,
we
released
version
six
last
Tuesday,
some
minor
updates
to
it
to
added
a
key
point
section
to
try
to
summarize
up
front
at
the
beginning
of
the
document.
Some
of
the
repeated
questions
we
seem
to
be
keep
getting
from
reviewers
to
try
to
bulletize
those
points
right
in
front
of
to
address
those
those
concerns
again
just
to
go
through
this
quickly.
Again,
the
skip
can
be
considered
a
tunneling
protocol.
Payload
is
opaque.
J
We
also
added
an
example
of
listing
skip
in
preference
order
when
there
are
multiple
codecs
listed
in
the
listed
in
the
STP,
and
probably
one
of
the
bigger
changes
that
we
made
after
getting
approval
from
the
skip
working
group
was
to
actually
provide
a
link
to
an
older
public
version
of
the
skip
210
specification
again
that
was
repeated
over
and
over
again
by
all
the
reviewers
that
that
they
weren't
getting
the
document
or
they
didn't
request
it
or
whatever.
When
they
did
the
review.
J
J
A
Yeah
so
yeah
I
think
you're
in
an
interesting
position,
because
you've
provided
the
public
link
now
and
now
we're
starting
to
get
people
reading
that
and
asking
questions
about
the
skip,
State
machine
right
and
act
as
though
it
I
mean
the
info's
out
there.
So
you
can
ask
the
questions
and
we
can
answer
them,
but
they're
really
not
relevant
to
the
draft.
A
E
E
L
A
Yeah,
so
it's
going
to
be
it's
interesting.
You've
now
you've
now
made
it
clear
that
the
information
is
available
so
now
they're
going
to
read
it
now
they're.
Somehow
we
have
to
get
out
of
this
because
it
is
a
tunneling
protocol
right,
which
means.
Yes,
you
have
all
this
great
information
now,
but
please
don't
make
use
of
it.
J
A
D
J
L
Yes,
if
I
may
comment
you're
exactly
right,
the
the
question
coming
in
about
the
video
mode
is
you
don't
want
to
be
harsh,
but
the
truth
is
it's
out
of
scope
for
for
what
this
draft
RFC
is
trying
to
do
we're
a
tunneling
protocol?
What
is
in
that
payload
should
be
opaque
to
any
device
other
than
some
skip
device,
and
if,
if
you
really
want
to
learn
Skip
and
make
a
skip
terminal,
we
can
happily
turn
you
in
to
turn
you
on
to
people
who
can
assist.
You
right
learn
to
do
that,
but.
A
Yeah
so
yeah
I'm
going
to
read
I'm
going
to
read
06
again
and
I
I
think
you
know
it's
gonna.
It
might
be
frustrating
for
you
because
I
think
you've
now
answered
the
availability
in
open
part,
but
you've
now
opened
another
can
of
worms
because
the
stuff
is
out
there
and
now
they're
all
going
to
read
it
and
now
they're
all
they're
starting
to
ask
all
these
questions
as
if
the
answers
mattered.
A
Yeah,
but
now
they
can't
because
it's
in
the
open,
so
let
me
I'm,
gonna,
read
it
again
and
and
just
if
it
makes
you
feel
any
better.
These
same
questions
are
coming
up
in
the
quick
working
group
because
middle
boxes,
you
know
in
TCP
we're
mucking
the
things
and
making
all
kinds
of
problems,
and
so
in
quick
they
have
something
they
call
greasing,
which
is
basically
they
randomly
change
bits.
A
So
you
know.
Yes,
you
have
all
this
wonderful
info,
but
we're
we
want
to
make
the
point
that
you
can't
mess
with
this,
so
we're
going
to
change
it.
So
if
you
try,
it's
gonna
break
I,
I,
don't
think
we
want
to
do
something
quite
as
extreme
here,
but
we're
just
trying
to
tell
people
not
not
to
not
to
use
all
this
wonderful
info.
L
A
A
H
J
Are
at
this
point
and
what
we
can
do
to
try
to
poke
in
prod
to
get
people
to
make
a
decision
or
cast
a
vote.
I
mean
they
were
four
people
on
the
list
that
had
that
didn't
even
cast
a
ballot.
I,
don't
know
what
what's
up
with
that
and
try
to
convince
the
other,
some
of
the
other
three
that
are
in
discuss
to
to
persuade
them
in
our
Direction.
So.
A
L
A
A
Bad
right,
because
now
you
basically
got
these
sbcs
that
are
randomly
breaking
you,
not
because
you're
skipped,
but
because
you're,
a
a
payload
type
that
didn't
wasn't
set
up
to
handle.
So
you
don't
want
to
transition
from
that
scenario,
to
one
where
they're,
understanding,
Skip
and
breaking
you
specifically
because
you're
the
wrong
version
of
skip
and.
A
A
And
that's
where
that's!
That
was
the
situation
in
TCP,
which
is
why
in
quick,
they
they
try
to
come
up
with
all
of
this
antiocification
stuff
to
prevent
that
same
I
mean
in
TCP,
essentially
they've
given
up
at
this
point.
Okay,
because
that
the
middle
box
junk
is
so,
is
so
prevalent
that
it
really
can't
be
removed.
So
they're,
big
and
quick.
They
they've
they're
taking
these
antioxification,
but
that
would
be
a
little
extreme
for
you
to
get
start
to
get
into
bit
greasing.
But.
A
I
So
one
yeah
one
one
thing:
you
know
it's
time
to
make
phone
calls
this:
this
email,
this
email,
stuff
or
it's
time
to
to.
Actually
you
know
talk
in
person
to
these
isg
people
people,
so
so
someone
has
to
go
to
Prague
and
they
really
set
up
a
meeting
beforehand
and
talk
to
them.
Yeah,
I,
think
I.
Think
a
lot
of
these
comments
were
were
still
based
on
on.
I
You
know,
lack
of
education
and
no
matter
how
many
emails
you
send
explaining
every
little
detail
and
no
matter
how
much
additional
text
you're
putting
in
people
don't
read
yeah,
even
even
though
it's
true,
so
you
have
to
talk.
Otherwise
you
will
not
get
the
thing
over
the
over
the
over
the
over
the
hurdle,
yeah
and
I
see
people
are
busy
in
Prague,
but
I'll
set
meetings
up
beforehand.
Yes,
it's
it's.
A
B
G
A
M
So
yeah
sure
short
update
on
what
we've
changed
since
the
last
meeting
read
the
section
on
considerations
for
using
stream
sources
using
datagrams
that
mainly
contain
some
background
info
about
the
differences
between
quick
streams
and
datagrams.
It's
purely
informational,
it
does
not
add
any
restrictions,
so
you
can
still
use
both
in
one
connection,
we
explicitly
State
now
that
applications
are
responsible
for
adapting
rate
by
deciding
what
what
they
actually
want
to
send,
and
previously
we
had
a
sentence.
M
That
said,
we
don't
mandate
any
algorithms,
but
we
made
that
a
bit
more
explicit
and
clear.
Now
and
then
we
have
PR
120,
which
moved
large
parts
of
the
rtcp
analyzers
that
we
talked
about
in
previous
meetings
to
an
appendix.
There
still
is
a
section
and
a
new
issue
that
I'm
gonna
talk
about
very
briefly
later.
That
concerns
the
same
part,
but
we
already
moved
a
large
part
of
the
rtcp
analysis
now
and
then
the
next
last
two
pull
requests
that
are
listed
here.
I
have
some
more
detailed,
slides
later
and
yeah.
We.
M
So
this
is
one
of
the
open
issues
currently
and
we
have
talked
about
stop
sending
and
reset
stream
in
the
past
a
couple
of
times.
I
think
this
slide
doesn't
have
anything
that
I
haven't
talked
about
in
the
past
meeting,
but
to
quickly
recap
of
a
receiver
sends
stop
sending
and
the
sender
must,
according
to
Quick,
send
reset
screen.
M
We
say
in
our
document
that
the
sender
still
should
continue
to
send
media
frames
of
that
media
stream
on
new
quick
streams,
because
stop
sending
should
not
be
interpreted
as
stop
sending
me
this
media
stream,
but
only
as
please
stop
sending
me
this
quick
stream,
and
currently
we
say
that
the
clicks
the
RTP
over
quick
sender
has
then
must
continue
sending
media
frames,
starting
from
the
first
one
that
it
hasn't
tried
to
transmit
on
the
quick
stream
before
I.
Have
one
more
slide
on
that?
A
A
G
Right,
and
so
you
you
are,
you
are
you
know,
issue
these
are
encouraged,
but
you
might
want
to
you
might
want
to
see
where
the
you
know,
where
that,
where
128
land
and
it's
children
land
and
see,
if
you
still
need
to
say
something,
okay,
thank
you
and
that's
actually,
that's
actually
good
advice
for
anybody,
but
especially
for
Bernard,
especially
on
that
on
that
issue.
Thanks.
M
So
last
time
there
were
some
questions
about
what
happens
if
there
are
media
dependencies,
and
since
we
say
that
the
sender
should
continue
sending
New
Media
frames
on
new
quick
streams,
but
not
re-transmit
the
previous
ones
that
received
stop
sending.
There
is
an
issue.
What
happens,
for
example,
if
the
frame
B,
the
second
frame
on
a
screen
depends
on
the
frame
a
and
this
has
to
send
on
a
new
click
stream.
M
The
frame
a
may
not
have
arrived
completely,
because
that's
why
this
receiver
sends
stop
sending
it
doesn't
want
this
Frame
anymore
whatever,
and
then
the
sender
must
continue
with
frame
B,
but
sending
frame
B
doesn't
make
that
much
sense,
because
it
may
only
be
decodable
when
the
receiver
already
received
frame
a
so.
We.
M
We
would
or
we
currently
the
application,
is
in
charge
of
what's
what's
to
do
with
the
next
frame.
There
are
some
options
listed
here
in
the
bottom
of
the
slide,
so
the
sender
could,
for
example,
decide
to
drop
B
Because
B
will
not
be
usable
by
the
receiver.
It
could
create
a
new,
independent,
really
decodable
frame
or
something
like
that
and
continue
with
that
and
treat
this
stop.
M
So
we
added
this
sentence
that
says
start
from
where
you
perform
what
you
have
never
sent
before,
and
so
we
would
like
to
keep
this
as
the
boundary,
because
otherwise
we
get
into
a
situation
that
we
discussed
I.
Think
in
Yokohama,
where
the
sender
could
three
to
stop
sending
as
okay
I'm
going
to
retransmit
the
same
thing
on
a
new
stream
at
the
receivable,
sent
again
stop
sending
and
it
will
kind
of
end
up
in
a
loop
where
the
receiver
keeps
saying
higher
and
wanted.
M
M
H
M
Think
it
would
yeah
I
think
it
would
be
problematic
if
we
add
that
as
text
in
our
draft,
we
expect
that
the
creek
at
the
quick
implementation
will
issue.
That's
a
real
world
service.
Some
error
to
the
applications
of
the
application
will:
no,
there
was
a
stop
sending
and
then
what
the
application
does
was
that
is
left
to
the
application.
M
G
G
Yeah
Bernard
I
just
want
to
add
we've
Madison
and
I
were
talking
about
this
pretty
recently
and
I.
Think
that
the
the
more
I'm
thinking
about
this,
what
we,
what
we
met
when
we
said
stop
sending,
is
pli
for
a
new
stream
actually
is
pretty
close
to
creating
a
new,
an
independent
next
frame,
but
I
think
I.
Think
I
think
that
I
agree
with
your
discouragement
of
guessing
what
guessing
what
quick
feedback?
Quick,
quick
error!
G
M
M
M
That
sounds
useful,
but
we
are
not
sure
how
exactly
or
how
relevant
it
will
be
in
in
practice,
because
it
allows
an
application
to
make
earlier
parts
of
the
stream
reliable.
But
when
the
receiver
or
the
sender
decides
that
the
later
frame
is
already
too
late,
for
example-
and
we
want
to
cancel
it
and
want
to
drop
this,
then
why
keep
the
offset
to
reliably
transmit
the
earlier
Parts?
A
So
we
came
to
Bro
roughly
the
same
conclusion
in
the
web
transport
API
the
only
place
so
that
we
would
not
add
this
so
that,
if
applications
when
they
have
the
ability
to
process,
send
closed
stream
or
anything
like
that.
For
the
same
reasons,
the
only
point
of
contention
was
whether
it
might
be
useful
in
a
control
Channel.
A
G
A
D
A
Well,
in
this
particular
case
we
were
looking
at
for
web
transport.
It
was
the
control
channel
that
sets
up
the
sessions
right
and
there
it
did
seemed
to
be
useful
to
have
closed
stream
and
know
that
a
particular
like
say
you
were
asked
for
a
session
to
be
set
up,
and
then
you
decided
to
close
it.
You
would,
you
would
be
able
to
say,
hey
I
want
this
particular
command
to
get
through
and
be
reliably
transmitted,
but
after
that,
I'll
do
the
shutdown
so
that
it
made
sense
there.
A
But
in
the
case
of
media
we
discussed
it
and
we
didn't
think
it
made
any
sense,
because
you
know,
if
you're,
in
the
middle
of
sending
a
frame
and
decide
you
you
don't
want
it
anymore,
you're
just
going
to
send
the
reset
and
you
wouldn't
want
it
to
be
partially
reliable.
You
just
decided
you
didn't
want
it
to
get
through
right,
so
yeah.
You
couldn't
think
of
a
reason
why
close
stream
would
be
useful
for
media,
but
but
the
only
place
where
it
was
debated
was
in
the
control.
Okay,.
A
M
I
I
would
argue
that
a
receiver
should
probably
not
send
stop
sending
for
rtcp
anyway,
because
it
doesn't
make
sense,
I,
think
and
for
the
sender
yeah,
there's
someone
that
knows
what
it
wants
to
get
through
right
and
if
it
knows,
I'm
gonna
have
to
open
new
streams
for
the
following
rtcp
messages
like
if
they
do
stupid.
Things
then
like.
F
F
M
Yeah,
that's
another
good
reason.
So,
okay,
we
will
then
remove
the
notes
in
the
main
document,
keep
the
list
in
the
or
keep
it
in
the
list
in
the
appendix
and
yep,
then
close
that
issue
okay.
So
this
one
is
one
of
the
things
that
I
mentioned
earlier
that
we
merged
yesterday
I
think
we
had
some
voting
on
suppressing
quick
signaling
in
favor
of
no
rkcp,
particularly
I.
M
Think
it's
in
favor
of
quick
signaling,
but
in
the
introduction
we
said
that
we
don't
want
to
change
any
of
the
protocols,
so
we
just
needed
a
standard,
quick
protocol
implementation,
and
we
also
don't
want
to
change
any
of
the
rtcp
feedback
rules.
We
just
want
to
be
able
to
use
Quick
State
information.
That's
there
anyway,
to
enhance
the
statistics
that
are
that
are
provided
by
rtcp.
M
D
M
This
adds
a
section
for
considerations
for
rtcp
enhancements
and
multi-op
topologies,
which
means,
for
example,
if
we
have
a
participant
in
a
session
that
uses
RTP
over
quick
and
then
we
have
a
middle
box
and
on
the
other
side
of
the
middle
box,
there's
a
participant
that
does
not
use
RTP
over
quick
but
some
other
protocol.
Then
this
other
participant
may
need
rtcp
feedback
as
usual
and
RTP
over
quick
participant,
May
not
send
as
much
rtcp
feedback
as
the
other
one
expects,
because
it
can
use
great
stuff
to
enhance
this.
M
So
now
we
added
some
considerations
for
this
for
what
what
could
be
done
to
solve
this
problem.
So,
first
of
all,
the
previous
pull
requests
that
I
took
before
this
slide
already
solves
this
a
little
bit,
because
we
still
say
that
we
need
the
basic
rtcp
receiver
reports,
for
example,
so
that
will
still
be
there
anyway.
But
if
the
middle
box,
for
example,
has
some
or.
D
M
Quick
acknowledgments,
instead
of
relying
on
negative
acknowledgments
from
rtcp,
then
one
solution
would
be
that
the
mailbox
adds
them
themselves
or
another
solution
would
be
that
we
need
some
signaling
that
tells
the
RTP
of
a
quick
participant.
Hey.
You
actually
need
to
do
rtcp
as
usual,
because
there's
someone
not
using
RTP
over
quick
so
that
the
RTP
request
participant
can
still
provide
this
feedback.
And
then
there
are
a
couple
of
topologies
listed
in
the
earlier
sections
of
the
draft.
I
think
I
think
RFC
767
has
a
lot
of
more
topologies
and
yeah.
M
F
M
M
Draft
now
says
and
yeah
then
next
slide
is
already
the
last
one
I
think
there's
a
list
of
issues
that
we
are
currently
focusing
on.
The
first
two
are
finished
error
codes.
We
have
one
request
for
that
which
we
already
merged
some
time
ago,
but
it's
not
yet
finished.
There
will
be
some
little
additions
to
that,
but
it's
almost
done
and
then
yeah.
These
are
the
or
the
the
list.
Here's
the
list
of
issues
that
we
are
currently
focusing
on.
D
M
A
A
G
C
G
Yeah
and
I
I
think
that
that
is
a
very
reasonable
thing
for
us
to
focus
on
it.
It
may
also
be
worth
me
just
saying:
medicines
refer
to
this
a
couple
of
times
in
the
in
the
meeting,
but
he
and
I
are
trying
to
keep
the
labels
on
issues
up
to
date
and
coherent.
We
have
I
think
three
or
four
issues
that
have
been
added
since
the
last
time.
A
C
So
since
last
time
there
were
two
pieces
of
feedback,
one
was
to
allow
what
I
was
calling
the
stage,
one
or
media
format,
specific
packetization
to
Output
more
than
one
RTP
packet
and
then
to
apply
the
stage
two
or
S
frame
specific
packetization
to
each
one
of
those
packets.
So
I
made
that
change
in
GitHub.