# HG changeset patch
# User michael
# Date 1163770365 0
# Node ID dc1a02e98cb69d2e22f1ef662cd5cd727c09a24e
# Parent  a8651041ba2b40d99a04c39a9b41480bda0aefc9
clarify syncpoint placement recommanditions
(note i would also like to add a "there MUST be 1 syncpoint per second" rule)

diff -r a8651041ba2b -r dc1a02e98cb6 DOCS/tech/nut.txt
--- a/DOCS/tech/nut.txt	Fri Nov 17 12:44:10 2006 +0000
+++ b/DOCS/tech/nut.txt	Fri Nov 17 13:32:45 2006 +0000
@@ -920,9 +920,19 @@
 
 Note, more complicated seeking methods exist which are capable of quickly
 seeking to the optimal point in the presence of an index even if only a
-subset of all streams are active but a muxer SHOULD place syncpoints,
-and keyframes if it can affect the placement of keyframes so that simple
-low complexity seeking works with fine granularity
+subset of all streams is active
+
+A muxer SHOULD place syncpoints so that that simple low complexity seeking
+works with fine granularity, that is syncpoints should be placed prior
+to keyframes instead of non keyframes and with high enough frequency 
+(once per second unless there are no keyframes between this and the previous
+syncpoint)
+
+encoders SHOULD place keyframes so that the number of points where all
+streams have a keyframe at the same time is maximized, this ensures that
+seeking (complicated or not) does not need to demux and decode significant
+amounts of data to reach a point where a presentable frame for each stream
+is available after seeking
 
 
 Semantic requirements: