►
From YouTube: IETF97-NETVC-20161115-1550
Description
NETVC meeting session at IETF97
2016/11/15 1550
A
C
G
A
Another
change
in
the
number
of
rd
points
and
also
changing
their.
There
are
open
issues
and
I'm
not
s-sure,
and
the
big
elephant
is
on
netflix.
Both
symmetric,
Emily,
fully
consumed
to
get
to
see
what
I
had
something
to
do
should,
which
is
sort
of
that
thing,
is
your
chance
right
here:
VMA,
f,
magic,
oh
right,.
B
F
G
E
A
G
G
A
C
C
C
C
C
Alright,
so
that's
the
administrative
tasks,
it
actually
wear
the
blue
sheet
today
out
already
yeah.
Okay,
start!
Thank
you.
So
the
agenda
today
we're
going
to
talk
a
little
bit
about
what
we
want
to
do
with
the
requirements
and
testing
documents
and
then
just
a
real
quick
overview
of
the
changes
in
those
two
documents.
Probably
ten
minutes
or
less
each
on
those
we're
gonna
get
an
update
on
Thor,
a
similar
update
on
dolla
and
then
the
discussion
of
using
pvq
outside
the
dollar
codec
any
comments
on
the
agenda
for
today
all
right.
A
So
are
our
first
milestone
back
when
we
chartered
was
was
too
perhaps
publish
an
informational
document
on
requirements
and
maybe
another
informational
document
on
the
testing
and
evaluation
criteria
and
we're
kind
of
past
that
milestone
by
a
little
bit.
So
we
should
decide
what
we
want
to
do
about
that.
A
First
of
all,
is
there
value
in
publishing
them
so,
and
the
second
question
will
ask
later
is:
is
how
complete
are
they
and
we'll
get
a
quick
update
on
what
the
status
of
them
is
from
the
editors,
but
first
before
that,
we
would
like
to
figure
out
what
are
the
views
on
actually
publishing
this
work?
Should
we
progress
it
as
an
informational
RFC,
or
should
we
let
it
expire,
that's
for
both
the
requirements
draft
and
the
testing
and
evaluation
criteria
draft
and
feel
free
to
answer
the
question
differently
for
those
two
drafts
have.
I
A
And
I
guess
the
notable
thing
is
that
we
wouldn't
we
wouldn't
reference.
The
big
big
question
in
my
mind,
is
whether
or
not
there's
value
in
referencing
this
from
whatever
normative
RFC's
the
group
generates.
So
if
we
generate
a
codec
and
there's
a
need
to
refer
to
anything
in
the
requirements
or
testing
drafts,
that
I
think
would
be
a
key
question
for
people
to
give
an
opinion
on
okay.
I
J
A
The
the
statement
was
that
if
we
publish
a
you
know
a
codec
specification
that
would
be
you
know
a
normative
standards
track
RFC,
whether
or
not
there's
value
in
referring
to
informational,
RFC,
s4
requirements
or
testing
methodologies.
Whether
or
not
that's
important,
and
if
it's
not,
then
there's
probably
not
a
good
reason
to
pursue
publication
of
them.
If
there
is,
then
then
it
probably
is
a
good
reason
to
try
to
publish
them
right.
K
Just
temporary
from
the
floor
just
as
a
point,
the
rc4
opus
6
7
16,
did
actually
reference.
Its
informational
requirements
document
did
ok.
L
If
the
group
doesn't
have
like
a
good
rationale,
but
I
think
the
fact
that
you're
talking
about
it
and
may
reference
it
gives
you
leeway
to
be
able
to
justify
whatever
decision
you
come
to
so
I
wouldn't
be
concerned
about
it,
but
it
might
just
be
worth
taking
a
look
at
that.
So
you
know
how
the
I
is.
She
is
looking
at
these
things
at
the
moment
was.
L
L
L
Yeah
I
I
would
say,
that's
true,
I
mean
there's,
it
was
mode.
It
wasn't
really
motivated
by
this
kind
of
use
cases
motivated
by
groups
which
seemed
to
get
stuck
like
serializing
their
work,
doing
these
kinds
of
drafts
first
and
then
the
protocol
work
legs
and
so
on,
and
that's
not
really
happening
here.
So,
okay.
H
Ben
Campbell
speaking
strictly
as
an
individual
I
say.
One
thing
to
consider
is:
what's
the
archival
value
of
the
information
in
the
requirements
documents
it's
one
thing
to
to
reference
them
in
the
solution
to
say
you
met
the
requirements
that
doesn't
really
have
a
huge
amount
of
archival
value,
but
if
there's
explanatory
material
and
things
like,
then
there
that
help
people
understand
the
solution,
then
that's
a
completely
different
story.
A
You
know
all
of
this
information
in
them,
which
doesn't
seem
to
make
sense
to
be
better
just
to
reference
the
information
once
and
it
would
already
have
the
explanations
of
you
know
why
a
metric,
that's
you
know,
objective
versus
more
perceptually
warranted.
You
know,
would
be
a
good
justification
for
including
a
tool.
That's
giving
objective
gains
vs.
a
tool,
that's
giving
you
know
mostly
subjective
gains,
so
I
think
there's
a
lot
of
a
lot
of
good
reasons
to
publish
a
testing
draft.
The
requirements
I
think
there's
some
some
weaker
justifications
to
publish
it
mostly
around.
C
C
No,
she
did
that
last
time,
so
I
I'm
in
its.
We
already
actually
had
this
question
raised
in
the
list.
There
was
one
person
sorry
also
screen.
Oh
we
did
again.
There
was
one
person's
woke
up
in
favor
of
it.
It
was
otherwise
silent.
I
would
say
you
know
we
can
take
this
to
the
list,
but
there's
probably
going
to
be
very
little
additional
comment,
so
I
suspect
we
will
do.
C
C
B
C
A
C
The
end
of
this
and
I
presume
you're,
going
to
cover
the
to
slide
back.
Yes,
oh.
A
Well,
we
can
let
Jose
speak
to
it
if
you
want
to
Jose.
If
you
want
to
talk
to
your
your
requirements
update,
is
it
cute?
Yes,.
J
I
would
like
to
okay.
Can
you
hear
me
yep,
okay,
great
first
Lottie,
so
thank
you.
I
can
see
that
so
the
changes
from
the
previous
version
02
were
very
minimal.
I
guess
the
most
important
one
was
that
originally
we
had
12
QP
points
for
for
the
evaluation
and
we
decided
to
only
have
10.
So
that's
really
the
major
major
change.
So
if
you
could
go
to
the
next
page,
I
will
go
very
quickly
on
on
what
we
did
over
the
over
this
past
few
months.
J
So
there
were
three
main
parts
of
the
document:
overview
of
applications,
use
cases
etc.
There
were
no
changes
in
that
then
the
section
on
the
requirements
themselves
and
then
the
evaluation
methodology
which
were
minor
changes
so
next
slide
please
so
the
basic
requirements
and
I
can't
see
that
too.
Well.
So
let
me
pull
out
my
own
copy
here,
so
that
I
can
talk
to
that
the
basic
requirements,
essentially
what
we
changed.
We
agreed
that
the
bitstream
specification
should
support
independently
decodable
subframe
units
kind
of
like
slices
or
independent
tiles.
J
But
you
know
we
don't
necessarily
say
that
that's
exactly
what
they
have
to
be,
but
they
must
be
independently
decodable,
and
so
it
should
be
possible
for
the
encoder
to
restrict
the
bitstream
to
allow
parsing
of
the
bitstream
after
some
packet
loss.
So
we
had
some
quite
a
bit
of
discussions
on
that
and
how
to
to
specified
in
how
to
communicate
it
to
the
decoder.
So
that
was
really
the
basic.
The
only
change
in
the
basic
requirement
so
to
be
more
explicit
as
to
packet,
loss,
partial
packet
loss
and
then
the
optional
requirements.
J
So
yes,
so
as
I
was
saying,
the
really
main
major
point,
I
guess
was
that
we
we
decided
that
the
number
of
QP
points
was
reduced
from
12
to
10,
to
simplify
and
to
be
able
to
better
in
quickly
more
quickly
assess
the
equality,
and
we
decided
that
we
will
perform
that
alignment
only
on
for
QP
points.
So
now
we
have
the
same
as
before
three
different
sections
or
low
middle
and
high,
and
then
for
for
QP
points
and
the
the
ends
overlap.
Basically,
and
so
we
also
continue
to
use.
J
Psn
are,
and
ms
ssim
for
basic
quality
assessment.
So
essentially
we
simplify
the
process
so
that
it
can
be
done
more
efficiently.
Next,
please!
So
that's
that's!
Basically
it
so.
Essentially
the
the
conclusions
were
that,
as
you
can
see
here,
we
try
to
take
into
account
all
the
comments
that
we
did
over
the
the
list,
and
so
that's
that's
basically
it.
Thank
you.
Any
questions.
A
J
M
All
right
am
I
in
front
I
at
Thomas,
Teddy
take
Thomas
Stadium
missoula
I
sent
a
couple
comments.
They're
all
minor
issues,
I
mean
it's,
it
I
think
it's
ready,
as
is
it
was
just
a
couple
wording
things.
C
C
C
C
A
C
It's
a
subject
to
the
outcome
of
those
reviews.
It
sounds
like
there
is
a
wording
change
that
Thomas
is
adjusted,
so
they'll
probably
be
at
least
one
more
revision
before
you
public
it,
and
I
think
the
it's
like
what
I'm
concluding
here
is.
We
will
have
probably
tim,
have
one
more
person
review
it
updated
according
to
that
and
thomas's
input
and
then
do
a
pub
break
as
soon
as
that
new
version
comes
out.
C
C
N
N
K
Alright
I'm
going
to
talk
about
the
the
latest
revision
of
the
testing
draft,
which
Thomas
daddy,
is
the
author
for
and
while
use
here
remotely.
He
asked
me
to
present
in
person
if
sorry,
that
better
I'm.
K
Excellent,
so
I
will
do
my
best
job
and
Thomas
will
interrupt
me
if
I
start
telling
any
lies
so
their
their
basic
two
basic
things.
Metric
updates
and
range
updates
slide.
So
for
the
metric
updates,
we
have
removed
fastest
as
I
am
entirely
and
replaced
it
with
regular
MSS
I
am
armed,
so
we
re
amenta
dem
SSS.
I
am
from
scratch
referencing
several
of
the
popular
implementations
of
it,
and
in
doing
so
we
found
some
bugs
in
the
fastest.
K
I
am
implementation
which
we'll
talk
about
more
later
on,
but
the
speed
difference
between
the
two
is
relatively
small
compared
to
how
incredibly
slow
all
modern
video
codecs
are
at
least
in
in
in
the
development
versions.
So
we
didn't
see
a
point
in
using
the
the
fast
version
side
arm.
K
We
also
updated
the
text
on
VMA
f,
which
is
the
metric
proposed
by
netflix.
One
point
of
clarification
was:
was
that
unlike
sm
and
MSS
somewhere,
we
do
this
log
conversion
to
make
them
give
numbers
that
look
vaguely
like
PS
and
our
decibels
arm
44
vm
AF.
We
just
used
the
scores
directly
and
that
matches
the
neth
addala
g
that
netflix
themselves
used
in
their
own
studies
next
slide
arm.
K
So
we
clarified
some
of
the
specification
of
the
quantizer
ranges
to
use
so
for
individual
tool
testing
we
now
list
for
explicit
quantizers
and
for
the
final
requirements
testing.
We
match
the
update
you
heard
of
in
the
requirements
draft
with
ten
specific
quantizers,
and
that
is
a
change
from
the
previous
version,
where
we
just
specify
the
minimum
in
the
maximum,
but
not
any
of
the
points
in
between.
So
now
we're
explicit
about
everything-
and
I
think
that
is
the
last
slide.
K
Oh
sorry,
one
more
on
that
yeah,
so
so
I
think
this
document
is
not
quite
done
yet.
We
wanted
to
add
a
few
more
clips
arm,
one
specifically
at
very
low
resolutions,
just
because
some
of
the
the
important
use
cases
are
dealing
with
very
low
bandwidth
situations,
and
so
you
want
your
scalable
video
to
go
all
the
way
down
to
240p
arm
and
then
on
the
other
end.
We
also
wanted
to
make
sure
we
had
at
least
some
HDR
sequences
on
in
the
the
baseline
test
set.
K
So
we
were
not
able
to
get
that
finalized
in
time
for
the
the
ITF
draft
deadline.
But
you
can
see
a
preview
of
the
the
sequences
that
we're
planning
for
that
at
that
URL
and
that
I
think
is
the
last
one.
A
K
I
think
they
are
not
yet
incorporate
into
our
we
compressed
yet
so
netflix
has
published
the
source
for
their
metric,
but
it
doesn't
take
input
in
the
same
form
that
we
have
all
of
our
test
sequences
stored
in,
and
so
we
need
to
modify
the
input
modules
and
that
just
hasn't
happened.
Yet.
Ok.
A
K
I
mean
it
is
on
our
to-do
list,
so
we'll
get
it
up
there
at
some
point.
It's
just
a
matter
of
typing.
E
M
M
Here
we
go
I
think
you've
noticed
Tommy
stadium
is
a
lot.
I
was
a
convention.
I
I
run
the
tool
oakley
with
the
is
using
hurting,
though
the
input
formats
myself
in
the
works
like
that
you
can
implement
it,
as
is
my
just,
have
a
I
posted
on
the
job
right
as
a
working
pet,
our
progress
patch,
so
that's
hopefully
coming
or
very
soon,
so
it
is
actually
possible
implemented
draft,
as
is
I
just
haven't
done
it
on
the
main
website.
Yet.
M
A
K
Yeah,
so
I
think,
in
addition
to
the
the
updates
to
the
test
sequences
at
some
point,
we're
probably
also
one
of
going
to
want
to
think
about
arm
testing
things
like
rate
control
and
we
don't
have
a
test
procedure
for
that.
Yet
so,
as
we
flush
out
our
rate
control
experiments,
I
think
we'll
we'll
come
up
with
good
criteria
for
that
Adam
to
the
document.
So.
J
Jose
yeah.
Thank
you
just
a
very
quick
thing.
Going
back
to
the
requirement,
you
know,
I
believe
that
we
included
Thomas's
comment,
so
I'm
gonna
ask
Thomas
to
please
you
know
later
on
to
quickly
take
a
look
at
the
document
and
make
sure
that
we
included
your
comments
Thomas
so
that
that's
basically
it
thank
you.
C
C
I
On
the
encode
aside
and
slightly
more
on
the
decoder
side-
and
it's
also
possible
to
encode
10
and
12
bits,
video
within
eight
bits,
internal
bit,
depth
which
reduces
the
complexity.
But
basically
you
destroy
all
the
benefits
that
you
have
from
high
bit
depth,
so
you're,
probably
desperate.
If
you
do
that,
and
the
video
bit
depth
and
the
internal
bit
depth
are
signaled
in
the
sequence
header
next
one.
I
I
All
these
sequences
are
HD
and
on
average
we
get
three
points.
A
3.8
gain
its
slightly
less
for
lower
resolutions
and
the
best
gains
are
had
for
the
high
bit
rates,
which
I
suspect
is
that
the
reason
for
that
is
that
at
higher
bit
rates,
the
rolling
errors
are
becoming
more
important
next
one
place,
and
if
we
move
up
to
12
bits
internal
bit
depth,
the
gains
are
slightly
better.
Four
point:
three
percent
and
it's
it's
a
result
of
both
reducing
the
bit
rate
and
increase
in
peace
in
our
next
one.
I
Moving
on
to
how
it
looks
in
in
chroma.
This
is
the
you
component
and
then
we
get
quite
good
gains,
almost
thirteen
percent,
but
these
numbers
have
have
to
be
taken
with
a
grain
of
salt,
because
this
is
B.
They
are
calculated
using
UPS,
NAR
and
a
bit
rate
dominated
by
white,
but
it
means
that
the
chroma
P&R
goes
up
quite
a
bit,
so
so
it's
the
gains
are
definitely
higher
for
chroma
and
the
next
one
place,
and
these
are
for
the
key
component
is
almost
identical
numbers
again.
I
A
Move
from
floor
mark
again,
so
I
was
surprised
by
how
large
these
numbers
were
and
actually
shocked
by
the
the
chroma
numbers.
I
couldn't
believe
that
that
much
gain
was
possible
just
from
a
simple
one
or
two
bit
too
or
forbid
extension.
So
it
made
me
wonder
whether
or
not
we
think
the
so
that
missing.
This
is
just
straight
pious
and
our
gains
right
straight,
pious,
an
hour
video
games,
yeah.
A
So
I
guess
what
I'm
wondering
is:
are
these
just
the
imperceptible
gains
that
we
think
may
be
a
subjective
metric
wouldn't
be
wouldn't
be
as
as
favorable
or
do
we
think
that
this
is?
This
is
really
a
good
quality
gain,
because
the
numbers
suggest
pretty
dramatic
quality
Kings
quite.
A
It
may
even
go
back
to
the
luma
ones,
even
the
LUMO
ones,
especially
for
video
copies,
simple
content
for
simple
content,
the
the
even
the
LUMO
that
was
pretty
high
hit
like
a
tin
man,
yeah,
eight
and
sixteen
percent.
The
bit
rate
savings
that
that
seemed
pretty
pretty
high
to
me
for
forcing
tube.
It
doesn't.
I
Have
I
don't
have
the
numbers
for
say
h.265,
but
I
suspect
that
they
would
be
similar
since
we
have
the
same
transform.
I
A
Maybe
useful,
try
to
run
the
the
perceptual
metrics
to
and
see
if
see,
if
ms
sm
gives
us
anything
or
if
we
can
ever
give
vmf
running
see
if
that
gives
similar.
I
K
To
tarifa,
missoula
yeah,
I
think
computing
PSN
are
our
computing
BD
rate
changes
using
PSN
are
from
chroma,
but
total
bit
rate
for
the
sequence
is
basically
garbage
you.
Eighty
to
ninety
percent
of
your
bits
are
in
the
LUMO
component.
So
if
you
change
the
luma
component
in
some
way,
that's
independent
of
how
the
chroma
changes,
then
your
whole
curve
will
shift
by
large
amounts
like
you
saw
yeah
so,
and
that's
not
telling
you
how
the
chroma
quality
changed
so.
I
So
that's
why
I
said
those
numbers
have
to
be
taken
with
a
grain
of
salt
yeah.
That's
the
chroma
p
is
not
didn't
go
up
so.
K
The
oreck
compressed
jet
has
a
metric
called
see
a
CID
cie
de
on,
which
is
the
CIA
color
space
delta
e
measurement
on
which
is
a
very
PSN,
are
like
measurement,
but
actually
takes
color
into
account
in
you
know,
attempting
to
use
human
perceptual
judgment
of
color
to
to
estimate
distances,
and
so
I
I
think
that
is
a
much
more
reliable
metric
on
to
evaluate
whether
or
not
you
are
improving
or
actually
improving,
luma
and
chroma
versus
just
you
know.
K
M
I
Okay,
thank
you.
Yeah
next
month
is
yeah
so
supporting
higher
bit
depth.
That
means
some
adjustments
to
the
code,
so
the
things
that
had
to
be
changed
where
the
shift
of
the
first
part
of
the
forward
transform
had
to
be
adjusted
according
to
the
debt
and
the
shift
after
the
second
part
of
the
inverse,
transform
and
also
the
strength
of
the
constrained
low-pass
filter.
I
So
when
we
had
120
for
in
8-bit
video
that
has
to
be
adjusted
to
for
8
or
16
for
10
bit
and
likewise
for
12
bits
and
also
the
same
thing
for
the
trestle
and
beta
for
of
the
deblocking
filter.
And
of
course
we
have
to
adjust
the
pics
to
clipping,
whereas
the
conversation
and
the
conversation
are
unchanged,
meaning
that
the
QP
range
remains
the
same,
and
that
makes
sense
for
me
from
a
user
perspective.
I
think
h.265
is
doing
it
differently.
I
I
guess
it
really
depends
on
whether
the
increased
death
is
for
increased
accuracy
or
for
high
dynamic
range,
but
the
user
can
always
change
the
QP
in
the
application
and
do
whatever
he
even
thinks.
This
is
right.
So
these
are
small
changes
on
paper,
but
they
have
large
implications
for
the
source
code
because
we
want
to
have
optimized
source
code
next,
one
please.
I
I
The
key
is
that
the
amount
of
source
code
remains
roughly
the
same,
but
the
executables
increase
in
size
next,
one
so
for
uses
an
abstraction.
How
common
seem
the
intrinsic
support?
Simdi
optimizations
for
different
architectures
reason,
for
this
is
that
we
just
want
to
write
seeing
the
optimized
code
once
and
an
have
good
results
on
multiple
architectures.
I
I
So
that
was
added
along
with
a
native
support
for
ATX
to
otherwise
these
new
256
bits
intrinsic
are
emulated,
which
is
mostly
by
simply
duplicating
128
bit
intrinsic.
So
in
the
end,
we
end
up
with
just
one
set
of
Cindy
optimized
code
to
maintain,
regardless
of
the
bit
depth
and
architecture.
Next,
one
arm.
I
But
it
did
it
needed
a
few
changes
of
the
existing
code
to
make
that
possible.
So
so,
rather
than
writing
new
code,
I
rework
the
existing
code,
it's
just
as
fast
as
before,
but
it's
now
trivial
to
convert
and
it's
just
a
matter
of
searching
replays
done
by
a
set
script,
and
now
that
we
have
even
widened
in
chicks.
I
We
also
have
the
door
open
to
add
a
txt
optimizations
even
for
the
8-bit
code,
but
that
has
not
yet
be
done
next,
so
to
just
have
a
summary
of
the
input
formats
that
Thor
supports.
Now
that's
8,
10
and
12.
It's
video
and
we
also
have
for
20
and
40
for
chroma
sampling,
which
was
adding
added
before
last
meeting,
and
we
have
basic,
simple
but
optimises
optimizations
for
everything.
I
For
seems
to
have
a
much
better
complexity,
compression
trade-off,
and
this
is
for
the
low
delay
conquer
the
configuration,
and
if
we
move
on
to
the
high
delay
configuration
on
the
next
slide,
then
sore
still
has
a
better
trade
off
than
h.265.
But
it's
not
quite
able
to
match.
Vv
9
at
least
leave
in
I'm
for
most
part
runs
faster,
but
I
also
believe
that
vp9
has
more
seemly
optimizations,
so
it
should
be
possible
to
rise
for
care
of
it.
I
So
you
know
not
a
long
list
of
new
tools
this
time,
so
we
could
perhaps
rather
say
that
for
has
matured
a
bit
now
support
no
supporting
what
it
absolutely
needs
to
support
so
yeah
any
questions
things
to
discuss.
A
So
I'm
at
a
point
about
the
surprising
game
for
the
high
bit
depth.
If
Jose
could
come
back
in
in
the
queue
I'm
trying
to
recall
what
did
the
requirements
say
about
high
bit
difficult
and
we
iterated
a
few
times
back
and
forth
on
that?
Is
it?
Is
it
just
an
optional
requirement,
or
is
it
a
separate
profile
or
are
we
baking
hi
bit
depth
internal
precision
into
the
basic
requirements
for
any
candidate?
Now
it
sounds
like.
Maybe
we
should,
if
I,
if
the
gain
is
really
that
good.
J
A
J
I
Well,
it's
a
requirement
to
have
10
bits
in
potato,
then
I
suppose,
there's
no
reason.
Why
not
use
that's
even
48
bits
video
input
since
it
has
to
be
implemented
anyway,
but
the
trick
really
is
what
you
do
internally,
not
what
the
resolution,
what
what
kind
of
resolution
that
you
accept
and
the
software
wise
there
is
no
difference
between
10
or
12
bits,
video
in
complexity.
So
if
you
have
to
support
10
bits,
you
can
just
as
well
support
12
bits
and
then
use
that
as
an
internal
to
at
least
from
a
software
perspective.
K
Then,
to
interior
from
ZOA,
so
I
know
you
guys
talk
to
while
up
go
about
implementing
arithmetic
coding
in
Thor
is?
Is
there
any
progress
on
that,
or
is
that.
K
Coding
we.
I
Have
thought
about
it
I
if
about
half
a
year
ago,
I
did
some
experiments.
I
tried
a
couple
of
ways:
I,
actually
an
had
a
couple
of
working
implementation
using
that,
but
the
gains
were
very
small
and
even
if
I
cheated
just
assuming
that
I
would
reach
the
entropy.
The
gains
were
quite
small,
so
the
trick
here
isn't
really
arithmetic
holding
with
how
we
do
the
adoption.
So
currently
it's
not
on
the
agenda,
since
the
gains
were
so
small
and
there
also
are
some
benefits
of
doing
it
like
we
do
now.
K
All
right,
good
people
here,
okay,
good,
so
say
that
that
there
has
not
been
a
large
number
of
changes
in
dolla,
but
but
we
have
done
a
few
things.
The
first
one
is
that
that
we
have
finally
finished
our
fixed
point
point
of
pv
q,
so
that
had
been
going
on,
I
think
for
a
couple
of
meetings,
but
is
now
done
we
also
ported
pvq
over
to
81,
and
so
we
had
some
interesting
results
there
that
you
Sheen's
going
to
talk
about
in
his
presentation
afterwards,
so
I
won't
spoil
his
his
thunder.
K
The
dollar
entropy
coder
had
also
previously
been
integrated
into
a
v1,
is
now
the
default
arm,
and
then
we've
done
several
improvements
to
metrics
and
tools,
including
all
of
our
metrics,
now
support,
10
bits
and,
as
I
said
in
the
the
discussion
of
the
testing
draft
we
found
and
fixed
in
overflow
and
fastest
as
I
am
next
slide.
So
let's
talk
about
that
one
a
little
bit
more.
K
Basically,
there
was
an
integer
overflow
that
only
affected
frame
sizes
of
1080p
or
larger,
and
so
we
did
our
initial
validation
of
fastest
as
I
am
we
did
it
on
our
still
image
test
sets
which
are
just
small
enough
not
to
trigger
it.
But
it
does,
however,
include
some
videos
in
ntt
short
one,
which
was
the
set
of
test
sequences
that
we
use
to
report
most
of
our
historical
results.
So
all
those
numbers
have
been
wrong
next
slide.
So
this
is
the
the
slide
I'm
sure
most
people
here
have
seen
before
on.
K
The
one
other
difference
between
this
slide
and
the
previous
one
is
that
x265
got
upgraded
from
version
1.8
to
version
2.1
on
our
testing
infrastructure.
So
we
have.
The
new
numbers
are
with
the
new
version
of
x265
and
that's
why
you
see
that
red
curve?
There
has
changed
a
little
bit,
but
most
of
the
rest
of
the
numbers
just
got
a
little
bit
worse
at
the
high
end,
but
the
overall
story
didn't
change
very
much
all
right
arm.
K
So
this
measures
with
fewer
points
and
on
a
different
set
of
test
sequences,
and
so,
as
you
can
see,
when
we
do
this,
I'm
also
using
regular
MSS
as
I
am,
as
I
mentioned
before,
instead
of
fastest
as
I
am
armed,
you
get
the
results
here
where
there
is
a
bit
of
a
larger
gap
between
us
and
x265
arm,
so
that
I
think
that
has
more
to
do
with
the
set
of
test
sequences
than
it
does
the
switch
from
fastest
as
I
am
to
MSS.
I
am.
K
K
So
you
can't
accuse
us
of
picking
our
test
conditions
to
make
us
look
good
overall,
since
Berlin
we've
had
about
60
commits
the
encoder
has
gotten
between
sixty-nine
percent,
faster
and
and
we've
had
fairly
small
improvements
in
berate
most
of
that
I
think
as
a
result
of
the
the
pv
q
work
right
next
slide
all
right.
So
these
are
a
bit
more
details
about
the
various
changes.
K
As
I
said,
fixed
point,
p
BQ
is
now
finished
that
was
27
of
the
60
commit
so
about
forty-five
percent
of
the
work
on
the
overall
be
rate.
Changes
were
we're
very
small
arm.
We
are
still
actually
using
double-precision
floating-point
in
the
encoder
side,
but
that's
not
normative,
so
we're
not
planning
to
fix
that
any
time
soon.
You
have
a
question
about
garden.
B
K
And
in
fact,
we
may
always
wind
up
using
floats
some
platforms,
just
because,
when
we
do
our
do
is
actually
very
convenient.
If
the
hardware
has
a
fast
reciprocal
square
root,
approximation
to
make
use
of
it
and,
for
example,
x86
has
that
for
floats,
but
not
integers
arm
has
it
for
both.
So
we
could
actually
do
that
in
fixed
point
for
arm,
but
but
we
may
wind
up
using
the
floats
in
the
encoder,
always
next
slide.
K
At
the
moment,
we're
mostly
just
using
raw
intrinsic
directly
for
every
platform,
we
did
look
at
the
Thor,
intrinsics
and
I
think
we
had
a
patch
from
Steiner
and-
and
we
had
a
bunch
of
review
comments
on
it
and
I
think
those
were
never
addressed.
So
we
never
landed
it.
Never
converted
all
our
stuff
but
I
mean
I.
Think
we'd
be
okay
with
using
an
approach
like
that,
but
it's
not
currently
integrated.
Okay,.
A
Because
I
was
going
to
say
maybe
a
it
may
be
good
for
a
smaller
team
to
figure
out
what
the
best,
what
the
best
intrinsic
approach
is,
and
especially
if
we
can
get
the
lift
of
supporting
a
bunch
of
platforms
with
a
common
library
and
and
with
the
recent
work
for
a
256-bit
that
beat.
That
would
be
good
and
if
you
guys
have
already
done
work
for
float
cindy.
That
might
also
be
good.
If
you
could
somehow
you
know,
I
guess
you
probably
have
totally
different
routines.
A
K
So
well
to
be
clear,
you
know
this
is
this
is
work
we
have
not
actually
done
yet,
so
so
there's
basically
no
Cindy
in
the
actual
pvq
code
at
the
moment,
but
you
know
we
know
how
the
instruction
sets
works
and
we
know
how
we
would
write
it
if
we
went
down
that
path
arm
so
so
like
we
have
not
actually
done
a
fast
RTO
search
using
the
reciprocal
square
root,
proxima
shins
in
in
SSE.
So.
A
K
So
we
also
made
some
algorithmic
improvements
to
PDQ
encoder
speed
since
as
Malouda
to
on
porting
pvq
to
other
contexts
has
in
fact
been
quite
slow
arm,
so
we
are
now
using
an
approximate,
an
approximate
rate
for
making
our
do
decisions,
and
we
also
spent
some
time
improving
that
rate.
This
is
instead
of
explicitly
encoding,
the
actual
the
actual
code,
words
and
then
counting
up
all
the
bits
arm.
K
I,
don't
know
if
everyone
remembers
exactly
all
the
details
of
how
PDQ
works,
but
we
have
these
two
parameters
gain
and
theta,
which
are
sort
of
of
you,
know
somewhat
perceptually
meaningful
parameters
gain
is
the
amount
of
contrast
and
theta
is,
is
how
much
like
the
predictor
you
are
armed,
and
so,
when
we
quantize
those,
we
consider
several
different
candidates,
basically
rounding
up
and
then
rounding
down
and
then
going
slightly
beyond
routing
down
just
for
our
do
purposes
and
from
the
given
value
of
gain
and
theta.
We
compute
this.
K
This
code
book
size,
k
arm,
which
is,
is
basically
the
l1
norm
of
the
resulting
coefficient
vector,
you're
going
to
code,
and
so
the
larger.
That
is
the
more
bits
you
have
to
spend
coding
that
coefficient
vector.
So
when
we
do
all
this,
we
consider
several
all
these
different
candidates
arm
and
at
the
end,
in
order
to
speed
that
up,
we
now
sort
arm
the
different
gain
and
theta
candidates
by
this.
This
value
K,
so
that
when
we
do
our
code
book
search,
we
can
reuse.
K
The
previous
results
just
add
more
pulses
on
to
the
previous
vector.
Instead
of
starting
our
search
from
scratch
each
time,
so
we
also
get
to
skip
the
search
entirely
when
when
K
is
the
same
for
different
gain
and
theta
candidates
arm.
So
this
this,
in
addition
to
being
faster,
also
gave
us
a
small
less
than
point
one
percent
improvement
on
be
rate
and
then
finally
any
gain
and
theta
candidate.
They
can't
possibly
have
a
lower
distortion
than
just
the
skip
candidate.
We
don't
bother
to
actually
search
anymore.
K
So
that's
assuming
you
know
given
given
the
distortion
introduced
by
quantizing
gain
of
theta,
assuming
the
distortion
introduced
by
quantizing.
All
the
coefficients
is
exactly
zero
and
some
minimum
rate
over
what
the
the
rate
we
would
have
to
code
for
skip.
If
all
that
is
is
still
worse
than
doing
skip,
then
then
we
just
don't
look
at
it
and
said
that
that
has
no
metrics
change
because
we're
you
know
not
considering
that
something
that
can't
possibly
help
next
slide.
K
We
also
made
a
number
of
changes
to
the
drinking
filter.
These
have
actually
all
been
changed
in
a
v1,
but
not
ported
back
to
daala.
Yet
so
the
first
one
we
use
a
shorter
five
type
filters
for
chroma.
So
if
you
look
in
objective
one
fast,
there's
one
particular
sequence
minecraft,
where
we
were
showing
fairly
large
regressions
by
turning
you
bringing
on
and
so
using
the
shorter
filters,
makes
those
regressions
go
away
on
the
overall
changes
for
the
the
chrominance
metric
I
mentioned
earlier.
K
Ci
ed
was
very
tiny
calm,
so
we
didn't
lose
any
quality
and
chroma
anywhere
else
by
using
these
shorter
filters
and
the
shorter
filters
are
basically
just
because
chromophore
20
is
subsampled.
We
also
now
support
for
22
input,
but
we
did
that
by
just
disabling
chroma
d
ringing,
so
we
thought
that
was
preferable
than
trying
to
do
something
more
complicated,
the
main
issue
being
since
our
during
filter
is
directional.
K
If
you,
if
you
subsample,
2422
the
directions
in
the
chroma
plane,
don't
line
up
with
the
directions
in
the
luma
plane,
unless
you
stretch
things
and
stretching
things
was,
as
I
said
complicated.
So
instead
we
just
disable
it.
But
you
know
that
makes
chromo
slightly
worse
4422.
But
if
you
care
about
that,
you
should
use
444
arm.
K
We
also
simplified
the
threshold
calculation
for
the
second
filter
arm,
so
this
used
to
be
based
on
the
amount
of
change
in
the
co-located
pixel
in
the
first
filter
and
instead
we
now
based
the
threshold
on
the
total
change
made
by
the
first
filter.
So
in
that
second
filter,
we
no
longer
need
to
look
up
what
the
change
was
on
a
pretty
cool
basis,
and
so
that
saves
a
bit
of
computation
and
it
was
a
tiny
regression.
K
A
Mulligan
from
the
floor,
I'm
on
your
42
comment:
I'm
a
little
confused
about
what
happened
there,
because
I
would
think
that
you
know
anything
sensitive
to
the
size
of
the
block
would
be
impacted
by
42
and
so
I.
Think
not
you
wouldn't
change
the
size
of
the
block.
You
just
have
more
blocks,
you
just
say
about
to
chroma
block.
You
know
four
corner
blocks
instead
of
two.
K
The
problem
is
not
the
size
of
the
blocks.
The
problem
is
the
direction
of
the
filter,
so
the
way
the
way
it
currently
works
is
that
we
estimate
on
the
dominant
orientation
on
the
luma
plane
and
then
reuse
that
orientation
for
the
chroma
planes,
and
so
we
support
eight
orientations
in
the
luma
plane
and
if
you
now
go
take
that
to
chroma,
because
the
chroma
is
only
subsampled
and
one
access,
your
directions
get
stretched
well,
II.
The
diagonal
directions
get
stretched.
K
A
K
A
K
It
does
not
have
a
45
degree
angle
in
chroma
when
you
do
for
22,
so
sampling
right,
it's
either
22
and
a
half
or
do
you
know,
depending
on
which
45-degree
angle
you
talk
about,
and
so
so
we'd
have
to
come
up
with
with
a
whole
bunch
of
different
filter,
filter,
step
sizes
and
directions
and
look
up
tables
just
to
handle
the
422
case
to
make
the
directions
match,
what
the
actual
direction
was
found
in
luma
and
that
just
didn't
seem
worth
the
extra
complexity.
So.
K
On
I
think
it's
not
so
much
size
as
it
is
direction,
and
so
so,
at
least
in
a
v1,
for
example
like
inter
modes
are
directional
but
Derek's,
but
the
chroma
plane
has
a
separately
coded
entry
mode
than
then
the
luma
plane.
So
it
doesn't
have
this
issue.
The
problem
here
is
we're
trying
to
reuse
something
from
the
little
plane
for
the
crumble
planes.
That
is
directional
and
it
didn't
seem
worth
worth
trying
to
do
the
conversion
to
account
for
the
fact
that
the
directions
all
get
skewed.
Alright.
A
K
K
Anyway,
next
slide
arm,
so
we
also
did
some
significant,
optimization
work
of
the
drain
filter
in
a
v1,
so
we
ported
over
all
the
sindhi
code
for
D
ringing
from
dela.
We
also
greatly
reduce
the
amount
of
copying
and
buffering,
and
this
is
so
one
we
made
the
buffer
smaller
and
we
eliminated
some
of
the
buffer
copies.
But
in
fact
the
largest
improvements
were
actually
from
getting
better
cache
coherency
in
the
way
that
we
we
managed
these
things
so
I
think.
K
We
also
stopped
running
at
all
on
blocks
where
the
threshold
was
zero,
so
that
it
couldn't
actually
do
anything
to
those
blocks
and,
overall,
the
decoder
speed
impact
went
from
around
fifty
percent
of
the
decoder
time
without
d
ringing
to
down
to
8.5,
so
three-point-two
percent
of
that
is
for
the
actual
filter
calculations
and
5.3
percent
is
still
buffering
and
copying
and
managing
things
like
skip
flags,
so
we
think
there's
still
room
for
improvement
there.
K
None
of
the
buffer
copies
are
Cindy,
and
you
know
d
ringing
is
currently
done
in
an
entirely
separate
pass,
so
that
could
be
done.
That
could
be
combined
with
the
blocking
to
even
further
reduce
cache
misses.
So
we
think
there's
room
to
move
that
number
down
I'm,
not
sure
how
much
effort
will
invest
into
doing
that,
but
it's
certainly
possible
slide.
K
Just
small
updates
on
the
queue
15
entropy
encoder
adaptation
that
we
discussed
in
Berlin
basically
wrote
it
down
in
this
draft.
If
you
have
questions
about
how
it
works,
see,
I
encourage
you
to
go,
read
it
and
give
us
comments.
We
showed
it
to
some
of
our
hardware
partners.
No
one
had
any
heartburn
about
it,
so
that
seems
good
arm.
K
We
still
may
change
and
improve
exactly
how
that
works.
Going
forward,
so
I
think
Thomas
Davies
of
Cisco
was
was
conducting
some
experiments
that
modified
how
this
adaptation
worked,
which
gave
some
some
coding
gains.
So
that
was
encouraging
next
slide
and
basically
we're
we're
planning
to
go
from
here
arm.
So
right
now
the
PDQ
integration
into
a
v1
was
just
done,
for
optimizing
for
PSN
are
with
flat
quantization.
K
So
we
had
no
activity
masking
and
nothing
else,
and
that's
just
to
make
sure
that
you
know
we
were
sure
that
that
the
basic
integration
was
working
correctly.
You
know
walk
before
you
can
run
so.
Obviously
the
next
step
is
to
start.
Turning
on
some
of
these
perceptual
tools
arm
we've
also
been
been
working
on
further
tuning
for
visual
quality
on
inside
dolla
and
I.
K
Think
we
were
seeing
seeing
something
on
the
order
of
two
to
three
percent
improvements
on
on
visual
metrics
in
dolla,
but
that
work
has
not
actually
landed
yet
and
at
when
it
does
landon
dollar,
then
we'll
port
it
over
at
AV
one
arm.
K
So
now
that
we
have
basic
pvq
into
a
v1,
we
can
start
porting
over
chroma
from
luma
and
also
plan
to
pour
it
over
dollars.
Rate
control,
I
just
say
that
the
things
that
we
already
have
ported
over
to
a
v1.
You
know
some
of
this
is
still
pretty
preliminary.
So
there's
a
bunch
of
work
to
do
to
improve
the
integration
with
the
rest
of
the
codec
and
I.
Think
that's
it.
I
Stat
line
is
calling
from
Cisco
you
mentioning
crow.
A
chroma
from
luma
I
tried
to
do
something
similar
using
the
Thor
Thor
tool
to
get
that
over
in
81.
But
I
gave
up
on
that
because
you
have
can
have
different
prediction
modes
for
chroma
in
luma
and
chroma.
Is
that
a
problem
for
the
chroma
from
luma
in
Palo
arm?
I
K
I
think
yes
and
no
arm
I,
think
it's
okay
to
have
different
prediction
modes
for
luma
and
chroma,
depending
on
on
how
you
want
to
go
about
integrating
it.
So
we're
actually
considering
a
number
of
different
options.
One
is
to
just
add
CFL
as
an
extra
prediction
mode
on
44
chroma,
so
we
just
be
explicitly
coded
as
one
more
mode
in
the
list
of
modes.
If
I
remember
correctly,
the
stuff
you
were
doing
with
or
tried
to
figure
this
out
automatically
without
signal
yeah.
K
We
get
to
problem
right,
so
so
yeah
one
solution
is
you
signaling?
The
other
thing
we
were
considering
is
is
is
just
removing
all
the
other
modes
and
only
using
CFL
at
least
44,
inter
frames
and
and
that
worked
reasonably
well
in
dalla,
in
the
sense
that
that
arm
cfl
using
CFO
for
everything
works
slightly
worse
than
actually
trying
to
use
real
intro.
K
You
have
explicitly
coded
integer
prediction
modes,
but
then
we
didn't
have
to
pay
the
cost
for
signaling
what
the
prediction
mode
was
so
overall
came
out
about,
even
but
because
we
didn't
have
to
do
on
a
mode
search.
It
was
much
faster,
so
we're
gonna
try
repeating
that
set
of
experiments
in
a
v1
and
see
which
way
things
come
out.
O
O
So
for
recap,
dispute
is
actually
a
perceptual
vector
quantization,
which
is
already
probe
proposed
for
net
pc
and
also
it
is
only
used
for
dollar
codec
and
we
wanted
to
see
how
it
is
doing
outside
dolla.
So
this
is
basically
gain
shaped
coding
of
the
transcription.
That's
like
the
opposite
and
I
would
say
the
most
distinguishing
idea
of
this
pubic
reach.
The
way
is
referencing
referencing
the
predictor.
So
this
is
also
a
big
difference
from
the
p
BQ
in
op.
O
A
Good
question,
and
just
to
clarify
so
part
of
motivation,
for
this
was
other
worlds
beyond
just
compression
quality
right.
You
were
trying
to
be
some
of
the
other
objectives
in
our
charter.
What
the
royalty-free
part.
A
O
O
There's
another
slide
that
some
diagram,
which
shows
what
is
the
actually
difference
in
architecture.
But
basically,
if
you
want
to
use
this
p
BQ,
you
have
to
apply
transform
to
the
predictor
cell,
because
the
pittock
is
actually
referencing.
The
predictor
in
transform
domain
and
also
the
original
signal
need
be
represented
in
transform
domain
so
different
from
traditional
video
codec,
where
the
transform
is
applied
to
reg
the
signal
with
PDQ.
The
transform
is
applied
to
original
signal.
O
Also,
as
Tim
mentioned,
the
activity
masking
automatic
activist
activity
masking,
which
is
actually
very
nice
Mary
the
PDQ,
which
is
not
enabled
yet
so
the
whole.
The
ldo
decision
optimizing
the
college's
solely
based
on
psu
now
next
slide.
So
this
is
diagram
for
traditional
architecture,
focusing
on
transform
and
quantization.
So,
as
you
see,
the
residue
signal
is
coming
from
the
subtraction,
so
difference
between
implant,
predictor
and
the
transform
is
exactly
applied
to
Reggie
signal
and
then
they're
quantized.
O
Symbols
actually
going
through
coefficient
coder
and
there's
a
bitstream
generally
next.
Next
slide.
Please,
however,
in,
however,
with
p
BQ
applied
in
a
b1,
the
difference
is
that
you
have
at
your
additional
transform
up
there,
which
is
applied
to
predictor
p.
So
we
have
two
signals
from
two
of
transformation:
p
of
x
and
t
FP,
there's
a
lot
out
there
and
then
the
pv
q
quantizer
need
to
input.
One
is
transformed
input.
Another
one
is
transformed
predictor,
so
also
with
p
BQ.
It
is
not
just
about
quantization,
but
it's
generated
coach.
O
The
symbols
are
completely
different
from
the
traditional
coder,
so
its
coefficient
coder
is
also
very
much
different
from
traditional
coders
and
then
the
inverse
transform
is
actually
applied
to
this
d.
Quantized
TRX
next
slide.
Please,
and
we
have
some
research
about
coding,
change
according
game
and
basically
there's
no
need
for
money.
So
I
can
say
that
I
I'm
just
happy
with
this.
I
know
I
mean
surprising
changes
here
so
at
least
for
optimized
with
pierson-el,
we
can
actually
directly
replace
the
existing
quantizer
with
pv
q.
O
O
Intensive
one,
that's
actually
for
high
latency
encoding
next
slide,
please
back
to
speed.
So
the
reason
why
there's
a
too
much
slow
die
down
is
because
p
decreased
self
is
actually
searching
a
lot
so
compared
to
existing
scalar
quantization,
which
has
over
when
complexity,
the
pdq
is
basically
doing
n
square.
O
So
also
we
have
only
used
PDQ
in
dollar
before,
but
dallas
I'll
do
search.
Space
is
much
much
smaller
than
that
of
81.
So
here's
one
example:
when
we
encode
of
just
one
frame
first
frame
of
the
grandmarc
qcif
in
inter
frame
mode,
the
a
b1
is
calling
hundreds
of
times
more
holes
to
the
quantizer,
so
the
region
is
that
dolla
does
not
have
interrupted
prediction
more
like
there
are
10
prediction
mode
in
a
v1
or
so
alien
has
different
sizes.
O
Transform
and
types
are
different
transport
types
or
furthermore,
the
81
allows
the
price
firm
size
can
be
smaller
than
put
a
prediction
size.
The
partition
size,
so
virtually
the
Avion
is,
can
be
say,
thousand
more
calls
to
the
contactors
compared
to
dollar
next
slide.
Please-
and
this
is
actual
counting
how
many
times
pantalla
yours
are
called.
So
again.
This
is
based
on
first
friend
on
intra
mode
and
these
the
first
column,
speed
rebel
is
actually
the
speed,
a
cpu
use
option
for
alien
codec,
so
five
weeks
fastest.
O
O
O
One
thing,
probably
you
your
question
is
from
speed
level
for
23
there's
a
big
increase
of
the
number
of
cold
the
region
is
that
it
starts
to
allow
the
click.
The
transform
size
can
be
smaller
than
prediction
size.
So
that's
the
reason
why
there's
a
big
increase
and
then
for
a
beyond
codec
the
skill
level
32,
basically
the
scene
for
intra.
So
it's
not
the
erica.
The
question.
A
A
M
O
O
I
rhythm,
yes,
we
believe
that's
possible
engineering
and
we
want
that
and
you
can
you're
welcome
to
contribute
that
part.
So
actually
that's
what
about
to
do
list
so,
instead
of
calling
the
transform
quantization
for
every
decision
pass
up
the
dis
audio
huge
if
we
have
some
nice
aldi
Modell
that
will
Cibola
the
time
a
lot.
K
O
Right
next
one
please.
So
there
are
some
interesting
issues
which
is
arising
during
this
intervention
work.
Actually,
this
experiment.
One
thing
is
that
I'm
not
sure
you
have
chance
to
see
Peter
key
code.
They
actually
full
of
audio
in
search
stage.
So
at
least
not
just
choose
one
code
point
or
vertex
in
a
hyper
hyper
stare
hypersphere
surface
of
the
hydrosphere,
but
it
has
to
actually
choose
best
quantization
point
in
latest
version
sense,
and
then
this
somehow
affected
I
mean
breaking
the
balance
between
luma
and
chroma
quality.
O
So
we
want
to
actually
compare
the
quality
with
a
b-1.
Maybe
this
is
not
really
worse
spending
time,
but
we
have
spent
the
ultimate
spend
several
weeks
to
resolve
issues
issues
so
probably
later.
If
people
is
really
adopted,
then
this
can
be
it's
impossible
issue.
Another
one
is
a
be
one:
is
using
hybrid
transform,
so
it's
not
just
DCT
and
ECT,
but
it
it
can
use
a
DST
so
which
is
a
synchronous
or
a
symmetric,
discrete
sine
transform.
M
O
N
A
F
C
Thank
you
very
much,
thank
you
so
that
that
takes
us
to
the
end
of
our
planned
agenda.
Presuming
no
one
has
gone
any
additional
items.
They
want
to
discuss
you're
going
to
be
have
the
rest
the
afternoon
off.
So
thank
you
very
much
for
showing
up.
Please
make
certain
if
you
didn't
put
your
name
on
the
blue
sheets
to
go
ahead
and
come
up
here
and
do
that
otherwise
have
a
good
evening.