Author: diego
Date: Sun Feb 10 20:49:49 2008
New Revision: 601
Log:
spelling/wording/grammar
Modified:
docs/nutissues.txt
Modified: docs/nutissues.txt
============================================================
==================
--- docs/nutissues.txt (original)
+++ docs/nutissues.txt Sun Feb 10 20:49:49 2008
 -6,8
+6,8 in the decoder.
Issue broadcast-preload-len
---------------------------
-Problem: How long should the receiver preload the nut file
before starting
-playback and after seeking, so no buffer over/underflows
happens.
+Problem: How long should the receiver preload the NUT file
before starting
+playback and after seeking, so no buffer over/underflow
happens.
Solutions to the above 2 issues are for example storing one
of the following
A. preload time
-16,9
+16,9 C. buffer fullness in seconds
D. buffer fullness in bytes
E. transmit time stamps
-Values in bytes scale nicer with increased bandwidth, that
is doubling the
-bandwidth from the one assumed by the muxer halfs the
needed preload. Time
-based sync values dont naturally change the needed preload
with increased
+Values in bytes scale nicer with increased bandwidth, that
is, doubling the
+bandwidth from the one assumed by the muxer halves the
needed preload. Time
+based sync values do not naturally change the needed
preload with increased
bandwidth but instead increase the needed buffer size.
These can be stored in one of the following
-33,22
+33,22 without that being changed.
Issue chapter-overlap/gap
-------------------------
If one changes the timebase between chapters then overlaps
(forbidden by the
-spec) or gaps (problematic with split&merge) can
happen.
+spec) or gaps (problematic with split & merge) can
happen.
Solutions:
-A. dont change the timebase
-B. store start and end in seperate timebases (breaks
compatibility)
-C. add a field into the info packet overriding the
chapter_end with a
+A. Do not change the timebase.
+B. Store start and end in separate timebases (breaks
compatibility).
+C. Add a field into the info packet overriding the
chapter_end with a
more accurate value.
-D. use the chapter start of the next chapter (breaks
compatibility and
- error robustness)
+D. Use the chapter start of the next chapter (breaks
compatibility and
+ error robustness).
-It seems the consensus is A
+It seems the consensus is A.
Issue stream-chapter-overlap
----------------------------
-It is possible especially in the light of the precission of
the previous
+It is possible especially in the light of the precision of
the previous
issue, that chapters might not end exactly at the same
points in time in
all streams. There could be a few samples difference.
Do we care about this?
-63,47
+63,47 duplicated for each stream it applies to
Issue multiple-programs
-----------------------
Multiple programs (that is several audio-video stream pairs
for example) can
-not be stored cleanly in nut.
+not be stored cleanly in NUT.
Solutions:
A. one backptr per program + any solution for issue
info-stream-subsets
-B. Design a seperate layer for it
-C. Dont support this
+B. Design a separate layer for it.
+C. Do not support this.
Issue info-overhead
-------------------
Info can be stored much more compactly by replacing common
strings by
-shorter represenstations.
+shorter representations.
Solutions:
A. Change syntax so a v value which indexes into a fixed
table can select
info names. (breaks compatibility completely)
B. Use/allow 1 char abbreviations (new demuxers could read
old files, old
- ones could read everything except the abbreviated
fields)
+ ones could read everything except the abbreviated
fields).
C. Leave info as it is.
Issue edit-lists
----------------
-For editing its very usefull to not rewrite the whole file
after every step.
+For editing it is very useful to not rewrite the whole file
after every step.
Solutions:
-A. Store such edits in info packets
-B. Store such edits in info packets but allow them only in
"private" nut
+A. Store such edits in info packets.
+B. Store such edits in info packets but allow them only in
"private" NUT
files. That is files distributed must be remuxed.
Players must reject
files with edit lists.
-C. Dont support this (this would mean no interoperability
between video
- editing programs using nut as they would use their own
formats to store
- edit lists)
+C. Do not support this (this would mean no interoperability
between video
+ editing programs using NUT as they would use their own
formats to store
+ edit lists).
Issue alternatives
------------------
Alternatives like a variant without some scenes or with a
happy ending
-instead of a tragic one cannot be stored in nut currently.
+instead of a tragic one cannot be stored in NUT currently.
Solutions:
-A. Store such alterative play lists of scenes in info
packets somehow
-B. Design a seperate layer for it
-C. Dont support this
+A. Store such alternative playlists of scenes in info
packets somehow.
+B. Design a separate layer for it.
+C. Do not support this.
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel
|
