►
From YouTube: IETF96-CELLAR-20160719-1400
Description
CELLAR meeting session at IETF96
2016/07/19 1400
A
C
C
B
C
A
B
D
B
C
G
Okay,
I
think
we're
gonna
get
started.
Welcome
to
the
inaugural
meeting
of
the
seller
working
group,
it's
codec
encoding
for
lossless
archiving
and
real-time
transmission.
This
is
our
first
in-person
meeting.
The
working
group
was
established
at
the
end
of
2015.
This
is
my
first
time
chairing
a
meeting,
so
bear
with
me
as
we
as
we
go
along.
There
might
be
some
errors
or
mistakes
and
I'm
happy
to
be
corrected.
G
E
Yeah,
what
all
that
text
up
there
is
basically
saying
is
that
that,
if
you
are
personally
aware
of
IPR
relating
to
a
contribution
that
that
you
are
making
specifically
IP
are
owned
by
you
or
your
employer,
then
you
are
required
to
tell
us
about
it
in
a
timely
manner.
All
the
details
are
in
bcp,
78
and
79,
which
you
can
find
online.
G
G
G
G
Well,
there's
just
just
a
brief
note
about
the
seller
origin
story
about
how
the
working
group
was
formed
in
late,
2015,
myself
and
tumor,
the
chairs,
you
can
find
our
Charter
at
the
you
are
all
there
and
the
mission
statement
is
using
existing
work
done
by
the
development
communities
of
matroska
ffv
one
and
flac.
The
working
group
will
formalize
specifications
for
these
open
and
lossless
formats,
and
so
these
are
our
current
milestones.
These
were
created
when
the
working
group
was
first
formed
and
some
of
them
were
updated
this
past
spring.
G
I
E
All
right,
well
just
just
to
give
my
personal
opinion
I,
think
the
the
draft
for
ebay
ml
is
probably
going
to
require
at
least
several
months
more
work
and
considering
that
that
blocks
the
drafts
for
matroska,
which
is
much
much
larger.
I,
think
that
even
the
July
deadline
is
is
going
to
be
unrealistic.
I
E
Go
pull
it
up
here,
yeah,
so
so
the
the
individual
draft
that
was
submitted
currently
says
that
it
is
standards
track
which
would
seem
to
indicate
it
was
for
the
milestone
for
version
4.
It
also
specifies
the
elements
for
all
the
versions,
one
two
and
three,
but
our
milestone,
for
that
is
informational,
which
means
that
would
need
to
be
in
a
separate
document.
So
I
I
don't
currently
think
the
individual
draft
that
was
submitted
directly
targets
either
of
these
two
milestones
without
some
adjustments,
so
we
will
have
to
figure
out
how
that
works.
J
Hi
this
is
David
Rice
I
mean
just
to
speak
about
the
I,
guess
the
workload
in
the
habits
that
we're
using
versus
the
informational
and
standard
submission
I
the
I
mean
for
IETF
in
matroska.
The
documentation
is,
has
been
historically
developed
on
within
the
matroska
community
and
integrates
all
of
the
versions
together
with
flags
and
identify
errs
to
kind
of
refer
to
what
version
they
relate
to.
J
So
we've
been
continuing
to
develop
it
in
conjunction
like
that,
but
a
lot
of
our
recent
discussions
have
been
to
focus
on
what
specifically
to
remove
from
the
I
guess
the
standard
version
of
this
draft
that
would
create
the
version
for
specification,
so
I
mean
I.
Think
a
bit
of
a
tactic
for
us
might
be
to
focus
really
on
this
standards
version
and
then
to
drop
the
aspects
that
relate
to
versions
one
two
and
three,
but
before
the
drop
would
be
considered.
J
The
the
informational
submission
like
that
it
contains
all
this
legacy
information
it
contains
documentation
of
depreciated
elements
like
that
entirety
could
be
possibly
a
an
informational
submission
and
then,
after
the
removal
of
the
content
for
one
two
and
three,
we
could
have
a
standard
submission
for
ritalin.
For
specifically.
E
Okay,
I
think
that
that
makes
a
reasonable
amount
of
sense
and
that
that
this
draft
could
probably
be
modified
to
do
those
things.
So
your
intention
would
it
be
for
when
you
say
you
you're,
removing
the
things
for
one
two
and
three
you're
you're
then
going
to
include
those
in
a
separate
document
that
does
not
have
anything
for
version
4
in
it
and
that's
what
you're
going
to
publish
this
information
I.
J
Mean
we
are
certainly
looking
for
for
advice
on
on
how
to
proceed,
but
I
I
think
there
is.
It
is
motivation
for
the
participants
to
to
release
in
informational
documentation
that
reflects
you
know
the
majority
of
matroska
files
that
are
already
existent
to
be
seen.
You
know,
as
in
as
an
informational
submission,
as
well
as
having
a
more
standardized
focus
for
FF
4
version.
4
I
mean
I
know.
J
One
of
the
comments
we've
received
is
that
the
document
is
massive
and
if
we
can
remove
a
lot
of
the
work
in
progress,
remnants
that
are
still
on
the
documents
and
a
lot
of
the
documentation
on
depreciated
elements,
I
think
we
can
really
constrain
this
for
a
standard
submission.
Well,
its
presence
for
the
informational
submission
might
be
necessary
to
kind
of
understand
what
happened
in
the
history
of
matroska
right.
E
I
This
has
been
and
I'll
address,
that
statement
first
and
then
back
to
what
I
was
going
to
say.
That's.
That
is
a
true
statement
to
some
degree.
It's
especially
true,
if
you
make
it
clear
and
informational
that
this
draft
this
document
is
documenting
work
that
was
done
elsewhere.
As
opposed
to
this,
is
you
know,
new
work
being
done
on
the
ITF?
I
I
I
think
the
separation
we're
talking
about
is
still
probably
a
good
one,
and
milestones
can
be
worked
in
parallel
if
that
works
for
the
working
group,
but
I
do
caution
people
not
to
get
caught
up
on
a
critical
path
where
everything
is
dependent
on
your
biggest
thing,
you
know
if
there
are,
if
there
are
anything,
that's
low
hanging
fruit,
we
can
get
this
done
quickly
and
show
some
output
from
the
working
group.
That
would
be
nice.
E
G
G
G
K
F
G
K
Yeah,
but
still
very
closely
so
I'm
Steve
lon
I'm
from
France
I
created,
not
alone
matroska,
based
on
another
format
that
never
saw
the
light
of
day
the
when
we
we
I
said
we,
because
there
was
more
people
involved
online
in
a
open
community
development.
Rasca
we
sub
a
good
design,
would
be
something
like
XML
been
binary,
but
not
too
verbose
that
so
we
created
eb
mls,
the
strut
underlying
structure
from
etruscan
and
then
matroska
was
built
at
the
same
time.
K
So
one
of
your
issues
see
to
see
if
we
could
work
on
progressing
and
matroska
was
a
BM
e
BML
is
not
finish,
is
completely
doable
because
we're
eb,
Mel's
already
quite
stable
and
my
choice
car
as
a
lot
of
stable
parts
too.
So
a
lot
of
stuff
can
be
done
in
my
troska,
even
though
the
ebm,
honest
spec
is.
K
Done
so,
if
I
to
finish
but
myself
so
I
just
did
that
as
a
side
project
and
it
evolved
into
something.
That's
now
used
in
web
m4.
So
for
Google,
a
lot
of
vp8
vp9
videos,
you
watch
in
Chrome
or
in
android,
probably
using
matroska
a
lot
of
people
download
videos
using
metro
scale
as
well
and
now
the
subject
of
the
working
group
seller
is
to
make
it
work.
K
C
K
The
original
ubm
aspects
were
done
in
the
inside
the
matroska
specifications.
Later
we
did
a
side
project
just
for
a
BM
l,
but
with
the
same
information
but
just
alone
now
you're
working
right,
the
I
mean
every
changes
to
the
current
specifications
are
done
on
github
and
discussed
on
the
seller
mailing
list
and
so
that
created
recently,
the
ebm
l
draft
RFC
and.
J
K
J
K
Video
and
subtitle
synchronized-
it's
not
something
the
user
sees
so
something
we
should
really
change
in
the
specifications.
As
everything
that's
refer
time
code
is
actually
changing
too
tensed,
and
on
top
of
that
we
do
not
have
proper
timecode
support.
Yet
so
the
thing
that
people
expect
to
see
the
time
flowing,
that's
something
that
is
needed
by
archive
people.
So
that's
something
that's
being
worked
on
in
the
Middle
East
and
the
Vienna
spec
room,
yes,
or
does.
K
K
A
very
rare
where
you
use
feature-
that's
not
completely
needed
now,
so
we
can
drop
that
from
the
specifications.
The
codec
mapping
definitions
even
on
our
website.
It's
it's
saturated
from
the
specification
between,
because
basically,
every
codec
used
in
the
container
should
have
its
own
document.
You
say:
are
you
map
the
codec
data
into
matroska
inside
and
out,
and
this
probably
are
the
parts
that
can
be
dropped
or
elements
they
are
not
used.
J
K
J
K
Been
deprecated
for
a
long
time
and
nobody
actually
use
the
world
for
not
a
document,
an
XML
document
to
generate
code,
so
it
always
matches
the
specifications
in
that
document
will
keep
the
deprecated
elements,
because
we
want
that
curve
to
still
be
able
to
read
these
elements.
So
I
think
we
should
still
have
one
way
somewhere
to
know
that
desire
not
exist,
so
somebody
doesn't
try
to
use
them
for
something
else,
so
I
propose
to
Damon
in
the
annex
or
one
way
or
another.
K
C
J
K
K
Yes,
so
you
can
post.
Obviously
your
questions
on
the
mailing
list
and
whatever
you
feel
like
talking
about
on
the
specifications
the
formatting
probably
could
still,
especially
on
the
mattress
casa
de,
been
improved.
That's
something
that's
been
worked
on
and
we
are
aware
of
that
also
like
adherence
to
the
ITF
protocols.
J
K
K
K
Are
but
it's
not
very
practical
and
not
very
readable,
so
I
think
we
might
change
that
formatting
to
just
saying
which
parents
that
element
belongs
to
when
it's
a
lot
clearer
and
faster
to
read
and
I.
Think
that's
it
for
me.
So
you
probably
have
a
lot
of
questions.
I
hope,
except
for
days.
Dave
knows
everything.
L
Thomas
Dayton
is
oh
I
want
to
expand
on
the
point
earlier.
I
was
fun
of
people
on
the
mailing
list.
I
was
making
comments
about
the
kind
of
what
to
do
when
you
have
a
bad
format
or
you
know
an
attack
or
something
that
the
big
thing
I'm
going
for.
There
is
not
so
much
just
you
know,
corrupted
data,
but
also
just
you
know,
poor
software
or
different
encoders,
because
right
now
I
think,
there's
many
ways.
L
There
are
many
many
different
ways
to
encode
a
matroska
file
and
the
question
is
you
know
what
what
is
valid
and
if
you
make
very
many
many
many
things
valid.
It's
very
easy
to
get
yourself
to
the
point
where
you
start,
depending
on
player
specific
behavior,
they
may
generate
a
file,
it
may
look
great
in
being
a
one
player
and
then
the
other
player
can't
read
it
or
plays
in
a
different
way.
L
That's
you
know,
that's
all
working
like
you
know
you
might
make
it
work
one
in
one
place,
but
this
is
very
confusing
and
I
think
it's
really
important
to
be
able
to
find
stuff
in
the
in
the
terms
of
the
player.
Behavior,
so
people
realize
that
they
have
screwed
up
and
they
can
say
this
is
this
is
valid,
or
this
isn't
valid
and
auto.
Just
as
we
know
it
plays
one
player.
Okay,.
C
L
Muhammad,
what
one
is
that
you
can
actually
one
way
to
tackle
this
is
you
could
probably
define
something
like
a
standard
way
to
handle
this
and
that
many
of
the
elements,
if
you
define
what
is
valid,
you
can
then
give
basically
standard
behavior
such
as
skip.
You
know
a
skipped
element
and
do
not
parsing
the
data
or
skip
them.
You
know
skip
skip
its
parent
or
it
like.
So
you
know,
however,
that
bubbles
up
you
can
opt.
You
two
probably
make
something.
K
K
Isolate
it
as
small
as
possible,
maybe
fix
it
even
so,
but
they're
so
that's
one
case
that
probably
should
bring
the
ebm
inspect,
because
this
year
see
is
there
and
it
can
be
put
anywhere
in
any
way.
I
BML
master
element
in
natural
scale,
there's
probably
a
lot
more
scrutiny
that
can
be
put
on
elements
to
see
what
could
happen
if
that
element
goes
bad
and
I.
Think
that's
actually
you
some
of.
J
L
And
last
thing
is:
I
was
whenever
Isis
also
you
talk
about,
that
is
little
to
youtube,
but
that
I
talked
about
the
ebm.
L
schema,
so
I,
don't
know
what
the
scope
of
that
would
be
like.
Is
it
going
to?
Are
you
going
to
use
to
validate
an
entire
matroska
document,
or
is
it
I?
Did
you
want?
Do
you
want?
Are
you
have
like
entire
validation
they're
described
to
the
schema,
or
is
that
going
to
be
just
for
the
correctness
of
Annie
BML
document,
but
not
necessary
of
the
Raza
file?
L
M
K
K
K
J
Steve
guys
I
want
to
ask
you
answer
a
bit
of
Thomas's
question
too
we're
we're
trying
to
use
the
the
basis
of
the
specification
for
the
xml
schema
to
sort
of
influence,
how
we
can
define
eb
ml
schema.
So
if,
if
there
is
an
analogy
and
an
analogous
method
of
making
such
a
declaration,
we're
using
that
and
if
we
have
to
go
outside
of
what
can
be
done
in
xml
schema,
we
we
are
a
little
bit
more
cautious
because
we
are
defining
something
new.
J
In
the
case
of
in
the
case
of
EV
ml,
we
have
a
couple
areas
where
we
have
to
define
a
default
value
and
in
an
XML
schema,
you
can
define
a
default
even
if
the
element
is
present,
but
we
have
a
few
instances
where
the
default
is
not
a
number
or
string.
But
it's
a
relator
to
related
element-
and
this
is
you
know
like
not
a
part
of
what
XML
can
do,
but
it's
part
of
what
matroska
is
currently
doing.
J
So
this
is
one
of
our
considerations
of
like
having
this
kind
of
relational
element
be
a
default
for
another.
The
other
part
is
that
we've
had
some
discussions
on
the
mailing
list
about
having
having
validation
rules
based
on
equations
of
other
elements.
So
the
case
you're
talking
about
we're
like
the
the
like
pixel
crop
left,
can
certainly
not
exceed
the
the
width
or
like
the
the
I
guess.
Pixel
crop
left,
plus
pixels
crop
right
cannot
be
greater
than
the
weights
with
the
pictures
with
so
so
I
mean
we
have
to.
J
We
have
to
define
how
to
express
an
equation
of
related
elements
like
how
to
get
like
an
ex-cop
style
expression
to
refer
to
the
related
elements
and
then
like
what
types
of
equations
we
want
to
support,
but
I
think
it.
It's
very
motivating
to
move
as
much
of
the
validation
into
machine,
readable
context
in
the
EPL
schema
as
we
can,
but
then
there's
certainly
there's
certainly
a
limit
to
what
we
can
do,
because
a
lot
of
the
recommendations
of
the
matroska
document
are
you
know
implies.
K
Also,
this
validation,
we're
talking.
Man
is
just
for
a
schema,
so
it
would
be.
The
mattress
k
part
doesn't
imply
eb
ml
validation
like
if
you
have
a
master
element.
The
size
of
the
elements
inside
cannot
exceed
the
size
of
the
master
itself,
the
element
above
and
that's
the
kind
of
thing
that's
not
really
defined
in
the
schema,
but
it's
actually
an
important
check
to
do,
because
you
can
find
that
something
is
wrong.
K
E
So
we
did
have
some
discussion
that
I'm
not
sure
the
current
matroska
draft
that
was
submitted
directly
supports
the
two
milestones,
as
we
said
before,
but
the
eb
ml
draft
does
seem
to
directly
support
the
milestone
with
that
respect.
So
we
can
I
think
we
could
issue
a
call
for
consensus
to
adopt
that
draft
as
a
working
group
item.
So
those
of
you
who
would
like
to
adopt
that
draft
please
home
now
the.
I
This
has
been
yeah,
it's
worth
saying
a
couple
of
words
what
that
means-
and
I
guess
I'll
do
that,
but
I
just
came
up
here
when
you
adopted
draft,
doesn't
mean
it's
done,
it
doesn't
mean
it's
right,
it
doesn't
mean
that
every
word
and
it
won't
change
before
you're
done.
What
it
means
is
that
the
working
group
believes
that
right
now,
that's
the
best
way
forward
to
fulfilling
that
well
piece
of
the
milestone
right.
E
J
Is
David
Rice
I
think
we
have
a
short
number,
maybe
like
a
half
a
dozen
issues
in
the
EV
ml
github
trucker
for
a
vmail
specification
that
we
need
to
resolve.
But
I
think
this
combined
you're,
quite
comprehensive
comments
about
the
EV
ml
draft
is,
is
about
the
extent
of
like
our
current
pots
are
between
where
the
document
is
at
the
moment
and
where
it
needs
to
get
finished.
So,
if
I
understand
the
the
status
that
is
being
proposed
now,
where
we
kind
of
have
the
the
vision
is
a
bit.
K
E
G
R
The
AFC
4
over
the
left
is
on
vaca
and
we
have
also
a
guitar
pro
positively
hosted
by
FFM
pay,
because
if
everyone
was
initially
created
by
ffmpeg
one
of
ffmpeg
developers,
so
I
am
NOT
with
developer
of
F.
Everyone
I
am
NOT
were
authorized
everyone
if
everyone
was
created
by
mckernon
emil,
and
I
helped
to
update
the
specification
because
the
first
thing
we
got
with
FF,
everyone
was
decoder,
encoder
and
decoder
directly.
It
was
coded
and
we
want
to
have
something
more
turned
out,
so
we
are
creating
the
corresponding
specification.
R
R
R
So
now
we
updated
a
lot
with
everyone
specification
with
frame
more
details
about
the
middle
of
a
slider
and
we
defined
what
is
a
plane,
how
the
bitstream
is
done
for
planes
and
lines,
and
there
was
already
a
lot
of
work
about.
How
is
the
decompression
method?
How?
How
is
the
algorithm,
so
this
part
is
well
I
was
not
touched.
R
We
also
created
an
independent
ffv
one
at
limitation
shaker
in
order
to
our
to
have
to
implementation
of
a
decoder,
not
only
the
ffmpeg
one.
So
it
is
a
completely
and
deponent
implementation
of
a
specification
from
scratch.
We
don't.
We
use
a
very
safe
MPEG
code
and
we
hope
with
two
decoders
and
20
to
be
to
see
what
is
wrong
in
the
specification,
and
we
want
to
fix
everything
in
the
specification
before
submitting
to
the
ITF.
R
R
We
want
to
create
bergey
files,
so
there's
already
some
magnifies
alive.
So
we
want
to
be
sure
that
the
specification
can
say
what
we
should
do
when
we
meet
some
such
file.
We
want
to
create
verifies
in
order
to
stress
a
bit
with
decoders
and
in
order
to
see
that
the
specification
is
okay
with
that,
and
we
want
first
to
standardize
on
I
ITF.
R
G
R
G
R
E
L
Thomas
tina's
or
I
one
thing
I
noticed
when
read
in
the
draft
is
that
there
is
almost
no
there's,
basically
no
colorimetry
information.
It
basically
just
says
everyone
says
you
know
ycbcr
or
I
think
as
one
will
flag,
they'll
switch
it
between
planer
and
packed,
and
you
have
basically,
the
demonstration
giraffe
includes
tons
of
all
the
color
information.
Is
that
the
general
ideas
you
basically
want
to
have
are
all
the
color
information
in
matroska.
R
Currently,
people
use
of
a
metal
container
for
feeling
more
colas,
the
phase,
information
transfer
characteristics
and
so
on.
It
is
in
matroska,
and
but
we
want
with
ffv
one
version
for
to
add
this
information
directly
in
flv
15
header,
in
order
to
lose
nothing
when
they
some
trance
working,
for
example.
So
the
first
stage
is
to
define
transfer
characteristic
and
over
color
space
information
in
the
matroska
continue
format
and
when
we
finish
flv
1
version
01
and
free
iPhone
national.
R
L
R
N
Sort
of
generalizing
that
a
little
bit
I
mean
you
could
also
say
that
in
the
standards
track
version
of
matroska
and
drop
this
information,
because
it's
an
f,
51
I,
guess
you
want
to
say:
do
you
want
to
support
standards
track
matroska
with
information
left
if
you
want
or
by
store?
So
you
wanted
to
say
that
if
you're
using
the
IETF,
a
trust,
a
UCI,
ATF
f51,
those
are
designed
to
work
together
and
the
older
information
ones
are
designed
to
work
together,
but
so
you're
moving
the
information,
not
copying
it.
N
J
R
This
information
is
often
lost
and
we
don't
want
to
lose
such
important
information,
but
it
is
not
something
specific,
actually
12
everyone.
A
lot
of
other
container
already
do
that,
for
example,
a
movie
quicktime
they
already
safe
such
data
in
the
container
and
h.264
already
safe
data.
So
we
we
do
the
same
as
the
the
ovals.
K
Every
codec
that's
putting
matroska
as
a
mapping
to
put
it
inside
and
outside,
for
example,
in
mp3
yeah,
MPEG,
3
or
mp3
audio,
it's
possible
because
mp3
is
also
a
container
and
a
codec.
Even
though
it's
small,
you
can
remove
completely
a
container
part
and
it
and
still
work
in
matroska.
It's
not
often
use
because
when
you
take
it
out
of
matroska
programs
are
lazy
and
they
don't
take
care
of
putting
bad
they're
backed
information.
K
But,
for
example,
right
now,
if
everyone
is
using
the
avi,
my
pin
with,
which
is
a
general
case
for
whatever
you
can
put
in
avi
you
can
put
in
my
troska.
But
if
we're
going
to
define
a
specific
mapping
for
FF
v,
one
Inlet
Rosco,
then
we
could
define
how
its
put
in
removing
hint
of
information
that's
already
set
in
The
Container.
R
Actually,
the
color
space
information
duplicated
in
the
container
is
not
anything
duplicated.
We
have
width
height,
we
have
frame
white,
it
is
often
duplicated,
so
it
is
not
the
only
information,
sometimes
a
container
needed,
and
sometimes
we
also
need
it
in
the
bitstream.
In
order
to
be
more
to
lose
nothing
when
we
do
some
trapping
something
else.
M
I
can
go
Knicks,
stevebotts
go
I
just
want
to
say
this
duplication
issue
was
not
unique
to
container
formats
right.
It's
certainly
possible
that
have
in
h.264
bitstream
in
a
sip
call.
I
have
different
information
in
the
bitstream
than
is
what's
advertised
in
the
in
the
SIP
SDP.
So
I
don't
know
that
we
need
to
solve
this
problem.
You
know
the
container
format
probably
has
a
reason
to
have
information.
That's
duplicative!
If
someone
is
foolish
enough
to
write
a
tool
that
allows
inconsistent
information,
then
it's
kind
of
on
them.
M
J
On
the
topic
of
conflicts,
I
wanted
to
mention
that
occasionally
it's
it's
it's
it's
intentional.
There
are
some
codecs
that
contain
information
such
as
like
I'm
thing
about
the
DV.
Codec
contains
a
aspect
ratio
as
a
flag
that
only
supports
like
43
in
69.
So
if
DV
information-
that
is
not
that
aspect
ratio
is
encoded
at
that,
like
that
value
could
be
overridden
by
the
container.
The
correct
information
I
mean
I
think
it
might
be
like
if
we
want
to
a
store
a
bit
stream
in
a
container.
J
If,
if
some
of
the
information
of
the
bitstream
cannot
be
clarified
because
of
the
limitations
of
that
specification,
then
we
have
the
container
that
can
correct
it.
So
if
we
have
the,
if
we
have
some
content,
that
is,
you
know,
20
19
aspect
ratio
and
it's
in
DV
I
mean
if
it
was
in
QuickTime
or
montrose
co.
This
this
could
be
clarified.
If
we
want
it
to
be
clear
in
DV
alone,
it's
not
possible.
The
specification
we
have
to
have
a
container.
That
is,
has
a
specification
that
clarifies
that
the
information
is
intended
to
override.
L
L
Agree
with
that
and
that
the
other
thing
I
want
really
want
that
I
actually
disagree.
I
would
actually
very
much
like
the
behavior.
When
you
have
these
mismatches
to
be
specified,
it
can
be
specified
either
in
a
mapping
or
in
the
matroska
container
depend
how
generic
it
can
be.
But
I
just
don't
want
the
case
where
people
say
they
take
a
format.
They
use
davids
a
badly
written.
You
know
if
they
use
some
buggy
software,
they
produce
Billy's
cut
this
conflict
information.
R
L
J
So
every
all
these
characteristics
that
are
even
you
know,
more
typically
put
into
the
encoding
in
more
modern
codex,
is
not
possible
with
uncompressed
video.
So
the
video
like
that
we
have
to
rely
on
a
container
to
do
everything.
I
know
the
QuickTime
specification
is.
There
are
some
parts
of
the
specification
that
say:
if
the
containers
used
to
store
uncompressed
video,
then
these
particular
parts
are
mandated.
O
G
Okay,
if
any
other
questions
concerns
comments
about
either
matroska
or
FFA
one
or
EDM
l,
okay,
so
we
are
doing
very
well
on
time,
which
is
great.
I'd
rather
have
more
time
than
run
out
of
time,
but
I
think,
but
I
went
to
talk
about
at
the
end
of
the
session-
was
moving
forward
and
our
next
steps
discussed
the
possibility
of
an
in-person
meeting
in
2017
if
the
group
finds
it
necessary
in
chicago
in
a
march
of
2017.
G
I
think
we
kind
of
discussed
or
started
to
discuss
two
and
three
as
to
mention
t,
and
I
will
review
the
milestones
and
then
circulate
revised
schedule
to
the
list,
and
then
I
think
the
four
or
five
and
six
pertain
mostly
to
having
more
people
involved
in
in
kind
of
the
document,
writing
and
shepherding
process.
I
guess
we're
on
the
editing
and
reviewing
side.
G
So
if
you,
if
you
are
interested
in,
have
not
yet
commented
on
the
list
or
you
know
taking
a
look
at
the
draft,
you
know
please
do
so
and
please
share
freely
and
frequently
on
the
seller
mailing
list.
So
if
there
any
questions,
comments
or
ideas
about
that,
you
know
these,
please
share
them
with
us.
I
think
yeah,
I
would
say,
looking
at
different
ways
to
kind
of
encourage
people
to
participate
other
than
just
you
know,
writing
to
the
mailing
list.
Over
and
over
again,
please
comment
plz
comment.
G
Okay,
so
it
may
be
a
discussion,
a
topic
for
the
list
and
then
number
seven
was
an
end
to
FLAC.
Neglect
flac
is
included
in
our
list
of
working
group
deliverables
and
we
have
not
done
anything
with
flack.
Yet
there
is
I,
think
and
correct
me.
If
I'm
wrong,
I
think
the
least
amount
of
work
needs
to
be
done
with
flack
in
order
to
get
it
ready
for
the
standards
track,
but
I
have
f
I
hadn't
reached
out
to
do
the
developers
of
flak
since
the
working
group
was
approved.
G
J
J
Think
it's
in
HTML
in
a
in
their
own
github
repository
I,
could
I
mean
I
could
help
right
the
the
make
file
to
make
the
conversion
from
the
specification
as
it
exists
in
their
current
form,
as
the
community
maintains
it
into
RFC,
so
that
we,
you
know,
can
have
the
document
in
a
form
that
is
comfortably
reviewable
by
both
communities,
the
the
working
group
and
the
fact
developers,
but
I
would
yeah
they're.
There
needs
to
be
some
type
of
bridge
between
the
two
communities
to
like
this
I'll.
Take
the
discussion
better
right.
G
I
absolutely
agree:
I,
don't
know
that
if
there's
any
sort
of
cross
participation
when
they
between
the
flak
and
the
you
know,
and
the
seller
Rob
sorry
at
the
seller
working
group,
so
that
I
think
communicating
with
the
flack
developers
and
writing
the
make
file
to
get
that
into
the
IRC
format
would
be
spectacular
and
I.
Think
that's
I
mean
you
know,
I'm
not
going
to
assign
your.
You
know,
speaked,
something
something
that
will
assign
work
to
somebody
else,
but
you
know.
G
G
H
J
This
is
David
Rice,
yes,
I
mean
I,
I
should
say,
like
kind
of
the
process
to
build
up
to.
The
meeting
has
been
especially
helpful.
That
I
mean
the
july.
Eight.
A
deadline
for
the
submission
of
drafts
for
consideration
for
the
discussion
here
like
was
a
big
motivator,
because
a
lot
of
us
are
quite
deadline
driven,
so
you
will
notice
a
huge
amount
of
work
happened
because
of
because
of
this
deadline,
particularly
on
matroska
matroska,
was
not
in
good
shape
for
this
kind
of
draft
submission
at
this
time.
J
So
there
was
a
lot
of
work
to
kind
of
adjust
the
formatting
and
gather
missing
sections
like
security
considerations
and
abstracts.
So
the
this,
the
structure
of
preparing
for
the
meeting
helped
quite
a
bit
also.
I
know
now
that
we
are
eternally
from
the
meeting
like
a
lot
of
the
commentary
like
that
that
you
and
others
had
provided,
is
quite
comprehensive.
C
G
H
J
Made
an
XSL
to
convert
it
into
mark
down,
to
run
it
through
mm
mark
to
run
through
XML
to
RFC
the
total
pile
is
220
pages
at
the
end
of
it.
Some
of
that
is
quite
massive.
I
think
there's
a
lot
of
changes
I
can
make.
I
can
it,
for
instance,
if
I
make
some
optimization
to
the
conversion
of
the
eb
ml
schema
to
mark
down,
I
think
we
could
probably
throw
out
60
pages
of
white
space
in
and
how
that
is
presented
in
the
RFC.
J
So
some
some
minor
work
can
get
that
number
down
quite
substantially,
something
where
I'm
not
I'm,
not
I'm,
not
the
you
know,
I,
don't
have
so
much
experience
and
how
I
see
the
ietf
yields
of
massive
specifications.
But
there
are
a
couple
sections
of
matroska
that
are,
you
know,
quite
quite
relevant
to
move
into
separate
sections.
J
For
instance,
the
matroska
specification
defines
a
structural
component
for
how
tags
are
stored
and
they
are
semantically
defined,
and
then
the
document
also
contains
a
lot
of
space
attached
to
a
specific
tags
that
can
be
used
within
that
structure
and
I.
Think,
like
the
metadata
vocabulary
of
matroska,
could
stand
alone
as
its
own
specification.
Possibly
that
is,
you
know
very
much
dependent
on
the
matroska
one.
The
other
one
is
that
a
question
is
that
we
have
the
representation
of
Madras
cos
elemental
structure.
As
an
XML
document,
Annie
BML
schema
I.
J
We
could
submit
this
just
attach
it
to
the
specification
in
its
xml
form,
because
that's
how
it's
used
in
machine-readable
context,
but
I
presumed
it
would
be
a
little
bit
more
reviewable
if
we
converted
it
have
the
process
to
convert
it
to
mark
down,
so
that
there's
tables
in
the
RFC
draft,
rather
than
just
like
a
bra
XML
dump
but
having
the
tables
and
the
XML
is
of
course
redundant.
The
XML
is
what
we
are
intending
to
standardize
through
the
eb
ml
process.
So
I'm
not
sure
if
this
redundancy
is
helpful
or
not.
I
Has
been
I
am
NOT,
a
document
editor
but
I
been
stacking
up
comments,
and
so
let
me
see
if
I
can
go
back
to
the
beginning.
Oh
the
idea
that
the
deadline
helped
drive
the
work,
I'm
I'm,
both
glad
and
horrified
to
hear
that
the
deadlines
to
drive,
work
or
an
attractive
nuisance
of
the
IETF
IM
poor
people
to
try
to
not
get
into
that
habit.
Work
can
happen
anytime.
We
don't
have
to
be
in
meetings
to
discuss.
I
Things
is
mailing
lists
and
such
especially,
if
you're
planning
a
meeting
cadence
of
you
know
once
a
year
or
I.
Guess
that's
not
quite
that's
not
quite
once
a
year,
maybe,
but
still
so
you
do
end
up
with
the
you're
in
danger
of
ending
up
with
the
great
big
Python
that
just
ate
the
whole
pig
right
before
every
meeting,
and
that's
not
the
most
efficient
way
to
work.
I
know
that
I
made
a
joke.
Earlier
today
you
probably
heard
about
the
normative
statement.
I
The
normative
statement
of
the
kind
of
must,
but
I
know
you
want,
and
this
probably
falls
into
that
because
people
will
become
deadline-driven.
So
it
was
one
thing
to
keep
in
mind
with
your
meeting
schedule
on
the
size
of
the
document.
I
thought
I
had
a
simple
response
to
that.
But
might
response
became
more
complicated
as
I
listened
to
Dave.
I
Because
now
I'm
at,
if
you
ask
everyone,
the
iesg,
with
a
think
of
massively
big
document,
to
get
20
different
answers
and
is
G
is
not
20.
People
in
case
people
didn't
know
that
the
it
can
be
useful
to
break
them
up,
especially
if
you
can
break
them
up
in
a
way
that
they
can
be
reviewed
brother
independently.
I
I
Bo
thing
I'll
say
now:
when
you
start
by
talking
about
the
XML
being
what
people
use
versus
the
text
being
explanatory,
we
need
to
be
careful
about
what
we
consider
normative
and
if
the
idea,
I
think
I
heard
the
idea
that
the
xml
might
be
the
normative
part
and
everything
else,
maybe
explanatory,
and
that's
not
out
of
the
question.
But
that
requires
some
thinking
about
it.
And-
and
I
don't
know
if
we
have
good
answer-
can
that
we
have
done
strange
things
with
codex
in
the
past.
E
I
J
So
just
a
clarifying
comment
like
to
do
to
Ben,
we
we've
kind
of
adopted
this
from
the
way.
A
lot
of
XML
documents
are
standardized
where
there'll
be
the
XML
schema,
which
is
the
machine,
readable
version,
and
we
can
use
tools
like
XML
into
to
do
validation,
and
there
will
usually
have
to
be
a
human,
readable
component
of
the
same
information
and
in
many
instances
I've
seen.
The
human
readable
component
is
produced
from
the
the
machine
readable
one.
J
So
one
is
one
is
the
derivative
of
the
other
I
mean
the
ebm
L
had
been
conceived
of
XML
as
an
analogous
like
related
format
from
the
beginning.
So,
like
the
the
method
of
handling
and
EB
ml
schema,
we
had
been
trying
to
maintain,
as
analogous
as
well
as
far
as
how
normative,
if
it
is
to
the
rest
of
the
documentation.