►
From YouTube: IETF-CELLAR-20230228-2000
Description
CELLAR meeting session at IETF
2023/02/28 2000
https://datatracker.ietf.org/meeting//proceedings/
B
A
B
A
B
A
A
A
A
A
B
A
A
A
B
B
B
A
B
B
I
think
the
only
thing
that
changed-
and
it
was
the
thing
that
needed
to
change
the
most
in
our
list
of
documents-
was
matroska,
went
from
I,
think
dash,
10
or
11
to-15,
and
that
draft
is
now
in
last
ietf
last
call
and
just
doing
the
Milestone
review
thing.
So
the
next
thing
that
happens
for
that
is
the
internet.
B
B
B
C
I
didn't
have
the
time
to
read
yet,
but
if
it's
okay
I
can
just
use
that
because
basically,
the
issue
is
that
the
text
that
we
currently
have
in
the
document
is
incorrect.
It
says
it's
using
a
type
of
encoding,
just
like
evml,
when
in
fact,
I
run
the
code
that
we
had
for
20
years
and
it's
definitely
not
the
same
results.
C
D
C
Yes,
because
it's
completely
my
trust,
guessing
that's
really
just
for
lacing,
and
if
you
look
at
the
like
the
code,
I've
run
all
the
values.
Some
are
coded
on
Two
by
Two
Bits,
when
the
actual
ebml
signed
value
would
be
on
one
bit.
So
there's
a
lot
of
waste
there
I,
don't
remember
how
it
ended
up
like
that,
because
if
we
would
just
use
the
ebml
signed
values,
we
had
something
efficient,
but
it's
not
the
case.
C
E
D
E
F
D
C
We
do
have
signed
values
that
if
you
look
at
the
code,
I've
run
I've
run
the
code
with
the
assigned
values
of
ebml
and
the
code
with
the
Metro
scale
list
size
encoding,
and
that's
why
you
have
for
each
value.
You
have
two
and
two
types
of
encoding:
the
one
from
ebml
the
sign
official
ebml
sign
code,
which
is
actually
efficient
and
correct,
and
the
one
from
matrosca,
which
is
a
completely
evil.
Guess
it
works.
But
it's
not
very
nice.
Well.
E
B
E
I
think
the
thing
is
that
the
this
signed
in
that
you
say
is
efficient
is
not.
It
does
not
describe
its
own
length,
but
the
sign
the
the
code
that
we,
what
the
what
is
implemented
for
laces,
does
describe
its
own
link,
so
I'm
I'm
I
do
not
agree
that
it
that
what
we
see
is
inefficient.
It's
no
there's
no
other
way
to
do
that.
C
C
C
C
But
the
encoding
efficiency
is
not
very
good,
at
least
for
positive
values,
but
for
negatives
it
seems
better.
So
all
in
all
because
you've
been
releasing.
Usually
you
have
actually
small
values
like
between
minus
20
and
plus
20.
So
you
don't
in
for
use
cases.
It's
just
fine
for
weird
the
sizes
of
audio
frames.
You
must
have
some
any
efficiency.
C
We
already
have
signed
integer,
so
I
don't
see
the
point
of
having
a
different
way
of
doing
it,
especially
since
one
hour
we
don't
have
to
I
mean
I,
don't
know,
but
I
don't
think
it's
worth
the
effort
might
I
mean
use.
Adding
rational
values
would
be
more
useful
than
in
your
second
type
of
sign,
integer
eating.
So.
C
B
B
E
Well
well,
I
wanted
to
thank
you
for
the
review
a
lot
of
things
I,
especially
liked
the
bird's
eye
overview,
because
we
have
done
a
lot
of
small
changes
in
the
last
few
months
and
maybe
lost
the
well
the
bird's
eye
perspective.
I,
guess
so,
especially
the
the
reasoning
that
we
shouldn't
use:
BCP,
14
I'm,
not
saying
that
correctly
terminology.
F
E
The
non-normative
parts
of
the
specification-
that
is
something
that
we
missed,
so
that
should
probably
indeed
be
removed
from
the
appendices
or
rewarded
and
perhaps
also
from
the
first
few
sections
because
they're
they
have
titles
like
yeah,
well,
they're
more
of
overview.
The
first
few
sections
are
more
of
an
overview
and
later
yeah.
B
E
Specification
started,
I,
think
section,
seven
or
eight
or
something
yeah.
So
the
question
I
had
with
the
review
is
I
think
most
points.
I
will
just
use
and
and
change
and
put
in
some
PR
on
GitHub,
and
there
are
a
few
things.
I
would
like
to
discuss
a
few
comments
which
I
think
I
can
clarify,
but
what?
What
is
the
best
way
to
communicate
that
should
I
put
it
in
a
mailing
list
or
what.
B
E
E
B
B
B
E
Said
but
this
provides
a
nice
what's
the
proper
name,
it's
the
sounding
board.
You
know
it's
always
nice
to
have
a
fresh
view,
because
when
we
did
the
working
group
last
call
I
I
send
a
notification
of
the
word
working
group
last
call
to
quite
a
few
people
who
used
the
flag
document
and
enthusiasts
and
stuff
and
I
got
a
lot
of
comments.
E
B
And
I
I
have
to
say:
I
was
really
pleased
in
how
how
well
written
the
document
was
so
and
the
append
the
appendices,
especially
because
I
think
that's
I,
think
those
are
things.
That's
easy
to.
You
know
just
kind
of
not
spend
very
much
time
on,
but
they
were
like
I
say
the
the
whole
thing
was
well
written,
but
you
know
it
was
just
good.
Thank
you.
E
B
B
B
So
we
were
going
to
talk
about
and
do
we
have
time
yeah
or
to
load?
We've
got
plenty
of
time.
You
talk
about
ffv1
and
V4
stuff
I
did
want
to
ask-
and
we
could
talk
about
this
now
or
later,
but
we
did
have
the
fostem
ffe1
presentation
that
was
scheduled
for
earlier
this
month
and
I
wondered
if
there
was
any
feedback
from
there.
G
G
G
But
yeah
there
was,
there
was
a
couple
of
questions
about
the
performance
and
the
comparison
between
JPEG,
Excel
and
ffv1,
and
we
need
also
to
to
demonstrate
with
a
couple
of
files,
what
is
the
performance
of
jpeg,
Excel
and
fav1,
and
also
everyone
lossless
version
so
yeah.
The
biggest
questions
were
about
comparison
with
other
patentless
or
supposedly
patentless
formats.
G
No,
it
was
mainly
about
I
presented
mainly
about
how
we
work
also,
but
we
try
to
to
create
an
ecosystem,
so
not
only
the
format
but
also
the
tools.
People
were
there
and
tested.
It
was
not
so
empty
because
of
our
presentation
got
whom
with
less
people.
So
people
were
curious
about
that
and
it
was
fine
but
nothing
specific
to
say
about
that.
So
we
never
know
what
is
the
outcome
of
presentations.
G
B
F
B
Okay
and
and
like
I,
say
I
I
I'm
getting
more
excited
about
using
using
labels
in
GitHub,
but
I'm,
not
sure
I'm
good
at
it.
Yet
so
you,
you
guys,
have
been
doing
this
little.
You
guys
have
been
doing
GitHub
a
lot
longer
than
I
have
so
are
there
particular
items
on
the
list
that
people
want
to
start
with.