February 2008 - NUT-devel - lists.mplayerhq.hu

[nut] [propchange]: r595 - svn:log
by diego 10 Feb '08

10 Feb '08

Author: diego Revision: 595 Property Name: svn:log Action: modified Property diff: --- old property value +++ new property value @@ -1,2 +1,2 @@ -Fix very bad wording. The original would have if taken litterally made +Fix very bad wording. The original would have if taken literally made it impossible to store any chapters.

1 0

[nut] [propchange]: r598 - svn:log
by diego 10 Feb '08

10 Feb '08

Author: diego Revision: 598 Property Name: svn:log Action: modified Property diff: --- old property value +++ new property value @@ -1 +1 @@ -clearer sentance +clearer sentence

1 0

[nut]: r598 - docs/nutissues.txt
by michael 10 Feb '08

10 Feb '08

Author: michael Date: Sun Feb 10 17:03:59 2008 New Revision: 598 Log: clearer sentance Modified: docs/nutissues.txt Modified: docs/nutissues.txt ============================================================================== --- docs/nutissues.txt (original) +++ docs/nutissues.txt Sun Feb 10 17:03:59 2008 @@ -93,7 +93,8 @@ B. Store such edits in info packets but 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) + editing programs using nut as they would use their own formats to store + edit lists) Issue alternatives

1 0

[nut]: r597 - docs/nutissues.txt
by michael 10 Feb '08

10 Feb '08

Author: michael Date: Sun Feb 10 16:16:26 2008 New Revision: 597 Log: chapter-overlap/gap consensus? Modified: docs/nutissues.txt Modified: docs/nutissues.txt ============================================================================== --- docs/nutissues.txt (original) +++ docs/nutissues.txt Sun Feb 10 16:16:26 2008 @@ -43,6 +43,8 @@ C add a field into the info packet overr D use the chapter start of the next chapter (breaks compatibility and error robustness) +It seems the consensus is A + Issue stream-chapter-overlap ----------------------------

1 0

[nut]: r596 - docs/nut.txt
by michael 10 Feb '08

10 Feb '08

Author: michael Date: Sun Feb 10 14:44:13 2008 New Revision: 596 Log: Same timebase for info packets suggestion. Modified: docs/nut.txt Modified: docs/nut.txt ============================================================================== --- docs/nut.txt (original) +++ docs/nut.txt Sun Feb 10 14:44:13 2008 @@ -828,6 +828,8 @@ chapter_id (s) chapter_start (t) timestamp of start of chapter + 2 info packets which apply to the same subset of streams SHOULD use the + same timebase. chapter_len (v) Length of chapter in the same timebase as chapter_start.

1 0

[nut]: r595 - docs/nut.txt
by michael 10 Feb '08

10 Feb '08

Author: michael Date: Sun Feb 10 14:36:55 2008 New Revision: 595 Log: Fix very bad wording. The original would have if taken litterally made it impossible to store any chapters. Modified: docs/nut.txt Modified: docs/nut.txt ============================================================================== --- docs/nut.txt (original) +++ docs/nut.txt Sun Feb 10 14:36:55 2008 @@ -814,8 +814,8 @@ Info tags: ---------- stream_id_plus1 (v) - Stream this info packet applies to. If zero, packet applies to the - whole file. + Stream this info packet applies to. If zero, packet applies to all + streams. chapter_id (s) The ID of the chapter this packet applies to. If zero, the packet applies

1 0

Broadcasting nuts [PATCH]
by Michael Niedermayer 09 Feb '08

09 Feb '08

Hi Attached patch should make broadcast of single program nuts possible. Its the minimal/least restrictive solution i found. Comments welcome, especially from mans/nico, others who know mpeg-ps/ts. -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact

6 54

[nut]: r594 - docs/nutissues.txt
by michael 09 Feb '08

09 Feb '08

Author: michael Date: Sat Feb 9 18:12:07 2008 New Revision: 594 Log: more solutions Modified: docs/nutissues.txt Modified: docs/nutissues.txt ============================================================================== --- docs/nutissues.txt (original) +++ docs/nutissues.txt Sat Feb 9 18:12:07 2008 @@ -65,6 +65,8 @@ 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 Issue info-overhead @@ -72,6 +74,12 @@ Issue info-overhead Info can be stored much more compactly by replacing common strings by shorter represenstations. +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) +C. Leave info as it is. + Issue edit-lists ----------------

1 0

[nut]: r593 - docs/nutissues.txt nutissues.txt
by michael 09 Feb '08

09 Feb '08

Author: michael Date: Sat Feb 9 16:36:05 2008 New Revision: 593 Log: Move to proper directory ... Added: docs/nutissues.txt - copied unchanged from r592, /nutissues.txt Removed: nutissues.txt

1 0

[nut]: r592 - nutissues.txt
by michael 09 Feb '08

09 Feb '08

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

1 0