//////////////////////////////////////////////////////////////////////////
//									//
//	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 |
+---------------------------------------+--------------------------------+