By Diego - punctuation and other important cosmetics to nut.txt

It also includes some FIXME's he added... (I'm sending this
patch for him 
due to mail server down...)

- ods15

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

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

Hi

On Sat, Feb 24, 2007 at 01:28:46PM +0200, Oded Shimon
wrote:
> It also includes some FIXME's he added... (I'm sending
this patch for him 
> due to mail server down...)
> 
> - ods15

[...]

>  keyframe
>      A keyframe is a frame from which you can start
decoding, a more
>      exact definition is below
> -    The nth frame is a keyframe if and only if frames
n, n+1, ... in 
> -    presentation order (that are all frames with a pts
>= frame[n].pts) can
> +    The nth frame is a keyframe if and only if frames
n, n+1, ... in
> +    presentation order (that means all frames with a
pts >= frame[n].pts) can
>      be decoded successfully without reference to
frames prior n in storage
> -    order (that are all frames with a dts <
frame[n].dts)
> -    if no such frames exist (for example due to use of
overlapped transforms
> -    like the MDCT in an audio codec) then the
definition shall be extended
> +    order (that means all frames with a dts <
frame[n].dts).
> +    If no such frames exist (for example due to use of
overlapped transforms
> +    like the MDCT in an audio codec), then the
definition shall be extended
>      by dropping n out of the set of frames which must
be decodable, if this

iam against this change


[...]
> +FIXME: The frame_code description is convoluted and
incomprehensible.
>  frame_code (f(8))
>      frame_code is an 8-bit field which exists before
every frame, it can
>      store part of the size of the frame, the stream
number, the timestamp
> -    and some flags amongst other things, what is not
directly stored
> -    in it but is needed is stored in various fields
immediately after it
> -    the values stored in it can be found in the main
header
> -    the value 78 ('N') is forbidden to ensure that the
byte is always
> -    different from the first byte of any startcode
> -    a muxer SHOULD mark 0x00 and 0xFF as invalid to
improve error
> -    detection
> +    and some flags amongst other things. What is not
directly stored
> +    in it but is needed is stored in various fields
immediately after it.
> +    The values stored in it can be found in the main
header.
> +    The value 78 ('N') is forbidden to ensure that the
byte is always
> +    different from the first byte of any startcode.
> +    A muxer SHOULD mark 0x00 and 0xFF as invalid to
improve error
> +    detection.

i cant clarify it unless you are more specific


[...]

> +FIXME: What does "at the frame header"
mean?
> +       5  FLAG_SIZE_MSB    If set data_size_msb at the
frame header,
> +                           otherwise data_size_msb is
0

if set data_size_msb is coded/stored at the frame header,
otherwise data_size_msb is 0


[...]
> +FIXME: What is a 'sub region'?
> +    A negative chapter_id indicates a sub region of
the file and not a real
>      chapter. chapter_id MUST be unique to the region
it represents.

s/sub region/region/


[...]
> +FIXME: Does this have to be lowercase?
>      "SourceContainer"
>          "nut", "mkv",
"mov", "avi", "ogg",
"rm", "mpeg-ps", "mpeg-ts",
"raw"

yes we would have to unfreeze the spec and break
compatibility to change it
and i prefer lower case anyway 


[...]
> +FIXME: Does the following line have a meaning here?
>          the language code

no


[...]
> +FIXME: This description is confusing, after 2^x *and*
end of file???
>  Each set of repeated headers not at the beginning or
end of the file SHOULD
> -be stored at the earliest possible position after 2^x
where x is
> -an integer and the file end, so the headers may be
repeated at 4102 if that is
> -the closest position after 2^12=4096 at which the
headers can be placed
> +be stored at the earliest possible position after 2^x
where x is an integer
> +and the end of the file. So the headers may be
repeated at 4102 if that is
> +the closest position after 2^12=4096 at which the
headers can be placed.

Each set of repeated headers not at the beginning or end of
the file SHOULD
be stored at the earliest possible position after 2^x where
x is an integer.

And at the end of the file. So the headers may be repeated
at 4102 if that is
the closest position after 2^12=4096 at which the headers
can be placed.

yeah i know its not well said, i just splited it to make the
intent clear ...


[...]
>  
> -in the absence of a valid header at the beginning,
players SHOULD search for
> +FIXME: Where is the syncpoint included?
> +In the absence of a valid header at the beginning,
players SHOULD search for
>  backup headers starting at offset 2^x; for each x
players SHOULD end their
> -search at a particular offset when any startcode is
found (including syncpoint)
> +search at a particular offset when any startcode is
found (including syncpoint).

in the set of startcodes at which the demuxer should stop

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

There will always be a question for which you do not know
the correct awnser.

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

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

On Sat, Feb 24, 2007 at 01:25:54PM +0100, Michael
Niedermayer wrote:
> Hi
> 
> On Sat, Feb 24, 2007 at 01:28:46PM +0200, Oded Shimon
wrote:
> > It also includes some FIXME's he added... (I'm
sending this patch for him 
> > due to mail server down...)
> > 
> > - ods15

This is a lighter patch which is supposed to be only
cosmetic 
captilization and punctuation. I did not go over it
thoroughly.

- ods15

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

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

Hi

On Sat, Feb 24, 2007 at 10:39:49PM +0200, Oded Shimon
wrote:
> On Sat, Feb 24, 2007 at 01:25:54PM +0100, Michael
Niedermayer wrote:
> > Hi
> > 
> > On Sat, Feb 24, 2007 at 01:28:46PM +0200, Oded
Shimon wrote:
> > > It also includes some FIXME's he added...
(I'm sending this patch for him 
> > > due to mail server down...)
> > > 
> > > - ods15
> 
> This is a lighter patch which is supposed to be only
cosmetic 
> captilization and punctuation. I did not go over it
thoroughly.

[...]
>  Features / goals:
>      (supported by the format, not necessarily by a
specific implementation)
>  
> -Simple
[...]
> +Simplicity
[...]
>  
> -Extendible
[...]
> +Extensibility
[...]
> -Compact
[...]
> -    a usual header for a file is about 100 bytes
(audio + video headers together)
[...]
> +Compactness
[...]
> +    A typical file header is about 100 bytes (audio +
video headers together).
[...]
> -    resync times
[...]
> +    resynchronization times.

while ive no immedeate objections to the ones above its not
just 
captilization and punctuation

so did you send the correct patch?

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

No snowflake in an avalanche ever feels responsible. --
Voltaire

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

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

On Sat, Feb 24, 2007 at 11:31:39PM +0100, Michael
Niedermayer wrote:
> On Sat, Feb 24, 2007 at 10:39:49PM +0200, Oded Shimon
wrote:
> > This is a lighter patch which is supposed to be
only cosmetic 
> > captilization and punctuation. I did not go over
it thoroughly.
> 
> [...]
> >  Features / goals:
> >      (supported by the format, not necessarily by
a specific implementation)
> >  
> > -Simple
> [...]
> > +Simplicity
> [...]
> >  
> > -Extendible
> [...]
> > +Extensibility
> [...]
> > -Compact
> [...]
> > -    a usual header for a file is about 100 bytes
(audio + video headers together)
> [...]
> > +Compactness
> [...]
> > +    A typical file header is about 100 bytes
(audio + video headers together).
> [...]
> > -    resync times
> [...]
> > +    resynchronization times.
> 
> while ive no immedeate objections to the ones above its
not just 
> captilization and punctuation
> 
> so did you send the correct patch?

I did. I understated what the patch does... It is a bit more
than just 
captilization and punctuation, but it supposed to have no
significant 
changes.

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

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

Hi

On Sun, Feb 25, 2007 at 07:47:17PM +0200, Oded Shimon
wrote:
> On Sat, Feb 24, 2007 at 11:31:39PM +0100, Michael
Niedermayer wrote:
> > On Sat, Feb 24, 2007 at 10:39:49PM +0200, Oded
Shimon wrote:
> > > This is a lighter patch which is supposed to
be only cosmetic 
> > > captilization and punctuation. I did not go
over it thoroughly.
> > 
> > [...]
> > >  Features / goals:
> > >      (supported by the format, not
necessarily by a specific implementation)
> > >  
> > > -Simple
> > [...]
> > > +Simplicity
> > [...]
> > >  
> > > -Extendible
> > [...]
> > > +Extensibility
> > [...]
> > > -Compact
> > [...]
> > > -    a usual header for a file is about 100
bytes (audio + video headers together)
> > [...]
> > > +Compactness
> > [...]
> > > +    A typical file header is about 100 bytes
(audio + video headers together).
> > [...]
> > > -    resync times
> > [...]
> > > +    resynchronization times.
> > 
> > while ive no immedeate objections to the ones
above its not just 
> > captilization and punctuation
> > 
> > so did you send the correct patch?
> 
> I did. I understated what the patch does... It is a bit
more than just 
> captilization and punctuation, but it supposed to have
no significant 
> changes.

well if thats true then iam fine with zhe patch

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

Everything should be made as simple as possible, but not
simpler.
-- Albert Einstein

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

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