Praschinger Bernhard v1.48
MJPEG capture/editting/replay and MPEG encoding toolset description
Introduction
Unsorted list of useful Hints
2.1 Some books we found usefull
Recording videos
3.1 lavrec examples
3.2 Other recording hints
3.3 Some information about the typical lavrec output while recording
3.4 Notes about "interlace field order - what can go wrong and how to fix it"
Creating videos from other sources
4.1 Creating videos from images
4.2 Decoding streams with mplayer
4.3 Decoding MPEG2 streams with mpeg2dec
4.4 Other things to know
Checking if recording was successful
Edit the video
6.1 Edit with glav
6.2 Unify videos
6.3 Separate sound
6.4 Separate images
6.5 Creating movie transitions
Converting the stream to MPEG or DIVx videos
7.1 Creating sound
7.2 Converting video
7.3 Putting the streams together
7.4 Creating MPEG1 Videos
7.5 Creating MPEG2 Videos
7.6 Creating Video-CD's
7.7 Creating SVCD
7.8 Creating DVD's
7.9 Creating DIVX Videos
Optimizing the stream
8.1 Scaling and offset correction
8.2 Frame rate conversion
Transcoding of existing MPEG-2
9.1 If you want to do every step on your own it will look something like this
Trading Quality/Speed
10.1 Creating streams to be played from disk using Software players
SMP and distributed Encoding
Interoperability
documented on: 2005.08.31
Video CDs are ordinary CDROMs in a special format which contain MPEG-1 encoded video. For long times this type of CD was mostly known in Asia whereas Video CDs and the according players were mostly unknown in the USA and Europe. Since almost every DVD player can also play VCDs (and since the recordable Video DVD for a reasonable price seems still far away) VCDs are getting more popular everywhere.
VCDs use a special type of CD sectors (mode 2 form 2) and have a special form of the filesystem, so they can not be mastered with the usual Linux CD-Tools (like mkisofs and cdrecord).
If you want to know more about VCDs, visit the VCD FAQ or do a search in the web.
The VCD-Tools should enable you to create your own VCD under Linux. The VCD-Tools contain two programs, vcdmplex for multiplexing a MPEG audio and video stream in a form suitable for the VCD and mkvcdfs for making a raw image of the VCD.
New in version 0.4:
Fixed some problems with sound blibs that were introduced with version 0.3
New in version 0.3:
Location of some files was wrong in previous version, some players refused to play the VCDs produced. This has been corrected and the VCDs should play now in (hopefully) every DVD player.
Removed optional files, this improved the behavior of the DVD players during playback (at least true for mine). Time and track info is now shown.
VCDs should be able to be played back by the windows Media Player now. Just drag and drop the AVSEQxx.DAT files into the Media player since they are not recognized as MPEGs by their extension.
MPEG system streams from other sources should make less problems now, file size of MPEG files needs not longer to be a multiple of 2324.
create a MPEG-1 video stream with the dimensions 352x240 (NTSC) or 352x288 (PAL) and a bitrate of 1152 KBit/sec (use the encoder of your choice, you find one for MJPG encoded AVIs or Quicktime files in the lavtools).
create a MPEG-1 layer 2 audiostream with a sample rate of 44100 Hz, stereo and a bitrate of 224 KBit/sec (use the encoder of your choice, you find one for MJPG encoded AVIs or Quicktime files in the lavtools).
multiplex these two streams with vcdmplex (vcdmplex is contained in the VCD-Tools).
I got the information that a tool called mplex may also be used for multiplexing and may give better results. I have not tried that myself, you may try it if you think that audio/video sync is not satisfying. Don't ask me for details! You find mplex for example at http://www.leo.org/pub/comp/general/graphics/mpeg/mplex/
use mkvcdfs to create a VCD image of one ore more of those MPEG streams (mkvcdfs is contained in the VCD-Tools).
use cdrdao to actually burn the VCD image to disk (you may get cdrdao from http://www.ping.de/sites/daneb/cdrdao.html).
get vcdtools-0.4.tar.gz
gunzip and untar it with tar zxvf vcdtools-0.4.tar.gz
go into the directory vcdtools-0.4 and type make
vcdmplex MPEG_video_stream MPEG_audio_stream MPEG_system_stream
MPEG_video_stream and MPEG_audio_stream are inputs, MPEG_system_stream is a output.
vcdmplex should be able to multiplex any MPEG video and audio streams, not just VCD compliant streams. It can be used even for MPEG-2 video streams, I don't know if the output adheres to any standard, however.
Messages in the form: "Inserted padding sector …" are normal when multiplexing VCD compliant streams, they just tell you that your actual bitrate is slightly below VCD bitrate.
Messages: "*** BUFFER underrun - output may not play correctly ***" are more severe, they come if the actual bitrate of your MPEG stream is higher than the one specified in the header. The resulting system stream might be unplayable!
If video and audio stream bitrates comply exactly with the VCD specification (1152 KBit/s or 224 KBit/s respectivly), exactly 75 sectors/second are generated and the system stream is stuffed with padding sectors as needed. Otherwise no padding sectors are created.
mkvcdfs mpegfile1 mpegfile2 …..
mkvcdfs takes MPEG files produced by vcdmplex and creates the raw CD-Image data suited for burning with cdrdao.
mkvcdfs creates 2 files (names may be changed by editing defaults.h):
vcd.toc contains the table of contents of the VCD
vcd_image.bin contains the CD-Image itself
Use vcd.toc as the argument for cdrdao for burning the CD!
cdrdao write —device your_CDR_scsi_id —driver your_CDR_driver_name vcd.toc
For further details see the cdrdao man page or visit http://www.ping.de/sites/daneb/cdrdao.html.
My DVD player plays back VCDs up to the double bitrate of normal VCDs. I use a video bitrate of 2500 KBit/s (and the usual audio bitrate of 224 KBit/s) for that. It refuses to play anything above double bitrate.
Reportedly double bitrate is possible with most DVD players. It enhances the image quality greatly, but the time you can store on a VCD is reduced to 37 min.
My DVD player also accepts VCDs where the MPEG video stream is in SVCD format: MPEG-2, image size 480x480/576, 2500 MBit/s. mpeg2enc from the lavtools is able to encode such streams. I multiplex these streams also with vcdmplex.
I have no documentation about the VCD standard (the "white book"). These tools where created mainly by reverse engineering the content of a VCD. I am pretty sure that VCDs mastered with these tools are NOT adhering to the standard. Actually I ommitted the CDI stuff completly since only a few people have a CDI player.
These tools are just a try to make it possible to produce Video CDs under Linux!
It may be that they work not correctly with every input even if the input is completly ok.
Rainer Johanni, Rainer@Johanni.de
But not all stuff in this directory is from me!
vcdisofs.c has many things I copied from mkisofs
edc_ecc.c is from the cdrdao package and is written by Heiko Eissfeldt
documented on: 2004.06.17
This section could theoretically be done in a different HOWTO because it uses a different method for recording/converting than the other sections of the VCR-HOWTO use. This is primarily because I haven't figured out how to create VCD compatible mpeg's using vcr. If your goal is to create VCD's, use this section of the HOWTO. If you don't care about VCD's, completely ignore this section of the howto because these procedures require MUCH MORE disk space than using vcr to record for playing under linux.
A linux supported CD writer.
A bttv compatible TV Tuner Card (WinTV is one good example)
A VCD player or DVD Player
This is one method for creating VCD's under linux. If you have a better method, please let me know. The following list of software contains the versions I found to work well for me under Red Hat 7.1.
NuppelVideo 0.52a (nuvrec must be setuid root)
exportvideo 7e-pre4 (must be this version or later)
mjpegtools 1.4.1 (installed rpm found on rpmfind.net)
toolame 02h
mplex 1.1
vcdimager 0.6.2 (installed rpm found on rpmfind.net)
cdrdao 1.1.4 (rpm from redhat 7.1)
nuvrec -t _NUM_m _filename_ _NUM_m = size. E.g. 30m = 30 minutes.
nuvplay -e _filename_.nuv | toolame -b 224 -m s /dev/stdin _filename_.mp2
exportvideo _filename_.nuv "|mpeg2enc -o _filename_.m1v"_
mplex -f 1 -s 2324 -p 1 -o _filename_.mpg _filename_.m1v _filename_.mp2_
vcdimager -l "Movie Title" -c _filename_.cue -b _filename_.bin _filename_.mpg_
cdrdao write —device _your_device_ _filename_.cue_
Eject the cd-r, stick it in the vcd player, press play and enjoy._
File Sizes From each step for 30 minutes of data._
| Bytes | Filename | Created from step? | Can Delete after Step? |
|---|---|---|---|
| 1391756119 | finefilm.nuv | 1) nuvrec | 2) toolame and 3) mpeg2enc |
| 50401280 | finefilm.mp2 | 2) toolame | 4) mplex |
| 259097824 | finefilm.m1v | 3) mpeg2enc | 4) mplex |
| 313793452 | finefilm.mpg | 4) mplex | 5) vcdimager |
| 120 | finefilm.cue | 5) vcdimager | 6) cdrdao |
| 318808896 | finefilm.bin | 5) vcdimager | 6) cdrdao |
Total approx 2.3g for 30 minutes of sample data. If you delete previous files after the appropriate steps, max used space for 30 minutes of data was 1.7gb.
Some time ago, I discovered VCD's. These are, essentially, VHS-resolution DVD disks that use plain old CD media. While they ARE lower resolution than DVD's, and the CD media limits the amount of video that will fit on one disk (about 70-80 minutes), VCD's seem to have a lot to recommend them. For one thing - the MPAA isn't likely to try to have me thrown in jail for daring to watch them on an "unsanctioned" player (though nearly all of their "sanctioned" standalone DVD players will, on the other hand, play VCD's as well). For another, I can make them myself, giving me a sturdier standard media format to store home videos or "space-shifted" (the - completely legal! - act of transferring a legal copy of something to another media for personal use, such as making a cassette recording of a CD you've purchased) or "time-shifted" (the - completely legal! - act of having your VCR or whatever record a show for you to watch later) legal copies of commercial VHS tapes that I've purchased. Since nearly all DVD players can handle VCD's, this makes a convenient format to inflict "home movies" and such on friends with, who need not have a computer to view them.
But enough ranting for the moment. I attempted to find out how to make VCD's on my Linux box. Unfortunately, while I did find some documentation describing the process, said documentation tended to remind me of Steve Martin's old "How to be a millionaire and never pay taxes" skit on Saturday Night Live ("First, get a million dollars. THen…") - in other words, the documentation covered the easy part - taking an already-vcd-formatted mpg file and making a physical vcd out of it. I had little luck finding documentation on how to produce VCD-formatted video files in the first place, so other than being able to back up the handful of commercial VCD's I'd purchased, there wasn't much else I could do with it.
Time passed. After a fair bit of experimentation, I finally have a working start-to-finish procedure for generating useable video files and VCD's on Linux, so I thought I'd share with the rest of the interested world (all 3 of you.) In the process, I'll also try to describe how to generate even lower bitrate (but still watchable) video files which might be carried on data CD's for personal viewing on, say, a laptop computer while on vacation or a business trip.
Ingredients:
To make your videos on Linux, you'll need the following materials:
Some way of getting video (with or without sound) to work with.
Some way of converting said video to the format you want
A fairly fast computer or a fairly fast and large hard drive, or both
A place to put the final video file (a CD burner and/or the aforementioned large hard drive)
A way to actually watch the videos before and/or after encoding (technically optional, but silly not to have.)
A little patience.
Getting video data to work with
There are, basically, three sources of video to work with:
An already-existing video file in a useable format
Direct capture from a video capture card or similar
Existing media from which a video file can be obtained
Existing video files
There are a number of video file formats and codecs that can be dealt with using Linux-based tools. File formats include (but are not necessarily limited to):
mpeg
avi
asf
rm
quicktime
Codecs for video are fairly numerous, but the primary ones I've played with are:
mpeg1 video
mpeg2 video
mjpeg
RealVideo 1.0
"raw"
Variations of "MPEG4"
A brief digression on MPEG4 as I understand it:
There are a few variations of "mpeg4" floating around. There is Microsofts particular version, there is a "hacked up" form of this called "Divx ;)" for non-microsoft platforms, there is an "OpenDivx" (which actually isn't all that open but is available for most platforms free of charge), and there is a reimplementation of OpenDivx in ffmpeg. I've not experimented to find out how interoperable or compatible they are. Note "Divx;)" is not to be confused with the pathetic failure known as "DIVX", which was a scheme by several corporations to push a restrictive "pay-per-view" rental format on consumers, which rapidly bombed.
Effectively, the differences between the video codecs are tradeoffs between picture quality, CPU-intensiveness, and compression. Any compression done by the video codec will (generally) result in a loss of picture quality and detail to some degree. More processor-intensive codecs tend to lose less detail for the same amount of compression.
Mpeg1 is the older mpeg video codec. It is also the format expected by vcd's (at a specific size and bitrate.).
Mpeg2 is a somewhat more recent successor. DVD video data is Mpeg2, encrypted so that you can't play it on a video player that the MPAA doesn't want you to, and so that they can sell the same video separately in different "regions" (i.e. so that Australians can't mail-order DVD's from the US, and instead end up paying more for the "Australian region" version.).
mjpeg, as I understand it, is just a series of jpeg images, each representing a frame. Flavors of mpeg generally have frames inserted that are generated by a "motion estimation" algorithm, which smooths the transitions between individual frames, but doing motion estimation takes additional cpu power. It is probably not TOO innaccurate to think of mjpeg as being more-or-less "mpeg without motion estimation". (More details on the differences as I figure them out later…)
RealVideo actually comes in a number of versions, but the only RealVideo-generating tool I've worked with (ffmpeg) only deals with version 1. RealVideo is often regarded as low quality, but then, it's also frequently used to generate very-low-bitrate video (for downloading or watching over modems, etc.), which will NECESSARILY result in low quality. Rumor has it that flavors of mpeg4 are better for low bitrate video now, though.
"Raw" video just refers to unprocessed, uncompressed video frames. As one might imagine, such a video format takes up a HUGE amount of space, but requires the least CPU power to handle. On the other hand, the amount of data being written like this can actually be generated faster than the hard drive can write it!
For my purposes, I generally do one of two things: I either capture directly to mpeg1 VCD (when I'm feeling impatient and don't want to reprocess later) or I capture as an mjpeg avi file and re-encode it into whatever formats I want later.
Direct Capture: Direct capture, using a video capture card, is the most versatile option. Consumer-grade video-capture cards are relatively inexpensive. I'm using one of the ironically-named "WinTV" cards from Hauppage for my video capture. At the base, though, direct capture is fundamentally just a way of obtaining "An already-existing video file in a useable format"
Direct capture does present a few additional technical hurdles to overcome, but they're not too difficult. Activating direct capture capability just requires a few additional kernel drivers to support. You need:
the "Video for Linux" ("v4l") version 1 or 2 ("v4l2"). "v4l" is the video device currently in the linux 2.4.x kernels. "v4l2" is the next-generation version and is compiled separately as a replacement. The name of the module is "videodev.o"
device drivers for the capture equipment itself. For the card I use this is the "bttv" module and its attendant support modules (the msp3400 module, in my case, the i2c "bit-banging" interface module, and the tuner module.)
The appropriate /dev entries (/dev/video0, etc.).
The main software tools I use for video watching and/or capture are the XawTV package and ffmpeg. XawTV includes X11-based software for "watching tv" (i.e. the input from the capture card in realtime) as well as capturing, and a program named "streamer" which is a command-line tool for video capture.
FFMPEG is still "beta" quality, but quite usable. It is used to convert video from one format (including direct capture from the video capture device) to another. It can handle a number of different file formats and codecs and convert between them.
It is possible to directly capture to the final format you want, but this will generally require a high-powered CPU. On my current system, an AMD "Thunderbird" 1.2Ghz, I am able to capture directly to VCD-style MPEG1 files in realtime, with "moderate" motion estimation.
The summary of the process I use to create video is:
Load the relevant modules. Note that for bttv, loading it with "modprobe bttv gbuffers=48" instead of the default number of buffers makes a big difference in having the encoder get behind while recording frames…
Determine where to start and stop recording VCD can only hold about 70min on a normal CD-R. For VHS tapes longer than this, one needs to find a convenient breakpoint that will give you 2 or more files that will fit on CD-R. I generally just fast-forward to roughly either 1/2 way through the tape or to roughly 55-60 minutes into it, and watch for a convenient scene-change, and note down the time at which this occurs.
prepare the tape. (rewind to where you want to start recording, etc.)
Capture the video segment as an mjpeg avi - example: streamer -o (filename).avi -f mjpeg -r 29.97 -s 352x240 -t (hh:mm:ss) -j (jpeg quality) -n ntsc -F stereo (start tape and press ) This will generate an avi file with mjpeg video frames and plain-old-.wav style 16-bit stereo audio
wait until it's done (duh.)
re-encode with full motion-estimation using ffmpeg: ffmpeg -f avi -vcodec mjpeg -acodec pcm -i (filename).avi -me full -b 1150 -ab 224 -f mpeg -vcodec mpeg1video -acodec mp2 (outputfilename).mpg This will generate a VCD-format mpeg1 file, with full motion estimation applied. This may take longer than it took to record…
Use vcdimager to convert the mpeg file to a ".bin" and ".cue" file for burning to CD (note to self - put example here)
Use cdrdao to "burn" the VCD (note to self - put example here)
The frame rate (29.97 in this example) and the image size (352x240 in this example) may vary depending on the type of video you are trying to create. The size and frame rate in the example above is specifically for NTSC (North America) VCD. PAL (European) is 25 frames/second at 352x288.
If you are generating video for "computer" consumption and don't care about being able to play the videos on a standalone DVD player, your options for size, frame rate, and bitrate vary considerably.
Bitrate is the sole factor in determining file size (and, consequently, how fast your internet connection has to be to view the file in "real time"). You could, quite likely, take a 720x480x29.97fps (DVD quality - up to 9600k/s!) video and try to recode it at the same size and framerate to, say, 40k for viewing over a 56k modem link, but you'd just end up with an unrecognizable changing multicolored blotch for video because the encoder would have to throw out so much data to fit that much video into that small size. In short, there are three things you can "throw out" to reduce the amount of data lost in the encoding step.
Frame rate - reducing the frame rate means fewer individual pictures that need to be stored in the file, which obviously reduces the size and bandwidth requirements. On the other hand, reducing this also makes the video less "smooth". At very low rates (approx 15 fps or below) the jerkiness becomes quite noticeable.
Picture size - reducing the size of the frames you are encoding reduces the size of the individual images being encoded. Obviously, though, as you reduce the frame size you are reducing the detail in the original picture before the encoding step. Note that to my eyes, 352x240x29.97 seems to be approximately the same quality as a VHS video.
"Quality" - this is what gets thrown out for you in the encoding step to get the video down to the bitrate you want. You end up with more pronounced "halos" (the distortion in jpeg-style images around objects at high compression) and more noticeable "blocks" in the final image. FFMPEG and many other encoders report this "quality" rating as it encodes, letting you know roughly how good the resulting video is on a scale of 1 (best) to 31 (worst). If you are encoding and you see the quality meter pegged at 31 nearly the whole time, you might consider stopping and retrying with more lenient frame rate or picture size settings.
If you want to fit a certain amount of video onto a certain amount of media space, just calculate what bitrate you need to be constrained to in order ot fit. On ordinary (640MB) CD-R: ~4200 seconds * (1150k/s+224k/s) = 5770800 kb. (that's video plus audio - VCD audio is 224k/s mp2.) So to fit, say, a regular 90-minute video onto a single CDR as a video data file will require a combined bitrate of: 5770800 / (90*60) = about 1068k/s between both the audio and video. Note that despite the hype of promotors and the rabid fear of MPAA lawyers, transcoding DVD video to a smaller format to fit on a single CD-R WILL result in a noticeable loss of quality - Mpeg4 may not be as bad as "1/9th" the detail in the 9600k mpeg2 DVD video, but there is absolutely no physical way to compress data that much without noticeable loss of quality. Of course, if you just want a backup copy of a favorite movie to watch while travelling, the loss of quality may not be an issue (certainly it IS possible to produce "watchable" video at these bitrates.)
Get and use MPlayer.
