[NUT-devel] [nut]: r167 - trunk/docs/nut-english.txt

[ods15]

Author: ods15
Date: Sat Oct 28 21:08:46 2006
New Revision: 167

Modified:
   trunk/docs/nut-english.txt

Log:
add error checking


Modified: trunk/docs/nut-english.txt
==============================================================================
--- trunk/docs/nut-english.txt	(original)
+++ trunk/docs/nut-english.txt	Sat Oct 28 21:08:46 2006
@@ -247,3 +247,28 @@
 syncpoint when seeking. Demuxing can only begin at syncpoints for proper
 last_pts context across all streams, including after seeking.
 back_ptr is explained in greater detail in the Seeking section.
+
+Error Checking
+
+There are several ways to detect a damaged stream in NUT during demuxing:
+1. Invalid framecode - If a framecode which has been marked as invalid in
+   the main header is found as the framecode in a frame header, then the
+   stream is damaged. For this reason, 0x00 and 0xFF are recommended to be
+   set as invalid frame codes in NUT.
+2. Bad CRC on a NUT packet, packet_header, or frame header - fairly
+   obvious.
+3. Decoded frame size causes a distance from the last syncpoint to be
+   bigger than max_distance, and frame does not follow a syncpoint.
+4. Decoded frame size is bigger than max_distance*2, and frame header does
+   not have a CRC.
+5. Decoded frame pts is more than max_pts_distance higher than last_pts,
+   and frame header does not have a CRC.
+6. A VLC is found with more than 8 bytes of stuffing in a frame header or
+   forward_ptr.
+7. Streams are found to not be strictly interleaved by comparing dts and
+   pts - a precise formula for this check can be found in the spec.
+
+All these conditions make it impossible for a demuxer to read, skip or
+buffer a large amount of data from a file because of damaged data. Also
+max_pts_distance prevents an overly large pts caused by damaged data to
+cause a player to get stuck.