[NUT-devel] [nut]: r592 - nutissues.txt

[michael]

Author: michael
Date: Sat Feb  9 16:34:54 2008
New Revision: 592

Log:
List of known issues, so we can keep track of what might need work and
what can be done to solve issues. And what the advantages / disadvantages
the solutions have.


Added:
   nutissues.txt

Added: nutissues.txt
==============================================================================
--- (empty file)
+++ nutissues.txt	Sat Feb  9 16:34:54 2008
@@ -0,0 +1,97 @@
+Issue broadcast-clock-sync
+----------------
+Problem: Clock synchronization leading to buffer overflow and underflow
+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.
+
+Solutions to the above 2 issues are for example storing one of the following
+A. preload time
+B. preload bytes
+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
+bandwidth but instead increase the needed buffer size.
+
+These can be stored in one of the following
+a. sync points
+b. info packets
+c. a new stream type
+
+Info packets are currently not allowed to change thus they are not suitable
+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.
+
+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
+  more accurate value.
+D use the chapter start of the next chapter (breaks compatibility and
+  error robustness)
+
+
+Issue stream-chapter-overlap
+----------------------------
+It is possible especially in the light of the precission 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?
+
+
+Issue info-stream-subsets
+-------------------------
+Currently if info applies to more than 1 stream but not all, it has to be
+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.
+
+Solutions:
+A. one backptr per program + any solution for issue info-stream-subsets
+
+
+Issue info-overhead
+-------------------
+Info can be stored much more compactly by replacing common strings by
+shorter represenstations.
+
+
+Issue edit-lists
+----------------
+For editing its very usefull 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
+   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)
+
+
+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.
+
+Solutions
+A. Store such alterative play lists of scenes in info packets somehow
+B. Design a seperate layer for it
+C. Dont support this