a few things about nut.txt

Hi,

While reading the spec, I noticed a few things that could
improve 
readability IMHO:

1.) It would be handy to have the type mentioned after each
tag in the tag 
description section. It is tiresome to have to scroll back
each time. e.g.
chapter_id	(s)
stream_class	(v)
fourcc		(vb)
et cetera

2.) The first column of the frame_flags table is called Bit,
but there is no 
such thing as the 4096th bit of a 64-bit value. I suggest
changing the 
column-heading to Mask or change the column-entries to
represent the bit 
number (i.e. 0, 1, 3, 4, 5, 6, 7, 12, 13).

3.) There is no explanation of what EOR actually means.

I could change 1.) and 2.) if nobody objects. For 3.) I need
an explanation 
first 

--Ivo
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

Hi

On Fri, Nov 24, 2006 at 12:50:13PM +0100, Ivo wrote:
> Hi,
> 
> While reading the spec, I noticed a few things that
could improve 
> readability IMHO:
> 
> 1.) It would be handy to have the type mentioned after
each tag in the tag 
> description section. It is tiresome to have to scroll
back each time. e.g.
> chapter_id	(s)
> stream_class	(v)
> fourcc		(vb)
> et cetera

ok


> 
> 2.) The first column of the frame_flags table is called
Bit, but there is no 
> such thing as the 4096th bit of a 64-bit value. I
suggest changing the 
> column-heading to Mask or change the column-entries to
represent the bit 
> number (i.e. 0, 1, 3, 4, 5, 6, 7, 12, 13).

ok


> 
> 3.) There is no explanation of what EOR actually means.

end of relevance pretty much marks the start of a gap in a
stream (no video
or no audio or no subtitles until the next keyframe) it is
(with the
exception of a EOR after the very last frame) AFAIK
relatively nut specific
(= will probably never be used by anyone)
* nut files with EOR cannot be converted to other containers
or more
  correctly you cannot seek correctly in the resulting file
* converting non nut to nut will not contain EOR except for
marking the
  duration of the very last frame
* lav* does not support it (and i dont plan to change that),
for lav*
  gaps are not allowed, you will have to encode
black/silence/no subs
  keyframes (which require only negligible storeage anyway)
* EOR breaks the ability to cut and merge nut files by
simply adding
  and removing headers

personally i would drop EOR from nut for anything but the
very last frame

[...]
-- 
Michael     GnuPG fingerprint:
9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or
copy any book
Today you'd get arrested for mere telling someone where the
library is
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

On Fri, Nov 24, 2006 at 01:34:44PM +0100, Michael
Niedermayer wrote:
> > 3.) There is no explanation of what EOR actually
means.
> 
> end of relevance pretty much marks the start of a gap
in a stream (no video
> or no audio or no subtitles until the next keyframe) it
is (with the
> exception of a EOR after the very last frame) AFAIK
relatively nut specific
> (= will probably never be used by anyone)

It's absolutely needed for subitles or seeking performance
will be
utterly abysmal. Consider a movie with 5 subtitles at
5minutes and 5
subtiles at 70 minutes and none in between (yes I actually
have a
movie like this). We wouldn't have added it if it weren't
actually
needed.

I would personally prefer to forbid EOR for audio and video
for the
time being except as a marker of final frame duration. If we
ever see
a need we could later allow them but it was never my
intention to
create a system for ugly special nut-specific semantics.

> * nut files with EOR cannot be converted to other
containers or more
>   correctly you cannot seek correctly in the resulting
file

Not true.

> * converting non nut to nut will not contain EOR except
for marking the
>   duration of the very last frame

It doesn't have to since these other containers suck and
don't care
about being able to synchronize subtitles on seeking.

> * lav* does not support it (and i dont plan to change
that), for lav*
>   gaps are not allowed, you will have to encode
black/silence/no subs
>   keyframes (which require only negligible storeage
anyway)

The nut muxer should automatically generate EOR for
subtitles and not
use it anywhere else (except perhaps eof). Just repeating an
'empty'
subtitle every few seconds is an ugly hack.

> * EOR breaks the ability to cut and merge nut files by
simply adding
>   and removing headers
> 
> personally i would drop EOR from nut for anything but
the very last frame

I think you missed the whole part about it being absolutely
essential
for subtitles and seeking...

Rich

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

Hi,

On Friday 24 November 2006 13:34, Michael Niedermayer wrote:
> On Fri, Nov 24, 2006 at 12:50:13PM +0100, Ivo wrote:
> > 1.) It would be handy to have the type mentioned
after each tag in the
> > tag description section. It is tiresome to have to
scroll back each
> > time. e.g. chapter_id	(s)
> > stream_class	(v)
> > fourcc		(vb)
> > et cetera
>
> ok

Done. Not every tag described in the tag section is an
actual tag in the 
file, so I left those blank.

> > 2.) The first column of the frame_flags table is
called Bit, but there
> > is no such thing as the 4096th bit of a 64-bit
value. I suggest
> > changing the column-heading to Mask or change the
column-entries to
> > represent the bit number (i.e. 0, 1, 3, 4, 5, 6,
7, 12, 13).
>
> ok

Done. It would have been less work to just change the
heading, but I dislike 
decimal bitmasks, so it lists the actual bitnumbers now.

--Ivo
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

On Friday 24 November 2006 17:14, Rich Felker wrote:
> On Fri, Nov 24, 2006 at 01:34:44PM +0100, Michael
Niedermayer wrote:
> > > 3.) There is no explanation of what EOR
actually means.
> >
> > end of relevance pretty much marks the start of a
gap in a stream (no
> > video or no audio or no subtitles until the next
keyframe) it is (with
> > the exception of a EOR after the very last frame)
AFAIK relatively nut
> > specific (= will probably never be used by anyone)
>
> It's absolutely needed for subitles or seeking
performance will be
> utterly abysmal. Consider a movie with 5 subtitles at
5minutes and 5
> subtiles at 70 minutes and none in between (yes I
actually have a
> movie like this). We wouldn't have added it if it
weren't actually
> needed.
>
> I would personally prefer to forbid EOR for audio and
video for the
> time being except as a marker of final frame duration.
If we ever see
> a need we could later allow them but it was never my
intention to
> create a system for ugly special nut-specific
semantics.
>
> [...]
>
> The nut muxer should automatically generate EOR for
subtitles and not
> use it anywhere else (except perhaps eof). Just
repeating an 'empty'
> subtitle every few seconds is an ugly hack.

How about this:

Index: nut.txt
============================================================
=======
--- nut.txt     (revision 21193)
+++ nut.txt     (working copy)
 -601,11
+601,16 
       12  FLAG_CODED       if set, coded_flags are stored
in the frame 
header.
       13  FLAG_INVALID     if set, frame_code is invalid.
 
+    A frame with FLAG_EOR set marks the beginning of a gap
in a stream.
     EOR frames MUST be zero-length and must be set
keyframe.
     All streams SHOULD end with EOR, where the pts of the
EOR indicates the
     end presentation time of the final frame.
     An EOR set stream is unset by the first content frames.
     EOR can only be unset in streams with zero decode_delay
.
+    A muxer SHOULD use EOR frames for subtitle streams to
mark large 
periods
+    where subtitles are absent.
+    EOR frames for non-subtitle streams are only valid at
the end of the
+    stream.
     FLAG_CHECKSUM MUST be set if the frame's data_size is
strictly greater 
than
     2*max_distance or the difference abs(pts-last_pts) is
strictly greater 
than
     max_pts_distance (where pts represents this frame's pts
and last_pts is

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

On Fri, Nov 24, 2006 at 06:37:33PM +0100, Ivo wrote:
> How about this:
> 
> Index: nut.txt
>
============================================================
=======
> --- nut.txt     (revision 21193)
> +++ nut.txt     (working copy)
>  -601,11 +601,16 
>        12  FLAG_CODED       if set, coded_flags are
stored in the frame 
> header.
>        13  FLAG_INVALID     if set, frame_code is
invalid.
>  
> +    A frame with FLAG_EOR set marks the beginning of a
gap in a stream.
>      EOR frames MUST be zero-length and must be set
keyframe.
>      All streams SHOULD end with EOR, where the pts of
the EOR indicates the
>      end presentation time of the final frame.
>      An EOR set stream is unset by the first content
frames.
>      EOR can only be unset in streams with zero
decode_delay .
> +    A muxer SHOULD use EOR frames for subtitle streams
to mark large 
> periods
> +    where subtitles are absent.

s/large//

> +    EOR frames for non-subtitle streams are only valid
at the end of the
> +    stream.

It would be nice to have a note that they are syntactically
valid but
that they need not be interpreted for compliance with the
current
version of NUT and that processes generating NUT files MUST
NOT write
EOR for non-subtitle streams.

Rich

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

On Friday 24 November 2006 19:34, Rich Felker wrote:
> On Fri, Nov 24, 2006 at 06:37:33PM +0100, Ivo wrote:
> > +    A muxer SHOULD use EOR frames for subtitle
streams to mark large
> > periods
> > +    where subtitles are absent.
>
> s/large//

Changed locally.

> > +    EOR frames for non-subtitle streams are only
valid at the end of
> > the +    stream.
>
> It would be nice to have a note that they are
syntactically valid but
> that they need not be interpreted for compliance with
the current
> version of NUT and that processes generating NUT files
MUST NOT write
> EOR for non-subtitle streams.

Perhaps:

EOR frames for non-subtitle streams are syntactically valid,
but, except
for the last frame, they SHOULD be ignored by demuxers and
MUST NOT be
written by muxers.

Or:

EOR frames for non-subtitle streams MUST NOT be written by
muxers and SHOULD 
be ignored by demuxers, except for the last frame.

?

--Ivo
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

Hi

On Fri, Nov 24, 2006 at 11:14:58AM -0500, Rich Felker wrote:
> On Fri, Nov 24, 2006 at 01:34:44PM +0100, Michael
Niedermayer wrote:
> > > 3.) There is no explanation of what EOR
actually means.
> > 
> > end of relevance pretty much marks the start of a
gap in a stream (no video
> > or no audio or no subtitles until the next
keyframe) it is (with the
> > exception of a EOR after the very last frame)
AFAIK relatively nut specific
> > (= will probably never be used by anyone)
> 
> It's absolutely needed for subitles or seeking
performance will be
> utterly abysmal. Consider a movie with 5 subtitles at
5minutes and 5
> subtiles at 70 minutes and none in between (yes I
actually have a
> movie like this). We wouldn't have added it if it
weren't actually
> needed.
> 


[...]
> 
> > * nut files with EOR cannot be converted to other
containers or more
> >   correctly you cannot seek correctly in the
resulting file
> 
> Not true.

wait, EOR is "absolutely needed" and it works in
containers which dont have
EOR, how can both be true?

just try:

Sub: K                                   K
Vid: KFFFFKFF..1hour..KFFFFKFF..1hour..KFFF

you can either
A. ignore the subs and seek purely based on the video stream
(will not
   display subs after seeking)
B. seek to previous keyframe of all streams (will not allow
you to seek
   into the 2 hour segment without sub keyframes


> 
> > * lav* does not support it (and i dont plan to
change that), for lav*
> >   gaps are not allowed, you will have to encode
black/silence/no subs
> >   keyframes (which require only negligible
storeage anyway)
> 
> The nut muxer should automatically generate EOR for
subtitles and not
> use it anywhere else (except perhaps eof). Just
repeating an 'empty'
> subtitle every few seconds is an ugly hack.

IMHO EOR is a ugly hack, puting keyframes where you want to
seek to is
the correct thing to do

also if you have a special case for "whole screen
transparent" then why
not for black frames or no audio? or gray frames or white
frames ...
this does make at least as much sense as for subtitles,
think of a audio
stream with music, one with actors voices, one with
commentary, one with
special effects, ...
having this split would be VERY nice, and these streams
would have alot
of large gaps which would benefit from EOR


[...]
-- 
Michael     GnuPG fingerprint:
9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or
copy any book
Today you'd get arrested for mere telling someone where the
library is
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

On Fri, Nov 24, 2006 at 09:26:00PM +0100, Ivo wrote:
> > > +    EOR frames for non-subtitle streams are
only valid at the end of
> > > the +    stream.
> >
> > It would be nice to have a note that they are
syntactically valid but
> > that they need not be interpreted for compliance
with the current
> > version of NUT and that processes generating NUT
files MUST NOT write
> > EOR for non-subtitle streams.
> 
> Perhaps:
> 
> EOR frames for non-subtitle streams are syntactically
valid, but, except
> for the last frame, they SHOULD be ignored by demuxers
and MUST NOT be
> written by muxers.

No, ignoring them is semantically incorrect. Interpreting
them should
just be completely outside the scope of the NUT 1.x spec. If
we ever
make a NUT 2.0, at that time it might or might not make
sense to
assign the natural meaning to them, but I'd be inclined
against it
still.

In any case there's no reason to make any specification
about what a
demuxer should do when it encounters data that's forbidden
by the
requirements on the muxer. It's as stupid as the #1
spam-friendly
contradiction in ESMTP RFC, which says that the sender must
use a
valid name in HELO, but also mandates that receiver must
accept any
syntactically correct name in HELO...

Rich

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

On Sat, Nov 25, 2006 at 12:03:55AM +0100, Michael
Niedermayer wrote:
> [...]
> > 
> > > * nut files with EOR cannot be converted to
other containers or more
> > >   correctly you cannot seek correctly in the
resulting file
> > 
> > Not true.
> 
> wait, EOR is "absolutely needed" and it works
in containers which dont have
> EOR, how can both be true?

Other containers don't support correct seeking with
subtitles unless
they have an index of all subtitles. NUT's back_ptr is the
mechanism
by which NUT makes this possible, but without EOR it will
ruin seeking
in files without extremely frequent subtitles.

> just try:
> 
> Sub: K                                   K
> Vid: KFFFFKFF..1hour..KFFFFKFF..1hour..KFFF
> 
> you can either
> A. ignore the subs and seek purely based on the video
stream (will not
>    display subs after seeking)
> B. seek to previous keyframe of all streams (will not
allow you to seek
>    into the 2 hour segment without sub keyframes

Having the same subtitle displayed for 2 hours duration (or
even more
than 5-10 seconds duration) is nonsense. If you meant for
the subtitle
at the beginning in your example to only be briefly
displayed, then no
subs for the next 2 hours, EOR is what allows NUT to
accomplish that!

The only other possibilities are to give up on your correct
seeking
with subtitles (which you seemed to want the most of any of
us) or
throw in thousands of fake empty keyframes.

BTW, for subtitles, EOR is nothing more than a fake empty
keyframe
after every syncpoint. It's just a shorthand notation where
they don't
actually have to be stored, and it makes it easier (with
index, at
least) to find all the actual _real_ subtitle frames if you
want to
extract them.

> > > * lav* does not support it (and i dont plan
to change that), for lav*
> > >   gaps are not allowed, you will have to
encode black/silence/no subs
> > >   keyframes (which require only negligible
storeage anyway)
> > 
> > The nut muxer should automatically generate EOR
for subtitles and not
> > use it anywhere else (except perhaps eof). Just
repeating an 'empty'
> > subtitle every few seconds is an ugly hack.
> 
> IMHO EOR is a ugly hack, puting keyframes where you
want to seek to is
> the correct thing to do

No, flooding the stream with a bunch of fake subtitle
keyframes is the
ugly hack. It's a huge waste of bandwidth and requires
_more_ special
casing by the muxer, not less. EOR is very simple to handle
and fits
in with all the existing semantics. That's why we were able
to add it
when the issue came up.

> also if you have a special case for "whole screen
transparent" then why
> not for black frames or no audio? or gray frames or
white frames ...
> this does make at least as much sense as for subtitles,
think of a audio
> stream with music, one with actors voices, one with
commentary, one with
> special effects, ...
> having this split would be VERY nice, and these streams
would have alot
> of large gaps which would benefit from EOR

They would, that's why I don't want to rule out supporting
it in the
future. But at this time it seems utterly incompatible with
most
player designs, and mandating support for it seems like a
bad idea. I
wouldn't mind offering support in an "advanced
profile" or something,
but I don't know if we want to go there yet... It seems like
we could
at least wait until the NUT 1.0 spec is out the door to
start worrying
about more advanced profiles that could be difficult for
existing
players to support...

Rich

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel