►
From YouTube: IETF102-NETVC-20180719-1550
Description
NETVC meeting session at IETF102
2018/07/19 1550
https://datatracker.ietf.org/meeting/102/proceedings/
A
B
D
E
F
B
C
C
No
well.
This
is
the
new
one
make
sure
you're
well
aware
of
it.
Please
declare
any
IPR
that
you're
personally
aware
of
it
doesn't
have
to
be
your
own.
Ip
are
welcome
to
make
third-party
declarations
as
well
now,
for
this
working
group
in
particular,
where
we're
trying
to
have
multi
free
deliverable,
it's
critical.
C
C
Yes
and
Jonathan
will
actually
be
presenting
remotely
all
right
so
agenda
bash.
We
have
the
room
for
two
hours,
but
we're
not
going
to
need
that.
We
currently
have
about
an
hour
of
the
agenda
scheduled,
so
we'll
have
update
on
our
our
workgroup
documents,
the
garments
and
testing
and
then
we'll
have
updates
on
the
codex
xvc
and
authority,
one
comparisons,
and
then
we
need
to
have
a
discussion
about
what
to
do
with
the
workgroup.
After,
after
all,
the
Kota
candidates
are
not
presented
any
other
topics
or
adjustments
that
we
need
to
make
all
right.
C
The
big.
The
big
problem
is
the
last
three
milestones:
the
codec
specification,
reference,
implementation
and
storage
format.
We
do
not
have
a
single
merge.
Could
a
candidate
that's
been
adopted
yet,
and
we
need
to
have
a
discussion
about
that
following
the
presentations
about
what
to
do
as
a
worker.
For
this
future
work.
C
H
H
There
was
already
a
section
on
suggestive
tests,
but
I
had
to
add
a
lot
of
more
information.
People
complained
that
there
was
two
different
types
of
test
pair
comparison
and
the
mosque
or
evaluation
method,
but
no
guidance
on
when
the
pick
which
and
also
a
lot
of
detail
lacking.
So
what
I
did
is
I
took
the
pair
comparison
tests
and
expanded
the
section.
A
lot
I
gave
actual
criteria
for
evaluation.
We
can
look
at
the
next
slide.
Oh.
I
H
Yeah
this
is
the
last
slide
so
but
there's
one
more
slide.
Actually,
but
yeah
we
wrote
the
pair
comparison
section
on
we
actually
used
a
methodology.
Net
pair
comparison
section
will
be
used
to
test
the
cdf
tool,
I'm
just
an
example
of
the
results
we
got
from
one
of
the
tests,
so
we've
already
made
sure
this
methodology
works
so
that
this
is
a
basically
produces
you'll,
get
a
votes
for
one
side,
the
host
other
side
and
you
know
votes.
H
You
know,
there's
a
rule
that
says
how
many
votes
you
have
to
have
for
it
to
be
considered
significant.
For
example,
our
are
the
fused
in
math
and
subjective
test
section.
The
second
third
and
fourth
we're
videos
on
this
result,
page
or
considered
significant,
but
the
first
and
in
fifth
and
sixth
ones
aren't
the
colors
are
just
for
the
color.
The
far
apart
so
red
is
voting
for
cdf
a
filter
on
a
green
is
voting
for
the
cdf
filter
off
and
then
our
gray
means
they.
H
Could
you
couldn't
tell
the
difference
between
the
two,
so
we
gave
the
option
for
a
tie
button
basically
and
in
an
exercise:
hey
yeah
I,
didn't
we
added
a
guidance
to
use
and
basically
we
found
that
the
mosque
or
in
method
was
not
very
popular
because
it
was
really
expensive
to
do,
and,
secondly,
they
were
because
it's
an
app
you're,
giving
an
app's
of
quality
rating.
We
have
to
have
a
testing
environment
set
up.
They
have
everyone
go
through
this
special
environment.
That's
basically
really
hard
to
do
when
you're
relying
on
people's
contributions.
H
You
know
so
the
fair
comparison
is
really
nice,
because
it's
robust
against
different
test
setup.
So
you
can
have
a
huge
crowd
of
people.
Do
it
basically
on
their
laptops,
and
you
can
always
view
basic
looking
in
relative
differences,
so
the
apps,
the
test
setup,
isn't
as
much
of
an
issue.
So
that's,
basically
all
the
changes.
I
did
the
district
pretty
much.
Nothing
else
was
touched.
I
think
there's
a
couple
minor
myths,
but
at
this
point,
is
basically
done
so.
F
B
J
Hello,
can
you
hear
me
answer
you,
oh
great,
perfect,
okay,
so
I
will
give
an
update
on
the
expressive,
video
codec
and
present,
especially
what
has
happened
since
the
last
IDF
meeting
when
it
was
presented
for
the
first
time.
So
we
can
look
at
the
next
slide.
Please
so
I'll
just
give
a
short
introduction
to
what
exbc
is
and
then
just
mention
about
the
technology.
J
But
the
focus
of
the
presentation
will
be
about
what
has
happened
since
last
meeting
news
since
IT
f11
and
then
I'll
show
the
results
and
results
for
the
new
royalty-free
baseline
profile
of
exbc
and
that's
basically
and
then
the
conclusion
is
that
actually
C
is
considered
a
candidate
for
fournette.
We
see.
So
if
we
look
at
the
next
slide,
please
so
X
you
see
is
what
we
call
a
next-generation
video
codec.
We
released
the
first
version
of
it
in
September
last
year
and
then,
just
a
few
weeks
ago,
we
released
the
second
version
of
it.
J
It's
been
developed
by
a
company
called
the
vision.
It's
a
software-defined
open-source,
video
codec,
there's
also
a
commercial
license
available
from
before
it's
from
from
Davidian,
and
we
have
a
specific
framework
for
for
dealing
with
the
evolution
of
the
codec,
which
I
presented
in
more
detail
at
the
last
meeting.
So
if
you
have
access
to
those
slides,
you
can
look
deeper
into
that.
We
also
focus
quite
much
on
making
sure
the
decoder
is
running
fast
and
and
the
decoding
complexity
isn't
too
bad,
so
we're
actually
have.
J
We
have
a
JavaScript
version
of
it,
which
runs
in
real-time
at
our
webpage,
which
you
can
check
out
next
slide,
please.
So
this
is
just
a
recap
of
the
technology
which
is
in
X.
We
see
there
is
quite
lots
of
similarity
with
conventional
codecs
such
as
ABC
and
HVC,
but
we
have
built
or
included
quite
a
few
novel
tools,
which
are
some
of
them
are
listed
in
this
list,
and
one
important
aspect
of
the
exbc
codec
is
that
all
of
the
coding
tools
are
isolated
within
restriction
flags,
as
we
call
it,
which
means
we
can.
J
We
can
control
from
the
bit
stream,
which
coding
tools
are
activated
for
for
a
specific
bit
stream,
so
the
decoder
will
know
how
to
handle
bit
streams,
which
are
only
using
a
subset
of
the
coding
tools
and
next
slide.
Please
so
so,
focusing
on
what
has
happened
since
lot
lost
ITF
meeting.
We
have
done
some
software
improvements.
We
added
multi-threaded
encoding
support
based
based
on
picture
level
parallelism.
J
J
It
has
a
little
bit
better
performance
than
what
we
reported
in
the
February
meeting.
We
have
improved
the
consolation
coding
but
and
I'm
also
defined
a
royalty-free
baseline
profile,
which
is
using
a
pure
subset
of
the
full
exbc
codec,
so
by
disabling,
actually,
roughly
two-thirds
of
the
coding
tools
we're
just
using
25
of
these
restriction,
flag,
controlled
tools,
so
that
gives
first
performance,
of
course,
but
it
also
using
a
much
smaller
tool
set.
C
J
I
mean
we
have
done
a
limited
analysis
of
of
the
IPR
situation,
will
focused
more
on
the
the
finding
a
tool
set
of
the
basic
tools
which
which
gives
good
performance
and
and
seem
to
be
generally
well
known
from
from
from
a
certain
time
back.
But
we
haven't
done
a
thorough
IPR
analysis.
So
it's
it's
more
relying
on
our
process
for
dealing
one
with
licensing
issues
when
they
arise.
J
C
Okay,
so
so
the
tools
that
you
disabled,
we're
just
basically
a
rough
stab
at
what
you
think
is,
is
not
going
to
impact
the
performance
too
much
and
maybe
new
enough
that
it
may
have
some
IPR
you're
not
actually
aware
of
any
it.
Wasn't
people
coming
to
you
and
asking
you
to
remove
things
for
your
process.
It
was
you
just
deciding
that
these
things
may
have
high
PR
on
them,
so
you
actively
remove
them.
Yes,
okay!
So.
J
Maybe
we
can
go
to
the
next
slide,
yes
ma'am.
So
these
are
the
results
that
that
we
presented
in
February
and
the
performance
has
not
changed
almost
anything
on
the
on
the
full
tool
set.
But
on
the
next
slide
we
report
results
for
the
royalty-free
baseline
profile
and
in
this
case
the
the
royalty-free
profile
is
the
anchor.
So
we
show
how
much
do
you
gain
from
using
the
full
tool
set
and
that
is
reported
to
be
around
twelve
and
a
half
percent
and
yeah.
I
J
Include
it
in
the
in
the
lives
or
in
the
updated
draft,
but
we
have
published
the
results
at
this
a
wcy
dr.
video.com,
so
you
can
pair
the
different
configurations
there.
If
you
want
to
compare
a
v1
with
the
royalty-free
baseline
of
exbc,
for
example,
it's
possible
to
do
that,
but
in
some
times
you
can.
You
can
also
derive
from
these
numbers.
From
from
this
slide
and
the
previous
slide,
you
can
get
an
rough
estimate
of
the
distance
between
the
different
options.
H
J
H
C
C
C
Yes,
yes,
okay,
the
reason
ask
is
because
the
I
think
in
Steiners
presentation
there's
also
some
discussion
about
whether
this
may
be
practical
for
for
modern
codecs,
and
it
seems,
like
your
performance,
shows
that
it
is.
Can
you
decode
high
resolution,
like
1080p
in
your
in
your
current
JavaScript
decoder,.
J
I
mean
what
we
have
on
our
web
page
is
360p,
because
that's
that's
what
we
believe
safety
to
demonstrate.
It
runs
on
all
pcs
and
so
on,
but
I
don't
think
in
general.
You
would
be
able
to
do
1080p
with
that
version,
because
that's
what
we
have
so
far
is
a
single
thread
version
of
the
decoder
you
might
want
to
do
multi-threading
if
you
want
to
do
1080p.
C
C
B
K
That's
right:
okay,
Shauna
for
ecstasy
and
England,
so,
starting
before
there
have
been
no
bitstreams
changes
since
the
last
meeting,
not
for
the
last
two
meetings,
I
think,
but
have
been
a
few
updates
in
the
github
repository
all
of
them
related
to
the
entry
in
six
library.
So
I've
added
the
optimizations
for
on
v8,
the
64-bit
ARM
processor
have
some
very
various
minor,
seeing
the
improvements
for
both
x86
and
arm.
Also,
some
new,
intrinsic
s--
added,
which
improves
performance
slightly.
K
Elaborate
slightly
on
the
seemed
e-library,
your
quick
recap
on
what
that
is
so
Thor
is
using
is
not
using
the
intrinsics
instructions
directly
its
instead
using
a
library,
and
the
idea
is
that
it
enables
an
implementation
rights
in
the
optimized
code
once
for
all
architectures
and
compilers,
and
all
the
low-level
compiler
specific
code
can
be
hidden
in
that
directory
and
if
we
want
support
for
a
new
architecture,
for
the
codec
will
simply
add
support
for
that
in
the
library
and
the
actual
code.
A
code
can
remain
unchanged.
K
So
this
in
twenty-six
are
generic
and
easy
to
implement
on
most
architectures,
which
also
means
that
intrinsics
that
are
very
specific
for
one
architecture
and
difficult
to
replicate
on
others
are
avoided.
So
the
final
assembly
may
not
always
be
optimal,
but
it's
usually
good
enough,
and
and
also
the
limited
support
for
the
highly
specialized
intrinsics
in
the
library
forces.
K
Interesting
possibilities
open
up,
so
it
means
that
the
decoder
itself
can
be
transmitted
in
with
a
bit
stream
and
run
at
near
native
speed
in
browsers,
and
that
allows
quick
deployment.
So
codec
changes
specifically
IP
are
issues
can
be
addressed
quickly,
so
I'm
just
bringing
this
up.
This
is
not
a
formal
proposal,
but
we
should
do
something
like
this
and
I
think.
Also
adding
simply
support
is
outside
the
scope
of
this
group.
So,
basically
just
asking
for
your
own
opinion.
If
you
have
comments,
I
have
more
sites.
So
just
interrupt
me
at
any
time.
I
The
one
thing
I'd
say
is
probably
it's
worth
sending
the
list
of
Cindy
instructions.
You
want
to
the
people
doing
the
web
assembly
projects
so
they
because,
obviously,
a
pretty
comprehensive
set
of
the
things
that
are
useful.
So
they
know
that
you
know
the
I.
They
presumably
need
to
know.
What's
people
actually
would
use
if
they
defined
it
so
yeah.
L
L
L
C
So
the
cheers
I've
had
some
discussions
about
this
point
along
with
ad
we've.
You
know
we
definitely
reach
consensus
that
the
majority
of
the
work
would
not
be
done
here
for
something
like
that.
I
only
open
question
is
whether
or
not
some
kind
of
umbrella
work
needs
to
happen
somewhere,
because
if
you
just
have
the
bits
and
pieces
of
this
sharted
across
a
lot
of
different
different
sto
is
not
just
workgroups,
but
you
know
that
clearly
some
things
would
need
to
be
done
in
ECMO.
C
Some
things
with
need
be
done
in
w3c,
but
there
you
know
it'd
be
hard
to
do
all
those
without
some
kind
of
coordination
or
some
kind
of
umbrella
effort.
So
the
the
only
work
to
be
done
is
really
binding.
All
of
this
up,
you
know,
defining
the
the
primitives
then
also
binding
it
up.
You
know,
communication
to
the
browser.
Api
is
talking
to
RTE
or
just
to
be
feedback.
All
those
things
so
there'll
be
a
lot
of
binding
work
in
some
parts
of
I.
L
L
K
Okay,
I'll
glue
on
I've
done
some
comparisons
I've
compared
xvc
versus
the
royalty-free
configuration
of
X
to
Z,
which
is
what's
also
what
Jonathan
did,
but
I
was
using
a
different
test
set,
not
I'll,
be
complicit
because
I
didn't
have
access
to
a
server
with
the
ecstasy
enabled
so
I've
been
using.
What
I
used
to
benchmark
for
with
before
we
had
I
will
compare
compressed
yet,
and
the
test
sets
consists
of
eight
sequences
ten
seconds
each
compared
to
1
second,
for
public
and
rest
yet
and
for
kingly
values
and
bit
rates.
K
C
K
Oh,
these
are
the
results
that
I
got.
I
was
using
speed
mode.
One
was
precisely
because
it's
speed
mode,
zero
was
just
too
slow,
so
obviously
well.
The
default
configuration
of
X
PC
is
here
the
anchor
and
I'm
comparing
with
the
relatively
and
obviously
there
is
a
PDR
loss
which
is
fairly
consistent
across
the
stream.
So
I
I
got
a
bit
rate
reduction
of
a
bit
rate
increase
of
14.7%.
C
C
K
K
K
Then
I
also
tried
with
speed
mode
zero
and
using
the
same
anchor,
but
then
I
got
mentor
and
exbc
have
the
pretty
much
the
same
complexity
and
again
xvc
performs
better
for
seven
of
the
eight
sequences
and
on
average
eight
and
a
half
percent
better,
and
even
if
the
dollar
entropy
Qadri
is
added
I,
don't
I
still
think
exbc
roll
free
will
perform
better.
I
also
did
speed
mode
too,
and
in
that
case
Thor
was
better
in
average.
But
then
again,
X
PC
is
running
three
times
faster.
K
K
But
if
you
compare
that
with
everyone,
the
numbers
are
quite
low.
Well,
everyone
has
something
like
seven
or
eight
times
the
number
of
lines
which,
for
the
most
part,
I
think
is
unnecessary,
but
I,
don't
think
I
think
it
was
very
hard
to
make
complete
implementational
every
one
with
fewer
lines
so
called
them.
Ecstasy
and
thought
so
finally,
a
quick
update
on
everyone.
The
spec
is
Bros
frozen.
I
said
that
at
last
meeting,
but
then
I
included,
quotes
for
frozen
this
time.
K
K
So
if
we
compare
it
in
line
with
anyone,
the
different
production
or
the
latest
code
is
now
between
31
and
33
34
%,
depending
on
what
magic
you
use
and
the
encoding
time
is
150
times
that
our
reckoning,
which
I
don't
think,
really
tells
the
complexity
of
everyone,
but
well.
The
reference
encoder
is
not
very
mature,
yet
I
definitely
think
it's
possible
to
make
that
number
go
down
quite
a
bit.
K
K
K
The
graph
is
finally
turning,
so
it's
at
least
going
in
the
right
direction
now,
but
this
is
frames
per
minutes
on
the
y-axis
there's
the
still
some
distance
to
make
the
referencing
called
attractive,
but
it's
definitely
possible
to
achieve
the
really
high
performance
with
everyone,
but
then,
of
course,
with
some
compression
cost.
Oh
yeah,
that
was
what
I
had
animal
questions
comments.
K
J
K
C
So
the
net
of
it
is
that
the
technical
requirements
are
being
met.
The
real
question
is:
what
is
the
IPR
story
around
this
RF
baseline,
and
is
it
something
that
the
workgroup
is
comfortable
with?
Or
is
it
something
that
needs
a
lot
more
thought
and-
and
you
know,
I
want
to
get
a
sense
of
the
room
of
what
people
think
about
doing
this
I
PR
effort.
As
you
know,
something
just
since
the
last
meeting
and
not
in
the
ground
up
on
the
codec
started
and
without
any
deep
analysis
of
the
IPR
during
design.
L
Territory
from
Missoula
well,
I.
Thank
you
guys
for,
for
you
know,
taking
the
effort
to
create
the
the
royalty-free
baseline
I
think
the
the
level
of
analysis
that's
been
done,
that
the
situation
is
still
basically
the
same
as
last
time.
You
know
there
are
a
lot
of
details
here
in
the
details
matter
and
unless
you
really
spend
time
reviewing
all
those
I'm
sure
Moe
knows
from
from
all
his
store
work.
You
know
it's
very
difficult
to
have
any
degree
of
confidence
that
something
is
truly
royalty-free.
C
Speaking
for
the
work
that
was
done,
the
Thor
team,
you
know
not
not
a
majority
of
the
effort,
but
a
certainly
a
large
chunk
of
the
effort
was
you
know,
getting
the
IPR
story
right.
So
you
know
if
we
had
spent
all
that
time
on
technical
progress.
Instead,
we
probably
could
have
made
a
much
better
codec,
but
so
I
have
some
concerns
about.
You
know
short-circuiting
the
IP
or
analysis
effort.
You
know
into
a
few
weeks:
compressing
it
down
to
one
meeting
cycle.
I.
C
L
Yeah
and
and
just
want
to
add
like
like
to
give
some
people
an
idea
of
the
level
of
effort
that
was
applied
here.
You
know
just
on
the
Mozilla
side.
I
think
we
can
estimate
the
amount
of
time
we
spent
on
IPR
review
for
a
v1
was
in
the
order
of
man
years
right,
and
there
were,
of
course,
plenty
of
other
people
in
the
Alliance
who
are
also
contributing
efforts,
in
addition
to
the
lawyers
that
we
hired.
So
you
know
this
really
does
take
a
lot
of
effort
to
get
right.
C
C
Both
of
those
teams
have
stopped
active
development
on
those
there's
been
a
little
bit
of
work
on
Thor,
the
Steiner
summarized,
but
it's
largely
stalled
because
both
of
those
teams
have
been
contributing
actively
to
av1
and
the
goal
originally
was
that
that
work
may
end
up
here
in
this
work
group,
but
that's
now
controlled
by
a
separate
forum
that
will
not
be
publishing
that
in
certainly
has
not
sent
any
signals.
This
work
group
that
they'll
be
any
effort
to
publish
that
here.
C
So,
while
those
two
teams
are
working
in
a
different
group
in
a
different
forum,
there
won't
be
anything
to
progress
here
in
DC
for
either
dolla
or
Thor,
so
that
really
only
leaves
X
BC
as
as
a
candidate
and
the
IPR
story
for
X
BC
doesn't
have
enough
confidence
from
enough
people
in
the
room
unless
others
want
to
stand
up
and
say
something.
Contrary
I've
only
heard
three
opinions
and
all
three
were
low
confidence
about
deploying
this
and
having
it
be
truly
royalty-free.
C
C
So
I'd
like
to
hear,
if
there's
any
ideas
from
anyone
of
what
direction
we
should
take
and
if
not
we're,
probably
going
to
pause
the
workgroup
to
see
what
happens
in
the
industry
with
with
a
b-1
and
some
other
initiatives
that
are
happening
in
other
groups
like
MPEG
and
see
if
there's
a
need
to
resume
later.
But
if
we
don't
have
any
direct
work
to
progress
now,
there's
probably
not
a
need
to
meet
in
the
next
meeting
cycle.
F
And
so,
although
I'm
I'm
sad
about
the
way
that
things
play
it
out,
I'm
sad
that
the
way
that
a
v1
was
developed
was
not,
in
you
know,
more
open
over.
Both
an
organization
like
the
IETF
I
think.
The
fact
that
it
has
finished
with
the
support
of
a
significant
portion
of
the
industry
means
that
even
if
we
could
publish
a
codec-
and
here
it
wouldn't
be
a
good
thing.
So.
C
C
J
Now
I
mean
yeah,
we're
happy
to
contribute
to
the
Buddha
ecstasy
and
if
there
is
an
interest
in
it
but
I
think
money,
we're
not
pushing
for
something
which
wouldn't
be
I
mean
we
want
to
work
collaboratively
around
it.
So
so,
if
there
isn't
it
interest
around
it
and
I,
don't
see
a
point
in
kind
of
pushing
for
it.
F
Adam
Roach
and
again
speaking
his
individual
and
sort
of
outside
that
the
the
charter
of
this
working
group,
I
I,
think
the
work
that
y'all
have
done
in
terms
of
getting
this
to
work
in
JavaScript
is
very
interesting.
This
is,
unfortunately,
the
wrong
venue
to
do
anything
other
than
maybe
a
little
bit
of
work
around
the
edges
and
I
would
encourage
you
to
continue
to
do
that
sort
of
work
as
mo
points
out.
F
I
mean
so
they're
gonna
be
a
little
knobs
here
and
there
that
you
have
to
do
on
like
WebRTC
to
get
this
to
work
accurately
in
browsers.
If
you
want
real-time
and
around
the
I'm
blanking
on
the
name
of
the
structure,
the
audio
and
video
graph
stuff
that
we
have
inside
web
browsers
to
make
it
work
for
non
real-time
I
mean
so
there'd,
be
a
lot
of
work
to
do
there
and
I
think
that
would
be
very
interesting
it's
just
most
of
it
is
not
I
ATF
work.
B
Essentially,
what
would
happen
next
is.
We
would
issue
last
calls
for
the
requirements
and
testing
documents
and
then
send
those
along
to
the
iesg,
assuming
there's
no
no-bake
qualms
within
this
working
group
for
those
and
then
from
there
we
would
pause
for
roughly
six
months
to
see
where
things
go,
so
that
would
mean
mailing
lists
would
stay
active,
but
no
more
physical
meetings
wouldn't
try
to
schedule
time.
Unless
something
really
came
up
six
months,
isn't
the
unit
number
of
IETF
meetings.
Let's
call
it
two
two
cycles:
okay,.