returning to the old index at the end system, alternatives are too complex with questionable advantages

git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@14920 b3059339-0415-0410-9bf9-f77b7e298cf2

1 files changed, 14 insertions, 32 deletions

diff --git a/DOCS/tech/mpcf.txt b/DOCS/tech/mpcf.txt
index 83d9e656d0..9341d463ae 100644
--- a/DOCS/tech/mpcf.txt
+++ b/DOCS/tech/mpcf.txt
@@ -119,7 +119,7 @@ main header:
 	version					v
 	stream_count				v
 	max_distance				v
-	index_distance				v
+	max_index_distance			v
 	global_time_base_nom			v
 	global_time_base_denom			v
 	for(i=0; i<256; ){
@@ -160,8 +160,6 @@ stream_header:
 	time_base_denom				v
 	msb_timestamp_shift			v
 	decode_delay				v
-	index_modulo				v
-	index_increment				v
 	fixed_fps				u(1)
 	reserved				u(6)
 	codec_specific_data			vb
@@ -205,7 +203,6 @@ index:
 	index_startcode				f(64)
 	packet header
 	stream_id				v
-	index_id				v
 	index_length				v
 	for(i=0; i<index_length; i++){
 		index_timestamp			v
@@ -242,7 +239,7 @@ sync_point:
 
 file:
 	file_id_string
-	while(!eof){
+	while(!eof && next_code != index_startcode){
 		main_header
 		for(i=0; i<stream_count; i++){
 			if(next_packet==video_stream_header)
@@ -253,15 +250,14 @@ file:
 		while(next_code != main_startcode){
 			if(next_code == info_startcode)
 				info_packet
-			else if(next_code == index_startcode){
-				index
-			}else{
+			else{
 				if(next_code == frame_startcode)
 					sync_point
 				frame
 			}
 		}
 	}
+	index
                 
 
 
@@ -309,30 +305,12 @@ max_distance
 	good reason to set it higher otherwise reasonable error recovery will
 	be impossible
 
-index_distance
-	distance at which indexes are approximately stored, or 0 if there are
-	no indexes in the file
-	in every [x*index_distance, (x+1)*index_distance) interval, there
-	must be an index packet for every stream, and these packets must be
-	located prior to all frames within the interval
-	reasoning: this ensures good error recovery as there are many and
-	evenly distributed indexes, and also allows very quick finding of the
-	index packets
-
-index_modulo
-index_id
-	each index packet contains every index_moduloth's keyframe of a stream,
-	so the i'th keyframe of a stream will be at least in packets with 
-	(i % index_modulo) == index_id 
-	furthermore a index packet contains all indexed keyframes since the
-	last index packet
-	(indexed keyframes == keyframes which are referenced from any index 
-	packet)
-
-index_increment
-	the index_id increment value, this MUST be a relative prime to
-	index_modulo
-	index_increment / index_modulo SHOULD be approximately 2/(sqrt(5)+1)
+max_index_distance
+	max distance of keyframes which are represented in the index, the
+	distance between consecutive entries A and B may only be larger if
+	there are no keyframes within this stream between A and B
+	SHOULD be set to <=32768 or at least <=65536 unless there is a very
+	good reason to set it higher
 
 stream_id[FIXME]
 	Stream identifier
@@ -507,6 +485,9 @@ index_timestamp
 index_position
 	position in bytes of the first byte of a keyframe, relative to the
 	last keyframe stored in this index
+	there MUST be no keyframe with the same stream_id as this index between
+	2 consecutive index entries if they are more then max_index_distance
+	appart
 
 id
 	the id of the type/name pair, so its more compact
@@ -599,6 +580,7 @@ info packets which describe the whole file or individual streams/tracks must be
 placed before any video/audio/... frames
 
 		Index
+Note: in case of realtime streaming there is no end, so no index there either
 
 		Info packets
 the info_packet can be repeated, it can also contain different names & values