First stab at porting mplex

Original commit message from CVS:
First stab at porting mplex

1 files changed, 67 insertions, 0 deletions

diff --git a/ext/mplex/INSTRUCT b/ext/mplex/INSTRUCT
new file mode 100644
index 00000000..e75d4cfa
--- /dev/null
+++ b/ext/mplex/INSTRUCT
@@ -0,0 +1,67 @@
+//////////////////////////////////////////////////////////////////////////
+//									//
+//	INSTRUCTIONS FOR MPLEX - THE MPEG1/SYSTEMS MULTIPLEXER		//
+//									//
+//////////////////////////////////////////////////////////////////////////
+
+
+Please note that I do not have a comprehensive instruction manual for this
+release. I suggest you try the program out with some default values and
+learn something more about ISO/IEC 11172-1 (aka MPEG1/Systems).
+
+For those of you that can read *German*, you can download a postscript
+paper discussing implementation and problems of this software, with
+introductions to MPEG1/Audio, MPEG1/Video and MPEG1/Systems.
+You should find the paper with the same distribution you got this
+program from.
+
+If not, you should find the postscript version of this 40-page paper
+on
+
+ftp.informatik.tu-muenchen.de in /pub/comp/graphics/mpeg/mplex
+
+(121822 bytes, Jun 30 , 1994 , mpeg_systems_paper_0.99.ps.gz)
+
+If you have any questions you cannot figure out by running the
+program, feel free to ask me.
+
+--------------------------------------------------------------------------
+
+One more thing that might save me many emails:
+
+when asked about the startup packet delay, try something like
+half the video buffer size divided by your sector size. Say you
+have a 40 kByte video buffer and a 2324 Byte Sector size, then
+a startup delay of 8 sectors will work just fine.
+
+What does the above parameter mean?
+
+Normally, the Decoding/Presentation Time Stamp of the first access
+unit is set to the clock value that will happen exactly after the last
+packet containig data from this first unit arrives into the system
+target decoder. This works fine if the video/audio streams are of
+*very perfectly constant* or the packet size are *very* small
+(ideally: the size of one access unit, that would mean variable
+packet length).
+Anyway: this parameter allows you to say that the System Target
+Decoder should start decoding the first access unit after he
+gets (startup_packet_delay + size_of_first_access_units[av])
+packets of data.
+This guarantees that the buffers are conveniently filled up.
+Note that both the video stream offset and audio stream offset (ms)
+add up even more bytes to this startup delay, but you can
+tell conveniently that audio should start so many ms after video,
+for example.
+
+Sorry for no further doc, enjoy multiplexing A/V :)
+
+Christoph.
+
+moar@heaven.zfe.siemens.de
++---------------------------------------+--------------------------------+
+| http://www.informatik.tu-muenchen.de/ |                 Christoph Moar |
+| cgi-bin/nph-gateway/hphalle6/~moar/   |                Kaulbachstr.29a |
+| index.html                            |                   80539 Munich |
+| email:moar@informatik.tu-muenchen.de  |   voice: ++49 - 89 -  23862874 |
++---------------------------------------+--------------------------------+
+