►
From YouTube: IETF99-CELLAR-20170721-0930
Description
CELLAR meeting session at IETF99
2017/07/21 0930
https://datatracker.ietf.org/meeting/99/proceedings/
C
B
B
J
I
H
D
K
L
C
A
M
G
N
A
F
A
D
I
All
right,
can
everyone
hear
me:
is
this
a
reasonable
volume?
Okay,
great!
So
thank
you
everybody
for
coming.
This
is
the
second
in-person
meeting
of
codec
encoding
for
lossless
archiving
and
real-time
transmission,
aka
seller
mm.
Before
we
get
started,
does
anybody
need
to
need
us
to
read
the
note
well
or
to
go
over
the
note?
Well.
I
I
Substation
statements
include
oral
statements
in
IDs
essence,
as
well
as
written
and
electronic
communications
made
at
any
time
or
place
which
are
addressed
to,
and
then
you
have
the
the
list
of
those
places
to
which
communications
can
be
addressed.
So
if
there
aren't
any
further
questions
about
the
note
well,
we
can
go
on
to
a
brief
introduction.
I
suppose
I
should
introduce
myself
I'm,
Tessa,
Fallon
and
co-chair
of
seller
and.
I
I
So
if
you
do
have
a
question
or
a
comment
and
you're
in
the
room,
please
remember
to
use
the
microphones
that
are
placed
in
the
center
of
the
aisle
and
to
clearly
articulate
your
question
as
well
as
your
name.
That
will
help
people
who
are
attending
remotely
and
as
well
as
our
note
takers
and
the
recording.
I
I
Okay,
so
the
agenda
has
not
changed
from
when
we
first
made
it
available
online.
So
you
can
go
past
that
gone
to
the
milestones.
We
have
a
number
of
milestones
that
were
planned
for
2017,
so
I
think
after
we
get
an
update
on
the
status
of
each
of
the
proposed
standards,
we
can
go
into
more
of
a
discussion
about
those
and
about
which
milestones,
we've
sort
of
we've.
I.
Guess
you
can't
really
sort
of
meet
a
milestone.
I
You
either
you
either
do
or
you
don't
right,
mm-hmm
but
I
know
we're
on
track
for
several
of
them,
and
so
I
just
want
to
make
sure
that
everybody
is
on
the
same
page,
and
we
know
what
the
next
sar
in
terms
of
getting
the
documents
to
their
to
their
appropriate
tracks.
I
think
in
terms
of
the
FFP
one
video
codec
versions:
zero
to
three.
We
have.
O
M
H
M
G
M
I
D
K
So
we
put
documentation
of
the
exception
in
the
specification
instead
of
changing
the
reference,
encoder
and
decoder.
So
now
the
specification
contains
the
expected
format,
plus
some
exceptions
for
the
documentation
of
the
bags
in
the
reference
encoder
and
decoder,
so
the
spec,
an
encoded
in
sync.
This.
M
M
K
M
K
No,
no,
the
next
session
of
the
format
we
will
change,
we
fix
the
bugs
in
encoder
and
decoder.
Maybe
I
will
decide,
it
will
be
a
discussion
in
the
mailing
list.
We
can
keep
them
as
Aziz
or
we
can
fix
fix
that
in
the
next
version
in
order
to
have
something
more
acquaint
in
the
environment,
but
for
the
moment
of
version
zero,
one
and
three
FISA
are
in
the
wild.
We
don't
want
them.
We
only
document.
K
And
generally,
we
met
our
view
of
a
specification
with
some
cleanup.
Sometimes
we
are
not
using
the
exact
same
wording
for
the
same
thing,
so
we
reuse
now
everywhere
the
same
name
for
the
same
thing
and
we
change
some
formatting
about
formulas
in
order
to
be
more
compatible
compatible
with
NFC
output,
and
we
also
doing
the
reviews.
So,
but
there
is
some
issues
the
specification
was
not
exactly
was
in
variations
encoder/decoder,
but
in
that
case
we
can
fix
the
specification.
For
example,
there
was
an
unsigned
in
the
the
decoder
and
respect
was
saying
signed.
K
K
We
added
a
mapping
for
matroska
of
history,
historical
part.
If
everyone
in
Matroska
was
using
the
API
a
compatibility
layer
of
Matroska
and
we
don't
want
to
use
a
compatibility
layer
from
Microsoft,
for
example-
and
we
we
want
to
have
a
direct
mapping
between
everyone
and
Matroska
without
using
any
compatibility
layer.
K
A
K
K
This
is
to
be
decided.
Parliament.
The
three
map-
none
mapping,
a
movie,
avi
and
Moscow-
are
in
F
every
one
document.
It
could
be
decided
to
extract
that
it
is
only
a
paragraph
so
to
be
decided
for
the
moment
it
is
inside.
If
every
one
document
is
it
something
we
should
remove
and
put
somewhere
else.
A
N
M
P
P
P
We
just
need
to
make
sure
it
doesn't
collide
and
have
issues
in
compatibilities
with
them.
Maybe
you
wonder
if
everyone
is
done,
if
it's
done
before
the
metrascan
one,
it
can
be
merged
into
the
Matroska
one
or
if
we
know
already,
there's
going
to
be
one
well
defined
for
everyone
I
just
put
in
the
nitrous
car
documentation
for
F.
Everyone
refer
to
that
document.
O
P
In
my
opinion,
it's
better
that
codex
do
their
own
mapping
because
they
know
better
the
codec
and
people
using
that
codec
will
actually
want
to
know
the
mapping
when
they
use
it
so
and
plus
we're
not
going
to
update
or
make
yeah
make
your
obsolete
might
risk
a
document
just
for
adding
one
codec,
because
there
are
so
many
so
in
my
opinion,
is
better
to
have
codex
do
their
own.
We're
going
to
have
one
for
well-known
codex.
P
There
are
actually
in
the
world
and
need
to
have
known
mapping
documented
and
will
unlikely
have
a
document
from
official
other
standard
bodies.
So
that's
why
we
need
that
document.
Otherwise
much
were
scared.
It's
not
very
usable
but
I.
Think
for
the
case
of
M
F.
Everyone
where
Matroska
will
be
documenting
is
better
to
have
it
in
that
document.
K
L
K
So
about
a
verse
specification
of
FF
v1,
we
describes
of
a
complete
bit
stream
up
to
the
pixel
and
the
four
unique
pixel
decoding
per
pixel
and
about
the
decoding
of
the
pixel.
We
have
already
will
not
described
in
plain
English
and
we
have
the
algorithm.
It
is
quite.
We
have
how
it
is
built,
how
the
encoding
was
built,
but
we
don't
have
it
yet
in
select
description.
O
K
K
The
current
implementation
of
fev1,
our
ffmpeg
there
is,
which
is
the
currently
where
I
found
encoder
decoder,
Lib
AV
as
it's
it's
an
odd
coder
and
decoder,
but
be
careful.
It
is
a
fork
as
it
is
a
photo
of
ffmpeg.
It
contains
the
same
pegs
as
ffmpeg,
and
we
have
another
decoder
in
median
fool
based
on
the
specification,
and
it
is
a
completely
different
implementation.
K
K
We
need
to
currently
we
rely
on
that
container,
for
example
Matroska,
but
it
will
be
good
that
if
everyone
can
transport
its
own
metadata-
and
we
may
add
some
optimization
of
the
AL
going
algorithm
for
F
everyone
before
and
all
of
this
need
to
be
discussed
on
the
millions
permanent.
We
standardize
FF
v,
1,
0,
1
and
3
files
on
the
world.
And
after
that
we
are
in
parallel.
We
need
to
define,
before
with
missing,
compare
pixel
formats.
O
K
K
J
I
I
I
Think
looking
at
looking
at
these
because
I
know
there
are
discussions,
thread
discussion,
threads
that
have
kind
of
come
to
a
standstill
where
you
know
it's,
it's
a
worthwhile
and
interesting
discussion,
but
my
consensus
isn't
reached
on
the
mailing
list
and
you
know
I
think
you
know
in
Cades
it's
you
know
one
possibly
a
matter
of
people
having
tons
of
work
to
do
and
being
overwhelmed,
and
you
know
and
everything
like
that.
But
you
know
I,
don't
know
what
the
answer
to
that,
but.
M
M
I
I
P
It
starting
to
date
is
wrong.
It's
not
2012,
but
2002,
so
about
15
years
are
good
to
do
or
my
goal
was
to
do
live
TV
capture
with
the
hardware
that
was
available
at
this
time.
So
was
not
very
good
with
the
existing
containers
when
you
have
lost
frames
and
stuff
like
that,
so
I
worked
on
a
project
that
already
existed
to
to
do
that
which
was
call
mcf
and
it
was
formed
because
we
had
differences
on
how
to
do
things,
especially
about
eb
ml.
P
So
the
idea
was
to
have
something
what
the
technology
is
borrowed
from
still
the
existing
avi,
the
EBI
marriage
inspired
from
XML
and
all
the
idea
that
the
semantics
can
do
a
lot
for
you
compared
to
storing
everything
in
the
file,
so
them
from
the
Semantic
Web
that
was
emerging
at
the
time.
So
now
the
major
use
of
Matroska
is
with
h.264
and
h.265.
P
You
can
find
that
basically
any
player
now
any
TV,
that's
out
that's
a
smart
TV
can
play
Matroska
with
these
codecs
Windows
10
has
built-in
support.
Now
the
right
players
I've
had
that
for
many
years
as
well.
All
the
offense
was
players
can
play
that
class,
vp8
vp9,
that's
mostly
from
Google
and
YouTube,
but
it's
also
use
I
think
by
Netflix,
it's
used
by
Nintendo,
I
think
as
well
all
in
much
work
as
well
for
audio.
P
A
Q
Q
P
So
WebM
is
basically,
if
you
look
at
their
web.
M
specifications
on
the
WebM
website
is
basically
the
metrascan
specification
on
our
website,
but
with
elements
removed,
it
uses
the
same
formatting.
Most
of
the
text
is
the
same.
It's
really
the
same.
Specifications
and
WebM
doesn't
have
anything,
that's
not
in
Matroska
and
everything.
That's
defining
Matroska
applies
to
weapon.
P
Q
P
Google
will
help
us
work
on
this
specification
as
well.
Some
of
Google
people
and
Mozilla
as
well
are
in
the
mailing
list
and
helping
a
little
but
not
really
working
on
the
determine
documentation,
but
that's
also
because
what
I
mean
is
just
a
subset
of
matroska.
So
there's
really
no
difference
finished.
P
That's
not
relevant
to
web
usage,
or
at
least
they
think
I've
always
thought
that,
but
almost
anything
that's
in
much
worse.
Cache
will
be
loaded
and
little
by
little.
Actually,
when
web
and
starting
they
only
had
a
very
small
subset
of
what's
in
matroska
and
little
by
little
little,
they
added
stuff,
they
already
that
always
already
in
Matroska,
because
they
realized
they
actually
need
it.
So
maybe,
as
time
goes
by,
they
will
add
more
and
more
stuff
in
where
then
that's
already
metrascan
yeah.
Q
P
Actually,
we
could
see
if
we
can
make
a
separate
documentation
for
WebM.
That
says,
but
basically
that's
already
in
the
web
and
web
site.
They
tell
you
we
use
this
and
that
element
from
metros
camera
plus
this
ones,
for
example,
encryption
to
have
better
specifications
for
encryption
that
we
might
take
from
there
but
yeah.
Basically,
that's
how
WebM
worked
so
far
without
I
think
for
them.
Their
website
is
the
official
specification
and
is
based
on
the
Matroska
specification.
K
Webinar
madness
in
this
working
group
we
are
mostly
working
on
Matroska,
because
we
we
have
no
power
on
WebM,
and
in
that
case
we
can
only
do
something
informative
in
the
specification
about
when
them
saying
which
item
from
matroska
is
used
in
weapon.
If
we
can,
the
contact
we
have
with
Google
is
not
very
often,
and
they
can
decide
in
military
to
add
some
item.
We
we
try
to
follow
WebM
and
not
to
be
incompatible
with
WebM,
but
we
cannot
say
it
will
be
compatible
forever
because
we
have
no
power
on
that.
A
Now
it
sounds
like
maybe
it's
worthwhile
at
least
talking
them
to
see
what
what
their
opinion
is.
They
might
be
interested
in
having
a
more
formal
venue
to
standardize
their
their
subset
of
Matroska
anyway.
So
I
don't
know
if
that's
appropriate
for
this
working
group
or
not,
but
it
seems
harmless
at
least
get
their
opinion.
P
So
on
this
next
slide,
it's
mostly
about
where
you
can
find
what's
being
done
right
now,
so
the
mailing
list
then
best
to
github
repositories,
one
for
eb
ml,
which
is
the
underlying
binary
format
for
matroska,
which
can
be
used
for
other
things
than
metrascan,
and
the
specification
is
done
that
way.
It's
not
tied
to
my
tour
schedule
and
one
is
more
for
Matroska
stuff.
P
P
Anyone
can
do
that
on
the
computer
and
there's
also
in
the
microscale
repositories
the
websites
like
a
shadow
version
of
the
website.
That's
the
official
specification
for
now
is
also
generating,
but
we
might
remove
that
because,
like
right
now,
the
ITF
documents
will
take
too
much
from
the
website
and
inform
our
way,
and
we
want
to
clean
that
up.
So
we're
probably
going
to
drop
that
and
there's
also
an
XML
file,
that's
defined
in
the
Metro
scale,
documentation
that
defines
all
the
elements
PML
elements.
P
Finally,
the
format
with
the
documentation
and
that
file
is
actually
news
to
generate
a
big
part
of
the
documentation
from
Matroska.
That's
also
used
to
generate
code,
at
least
two
libraries,
maybe
more.
We
try
to
encourage
people,
because
that
will
be
probably
the
formative
document
for
how
you
interpret
natural
scan.
P
This
way,
we
don't
have.
Even
the
text
in
the
documentation
has
to
match
that
document
and,
like
I
said
it.
Oh
there's
also
a
field
for
a
chairman
that
tells
is
it
in
webbing
or
is
it
not
even
that's,
as
the
current
web
and
specifications
are
because,
like
we
said
they
can
add
elements
at
any
time
when
they
add
new
things,
I
think
they
did
it
in
the
past
whatever.
So
we
added
that
you
might
want
to
add
it
to
the
microscopes
and
we
do
it.
P
We
wish
it
would
be
more
open
because
sometimes
the
different
things
their
own
way,
and
when
we
look
at
it
we
would
have
done
it
a
bit
different,
but
that's
too
late
because
it's
owned
by
them,
but,
like
we
said
we
don't
have
any
control
of
that.
Even
though
we
work
together,
it's
usually
in
one
way.
A
I
have
a
question
so
if,
if
the
set
of
elements
that
are
included
in
WebM
is
expected
to
change
more
frequently
than
the
Matroska
specification
itself,
perhaps
that's
something
that
shouldn't
be
in
the
RFC.
But
it
could
be
maybe
added
in
an
Diana
register
here
or
something
like
that
that
we
could
update
more
easily.
P
Yeah
I
guess
we
can
do
that
for
now.
It
was
also
done
that
way
because
it
was
used
to
generate
the
website
in
metros,
Karen,
dot,
born
that
has
a
table
with
all
the
elements
and
if
it's
supporting
the
Russian
one,
two
three
and
D
Beck's
vertically,
like
so
so
as
extensions
too
much.
What
are
they
up
there
on
that?
P
D
P
So
the
milestones
we
already
discussed
that
there's
the
current
one
in
April
and
July
San
April,
we
publish
the
document
for
ibn
el.
This
document
is
actually
quite
good.
It's
in
good
shape
it's
understandable
and
covers
most
of
the
stuff
we
want.
Then
in
July
we
publish
mattress
v3
specification.
Other
documents
probably
still
need
a
bit
of
work.
Like
I
said
it
was
boring
too
much
from
an
informal
website,
and
we
want
to
clean
that
up
and
the
plan
is
to
have
in
September.
P
P
P
So
the
document
for
IBM
L
is
close
to
final.
In
my
opinion,
you
have
the
same
question
as
usual.
I
have
no
idea
how
many
people
read
it
probably
the
same
as
four,
if
everyone
at
least
some
people
from
Google
and
Mozilla
as
well,
I
know
that
I
don't
know
how
many
people,
the
so
in
the
github
repositories,
which
we
try
to
also
match
with
whatever
is
discussed
on
the
cellular
mailing
list,
there's
currently
zero
to
flow
request.
Everything
that's
been
proposed
and
to
be
merged.
P
That's
currently
for
issues
or
to
text
clarifications
on
how
and
what
you
do
with
the
jam
data
or
invalid
data.
How
it's
supposed
to
be
interpreting.
We
have
to
clarify
that
there's
also
a
proposal
to
have
version
zero
for
a
document,
maybe
a
document.
That
means
it's
not
in
usable
state.
If
it's
Russian
zero,
you
cannot
expect
the
semantics
to
be
stable.
P
So
that's
something
we
probably
want
to
add
a
BB
ml
definition
and
one
is
to
add,
maybe
in
that
document,
maybe
in
an
extra
document
how
to
define
an
EB
ml
like
IBM
L
data
but
in
the
readable
form,
so
probably
something
that
resembles
ml.
So
I
don't
know
if
it
could
be
that
document
or
another,
and
the
other
thing
I
would
like
to
do
before.
M
The
other
comment
I
had
actually
is
I've
actually
scanned.
This
one
and
now
I
see
scan
is,
like
you
know,
scan
of
the
operative
word
and
I.
Think
one
thing
that
probably
should
be
clarified
in
it
probably
in
the
abstract
introduction,
is
why
we're
doing
this,
because
when
we
take
a
yet
another
file,
format,
document
data
format,
document
to
the
IETF
last
call
and
the
iesg
that's
going
to
be
a
lot
of.
Why
and
the
fact
there's
a
dependency
for
matroyshka
and
such
is
an
important
thing
to
make
sure
people
understand.
Okay,
so.
P
P
I
M
P
P
P
Where,
for
example,
Nintendo
is
because
the
they
actually
use
WebM,
so
they
actually
use
much
worse
castings
that
was
a
few
years
ago.
I
don't
know
if
they
switch
to
something
else
now,
but
at
the
time,
for
example,
anything
that
was
coming
from
YouTube
was
not
in
h.264,
but
only
in
a
weapon
on
Nintendo.
P
That's
it
on
defects,
it's
different
because,
but
that
was
like
we
had
10
years
ago.
I
think
they
decided
that
needed
their
own
file
format
and
they
went
with
Matroska
and
I
did
a
few
extensions
that
they
have
documented,
but
I
don't
even
know
if
the
week
still
exists
anymore
or
if
they
actually
do
maintained
and
format
of
their
switch
to
something
else.
A
Yeah,
so
to
go
back
to
the
the
eBay
ml
document,
are
there
any
people
who
are
willing
to
to
step
up
and
and
put
out
their
name
as
someone
who
will
review
this
document,
so
I'll
go
ahead
and
start
on,
but
I'm
I'm,
one
of
the
working
group
chairs,
so
I
probably
have
to
do
it.
But
I've
looked
at
this
once
before
and
had
a
bunch
of
comments
and
so
I'll
take
a
look
at
it
again.
But
anyone
else
in
the
working
group,
all
right,
Jerome,
is
put
forth
his
name.
Q
I
Another
request,
investors-
well,
sorry,
so
I
think
I
think
we
should
also
send
out
a
request
on
the
mailing
list
as
well
to
get
people
to
depend
on
people
to
commit
to
reviewing
the
e
BM
BM
l
document,
so
in
case
anybody
who's
participating
remotely
needs
some
time
to
think
about
it.
Before
throwing
their
hat
in
the
ring
yeah,
we
can
do
that
as
well.
But
oh
okay,
that's.
P
This
is
one
more
slide:
I,
okay,
to
be
two
or
three,
which
is
the
where
we
get
with
metrascan.
So
as
a
five
video
multimedia
file
format,
it's
actually
huge
task
to
standardize
because
there's
currently
243
EB
ml
elements.
So
that's
you
know
xml.
That
would
be
a
tag
name,
so
there's
250
43
43
of
them
are
marked
as
deprecated,
but
we
still
need
documented
for
old
files.
A
lot
of
elements
depend
on
the
other,
at
least
their
parent,
also,
sometimes
their
interactions
between
parts
of
the
file.
P
So
that's
also
tricky
to
to
document.
You
cannot
just
define
that
element
means
that
sometimes
it
in
reference
to
something
else
so
I
in
terms
of
what's
currently
in
the
pipeline.
So
there's
seven
pending
requests
on
the
github
three
text,
classifications,
most
of
them
on
chapters
less
one
on
codec
mapping
in
one
on
font,
basically
be
more
precise.
P
How
to
use
these.
There
are
three
codec
definitions
which
are
currently
the
main
document,
so
every
codec
that
we
know
has
codec
mapping
with
the
name
how
to
interpret
the
data
in
the
codec,
private
and
the
blocks
and
there's
one
request
with
text
formatting
and
then
the
issues.
So
it's
moving
target
I
cleaned
a
lot
recently,
but
there
we
keep
adding
more.
So
as
last
night
testing,
this
22
issues,
so
eight
are
texts,
clarifications,
basically
the
format
if
text
me,
which
needs
to
be
improved
so
tells
on
which
part
and
why
format
additions.
P
It's
for
ideas
that
people
have
for
future
things
in
Matroska
compared
to
what
exists
now
seems
to,
and
so
that
will
be
something
like
v4
v5
version
of
matroska.
There
are
three
text
formatting
and
five
codec
definitions
which
needs
some
work,
that's
probably
more,
but
that's
because
that's
what
people
reviewed
the
documents
so
I
think
we
can
go
on
the
next
line,
because
it's
more
refinement
of
more
I
just
said.
A
P
P
P
Then
there's
the
this
proposal,
that's
been
discussed
on
the
Middle,
East
and
I
would
like
to
do
is
to
split
the
current
specification
in
three
documents:
one
with
the
matroska
elements,
like
the
core
specification
of
the
format
and
to
separates
one
for
the
Kodak
mapping
and
as
we
discussed
in
an
ideal
world,
there
will
be
a
document
for
each
codec
and
each
codec
workgroup
will
define
their
own.
My
opinion
Matroska,
but
it's
unlikely
to
happens.
P
So
we
need
to
do
that
work
at
least
four
major
codecs,
but
on
the
other
end
it's
a
moving
target
and
it's
also
a
lot
of
work.
I
would
prefer
that
such
separate
documents,
so
we
can
with
one,
is
not
blocking
the
other
and
it's
the
same
for
tags.
There's
a
lot
of
tags
that
you
can
have
custom
tiles
and
we
have
a
list
of
official
tags.
That's
better
for
people
to
use
so
tags
are
metadata.
P
P
Important
well,
it's
important,
but
like
different
issues.
There's
one
document
can
be
done,
while
the
other
speaking
of
being
worked
on
and
then
there's
to
work
on
the
wording
and
the
cleaning
and
the
specification
to
remove
all
the
Parden
that
come
from
the
website
that
was
informal
or
even
Dizon
shouldn't
be
at
all
in
the
specification.
O
Jonathan
likes
the
structure
you've
described
through
the
codec
registrations
feels
a
lot
like
the
way
we
do
RTP
payload
format,
switcher
that
the
IDF
is
pretty
comfortable
with
and
basically
what
our
TP
was
originally
written.
They
wrote
one
document
which
is
a
separate
document
published
simultaneously
with
the
payload
formats
for
a
bunch
of
the
existing
things
that
we're
using
and
then,
as
new
pillows,
have
been
defined
over
the
years.
I've
just
been
new
things
added
I
mean
the
one
question
I
will
have
is:
how
is
the
this
line
is?
O
P
P
And
then
for
new
formats,
like
if
everyone
and
in
the
future,
then
I
think
it's
better
yeah
if
it's
done
in
a
separate
document
and
probably
goes
Rihanna
other
process
to
define
it,
that's
also.
The
idea
of
Metro
Scott's,
completely
independent
from
what
you
store
inside
is
the
format
and
the
rest
of.
What's
in
the
codec
and
also
the
tags,
the
file
can
be
used
even
with.
If
you
know
absolutely
nothing
about
this.
So
that's.
A
Q
P
So
I
talked
earlier
about
things
that
might
go
might
be
added
to
metrascan
now
on
the
future.
So
that's
document
where
IT
talked
about
that
XML.
So
we
talk
about
that
anymore.
There's
a
different
kind
of
defining
colors
when
they
study
match
was
guy,
especially
for
raw
video.
So
it's
called
lute
blue
cap
table.
P
It
seems
to
be
something
that's
used
in
archiving
and
so
that's
a
way
of
defining
things
we
don't
have
in
Matroska,
so
we
probably
won't
you
have
it
then
there's
work
on
the
encryption
it's
used
in
WebM,
but
and
they
use
the
elements
that
were
defined
originally
for
that,
but
originally
it
was
defined
with
not
much
knowledge
on
in
knowledge
and
encryption.
There's
a
lot
of
stuff
that
can
probably
remove.
P
There's
one
task,
but
something
to
add
more
language
support,
there's
a
way
to
tell
this
audio
track
or
this
video
that
audio
or
subtitle
track
is
in
that
language.
But
the
way
it's
done
is
using
the
eyes
or
something
format
that
doesn't
cover
all
languages.
So
we
want
to
have
one
tag.
That's
also
cover
all
the
languages
defined
in
RFC
5646.
P
So
that's
another
thing:
we
need
to
add:
there's
the
new
codec
ID
prefix,
basically,
every
codec
right
now,
for
example,
and
hood
your
codecs
already
has
to
start
with
a
underscore.
We
do
the
underscore
subtitle
s
underscore.
We
need
to
add
more
for
the
track
types
that
exist
exist
in
Matroska.
That's
what
needs
to
be
done
and
type
timecode
track.
That's
also
something
important
for
archiving
in
people
they
use
the
tankards
from
various
sources
and
write
nets
not
handle
at
all
in
mattress
casts.
P
I
So
the
next
presentation
is
just
very
briefly
an
overview
of
the
work
that
was
done
on
flack
in
June
2017.
You
know.
In
June
of
this
year
a
number
of
people
had
been
working
on
getting
a
draft
of
the
flack
documentation
into
into
the
cellar
repository
earth
and
any
rate
so
andrew
is
going
to
just
briefly
tell
us
a
little
bit
more
about
that.
R
Cool
I'm,
sorry,
it
doesn't
seem
like
it's
a
transmitting
video
but
audios
working,
so
I'll
just
roll
with
that.
Yes,
as
that
rejection
said,
this
will
be
short
and
sweet
since
the
work
on
the
making
the
standardization
of
wack
the
free,
lossless
audio
codec
just
began
so
I
guess
we
can
go
to
the
next
slide.
R
So
the
process
started
in
May
of
2017,
and
most
of
the
work
was
done
then
in
June.
So
this
slide
pretty
much
summarizes
were
the
bulk
of
the
work
that
has
been
done
to
date
has
been
focused
and
a
majority
that
really
has
just
been
to
create
a
semantically
identical
translation
of
the
existing
specifications
that
are
on
the
website
right
now
and
to
translate
those
into
markdown.
The
reason
being
for
this
that
the
approach
is
being
taken
with
this.
R
That
is
similar
to
the
other
standardization
processes
that
were
just
discussed
where
the
markdown
is
then
used
to
generate
XML
and
the
HTML
text
documents
that
become
the
RFC.
So
that
is
a
kind
of
getting
that
translated
and
making
sure
that
it
is
semantically
identical
with
no
errors
in
the
translation
and
then
adapting
the
make
file
tool
to
generate
those
derivatives
is
where
most
work
has
been
done.
Then
some
work
has
been
done
to
correct
some
minor
errors
that
were
found
during
that
translation
process.
R
From
the
original
document
such
as
typos,
they
were
through
broken
links
or
links
that
were
pointing
towards
updated
sources
that
were
then
fixed
or
rerouted
to
a
archive
like
an
archived
copy
of
what
those
links
were
originally
linking
to,
and
yes,
this
is.
This
is
where
most
of
the
time
has
been
spent.
I
guess
we
can
move
to
the
next
slide,
and
then
this
is
once
that
process
of
translation
was
done
and
it
had
been
read
over
a
few
times
and
checked
for
any
errors
in
that
process.
R
R
Some
minor
changes
have
been
made
to
decrease
ambiguity
such
as
showing
calculations
where
the
sum
of
the
numbers
used
in
the
specification
come
from
that
are
absent
in
the
original
specification
and
then
rewording
to
make
it
more
conform
with
the
RFC
format
in
terms
of
wording
and
what
the
words
mean
with
the
specific
meanings.
There
have
been
some
changes
that
have
come
through
Lac,
dev,
deflective
lists
that
have
been
incorporated
as
well.
Those
also
kind
of
ate
all
more
into
the
category
of
decreasing
ambiguity.
R
So
some
of
the
some
of
the
discussions
that
have
been
on
fact
because
has
been
a
little
bit-
we've
been
keeping
so
far.
Black
dev
lists
kind
of
appraised
at
the
same
level
that
the
seller
list
is
and
there's
been,
some
response
there
and
some
of
those
have
spurred
some
things
that
some
of
the
collective
Oliver
people
who
have
used
it
and
thought
had.
Other
suggestions
for
improving
clarity
have
made
those
changes.
R
R
Currently,
it's
linked
out
to
the
Vorbis
comment,
specification
and
so
suggestions
and
issues
on
the
github
right
now
about
including
those
as
part
of
this
transportation
and
in
terms
of
work.
That's
been
done
so
far.
That
is
basically
it.
So
this
is
short
and
sweet.
I
think
if
we
go
to
the
next
slide
is
just
for
questions,
but
hopefully
this
is
a
good
chance
to
for
some
comments
or
talk
about
this.
R
I
mean
myself
personally,
who
I
have
I
liked
that
comment
earlier
about
being
an
academic,
not
a
coder
I'm,
a
librarian,
not
a
coder,
so
I've
been
involved
in
the
process
with
helping
kind
of
steward
the
documents.
I
know
that
there's
some
of
the
people
who
are
also
have
been
involved
in
the
process
are
participants
in
this
meeting
right
now.
R
So
I
don't
know
if
they'll
be
able
to
speak
to
that
I
think
that,
ultimately
there
it
would
be
good
if
there
was
more
more
communication
out
of
kind
of
a
you
know,
morphs
right
now,
there's
not
actually
a
person
kind
of
spearheading.
The
effort
and
they'll
probably
be
helpful
if
there
was
more
communication
with
the
lac
development
list
right
now,
the
work
that
is
being
done
does
exist
not
in
an
institutional
repository.
It
just
exists
in
a
repository.
R
I
Sorry,
this
is
one
of
the
last
milestones
for
the
working
group.
I
think
it's
December
of
2017,
so
this
is
really
just
to
give
just
to
give
everyone
in
the
room,
and
you
know
attending
remotely
an
idea
of
of
why
that
document
is
currently
you
know
in
their
inner
groups
website
and
what's
been
going
on
with
that,
I.
O
R
Far
the
work
that's
been
done
has
just
been
focused
on
that.
I
know
that
several
months
ago,
when
there
was
some
discussion
about
work
on
the
black
standardization
on
the
seller
list
serve
some
people
who
seem
to
have
been
had
a
significant
experience
with
using
black
did
seem
to
express
some
interest
in
working
on
the
kind
of
more
technical
end
of
that
I.
R
I
I
think
next
on
the
agenda,
they
just
kind
of
wanted
to
see
if
there
needed
to
be
any
discussion
about
what
the
next
steps
were
for
the
documents
that
are
in
the
pipeline
and
you're
coordinating
future
work.
It
seems
to
me
that
what
needs
to
be
done
for
most
of
the
documents
is
finding
more
viewers
trapped.
You
know
actively
seeking
out
specific
individuals
to
do
the
reviews
and,
in
addition
to
you,
know,
people
who
have
been
doing
the
work
already
in
the
in
the
working
group.
I
M
This
has
been
just
going
back
and
looking
at
milestones
and
up
from
them
and
I
want
to
recap,
my
understanding
I
gather
that
ffv
one
one,
two,
three,
the
information,
the
the
documented
current
stuff
and
the
EB
ml
are
both
pretty
close
to
ready
in
the
author's
opinions
did
I
understand.
That
correctly,
is
that
what
the
chairs
understand
yeah.
M
B
I
M
I'm
sorry,
that's
kind
of
closed
on
the
next
steps.
First
I
thought
you
had
more
to
say.
Maybe
so,
okay
next
steps
are,
if
I
understand
it
correctly,
we're
just
solicit
reviews
on
those
two
things
that
are
almost
done
and
assuming
nothing
blows
up
in
a
small
number
of
weeks
of
soliciting
reviews.
I'll
go
to
ask
oh.
M
M
I
I
A
M
D
R
D
L
My
view
here
so
I
can
see
the
slides.
You
can
still
hear
me
and
see
me,
okay,
great,
so,
first
off.
Thank
you
all
for
having
me
I'll
move
through
this
kind
of
briskly,
cuz
I,
don't
know
if
there's
any
more
business
that
you
all
have
to
do.
Thank
you
for
having
me
a
special
thank
you
to
Tessa
for
putting
me
on
the
agenda
and
for
answering
various
and
sundry
tech
issues.
So
thank
you
should
I
just
say
next
slide
when
it's
time
for
them
to
be
advanced,
okay,
yeah.
L
So
introduction
to
me.
I
know
some
of
you
a
little
bit
from
some
my
past
work.
I
am
a
doctoral
student
at
the
University
of
Illinois
in
urbana-champaign,
our
library,
Information
Sciences
Department,
and
the
United
States
I'm
working
on
my
doctoral
dissertation
and
I'm,
embarking
on
the
research
phase.
Finally
of
the
dissertation
work
and
one
of
the
things
that
I
want
to
do.
But
this
work
is:
do
qualitative
analyses
of
two
examples
of
standards,
development
and
their
implementation,
so
I'm
I'm,
currently
embarking
on
the
data
gathering.
L
That's
going
to
involve
interviews
with
at
least
some
of
you
I
hope
I'm
over
the
next
year.
Probably
the
earliest
that
would
start
will
be
in
September
and
then
I
plan
to
actually
write
the
dissertation
the
following
year
with
the
hope
that
it
will
be
deposited
in
two
years.
So
we
will
see
what
actually
plays
out,
but
that's
the
plan
next
slide.
Please.
L
So
I
worked
on
the
Library
of
Congress's
mxf
jpeg2000
standard
for
three
years
before
I
came
here
to
be
a
doctoral
student,
what
we
were
calling
ASO
seven
uses
mxf
and
jpeg2000,
and
it
was
and
is
being
developed
with
considerable
input
from
the
American
television
broadcast
community,
mostly
through
the
form
of
the
a
MWA,
the
advanced
media,
floo
association.
So
the
development
and
implementation
of
that
standard
is
one
of
the
two
standards
that
I
want
to
look
at
next
slide.
L
Please
and
then
your
standard,
the
one
that
we're
talking
about
tonight
that
you've
been
working
on
diligently
over
the
past
few
years,
the
seller
standard-
and
this
is
where,
where
you
come
in,
where
we
talk
about
the
Matroska
and
FFP
one
and
FLAC
work
next
slide.
Please
so
I've
two
research
questions
one
and
in
in
no
particular
order.
L
The
first
one
is
the
question
of
how
how
did
the
group's
the
the
seller
group
you
guys
and
the
fangy
group?
What
are
the
influence
and
kind
of
power
dynamics
between
the
people
in
the
groups?
As
you
all,
do
your
work
to
create
the
standards
and
how
you
are
negotiating
issues
of,
and
questions
of
what
quality
means
and
what
sustainability
means
in
the
moving
image
preservation
realm
next
slide.
L
So,
following
from
that,
some
kinds
of
concepts
that
I'll
be
exploring
in
the
interview
phase
is:
how
do
these
groups
have
the
members
within
the
group's
negotiate?
The
definitions
of
quality
are
the
different
ideas
of
quality
different
between
people
who
come
from
a
strict
kind
of
engineering
background
and
people
who
come
from
say
in
archives
and
library
background.
You
know
how
do
we
all
get
on
the
same
page?
Do
we
start
off
on
the
same
page?
Do
we
have
to
you
know
how
do
we
communicate
these
ideas
with
each
other?
L
Is
there
any
disparity
to
begin
with?
How
do
the
groups
assign
leaders
how
do
people
kind
of
rise
up
as
leaders
in
the
different
kinds
of
work,
that
you're
doing
you
know,
and
it
or
is
it
completely?
You
know
loose
Confederacy
and
in
and
no
one's
really
considered
a
leader.
You
know
these
are.
These
are
all
questions
that
I
want
to
tease
out
in
terms
of
how
how
the
groups
do
their
work
to
develop
the
standards
next
slide
and
then
the
the
second
kind
of
parallel
research
question.
L
You
know
we
want
to
look
at
how
these
things
are
developed,
but
then
I
also
want
to
look
at
how
these
standards
are
implemented
in
the
preservation
community's
work.
So
next
slide.
So
the
concepts
that
I
want
to
look
at
here
with
inner
with
interviewing
people
is
what
kind
of
factors
inform
preservation,
professionals,
decisions
of
which
standards
to
use
or
not
to
use
in
their
video
digitization
work.
You
know,
infrastructure
kinds
of
questions,
staffing,
factors,
cost,
etc.
L
In
some
cases
this
might
be
kind
of
ethical
decisions.
You
know
we
want.
My
institution
wants
to
align
ourselves,
consciously
align
ourselves
with
the
open-source
community
and
not
with
any
kind
of
industry
community
like
Apple,
or
something
like
that.
You
know
it
might
not
just
be
the
kind
of
dollars
and
cents
decisions,
it
might
be
more.
You
know
ethical
perspectives,
you
know
or
moral
perspectives.
L
However,
you
want
to
say
that,
and
do
the
standards
that
are
being
produced
by
these
groups
or
similar
standards
do
they
need
to
be
adapted
for
local
practice
at
these
different
institutions
or
do
they
work?
You
know
right
out
of
the
box.
How
active
are
the
users
of
the
standards
which
may
not
always
be
the
same
people
as
the
designers
of
the
standards?
How
active
are
they
in
helping
these
standards
to
change
and
mature
over
time?
L
Next
slide,
please
so
I
would
like
to
in
order
to
to
gather
data
and
I
know
that
you've
probably
seen
my
calls
for
participation
on
the
AMIA,
listserv
and
I'm.
Your
seller,
listserv
I,
want
to
do
interviews
with
standards,
develop
developers
and/or
implementers
again,
they
may
not
all
be
the
same
populations
likely.
A
lot
of
this
stuff
is
going
to
play
out
over
Skype,
but
I
do
plan
to
be
at
the
AMIA
conference
in
New
Orleans
later
this
year.
L
L
So
far,
at
Indiana,
University
who
I
know
uses
or
and/or
is
planning
to
use
ffv
one
in
coatings
with
Matroska
and
I
think
they
may
also
be
working
with
avi
containers
on
the
the
mass
digitization
they're
doing
there
digitizing
thousands
of
hours
of
content,
probably
as
we
speak,
and
the
folks
at
the
Library
of
Congress's
Culpepper
facility,
south
of
Washington
DC.
So
some
of
the
people
who
have
been
very
vocal
in
the
development
of
the
fangy
specification,
that's
the
mxf
jpeg2000
specification
and
also
are
implementing
it
for
their
use.
L
So
so
far,
those
are
the
two
sites
that
I
want
to
to
visit
and
talk
with
I'm
happy
to
hear
ideas
about
more
sites
who
might
be
using
something
very
similar
to
what
seller
is
doing
or
what
faggios
has
produced.
But
I
also
want
to
look
at
and
you
kind
of
a
close
read
of
the
documentation
surrounding
to
work.
So
the
standards
development
documents
and
drafts,
like
you,
have
on
the
seller
site
meeting
minutes
best
practice
documents
in
the
case
of
people
who
are
implementing.
L
You
know
these
kinds
of
concepts
and
then
how
the
standards
and
why
the
standards
are
are
or
are
not
implemented
and
I
know
that
the
seller
standard,
of
course,
is
being
worked
on
as
we
speak,
but
if
there
are
similar
kinds
of
combinations
of
matroska
and
FFT
one
as
in
Indiana
University's
work,
you
know
why
would
they
choose
that
over
the
spec?
You
know
why
would
they
choose
that
over
just
digitizing
uncompressed
with
an
avi
container,
bla
bla
bla
again?
L
L
So
if
you
would
like
to
participate
in
my
work,
if
we
have
not
already
talked
with
each
other,
please
contact
me
I'm,
looking
forward
to
learning
more
about
the
work
that
you're
doing
and
and
working
with
you
on
this
research.
I
know
I've
already
talked
with
several
of
you
and
you've
already
agreed
graciously
to
be
interview,
subjects
I'm,
happy
to
anonymize.