1.		Questions about Motion JPEG (MJPEG) (and MJPEG AVI)

1.1		What is MJPEG?

MJPEG stands for Motion JPEG and is basically video encoded as a
series of JPEG compressed images.  Unfortunately, it is not a proper
rigorously defined standard like MPEG.  For a start MJPEG really only
says frames of video are encoded as JPEG.  To package them together
into a sequence with audio and synchronisation information a "carrier"
format is needed.  This is typically either Microsoft's "AVI" or
Apple's Quicktime format.

1.2 I've created an MJPEG AVI or Quicktime file with mjpegtools but it
won't play on my Windows/MacOS machine (or vice versa!).

The Problem is that lack of rigorous definition of MJPEG.  The JPEG
format has a lot of options and, due to the need for speed, the JPEG
encoders/decoders used in MJPEG codecs only support a small subset.
Worse, the different codecs support different subsets.   Its a pain!

1.3	   Why is there a 2GB file-size restriction on individual AVI files
created using mjpegtools?

The original AVI format is inherently limited to files no larger than
2GB as certain internal pointers are only held as 32-bit values.  The
"OpenDML" extensiojns subsequently extended the format to support much
larger files.  Unfortunately, the mjpegtools do not currently support
this format.  

1.4	   How do I get around the 2GB file-size restriction on individual AVI files created using mjpegtools?

The work-around is to use Quicktime or multiple AVI files.  All the
mjpegtools will work with a seq of AVI's just as happily as they would
with a single file.  To create a sequence of AVI's using lavrec you
use a pathname pattern rather than a pathname.  A "%d" in the pathname
you specify is replaced by a sequence number (1,2,3,4,5,6) and so on
and files created as needed.

2.		Questions about MPEG VCD, SVCD and DVD

2.1		What is the difference between MPEG-1 and MPEG-2.

MPEG-2 is (basically) a superset of MPEG-1 that is much more flexible
in terms of data-rates and formats and can handle interlaced video.
There's more to it than that but most of the the other differences
relate to support for digital TV broadcasting.

2.2	   How does MPEG-1/MPEG-2 compare to MPEG-4 video (or "DivX")

The MPEG-4 video compression standard provides somewhat better
compression at low-to-medium bit-rates (up to around 1Mbps).
Basically, MPEG-4 still gives useful pictures where MPEG-1 or MPEG-2
would start to break down. To do this it has special encoding modes
for efficiently encoding subsampled (down-scaled) images and for
masking the artefacts caused by very low data-rate encoding.  At
higher data-rates these features aren't really needed and bring
relatively little. MPEG's own figures suggest MPEG-4 gains about 15%
over MPEG-1/2 at around 1MBps,  more at lower rates less and between 5-10%
at datarates above 2Mbps.

These figures are, however, for encoders working with comparable
parameters.  One reason why DivX seemed to be such a big leap over
MPEG-1 was that most MPEG-1 encoders generated very conservative
MPEG-1 like that used for standard VCD disks. When encoding for a
Software decoder running on a computer lots of extra MPEG features can
be used to improve compression.  Top amoungst these is the use of variable bit
rate encoding and assuming large buffers in the decoder.

Basically, if you want to put an acceptable quality encoding of a
Movie onto 1 CD MPEG-4 is the sensible choice.  If you want higher
quality and are willing to use 2 CD's or more MPEG-1/2 will work at
least as well and will allow you to use VCD and SVCD formats that can be
played on DVD players.

If you need to encode interlaced material at high quality MPEG-2 is a
sensible choice because MPEG-4 cannot encode interlaced video
directly.  It needs it to be deinterlaced first.


2.3	 What is this "multiplexing" business?

An MPEG video stream (as found say on a DVD) is actually one or more
video streams proper interleaved with one or more audio streams in a
special carrier format.  The carrier format also holds the
synchronisation and timing information needed to deliver the audio and
video data to the decoder at just the right time to avoid glitches
without overflowing its memory buffers. Multiplexing takes the video
and audio streams specified and wraps them up in the carrier format
(generating the synchronisation and timing information as it goes).
The latest versions of the multiplexer "mplex" don't actually need
intermediate files for the video and audio streams.  You can feed them
direct from the encoders via fifo's (named pipes - see the "mkfifo" command).
See 4.3


2.4	   Why do I need to use special settings to encode and multiplex MPEG
for VCD, SVCD or DVD.

The MPEG standards are *huge* with many rarely-used or even downright
exotic options.  For use in consumer disk players particular narrowly
defined subsets of MPEG were specified that also added additional
features (e.g. Dolby Digital and DTS audio for DTS) and special
extensions for the disk application (e.g. subtitle images).
Unfortunately, consumer electronics people being who they are the
standards also specify some things that are very "unnatural".  You
have to tell the encoder

2.5 Can I capture video and compress it so that I can burn it to CD
and play it in my DVD player?

Your best bet is probably to compress it as an SVCD stream and use the
"vcdimager" program to create the burnable CD image. Many current DVD
players can play SVCD format CDs.  Unfortunately, there's currently no
free authoring software that would allow the same to be done for
DVD-format MPEG.  Hopefully, this will change someday.

2.6 I've just encoded a huge MPEG file on my P133 an it took *ages*.
    Is there any way I can split it to fit ontp VCD's without re-encoding?

In theory this is sort-of possible.  In practice there aren't any free
tools around that can do the fine surgery on the synchronisation
information and copying of headers that would be necessary.  If you
want to play back using a computer the best solution is simply to
split the file for storage and join it again for playback.


3.		Questions about the MJPEG and audio drivers.

3.1		I've got a Buz card and I just can get it to capture without lots
of dropped frames.

Unfortunately, some aspects of the Buz design make it very sensitive
to devices that share or affect the computer's PCI bus that behave
less-than-perfectly.  The extent of the problems depend both on the
quality of the BIOS and the mainboard chipset.  VIA-based mainboards
are generally particularly awkward in this respect.  The DC10(+) and LML33
boards are much less sensitive than the Buz.


3.2	   I can capture nicely if I disable audio (-a 0 to lavrec) but bad things happen if I enable it.

Unfortunately, the quality of Linux audio drivers *recording*
facilities can still be very patchy.  Especially, the "mmap"
programming interface that lavrec prefers to use.  Often simply
telling it to use the (slightly less accurate) "read" interface fixes
the problem.  Sometimes, the driver is just plain broken and the only
solution is to wait for the problem to be fixed or to get another
sound card.


4.	  Questions about MPEG encoding with mjpegtools

4.1	  Damn!  When I burn an SVCD my player plays trash.

	  Unfortunately, the quality of the firmware for SVCD in many DVD
	  players for markets outside Asia is rather poor.  Various nasty
	  little bugs can cause SVCD to fail to play back.  To help
	  the unfortunates with such players there some special bug fix flags.

	  --correct-svcd-hds

	  May help 16:9 streams to play back correctly on correct players.
	  This is not on by default because it breaks all SVCD playback on many
	  players

	  --no-altscan-mpeg2

	  Some players seem not be able to cope with the "alternative"
	  pattern for scanning pixel blocks that MPEG2 supports.  This
	  flag forces mpeg2enc to use only the less efficient "normal" pattern.


4.2	  When I encode stuff it is just too damn slow how can speed things up?

	  o If you're encoding MPEG2 (-f 3,4,5 and 8) and encoding
	  non-interlaced video (e.g. movies) you then you can make big
	  speed gains by switching off the special calculations needed for
	  encoding moving interlaced scenes by setting '-I 0'.  Note that
	  even for interlaced material it is faster to deinterlace and encode
	  deinterlaced video than encode with interlaced support.  However, this
	  can cause some quality loss (it depends a lot on the source material). 

	  o You can trade (very modest) reduction in compression for significant
	  speed gains by using the -4 and -2 flags.

	  o If you have a long processing pipeline with scaling and
	  denoising then these tasks take about as much CPU as the MPEG
	  encoding itself.  If you split the work across several CPU's
	  either in a multi-processor machine or using a fast network then
	  things can go much faster.

	  E.g. if you have the a remote shell login daemon running on
	  machine1

	  rsh machine1 "lav2yuv blah.avi | yuvdenoise ... | yuvscale ..." \
		 | mpeg2enc ...

	  will split the work between the machine you're working on machine1.
	  The best way to split the work depends of course on the relative speeds
	  of the machines.   If you have more than two machines you can split the
	  work even more.  Later release of the mjpegtools will probably gain a
	  special "network pipe" mode for maximising efficiency with this kind of
	  setup.

	  Even if you're only doing "lav2yuv | mpeg2enc" for MJPEG some gains may be
	  possible using this approach as MJPEG decoding takes a not insignificant
	  amount of time.

	  o If you have a multi-processor machine and its not running at full load
	  during encoding you can tell mpeg2enc to run multiple encoding threads
	  using the -M flag.  Here's what I do when encoding on a pair of dual
	  P-III machines:

	  rsh machine1 "lav2yuv ... | yuvdenoise ... " | mpeg2enc -M 2 ...

4.3	  How can I avoid those space-hogging intermediate files generated by
	  mpeg2enc and the MPEG audio encoder?

	  The mplex multiplexer can accept data from fifo's (named pipes)
	  as well as intermediate files.  This means you can directly pipe
	  the output of the MPEG audio and video encoders in mplex and
	  generate the final multiplexed MPEG stream directly.  The recipe if 
	  you're using "mp2enc" for audio encoding is as follows:

	  mkfifo audio
	  mkfifo video
	  ... mpeg2enc ... -o video &
	  ... mp2enc ... -o audio &
	  mplex ... audio video -o audvid.mpg
	  rm audio
	  rm video

	  Easy isn't it!


5.	  Question about Digital Video in General