►
From YouTube: IETF92-AVTEXT-20150324-1730
Description
AVTEXT meeting session at IETF92
2015/03/24 1730
B
A
Sorts
of
other
places
agenda.
We
are
very
constrained
for
time.
There's
lots
of
people
came
in
with
lot
late
documents
on
time
documents
as
far
as
their
deadlines
were
concerned,
but
late
as
far
as
us
asking
for
a
gender
time
in
this
meeting
we're
concerned,
so
we're
going
to
try
and
get
through
this
fairly
quickly.
I
appreciate,
as
I
said
on
the
mailing
list.
A
If
you
could
limit
your
questions
to
those
things
that
are
basically
around,
is
this
the
right
job
for
a
header
extension
ie,
the
right
thing
for
a
vtx
to
do
and,
of
course,
whether
we
want
to
support
the
work
or
not,
and
there
is
interest
in
doing
the
work
a
lot
if
it's
something
down,
as
you
know,
I've
got
this
minor
technical
problem.
Don't
bother
raising
it
here,
do
it
on
the
mailing
list
or
save
it
for
the
next
meeting,
assuming
we
do
have
a
discussion
on
it
at
the
next
meeting
anything
your
title.
C
A
A
Splicing
notification:
we
had
a
late
IPR
declaration
after
the
adoptions
working
document,
so
I
hope
people
are
there's
been
a
couple
of
males
on
the
list
asking
if
there
are
any
concerns
with
this.
So
this
is
your
final
time
for
asking.
Are
there
any
concerns
with
this
IP?
Our
declaration
and
therefore
with
us,
proceeding
with
this
document
is
working
group
document?
A
I
think
I.
Both
the
chairs
are
also
concerned
with
declarations
coming
in
late,
I
mean
basically,
ideally-
and
this
applies
to
the
four
drafts
on
the
table
at
the
moment.
Please
then
we're
going
to
discuss
later.
Please
do
try
and
make
any
declarations
you
know
of
at
the
time
when
it
stood
an
author
draft,
so
we
can
actually
see
those
and
take
them
into
account
when
we
make
the
decision
as
to
whether
we're
going
to
work
on
these.
A
As
I
work
in
group
draft,
it
is
much
easier
if
we
do
get
it
then,
rather
than
later
right
stream
pause,
it
was
had
one
working
group
last
call:
we've
had
some
changes.
Is
anybody
seeing
the
need
for
another
working
group
last
call
on
the
stream
pause
document,
or
are
people
happy
with
the
document
as
it
is
currently
now
is?
In
other
words,
are
there
any
other
concerns
that
people
want
another
review
cycle
on
so
I
think
we're
just
proceed
with
the
getting
it
tied
it
up
for
publication,
request
you
and
do
that
one
yeah?
A
B
So,
on
the
header
exception
draft,
it
was
adopted
as
a
as
a
spitter
as
a
working
group
document
Monday
morning
the
consensus
40
working
document
last
cycle,
but
I
had
neglected
to
ask
the
ad
for
the
mouse
own
until
dope
I
was
reminded
so
I
apologize
for
that.
So
this
is
the
plan,
as
suggested
by
the
authors
they're,
going
to
update
the
drafts
based
on
number
of
comments
they
received
so
far.
B
The
last
time
it
was
presented,
so
the
expectation
is
they'll,
have
an
updated
version
of
this
document,
so
in
early
May,
another
occupied
before
the
July
meeting,
and
then
hopefully
we
can
go
to
working
with
Les
Paul
in
august
or
September
before
the
November
meeting
and
then
do
a
publication
request
at
the
December
meeting.
Anybody
have
any
suggestions
or
concerns
of
that
timeline.
Just.
B
A
B
B
C
A
A
F
C
B
The
next
slide,
so
a
layer
refresh
point
as
I've
defined.
It
is
so
you
have
a
receiver
which
previously
could
all
good
all
was
only
able
only
had
the
state
to
decode
some
of
the
layers
of
a
of
a
layer
of
a
layered
included
source,
possibly
done
and
after
and
and
so
then,
after
the
refresher
point
can
decode
a
greater
number
of
the
layers.
B
So
next
slide
I
have
some
illustrations
of
this.
So,
for
instance,
this
is
a
spatial
refresh
point.
It's
the
ideas,
so
we've
got
two
spatial
layers
which
are
called
s0
and
s1,
and
a
decoder
is
currently
decoding
layer,
s0
and
then
at
frame
3.
He
can
certainly
coding
a
sorry
mess
one
because
frame
3
s,
1,
there's
no
dependency
on
previous
frames
in
that
layer.
It's
only
it's
only
dependency
on
the
lower
layer
and
future,
so
he
can
start
decoding
that
without
s0
stream
needing
any
kind
of
special
refresh
points.
B
B
Earlier
pictures
in
the
temporal
layer,
which
is
valid,
most
definitions,
upper
layers,
then
similarly,
the
point
at
which
you
can
start
decoding
the
higher
temporal
layer
without
needing
earlier
friends
of
that
temporal
layer
on
this
picture
frame.
Six,
sorry,
the
type
on
the
slide
that
should
be
temporal,
refresh,
point
copy
and
paste
for
layer
t1
and
the
next
slide.
So
this
is
the
concept
of
temporal
nesting.
B
So
just
to
say
that
you
know
it's
possible
that
you
may
never
need
this
method
as
and
before
you're
doing
temporal
only
temporal
scalability
with
certain
structures.
So
next
slide.
So
the
layer,
refreshed
message
is
and,
as
I
said,
an
80
PF
feedback
message
for
the
details
are
in
the
draft.
It's
pretty
straightforward,
a
BPF
message.
B
So
what
you
say
is
you
what
you
say
that
you
basically
specify
the
new
layer
you
want
and
optionally
the
current
lowest
layer
you're
able
to
decode.
If
you
don't
specify
that
lowest
layer,
it
means
you
currently
can't
decode
anything
how
you
describe
layers
and
how
you
identify
when
you've
actually
gotten
the
Refresh
point
is
codec
dependent,
but
so
I
mean
we've
got
layer,
definitions
and
for
the
butcher
sort
of
sketchy,
just
quick
and
dirty
for
the
four
codecs
we
identified
that
have
some
form
of
temporal
or
spatial
scalability.
B
Still
a
lot
of
details
needed,
especially
how
you
recognize
where
the
Refresh
points
are,
because
that's
because
I
think
identifying
layers
a
straight,
usually
straightforward,
identifying
refresh
points.
So
you
know
when
you've
been
satisfied,
you
can
start
using
the
layers,
often
trickier
any
comments
so
far
by
the
way
or
and
then
the
next
slide,
and
then
for
the
applicability
to
the
multi
stream
modes.
B
The
question
for
the
multi
stream
modes
is
always:
could
you
just
use
F
IR
send
fi
are
for
one
of
the
streams
and
the
question
I
have.
The
problem
I
have
is
no.
Where
have
we
actually
specified
what
fer
means
for
any
sort
of
multi
stream
encoding
of
a
layered
source?
Does
it
refresh
the
individual
stream?
Does
it
repress
the
whole
source?
I
think
there's
cases
where
would
be
useful
to
have
refresh
the
whole
source
semantics
at
which
point
saying
that
fi
are
just
means
refresh.
The
stream
is
problematic.
B
A
E
G
Just
Bernardo,
but
just
a
general
comment
right
at
least
typically
for
temporal
scalability.
It
doesn't
make
a
lot
of
sense
to
send
an
fi
are
for
an
extension
layer
right.
That
is
certainly
true.
Yes
right,
so
in
some
sense
it's
kind
of
an
irrelevant
question,
because
you'd
send
it
to
the
base
SSRC,
and
that
would.
B
Yeah
but
I'm
in
yeah,
that's
there
yeah,
so
it's
but
the,
but
for
but
I
think
most
people
don't
yet
people
don't
tend
to
do
multi
stream
temporal
scalability
as
much
anyway.
Since
I
mean
I
don't
know,
I
mean
you
reduce,
you
guys
need
to
be
the
most
multi-stream
guys.
So
what
how
do
you
do?
Just
everything's?
Actually
a
separate
stream
yeah.
C
G
B
Lemon,
I
guess
I
guess
the
main
thing
is
that
I
don't
actually
know
how
existing
stuff
works
and
if
we
want
to
say
that
f
ir
means
refresh
the
whole,
I
mean
look
at
if
you're
just
doing
temporal.
It's
probably
six
of
one
half
dozen,
the
other.
It's
for
multi
multi
stream,
spatial
that
I
get
confused.
G
G
B
G
B
B
B
D
B
B
D
D
B
H
B
Yes-
and
I
currently
have
text
in
there
for
vp9,
because
that's
the
one
we're
actually
working
on
when
we
realize
this
is
a
good
idea.
It
will.
That
will
also
need
to
be
codec
specific,
just
recognizing
when
you
have
an
eye
DRS,
codec,
specific,
so
yeah,
so
we're
okay.
So
the
draft
I
currently
have
sections
for,
for
you
know
like
the
four
codecs
I've
identified,
which
I
have
scalability,
that
people
care
about
I
mean
how
that's
recognized
does
need
to
be
cut
a
specific
yeah
and.
B
B
Exactly
so,
it's
possible
we'll
discover
that.
Oh
no
wait!
This
codec,
you
can't
actually
detect
it,
so
we're
going
to
not
have
to
not
allow
for
that
Kodak,
but
we're
hoping
that
I
mean
certainly
for
anything,
that's
not
yet
a
published
RFC
or
in
public.
Hopefully,
we
can
figure
out
how
to
identify
this
for
all
the
fool.
Arguably,
you
could
so.
B
Yeah
so
I
mean
I
think
for
well
prefer
things
that
are
currently
I
mean
where
it
is
documentation
wise,
whether
it's
in
the
payload
type,
documentation,
okay
and
for
anything
in
the
future,
would
clearly
be
analytic
definition
for
anything.
That's
already
published
RFC
will
be
in
this
document,
things
that
are
currently
in
progress.
It
depends
on
where
they
are
in
the
cycle.
Arguably,.
H
B
A
A
Might
make
me
generate
right?
Okay,
so
I
guess
the
fundamental
question
will
confirm
all
these
on
the
list
is
sam,
is
their
intro
I
mean
basically
I
guess
show
of
hands,
preferably
because
it's
easier
for
me
to
see,
but
basically
show
your
hands
of
you.
If
you
think
this
is
something
that
I
ATF
should
be
working
on,
adverse
is
no,
you
don't
think
something.
This
I
tips
should
be
working
on
and
then
I'll
be
asking
after
that
for
a
show
of
hands
on
interest
in
actually
supporting
the
work
just
to
give
it
some
prioritization.
A
I
Okay,
so
this
is
a
video
frame
marking
a
header
extension
proposal,
co-authors,
a
Espen
and
Sue
house
next
slide,
please.
So
the
reason
for
this
work
it's
primarily
derived
from
some
parallel
work
happening
in
a
VT
core.
Well,
actually,
now
it'll
be
probably
new
working
group.
There
are
some
security
architectures
that
are
being
proposed
where
the
traditional
middleboxes
will
not
have
access
to
media
keys,
and
so
the
payload
will
potentially
not
be
visible
to
those
middleboxes
that
do
the
actual
media
switching
and
in
those
into
end
private
media
architectures.
I
We
need
some
some
more
critical
metadata
available
at
the
switch
in
order
to
make
forwarding
decisions
possible.
So
the
the
goal
of
this
work
is
to
have
an
agnostic
switching,
so
these
middleboxes
never
ever
have
to
inspect
the
payload
and
they
can
still
perform
all
their
forwarding
functions
again,
mainly
because
the
payload
may
be
encrypted,
even
if
you're
not
doing
in
private
media.
If
the
payload
is
encrypted,
you
can
avoid
the
cost
of
doing
the
decryption
in
the
middle
box
for
higher
scale.
But,
most
importantly,
is
the
middle
bullet.
In
these
Indian
architectures.
I
It's
simply
impossible
to
do
any
kind
of
payload
inspection
and
that
that
seriously
hampers
some
of
the
forwarding
functions
that
you
need
to
do
in
the
switch.
And
so
we
need
something
beyond
the
current
RTP
headers
to
make
those
decisions
and
then
also
a
more
forward-looking
goal
is
to
have
the
switching
function,
be
something
that's
codec
agnostic,
a
truly
capable
of
handling
any
codec
format,
potentially
even
not
even
knowing
what
the
codec
format
is.
I
As
long
as
it
knows
that
the
format
is
conforming
to
these
to
these
metadata
markings,
it
doesn't
even
need
to
know
what
the
what
the
underlying
codec
is
next
slide.
Please,
and
so
the
the
intelligence
in
the
switch
can
help
to
provide
cleaner
video
switching
typically
when
these
switches
operate
they're,
usually
using
an
active
speaker
role,
so
that
when
the
active
speaker
is
talking
using
the
voice
activity
level,
arti
beta
extensions
when
the
active
speaker
is
talking
their
video
will
be
switched
in.
I
And
if
you
do
that
naively,
you
won't
get
it
at
a
clean,
iframe
boundary.
And
so
there
may
be
a
glitch
during
speaker
switching.
So
we
need
some
kind
of
indicator
so
that
the
switch
knows
when
it's
able
to
deliver
a
full,
clean,
intra
frame
you'll
also
be
able
to
have
better
recovery
during
packet
losses.
I
If
there's
information
about
the
priority
of
the
packets
in
that
media
flow,
the
switch
can
make
better
decisions
that
affect
less
participants
and
then,
finally,
if
you
have
diversity
in
the
capabilities
of
the
participants,
you
can
drop
entire
layers
towards
some
of
them
and
the
setter
extension
will
allow
that
and
for
the
endpoints
there's.
Also
a
small
side
benefit
of
being
able
to
have
better
recovery
same
as
in
the
sense
of
the
switch
would
have.
You
can
better
identify,
leading
and
trailing
loss
scenarios
to
know
when
you
have
full
media
frames.
Next
slide,
please!
I
Yes,
the
proposed
solution
is
the
RTP
header
extension
and
it's
split
into
two
parts:
there's
a
mandatory
fixed
length,
codec
independent
part,
and
that's
what
really
want
to
focus
on
today.
There's
also
an
optional
variable
length,
part,
that's
codec
specific
and
it
could
be
defined
for
each
payload
format,
we're
initially
proposing
to
define
the
popular
paler
formats
in
this
in
this
draft
and
specify
what
that
optional
extension
looks
like
for
those
formats.
I
New
formats
going
forward
in
payload
would
be
encouraged
to
to
define
what
this
blob
means
for
those
formats
and
we're
using
the
standard
header
extension
model
from
fifty
to
eighty
five,
so
the
the
length
that's
encoded
in
that
standard
tells
you
whether
or
not
there
is
an
optional
part
present
and
if
its
present,
how
big
it
is
and,
of
course,
it'll
be
negotiated
in
stp.
So
you
can
figure
out
whether
or
not
you're
going
to
get
this
info
from
from
your
peer
next
slide.
Please,
ok!
I
So
the
codec
independent
part
that
we
want
to
focus
on
a
few
flags
and
then
an
identifier,
so
the
first
pair
of
flags
are
start
and
end
of
frame
and
we'll
we'll
talk
a
little
bit
more
in
later
slides
about
well,
as
some
of
these
are
important
and
what
the
relation
to
current
RTP
header
fields
are,
and
then
the
next
pair,
independent
and
discardable
frames.
This
is
talking
about
what
the
encoded
media
frame
is,
whether
it's
a
traditional
man
called
an
iframe
or
a
keyframe.
We're
calling
independent
here
to
make
it
more
general.
I
But
basically
this
means
that
this
frame
doesn't
depend
on
anything
that
came
before,
and
discardable
means
that
this
frame
can
be
dropped
without
any
kind
of
impact
on
the
decoding
dependencies
going
forward.
The
next
to
sorry,
the
next
two
are
for
temporal
scalability,
which
was
just
presented
on.
This
is
a
the
the
base
layer.
Sync
indicator
lets
you
know
when
you
can,
you
can
effectively
resynchronize
to
hire
enhancement
layers
and
the
temporal
ID
is
similar
to
the
temple
ID.
That
Jonathan
was
talking
about
next
slide.
Please
quick.
I
F
Definitely
a
2
comments.
One
is.
It
is
entirely
legal
and
useful
in
some
scenarios
at
least
to
have,
for
example,
a
discount
double
base
layer
picture,
hapless
yeah,
so
don't
get
get
too
much
into
this
mpeg-2
type
of
thinking
it's
over.
It's
that
it
was
done
10
years
ago.
Second
comment
is
M.
You
have
absolutely
no
space
for
any
extensions,
impair
the
I
would
suggest
grab
another
bite
call
it
reserved-
and
you
know
just
to
be
fruit,
future
proof.
Okay,.
I
I
E
I
J
J
I
G
So
I'll
answer
that
question,
at
least
for
h.264.
The
answer
is
definitely
no.
You
don't
want
all
the
crap
that's
in
there
in
this
extension
it
would
be
worthwhile.
I
think,
as
part
of
this
exercise,
to
go
off,
for
example,
stuff
like
vp8,
which
is
and
why
you
need
it
or
don't
in
the
rest
of
you,
but
I
do
think
that
yeah,
but
that
that
would
things
like
the
key
idx
I
would.
I
would
personally
argue
that
certain
fields
are
needed
that
are
missing,
but
I
think
you
know
that
would
be.
I
Young
little
bits
in
the
discussion
sure
go
ahead
next
slide,
please
for
independent
we've
already
covered
it.
It's
to
allow
clean
video,
switching
at
interfering
boundaries.
Discardable
we've
already
touched
on
that
to
drop
packets
whenever,
whenever
you
have
congestion
with
the
least
disruption
to
the
video
quality
next
frame
next
slide,
please
the
temporal
ID,
if
you're,
if
you're,
not
in
scalable
media,
this
would
would
always
be
zeros,
so
it
would
be
used.
I
But
if
you
have
defined
hierarchy
yet
you're
using
temporal
scalability
with
a
well-known
to
find
hierarchy
and
signaling,
this
would
be
very
useful
for
middleboxes
to
be
able
to
peel
off
individual
temporal
layers,
and
signaling
may
already
provide
some
part
of
this.
If
you
using
something
like
Mrs
T,
if
you're
using
mrs
t
RM
RM
t
these
might
already
be
coming
on
different
SSRC
s
and
there
may
be
signaling
means
to
associate
those
sources
with
with
what
layer
they
are.
So
in
those
cases
may
not,
it
may
not
be
needed,
but
an
srst.
I
You
would
have
no
way,
no
easy
way
to
discern
that
without
having
something
like
this
and
then
the
base
layer
sink
is
useful
for
being
able
to
once
once
you
have
loss
and
you
need
to
recover
when
you
can
start
forwarding
enhancement
layers
at
a
point
when
you
know
that
the
base
layers
have
been
synced,
it's
kind
of
a
hard
point
to
to
convey
quickly
here
in
the
few
minutes,
but
a
few
people
that
know
the
vp8.
Why
bit
it's
essentially
the
same
thing
as
the
vp8?
Why
bit
next
slide?
Please
I!
A
C
B
Concern
is
while
it
feels
pretty
solid
for
temporal
scalability.
It
feels
a
little
under
baked
for
spatial.
We
can
talk
about
that's
about
flying
about,
but
I
feel
like
I.
Don't
have
a
clear
notion
of
how
I
would?
How
does
whether
this
would
do
everything
I
need
for
spatial,
whereas
for
temporal
it
feels
very
solid
I.
I
Agree
and
it's
mostly
because
it
could
be
abstracted
out
the
codec,
codec
agnostic,
part
of
special
skill
that
he
could
possibly
be
extracted
out,
but
it's
a
little
more
nuanced
temporal
scalability
is
uniform
across
the
board.
The
only
difference
is
vp8
is
to
bits
everybody
else's.
Three,
that's
the
only
different,
so
give
three
bits:
n,
57
spatial
and
quality
skillet
a
little
more
confusing,
because
in
264
you
have
seven
bits
and
they're
partitioned
hard
into
three
and
four
and
265.
It's
not
it's
not
hard
to
partition
at
six
bits.
I
G
So
I,
more
or
less
agree
with
Jonathan
that
the
temporal
stuff
is
well
understood,
I
think
to
get
really
get
down
into
this.
You
have
to
go
over
a
lot
of
specifics
about
how
implementations
really
work,
what
they
use,
what
they
don't
use.
But
you
know
it's
a
good
start
and
there's
no
claim
it's
done
yet
so
will
I
kind
of
have
to
have
the
discussion
probably
go
over?
You
know
the
in
and
outs
of
various
codecs
and
what
is
used
and
what
isn't
and
also
frankly,
what
feedback
messages
are
used
in?
A
C
H
D
A
Think
we
need
to
get
the
questions
I'm
going
to
ask
it
anyway,
but
I
think
there's
a
bit
scope
for
a
bit
more
discussion
on
the
list
on
the
actual
scope,
but
I'd
like
to
get
a
viewpoint
and
what
the
support
is
in
the
room
for
doing
the
work
so
same
questions
as
last
time.
Those
you
think
this
is
something
that
I
TF
should
be
working
on
versus
those
who
do
not
and
then
I'll
ask
for
interest
in
supporting
the
work,
but
I
do
expect
to
see
some
more
discussion
on
the
list
on
scoping.
A
C
D
A
So
I
think
what
I'm
expecting
you
to
do
colonies
post
that
to
the
list
with
Santa
sort
of
initiate
the
discussion.
Is
that
something
you
can
do
I
mean.
Basically
that's
what
I
want
to
see
on
the
list
is
what
is
now
the
real
scope
of
what
we're
trying
to
do
and
and
so
on.
What
are
the
constraints
on
that
scope?
So
we
can
actually
know
what
to
write
in
the
milestone.
F
F
A
A
C
C
K
So
my
name
is
Bob
Berman
I'm
be
presenting
this
about
reference
picture,
verification
information
that
is
again
things
that
you
want
to
handle
specific
codec.
So
next,
please
there
is
IP
are
multiple
on
this
one
next,
please
so.
The
motivation
for
this
is
that
with
modern
video
codecs,
you
often
have
multiple
reference
pictures
like
you
can
use
for
for
improved
compression,
and
you
can
also
use
it
to
recover
from
decoding
errors
and
packet
losses.
K
For
example,
the
hevc
codec
has
also
a
possibility
to
include
a
decoded
picture
hash
information
to
really
verify
that
you
decoded
the
frame
correctly,
which
is
usually
left
out
since
previous
codex.
It's
not
a
per
pixel
exactness
measure,
but
here
you
have
that,
and
this
message
is
introduced
to
enable
the
use
of
these
features
having
a
controlled
way
of
referencing
pictures
that
may
be
lost
and
also
checking
that
the
correctness
of
the
decoding.
K
We
propose
to
use
an
RTC
p
feedback
message
to
enable
the
communication
of
this
information
from
the
decoder
to
the
encoder.
You
can
indicate
multiple
decoded
pictures
that
are
to
be
used
for
reference
or
indicate
that
a
specific
picture
was
not
decodable,
maybe
because
of
loss.
You
can
indicate
also
that
a
specific
picture
was
decoded,
but
with
an
incorrect
result
and
thus
should
not
be
used
for
reference,
and
you
can
also
explicitly
include
the
this
decoded
picture
hash
for
the
encoder
to
evaluate
whether
this
was
correct
or
not.
K
Next,
please,
there
is
some
relation
to
existing
feedback
messages.
The
most
obvious
one
is
the
rps
I
and
or
if
say,
RFC
4585,
the
AV
PF,
but
there
you
only
have
the
possibility
to
indicate
a
single
picture,
not
met,
not
multiple
that
one
or
a
vpf
also
has
the
picture
loss
indication,
but
there
you
only
have
the
possibility
to
indicate
that
pictures
are
lost,
but
not
which
and
specifically
not
which
of
of
certain
reference
pictures,
and
there
is
no
mechanism
to
indicate
the
incorrect
decoding
result.
A
G
Our
wellnes
microscope
Pam-
and
this
is
just
more
of
a
question
about
relevance.
You
know,
having
done
a
little
bit
of
asking
around.
It
turns
out
that
our
psi
is
typically
not
used
in
conferencing
scenarios
and
I'm
just
wondering
here.
If
you
think
of
this
more
as
a
person-to-person
kind
of
a
thing
or
a
conferencing
thing,
yep.
I
Yes-Mo
zanetti
and
the
direction
that
we've
looked
at
for
especially
for
conferencing,
is
more
about
exposing
our
TP
level
data
instead
of
codec
level
data,
so
things
where
you
surface
codec
level,
frame,
ids
and
codec
level
dependencies
between
those
formalities.
We've
some
implementations
have
gone
a
different
direction
to
only
focus
on
RTP
sequence,
numbers
and
and
the
delivery
of
those.
And
if
you
look
at
the
congestion
work,
that's
being
done
this
very
likely
that
we'll
have
actors
and
things
like
that.
For
four
reasons.
I
You
know
mostly
related
to
congestion
control
but
could
also
be
used
for
you
know,
for
recovery
and
repair
and
resilience.
So
I'm
inclined
to
think
a
better
direction
is
to
go
towards
RTP
level
repair
rather
than
deep,
codec
level
surfacing
of
those
those
codec
specific
values
up
to
up
to
some
other
up
to
some
other
feedback
messages
or
headers.
C
Cullen
Jenks
I'm,
just
given
how
much
we
we've
had
feedback
messages
of
various
types
over
the
years
and
that
there's
not
all
that
much
optimization
of
combining
them
together
in
the
same
way
I.
You
know
I'd,
prefer
to
see
us
pursue
something
like
this,
that
it
wasn't
as
obviously
IP
are
encumbered
and
see
if
we
could
find
a
Realty
free
sort
of
version
of
it
seems
like
an
area
where
we
easily.
B
C
A
B
H
Stoop
icicle
another
question
I
have
is
really
in
order
to
actually
use
this
at
the
source.
The
information
has
to
get
there
very
very
quickly
in
some
scalable
scenarios,
maybe
quickly
is
longer
than
if
it's
not
scalable,
but
you
think
one
of
the
reasons
messages
like
this
haven't
been
adopted
in
the
past
is
that
by
the
time
the
message
gets
to
the
encoder.
The
encoder
has
no
real
good
way
to
repair
a
frame
that
was
lost
ten
frames
ago.
L
Minus
with
them
so
I
think
I
mean
one
reason
it
might
works
more
these
days.
Pretty
more
modern
codec
is
that
they
have
bigger
frame
buffers
and
more
depth
and
actually
can
look
started
back
into
history.
So
you
actually
have
still
have
your
old
reference
pictures
in
the
buffers,
so
you
can
actually
reach
back
and
use
them
when
you're
repairing
rather
than
having
to
do
an
eye.
Dr
to
repaired
applause.
C
A
B
Might
mean
we
need
a
clearer
definition
of
what
the
problem
is
that
that
this
solution
songs,
because
I
don't
think
this
draft
doesn't.
I
didn't
feel
like
this
draft
at
least
turned
out
the
presentation.
I
don't
recall
the
draft
should
have
explained
you
know
what
the
use
case
or
models
was
where
this
would
be
a
useful
thing
to
do.
Yeah.
B
Mean,
like
all
the
things
you're
talking
about
like
you
know
the
round
trip
time
issues
and
I
mean
you
know
it
is
it
just.
You
know.
Hevc
has
this
feature
so
therefore
we
want
to
use
it.
I
mean
what
what
is
the
scenario
in
which
this
would
be.
You
know
I
mean
what
is
the
network
topology?
What
is
the
setup
things
like
that?
No,
why
does
it
be
the
best
useful
thing
to
do.
G
Bernardo
Mike's,
just
a
general
comment,
though
I
think
it's
important
to
take
into
account
the
comment
of
that
mo
made
and
kind
of.
What's
behind
it,
we're
having
an
explosion
in
video
codecs,
this
interest
in
privacy,
all
that
tends
to
lead
to
away
from
solutions
that
are
very
specific
to
certain
codecs
and
are
incompatible
with
privacy
right
if
we're
going
to
have
a
dolla
and
vp9
and
v10
and
h.265
and
whatever
you
don't
want
to
have
a
zillion
specific
messages
that
only
work
with
one
specific
codec
right
nobody's
going
to
want
to
implement
that
stuff.
G
So
that's
kind
of
the
general
context
here
and
maybe
that's
explains
the
lack
of
enthusiasm.
It
certainly
does
on
my
part.
You
know,
especially
when
I
looked
at
all
the
feedback
messages
we
have
and
discovered
that
like
half
of
them
aren't
used
by
anybody
anymore,
you
know
so
inventing
yet
more
stuff.
That's
future
legacy.
It's
not
real
happy.
K
A
So
what
we
do
is
we'll
do
a
quick
call
to
see
between
what
are
this
interesting
working
on
this
now
this
is:
do
we
taking
another
round
of
discussion
as
an
author
draft
and
see
where
people
want
to
go
with
it?
So
basically,
yes,
we
think
this
is
a
working
group
item.
Now
we
want
to
get
working
on
it
vs.
A
A
J
Okay,
so
I'm
proposing
a
header
extension,
that's
like
the
mi
da
door
extension,
but
for
multiple
layers
instead
of
multiple
media
sources.
Next
slide,
so
we
have
three
different
things
or
three
different
layers
within
our
taxonomy.
We
have
media
sources,
we
have
encoded
streams
or
dependants
dreams
or
in
other
words
different
layers
within
a
media
source,
and
then
we
have
different
RTP
streams,
so
media
source
can
have
n
layers
or
encoded
streams
and
dependents
dreams.
J
Each
one
of
those
can
have
one
two
three
RTP
streams,
r-tx
FTC
or
either
and
before
we
could
always
use
payload
type
for
all
of
them.
But
payload
type
has
problems
in
the
sense
that
you
can
run
out
or
you
could
as
SSRC
for
everything,
but
as
the
sources
have
their
own
issues,
and
so
we
defined
the
midd
extension
for
the
class
on
the
top
row,
which
is
media
sources.
And
now,
if
we're
not
doing
any
simulcasts
or
any
layering,
you
can
just
use
em,
ID
and
payload
type.
J
D
D
J
D
D
J
J
C
J
My
d,
it
like
it's
kind
of
a
mess
and
it
might
be
cleaned
up.
A
lot
of
ms
4
bundle
where
we
have
multiple
media
sources
over
the
same
network
port.
But
now
we
have
the
same
problem
for
multiple
layers
within
the
same
media
source
and
so
there's
kind
of
a
missing
thing
for
the
box.
So
what
I'm
proposing
is
next
slide?
Now
we
fill
in
the
box
with
a
header
extension
that
identifies
the
layer,
and
you
know
honestly.
J
This
could
potentially
be
part
of
this
other
header
extension
where
we
have
a
temporal
ID,
but
instead
we
put
in
a
spatial
ID,
but
they
didn't
have
a
spatial
later
ID
in
theirs.
So
if
we
don't
have
anything
anywhere
else,
I'm
proposing
that
we
have
a
header
extension
where
we
can
specify
an
ID
that
indicates
the
layer,
the
spatial
layer
and
that
could
be
called
an
encoded
string
or
it
could
also
be
for
a
dependent
stream.
J
I
chose
to
call
it
esad,
but,
like
I
pointed
out
here,
it
could
be
li
d,
4,
layer,
ID
or
some
other
thing.
So
if
you
can
go
to
the
next
slide,
the
benefit
is
you
don't
need
to
signal?
S2
Circe's,
there's
no
risk
of
running
out
of
payload
types,
which
were
the
same
problems
that
we
overcame
with
mi
d
X
epilators,
and
this
could
work
in
conjunction
with
them.
Work.
J
L
My
name
is
wisdom.
I
think
you
start
in
the
wrong
group.
I
think
you
need
to
go
to
a
music
and
actually
scarce
what
type
of
configuration
identifier
set
cetera,
because
that
part
of
the
of
this
work
is
actually
more
relevant.
I
mean
putting
in
a
header
extension
against
England,
which
is
basically
whatever
text
is
scope
for
doing
it
is
trivial.
L
What's
it
what's,
the
big
question
here
is:
can
is
ID
be
singled
in
the
indie
stp
in
a
reasonable
way
to
actually
mean
which
is
resting
it
to
me
and
I
mean
I
I
want
some
solution
for
simulcasting
identify
the
kind
of
the
configuration
of
the
encoded
stream
and
payload
type
isn't
enough
from
my
perspective.
So
yes
I
in
that
sense,
I
support
the
work,
but
I
think
we
need
to
start
talking
and
draw
the
saying.
How
does
this
look
in
stp
rather
than
being
here
and
discussing
itself
right?
So.
C
A
J
Is
to
define
the
header
extension,
which
you
point
out
is
fairly
trivial.
In
fact,
I
just
copied
the
text
from
the
mi
da
door
extension
and
rename
some
things,
and
that
was
that
part
of
it,
and
I
actually
think
that
part
of
it
is
is
useful
all
by
itself,
and
I
would
be
happy
if
we
just
had
that
be
four
scenarios
where
we
want
to
use
this
header
extension
outside
of
the
realm
of
stp,
which
is
still
valuable.
The
second
half
is:
how
do
we
map
at
stp?
J
For
those
you
want
to
use
STP
and
how
do?
How
do
we
define
that?
So
the
second
half
of
the
of
the
draft
is
defining
a
proposal
for
that,
but
you're
right
in
the
sense
that
this
might
not
be
the
right
working
group
for
this.
Maybe
instead
we
define
the
header
extension
here
and
then
the
music.
The
end
music
group
can
take
the
header
extension
incorporated
into
one
of
their
drafts
for
the
work
on
simulcast
with
n
stp.
C
C
Probably
some
part
of
it
has
to
happen
here
as
well,
so
I
don't
see
why
we
have
to
block
the
part.
That's
happening
here,
waiting
on
something
to
happen
in
the
music.
It's
not
the
fastest
working
group
in
the
world.
So
and
just
a
quick
question
and
you
can
feel
free
to
answer.
Read
the
draft,
the
es
ID
in
a
scenario
with
let's
at
a
conference
with
ten
participants
that
doesn't
have
to
be
unique
for
every
participant
right.
It
can
be
the
same
yes,
ID
use
percent
short
stream
for
engagement.
A
D
C
D
Colin
Perkins
I
have
no
objection
to
defining
identifiers
to
correlate
to
different
streams.
I
think
that
is
generally
a
good
idea.
I
have
strong
objections
to
the
way
this.
This
particular
draft
works.
I
think
the
way
it
overloads
the
sdp
format
parameter
is
completely
and
utterly
broken.
I
think
the
way
it
attempts
to
extend
pelo
types
is
completely
and
utterly
broken,
so
I
would
object
in
the
strongest
possible
terms
to
this
draft,
although
I
would
think
the
general
idea
of
correlating
streams
is
something
that's
worth
considering.
So.
J
D
J
A
J
D
Completely
broken
once
you
have
defined
an
appropriate
way
of
identifying
these
streams,
then
wrapping
it
in
a
header
extension
is
trivial,
but
the
mechanism
you're
using
took
to
identify
the
streams.
The
identifier
you've
chosen
does
not
work.
So
once
you
have
identified
an
appropriate
identify,
then
sure
will
come
into
a
header
extension
it'll
take
10
minutes
to
write
the
draft.
That's
not
the
hard
part
right,
so
Ronnie.
A
E
Doesn't
make
sense
without
the
other
part,
because
you've
said
it's
that
she
should
not
be
unique.
It
depends
on
how
you
define
in
detest
DP,
because
the
way
of
defining
now,
unless
they
pay
what
you
make.
But
if
it
you'd
find
me
differently,
it
may
be
needed
to
be
unique.
So
it's
not
it's
until
you
go
to
the
sdp
part
and
define
how
it's
being
used.
There's
no
reason
to
do
this
headaches
tension
or
that
I.
The
way
we
had
this
before
we
had
this
before
in
the
application.
A
Mean
what
I'm
saying
a
word
can
be
separate
and
why
you've
actually
Skyped
the
problem
in
the
moment
sufficiently
people
are
coming
up
to
the
mic
saying
we
don't
believe
this
is
right
to
that.
You
basically
need
to
go
round
the
loop
and
basically
have
another
look
at
the
problem.
Someplace.
If
that's
what
Manderson
I.
J
D
D
J
D
J
D
D
A
A
Take
the
opportunity
here
to
talk
to
their
music
chairs,
possibly
with
in
conjunction
with
other
people
and
see
where
you
go
next,
but
I
think
you're,
basically
going
to
have
to
have
an
re
spin
at
the
draft
so
that
it
actually
more
clearly
says
this
is
something
that
is
valid.
This
is
the
header
extension
that
encompasses
that
thing
that
is
now
valid.
Okay,.
G
A
J
C
A
B
D
Don't
think
anyone
is
objecting
to
the
header
extension.
That's
not
the
problem
here
right,
but
the
problem
is
not
the
idea
of
putting
a
header
extension
to
correlate
streams.
That's
a
wonderful
idea.
The
problem
is
the
particular
thing
you're
trying
to
use
as
the
header
extension,
the
particular
identify
your
choosing.
It's.