(0) If you're just starting run, don't walk to the HOWTO.
There's a text copy mjpeg_howto.txt where you found this file.
Its online at http://sourceforge.net/docman/?group_id=5776.
If you're interested in the source-code and what's buried there
read the README's. There's a lot of useful info buried in there...
There are specialist README's for mpeg2enc and mplex in the corresponding
sub-directories as well as the general README in the top directory.
The scripts directory contains shell scripts that provide
a convenient interface for common tasks.
E.g. lav file (editlist, avi, quicktime) -> MPEG for disk
storage, VCD or SVCD.
(1) VCD and SVCDs.
VCD's have very specific requirements as to the format of the
multiplexed systems stream. For VCD these are actually at least
"bendings" of the original MPEG standard and are far from optimal
as far as maximising possible quality for software decoding goes.
The simplest way to generate VCD and SVCD streams that can be burnt to CD
and played using DVD players etc is to use the lav2mpeg script
with the "-V" and "-S" flags.
If you want to play around a couple of hints.
To build a VCD you absolutely *must* used the VCD format
option for mplex "-f 1". This turns on a lot of weird stuff that
otherwise has no place in a respectable multiplexer!
Obviously, to play on all players your original MPEG video must be the
standard 1151Kbps and audio must be 224Kbps MPEG-1 layer 2 (as produced by
the "-v" flag of mp2enc.
The systems streams generated by "-f 1" have been tested and succesfully
burned onto CD using vcdimager and vcdburn.
An SVCD video stream is variable bit-rate MPEG-2
with a maximum rate of around 2500Kbps and a video buffer size of
230KB. Currently I recommend encoding -m 2 -F 3 or (for
progressive material like PAL films) -m 2 -F 0. -F 1 and -F 2
will work but are currently handicapped by rather dumb code to
choose the type of motion compensation. I have some suspicions
that the rate control code and multiplexer needs adjusting for
field sequences (-m 2 -F 1 and -F 2) also. To generate a legal S
VCD program stream with mplex use the "-f 3" flag.
(2) For transcoding existing MPEG-2 streams from digital TV cards or
DVD a still lower data-rate than for broadcast will give good
results. Standard VCD 1152 Kbps typically works just fine for
MPEG1. The difference is in the Signal/Noise ratio of the
original. The noise in the analog stuff makes it much
harder to compress.
You will also need to manually adjust the audio delay offset
relative to video when multiplexing. Very often around 150ms
delay seems to do the trick.
(3) If you want to play MPEG1 on hardware decoders don't build variable
bit-rate video streams. If you intend to use software players
variable bit-rate is a much more efficient way of encoding and
guarantees decent quality. All in all a *much* better
bet. The code for the "-S" (SVCD) flags in the lav2mpeg script shows
an example for typical usage.
Buffer sizes. For hardware players experimentation is the order
of the day. My DXR2 seems to use a nice big > 100K buffer for
VCD as well as DVD streams and be happy to read MPEG-1 streams
*much* faster than the official VCD 170K/sec. 300K seems fine.
Generally, you'll probably need a buffer size of around 1/4
data-rate to avoid buffer underflows (signalled as "TO<framenum>"'s
by mplex).
(4) If you want to play MPEG-1 stuff on hardware decoders stick to
44.1 224Kbps Stereo layer-2 audio. The 100Kbps or so maximum you'll gain
using MP3 aren't going to make a visible difference to video anyway.
(5) If you want to reduce bit-rate without annoying artefacts when
compressing broadcast material you should try the noise filters.
(6) Storing MPEG's. If you record the data as XA mode 2 tracks you
can fit appreciably more on a CD (at the expense of error
correction/detection). You can use vcdimager to do this and readvcd
to extract the resulting files.
(6) For MPEG-1 encoding a typical (45 minute running time) show or 90 odd
minute movie from an analog broadcast I have found a constant bit-rate
of around 1800 to be ideal. The resulting files are around 700M for 45
minutes which fits nicely as a raw XA MODE2 data track on a CD-R.
(I use cdrdao to write such CD's and a hacked version of vcdread -
soon to be included to extract them).
Update: I've now got a digital cable provider. Digital TV sources
(even when captured via an analog interface) give *much* better
results. There doesn't seem much point going above 1400 or
1500Kbps. Often even VCD 1152 works fine. It depends a bit on the
quality of the original. However, IMHO the VCD rate is silly 'cos
it means every movie still needs two CD's but the second is mostly
empty. Might as well crank the rate (and quality) up until you
come in at just under 2 CD's.
For pure digital sources (DTV or DVD streams and similar) VCD 1152
works fine.
Extrapolating this suggests using 2500bps for MPEG-2 SVCD from
broadcast sources with 2000bps or less o.k. for pure digital.
(7) Speed. On modern 400Mhz+ CPU's there is *no point* running with a motion
compensation setting less than 16. The speed gains aren't huge as
other parts of the encoder take a significant fraction of the
time. It is much better to leave the radius at 16 and push -4 and -2 to 4.
See README.
(8) Variable bit-rate. Remember to tell mplex you're encoding VBR as
well as mpeg2enc (see the example scripts). It *could*
auto-detect but I haven't got around to that yet. You should tell
mplex a video buffer size at least as large as the one you
specified to "mpeg2enc". Sensible numbers for MPEG-1 might be a
ceiling bit-rate of 2800Kbps, a quality ceiling (quantisation
floor) of 6 and a buffer size of 400K.
(9) Big files. Under typical linux 2.2 systems files are limited to
2G bytes. This is rarely a problem for MPEG-1 video files but it could
bite. If your video threatens to exceed 2G you'll need to do it in
seperate chunks (for now).
10) Interoperability.
Quicktime files capturing using lavrec can be editted using Broadcast2000.
mjpeg AVI files captured using the streamer tool from the xawtv package
can be editted and compressed and played back using software.
Hardware playback is not possible for such files due to limitations in
the Zoran hardware currently supported.
MPEG files produced using the tools are know to play back correctly on:
dxr2 (hardware decoder card)
mtv
ztheater
xine
oms
dvdview
MS Media player versino 6 (anyone like to test version 7?).
Obviously, there are some limitations. MPEG-1 players won't play MPEG-2!
11) Optimising encoding.
Encoder performance is slightly enhanced if you allow it to dynamically
size the output streams groups-of-pictures to reflect scene changes.
This is done by setting a maximum GOP (-G flag) size larger than
the minimum (-g flag).
The default value for both is 12. For VCD's sensible values might be
a minimum of 9 and a maximum of 15. For SVCD 9 and 18 would be good
values.
Andrew
