►
From YouTube: IETF97-PAYLOAD-20161117-1110
Description
PAYLOAD meeting session at IETF97
2016/11/17 1110
A
A
A
C
A
I
think
that's
why
we
don't
see.
That's
why
we
don't
see
Krista
in
this
room
too,
because
he's
blocking
everything
the
we
have
in
the
ancillary
payload
is
in
the
isg
processing.
There
are
some
comments
and
from
security
ESO,
and
they
are
dressing
that
other
document
the
and
map
codec
it's.
It
was
ready
for
publication,
but
before
I
said
the
needs
there
were
some
needs
to
ask
the
authors
to
address
them
before
we
send
it
to
publication.
D
So
here
jump
onyx,
that's
vp9
is
tactically
complete
I
feel
like
there's
a
lot
of
like
explanatory
text
of
vp9,
which
I
was
helping.
My
co-authors
would
write
and
I
didn't
because
they're,
probably
more
equipped
to
do
so
than
I.
Am
we
have
any
google
people
here?
Who
could
go
like
you
know,
hit
them
with
a
hammer
or
something
that'd
be
helpful,
but
if
having
care
all
those
left,
so
I
will.
A
E
A
Otherwise
we
want
to
remove
these
milestones,
at
least
from
the
bluetooths
SBC
I
got
a
response
that
says
that
they
don't
have
any
interest
in
pursuing
this
work,
so
we
can
remove
it
also
based
on
that,
but
I
would,
since
we
didn't
get
any
other
response
on
the
list
on
that,
we
we
intend
to
do
that
and
I'd
like
also
to
ask
you
in
the
meeting.
If
anyone
has
any
objection
to
us,
removing
those
milestones
and,
of
course,
removing
those
documents
from
the
from
did,
they
are
expired.
Anyhow,
all
this
document.
A
So
any
anyone
object
to
removing
this
for
document.
It's
the
EVP
rg7
18
for
Papa
standard,
the
AIESEC
codec
for
proposed,
under
which
I
think
they
don't
care
because
they've
now
the
opposite
or
whatever
the
SBC
and
does
the
mpeg-2
TS,
which
I
don't
think
we
have
any
that
was
between
I
talked
to
his
early
about
it.
We
don't
have
any
motivation
to
continue
with
that.
So
if
there
are
no
objections,
we'll
just
remove
those
milestones,
so
I
don't
see
anyone
running
to
the
mic
was
objecting,
so
I
think
we
can
do
that.
A
Ben
will
need
to
discuss
how
how
to
remove
those
milestones
right,
just
remove
them.
Okay,
okay,
okay,
so
we'll
remove
those
milestones.
The
other
milestones
that
the
we
have,
the
feck
the
perfect.
The
fact
we
have
the
vp9
video
codec
will
need
to
update
the
the
milestone
date
for
that
one
we
have
the
map,
which
I
hope
will
submit
it
for
soon
to
to
publication
when
we're
done
with
this-
and
we
now
have
a
milestone
also
for
the
VC
to
H
high-quality
profile,
video,
okay.
F
F
There
was
a
decision
at
the
last
ITF
in
Berlin
to
remove
the
the
non
XOR
codes,
so
the
non
parody
codes
out
of
this
draft.
So
there
was
a
raptor
and
reed-solomon
planned
as
as
alternate
codes
negotiated
through
rstp,
but
that
sense
has
been
removed
from
the
draft.
That's
the
most
major
change,
there's
a
lot
of
text
removed
for
that.
So
the
plan
is
to
have
new
drafts
that
cover
those
different
formats.
F
The
second
major
change
was:
there
was
a
retransmission
format
that
was
added
11
rev
ago,
and
people
commented
that
it
was
relatively
inefficient
compared
to
the
RFC
4588
r-tx,
and
so
we
looked
at
the
packet
format
and
try
to
do
some
reduction
of
the
fields.
That
would
not
be
necessary.
So
we
we
got
it
down
to
12.
Bytes
I'll
show
a
minute
what
what
the
differences
were,
but
basically
you
know
it's
now.
Three
words:
instead
of
four
to
four
to
eight
words
for
a
full
effect
header,
but
it's
still
not
as
efficient
as
4588.
F
The
the
old
retransmission
header
is
only
two
bytes,
there's
a
original
sequence
number
and
that's
it.
Everything
else
is
basically
inherited
from
the
RTP
header.
So
there's
a
little
bit
of
friction
here
that
if
we
try
to,
if
we
try
to
reduce
the
overhead
too
much
and
we
lose
some
of
the
benefits
of
flexible
affect,
the
point
of
flexible
effect
is
to
have
flexibility.
To
do
multiple
things.
You
could
cover
multiple
RTP
streams
you
can
cover.
F
You
know
different
editor
extensions
on
there
on
the
on
the
flexpay,
its
versus
the
original
packets,
and
you
could
have
SSR
seas
that
are
different
between
the
repair
stream
and
the
and
the
original
stream,
and
all
those
things
would
not
be
possible
if
we
collapsed
all
the
way
down
to
the
4588
format.
So
if
you
look
at
all
the
stuff
that
it
that
it
doesn't
allow
to
be
different,
as
sir
see
the
timestamp,
the
payload
type,
all
of
those
things
cannot
be
flexible
under
4588.
F
So
we
think
we're
maybe
pretty
close
to
the
right
trade-off,
but
if
anybody
has
ideas
that
they'd
like
to
bring
it
down
even
further
or
we're
open
to
pushing
the
trade
off
even
more
towards
efficiency
instead
of
flexibility,
okay,
so
next
slide
please.
So
this
is
the
the
new
retransmission
format.
This
is
not
the
RTP
header
or
two
Gators
before
this.
This
is
the
actual
effect
payload,
which
starts
off
with
what
is
essentially
an
RTP
header.
This
is
the
arts
be
either
of
the
original
packet
and
so
there's
a
the
change.
F
Was
we
removed
length
recovery
which
doesn't
make
any
sense
if
you're
protecting
a
single
packet?
You
don't
need
the
length
recovery
field
anymore,
so
the
length
recovery
was
removed
and
we
moved
the
sequence
number
up
into
that
spot.
So
now
looks
a
lot
more
like
a
an
old
old
style,
RTP
header
and
the
the
SSRC
count
field
is
removed
and
it's
reserved
bits
are
also
removed.
So
you
don't
end
up
with
three
words
of
overhead
12
bytes
of
overhead.
You
know
followed
by
the
actual
payload
and
payload.
F
Here
is
actually
the
CSRC
list
and
the
extension
headers
and
then
the
real
payload
of
the
original
packet
all
right
next
slide,
please.
Okay,
there
are
also
some
minor
changes.
There
was
a
in
order
to
optimize
the
retransmission
format
we
had
to
swap
the
the
first
two
bits
of
the
format:
the
are
bit
the
retransmission
bit
versus
the
eff
bit
fixed
bit,
and
so
now,
the
very
first
bit
of
this
of
the
foot.
New
format
tells
whether
or
not
it's
a
retransmission
format
or
effect
format.
F
F
This
fact
packet
can
be
protecting
up
to
108
source
packets
before
it,
and
this
mask
tells
you
which,
which
of
those
packets
is
protecting
and
there's
a
there's,
an
extension
bit
as
the
mass
grows
from
16
bits
to
32
bits
to
64
bits,
there's
an
extension
bit
on
each
one
of
those
to
let
it
let
it
grow.
And
obviously
you
don't
need
the
extension
bit
on
the
very
last
64
bit
version
of
the
mask.
F
F
Nobody
would
actually
move
it,
but
if
anyone
has
a
strong
opinion
of
it,
let
us
know
if
not
we'll,
probably
just
go
ahead
and
and
do
that,
remove
the
note
and
then
remove
the
remove
the
bit
unless
anyone
objects
to
it
and
there's
a
lot
of
editorial
clean
up
in
a
lot
of
the
other
sections.
Next
slide,
please.
This
is
the
new
format
for
sorry
go
down.
D
F
F
You
know
we
originally
want
to
be
able
to
extend
adco
points
or
reed-solomon
and
raptor
that
wouldn't
require
new
pelo
types,
and
you
could,
just
you
know,
switch
them
indirectly
now
they're
going
to
have
to
go
ahead
and
separate
drafts,
but
we
still
may
be
would
have
a
way
to
you
know
figure
out
an
extensibility
mechanism
to
not
require
bunch
of
new
pelo
types
for
those
things
either.
So
the
goal
is:
if
we
ever
wanted
a
mask
bigger
than
then
what's
currently
defined.
F
F
B
F
I'll
make
a
note
to
ask
them
about
what
they
feel
about
yeah.
A
lot
of
those
formats
are
for
basically
wired.
Ethernet
kind
of
applications
were
a
minute.
They
might
be
a
blind
fekr
and
expect
any
loss,
but
I'll
ask
around
and
see
what
it's
also
worth,
noting
that,
if,
if
you
do
have
a
need
for
enormous
windows,
there
is
in
the
currents
back,
there
is
a
facility
for
up
to
64
K
windows.
F
If
you
don't
use
the
mask,
if
you
use
the
row
and
column
you
can
have
up
to
256
rose
into
n
56
columns,
so
you
can
have
up
to
a
64k
window
of
packets
that
you're
protecting.
That's
if
you
have
a
very
regular,
fixed
pattern
and
large
video
like
that,
would
have
a
very
regular,
fixed
pattern.
The
mask
is
more
for
flexible
video
and
coatings,
where
the
only
one
protect
certain
packets,
because
some
of
them
may
be
disposable.
F
So
you
had
a
you
know
more
pretty
complicated
video
video
frame,
structure
of
disposable
frames
and
then
less
important
frames,
and
things
like
that.
Certainly
thinking
some
of
them,
that's
what
the
so
the
mask
is
used
for.
It's
hard
to
see
that
growing
much
more
than
100
packets
in
the
past
forward,
one
side
you
going
backward
or
forward.
Oh,
it
must
be
air
here
because
it.
F
Alright
next
slide.
So
the
only
open
issues,
removing
that
kay
Binn
I
think
we'll
go
ahead
and
just
do
that
unless
anybody
objects
give
it
a
few
days
on
the
list
to
make
sure
nobody
has
an
issue
with
it
and
then
the
second
major
thing
is
I'd
like
to
hear
nobody
from
from
the
chrome
team.
I
don't
think
is
here,
but
they're,
the
ones
that
originally
objected
to
having
the
retransmission
format
be
inefficient.
I
think
we,
everybody
supported
having
the
retransmission
format,
isn't
as
an
optional
thing,
built
into
flex
effect.
F
So
you'd
have
to
negotiate
r-tx
separately,
so
the
support
for
having
retransmission,
but
nobody
liked
it
that
it
was
so
inefficient
that
you
know
you're
eating.
You
know
it
was
before
it's
like
20
or
30,
something
bites
Mariana
12.
The
question
is
doing
willing
to
be
more
efficient
than
that.
Are
there
people
that
want
to
use
this
for
audio,
where
you
know
the
whole
audio
payload
is
only
20
or
30
bites
and
12
makes
a
big
difference
so
like
to
hear
from
anyone
that
has
an
opinion
on
that
and
I'm
going
to
go.
D
D
D
F
Opus
internal
is
good
for
the
low
rate
voice
man
streams,
but
if
you
at
the
subway
you're
going
to
need
higher
you're
going
to
need
higher
level
effect,
you're
going
to
need
outside
fact
for
it
for
that.
So,
if
you're
using
opus
for
music
streaming
or
something
if
I
want
something
like
flex
vac
just
for
voice,
it's
probably
just
as
good
to
use
in
band
opens
in
band.
F
But
okay,
so
we'll
probably
will
pie
float
a
few
ideas
for
optimizing,
the
retransmission
format
on
the
list
and
see
if
anybody
has
an
opinion
either
way
again.
Like
I
said,
the
trade-off
is
basically
flexibility
for
efficiency.
You
know
as
we
as
we
try
to
squeeze
it
down.
It's
going
to
reduce
some
of
the
flexibility
that
that
the
returns
we
should
format
has
yet
to
fix
the
you
know
some
fields
to
be
negotiating
stb
versus
versus
dynamic
and
things
like
that.
F
B
F
Lower
case,
if
we
sort
them
all
the
lower
case
or
something
okay,
yeah
is
all
confusing.
Some
someone
actually
asked
me.
You
know
they
look.
They
saw
the
format
they
were.
They
were
thinking
was
the
RTP
header
and
that's
actually
the
payload,
so
you're
right,
it
is
a
little
confusing
when
you
look
at
it
looks
directly
like
an
hour,
RTP
header,
so
we'll
we'll
do
some
renaming
there.
Maybe
we'll
slap,
the
full
RTP
header
above
it
too,
so
that
it's
clear
that
there's
both
in
RTP
header
and
effect,
payload
header
sandwich
together.
A
E
A
F
G
Alright,
nice
to
meet
you
very
well,
I'm
away
and
Marvin's
minors
name.
This
drops
this
drop
talks
about
how
to
be
pelo
from
that
for
HTTP
adaptive
streaming.
Actually,
this
is
the
second
version
of
this
trap.
We
present
this
drop
last
time
in
burling
and
since
then
we
have
revised
our
idea
and
to
make
it
more
to
make
a
clearer
so
next
place.
What
we
see
is
a
little
bit
into
the
background.
G
What
we
see
is
that
paid
video
is
becoming
a
revenue
driver
for
operators
so-
and
you
see
that
operators
have
already
had
this
excellent
excellent.
The
video
delivery
platform
IPTV
network,
with
a
lot
of
features
like
for
what
channel
change
and
the
forward
error
correction,
are
features
to
ensure
the
quality
of
experience
to
the
end
users.
So
why
not
bridge
the
HTTP
adaptive
streaming
technologies
onto
this
management,
IP
TV
network
to
bring
more
contents
to
the
operators
and
to
help
them
simplify
their
the
operations?
G
G
We
have
update
the
architecture
use
now
using
the
drug
to
reflect
our
new
idea,
and
we
have
some
updates
to
the
fields
in
the
payload
format,
which
will
I
will
mention
later.
Yes,
please.
So
this
is
the
the
proposed
a
catcher.
The
key
thing
is
the
multicast
gateway.
It
works
kind
of
like
a
LED
clam
and
pose
this
that
you
objective
stream
streams
around
the
otd
server
and
convert
each
of
the
streams
into
a
multicast
group.
G
So
it
also
does
the
it
also
fits
the
media
segments
into
the
riv
packets
so
from
the
multicast
gateway
it
passed
down
the
marcus
streams
down,
maybe
further
into
the
home.
At
at
home,
we
have
the
we
can
use
the
traditional
setup,
set-top
box
to
receive
the
multicast
stream
or
we
can
deploy
a.m
to
you,
which
is
mark
a
stream
cast,
acting
as
a
RB
translator
to
convert
the
mod
cast
to
unicast
to
some
device
that
does
not
support
multicast
directory.
G
So
the
whole
thing
about
this,
a
catcher
is
them
is:
where
do
we
think
the
traders
are
made?
We
believe
that
that
video,
that
is
life
and
of
high
quality,
will
bring
more
public
to
the
operators.
So
we
hold
our
captures.
The
whole
trade-offs
are
made
for
life,
video
of
high
quality,
of
example,
a
4k
Ultra
High
Definition,
so
we
won't
be
on
so
we
want
the
multi-mode
cast
gateway
to
be
as
simple
as
possible.
G
You
know
it
may
has
a
lot
of
processing
to
the
video
contents,
but
we
need
to
ensure
it
to
be
low
delay
for
the
lac
content
and
to
have
high
throughput
for
high-resolution
video,
so
they
might
require
some
updates
to
the
click
to
the
receivers
at
home
clanks.
They
may
need
to
update
their
software
to
support
this
new
arm
okapi
formats-
okay,
let's
please!
So
why
has
over
rdp?
Why
are
a
new
format,
new
payload
format?
As
I
mentioned?
We
need
the
multicast
gateway
to
be
as
the
most
possible
suppose.
G
The
Armani
Cascadia
we
just
just
just
retrieves
the
manifest
files
for,
for
example,
their
dash
media
presentation
or
the
HS
the
the
manifest
file
four
hrs.
It
only
passes
those
manifest
files
and
take
out
of
the
media
segments
and
and
cut
cuts
and
fix
those
media
signals
into
a
TV
packets.
That's
the
very
simple
possessing
on
that
just
cut
and
just
retrieve
cut
and
forward.
G
We
want
to
be
like
that
simple,
so,
the
the
the
arm
not
using
our
to
be
existing
RTP
payload
formats,
of
course,
at
present
some
Poppins
first,
you
know
the
existing
a
DBMS
may
already
be
supported
by
clowns,
so
we
might
need
to
update
the
clowns
and
existing
body
be
paleo.
Formats
may
require
the
multicast
gateway
to
take
a
deep
look
into
the
payload
format
to
pass
the
data
of
the
media
segments,
so
that
is
I
think
is
too
much
in
the
processing.
G
Okay,
so
nested,
please
so
this
is
the
EP
had
a
no
change
to
the
two
to
use
of
a
DP
had
a
since
last
draft.
We
have
the
mac
abide
to
engage
the
last
fragment
of
a
media
segment.
Conventionally
we
have
the
payload
type.
We
have
the
sequence
number
incremented,
/,
rdb
packets.
What's
tricky
is
about
the
field.
Is
the
is
a
time
step?
Actually,
we
set
the
time
step
/
media
segment
so
which
I'll
show
you
a
diagram
nest
nest
slice.
So
this
is
a
example
of
how
of
the
pectin
station
I
mean
I.
G
If
you
look
at
the
has
media
segment
one,
it
has
the
time
step
of
1099,
two
three
four.
So
it's
divided
into
two
out
of
eight
packets,
the
two
out
of
eight
packets
will
share
the
same
time
stabbed,
but
each
individual
rd
Bacchus
will
have
indepent
distinct.
This
sequence
number
and
the
sequence
number
will
grow
across
multiple
RTP
packets,
like
that's
in
text
like
those
packets
for
the
second
segment.
G
G
Is
the
we
added
an
offset
field
in
the
impaler
format
to
help
the
client
to
relate
the
fat
man
to
the
media
segment
and
we
have
removed
the
type
type
field
there
used
to
be
a
type
field
to
indicate
whether
this
is
manifest
by
our
initial
sequence
of
these
of
the
has
of
dash
or
HS,
and
but
we
don't
think
we
don't
want
to
multiplex
those
kind
of
information
into
the
the
one
stream.
So
we
leave
out
those
manifester
in
issues,
information
22
for
the
architecture
to
address,
so
we
just
so.
G
F
I
just
want
one
slide
back
question
on
this,
so
you
removed.
You
said
you
removed
the
multiplexing
of
some
things.
You
remove
the
multiplexing
of
the
meta
information
of
the
container,
but
you're
still,
but
the
media
segments
themselves
are
still
multiplexed
audio/video
subtitle,
whatever,
whatever
tracks
the
container
had
multiplex
together
in
each
media
segment
right
right,.
E
G
F
A
G
F
Going
was,
if
you
don't
expect
receivers
of
this
arts
pedia
to
be
the
ones
that
actually
render
the
media.
They
just
can't
afford
it
long
as
to
something
else,
then
why
even
bother
with
our
tepee?
Why
not
just
multicast
this
you
know
directly
as
as
the
segment
you
know
over
anything
over
straight
UD,
Pearson
thing.
What
is
RTP
add
to
the
mix
here
if
the
receiver
of
that
is
not
actually
going
to
render
it
or
time
sync
it
or
anything
like
that,.
E
That
I
mean
RTP
is
a
little
bit
more
than
an
entrant
protocol.
You
you
can
do
faq,
you
can
do
retransmission,
you
can
do
it.
You
can
use
the
whole
infrastructure
of
all
of
our
little
support
thingies
where
their
sake,
yeah
I'm,
not
sure
whether
it's
a
good
idea
but
I
mean
RTP.
Is
there
for
a
reason
and
the
reason
it's
not
only
that
to
provide
multiplexing
of
different
pelo
types
it
since
that's.
G
B
G
Okay,
we
have
two
ways
for
fragmentation:
wise,
quite
a
straightforward.
We
can
just
cut
the
media
segments
without
without
concern
too
much
about.
What's
inside,
we
just
cut
it
in
to
fit
into
the
other
packets.
So
the
this
way
arm
it's
more
or
less,
it's
less
resilient
to
pack
a
loss,
because
one
loss
of
this
fragment
could
lead
to
the
whole
media
segment
antico
table.
Maybe
we
can
let
the
multicast
gateway
to
do
it
in
a
more
intelligent
way.
G
There's
some.
There
are
several
ways
to
do
it.
If
the,
if
the
media
format
carrying
a
half
segment
is
very
simple
house,
maybe
has
a
fixed
length,
we
can
cut
it
just
with
them.
We
can
cut
it
by
offset.
So
is
a
quite
simple
operation
or
the
the
media
presentation.
The
manifest
files
can
provide
some
hangs
are
where
the
next,
where
the
next
point
is
so
the
multicast
gateway,
can
cut
them
in
a
sickness.
In
2k,
we
packed
the
media
segments
into
smaller
pieces
to
make
the
each
individual
pieces
Dakota
power.
G
So
this
in
this
way,
it
may
require
more
processing
for
the
multicast
gateway,
maybe
more
configurations
for
the
multicast
gateway,
but
the
thing
is
is
more
resilient
for
the
mod
is
more
resilient
to
to
the
packet
loss.
Okay,
so
this
is
trade-off
to
be
made
between
the
balance
is
to
balance
the
packet
loss
and
and
the
complexity
in
the
multicast
gateway,
which
needs
to
take
care
of
when
we
implement
this
all
right.
So
next
slide.
A
A
A
So
this
is,
this
is
a
payload
format,
so
the
question
is
I
would
like
to
ask
for
adoption.
This
is
a
working
group
document
for
the
RTP
payload
format,
based
on
also
that
this
being
done
in
also
they
work
for
the
architecture
and
the
solution
is
done
in
another
body,
not
in
the
ITF,
so
eventually
they
will
need
some
payload
format
to
to
describe
it
as
a
solution.
So
the
question
is:
do
do
is
that
who
would
like
to
who's
there
for
adopting?
This?
I
A
Alibi
also
I'll
try
out
some
day,
Lisa
last
words
on
the
list
or
the
first
one
I'd
get
here,
but
that
we
won't
take
a
decision
only
on
what's
here.
I
just
want
to
see,
what's
here
and
I'll
also
go
to
the
list
and
ask
for
people
that
to
read
them
to
provide
the
the
view
about
adopting
this.
This
is
a
milestone
for
the
working
group,
so.