[NUT-devel] [nut]: r601 - docs/nutissues.txt

[diego]

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.