Making a DVD with a Menu in Linux

As a follow up to my previous post about transfering VHS tapes to computer, I thought I would show the next part of the process, authoring your own DVD's with menus.

Before doing anything, I had to go through my video files with Virtual Dub and set the frame rate to 25 fps and resync the audio and video.  The sync problem was caused mainly by dropped frames when I did the initial capture.  Because the video was poor quality in a few places, the capture card couldn't record a frame.  This is a dropped frame.  The audio however doesn't come with that problem.  Because the audio is just an analog signal with no structure, it is just recorded as is.  As time goes on, the audio starts to lag the video.  Most of the videos only had a couple of dropped frames, and by luck were only short videos, so the problem wasn't evident.  A couple of clips required a bit more attention.  All I had to do was copy some frames and insert them back into the movie in the static to lengthen the vision and re-sync it with the audio.  Now onto authoring the DVD.

After looking around for a while I settled on Bombono DVD, which is available for Windows and Linux.  At first I tried to use it in Windows, but I didn't really get anywhere, so I just went back to the Linux version.

The interface is pretty simple, you start by adding media on the "Source" tab.  This can be audio, still images or video.  After all media is added, switch to the Menu tab.  From here you can create all the different menus you want and create links to media items and other menus.  The links can be either text, static images or movies.  I did have a little trouble lining up my links and images but I just altered the resulting xml file by hand.

After you set all this up, go to the output tab and select the output method.  I choose to have a disc image created that I could then burn to DVD later.

I had one problem though.  The image quality was pretty crap.  This was because Bombono had to transcode my video files, and without knowing more about them, all it could do was use the default options.  So by doing the transcoding myself I could tailor the options to my video.  This was pretty easy with WinFF.  Set "convert to" to DVD, and "preset" to PAL DVD HQ Fullscreen.  To get the best quality and specify that the video was interlaced, the following line is added to the FFmpeg tab.

-flags +ilme+ildct+alt -top 1

Once the AVI's had been transcoded to MPEG's and used as the media in the Bombono project, the output was perfect.  You may want something a little more flexible and powerful, but for something free it was perfect for my use and I highly recommend it.

Transfering VHS Tapes to a Computer

I recently just took a couple of weeks off work, and as part of my current quest of making things in my life more efficient I decided to digitise the old family video tapes.

There are a couple of reasons why you may want to do this.  Firstly, the quality of VHS and camcorder tapes aren't going to get better with age, slowly they will degrade and the information will be lost.  However, if you digitise the video you effectively take a snapshot of the information preserving it, preventing further degradation.  Secondly you have to consider how long the equipment to play back the tapes will be accessible and still operational.  VHS players will be around at garage sales for years to come, but camcorders are a different matter.  Mine is nearly 20 years old and eventually it'll die.  As it was, I had enough trouble with the last tape and probably could have done with a head cleaning tape (fat change finding one of those).  So now I can save space by not needing to keep a camcorder, VHS player and tapes.  Digitising the video in raw mode takes around a GB a minute so, even without compression you can fit around 5 VHS tapes on a 1 TB drive, with compression, around 80 tapes, that's a pretty significant space saving.

I spent a week looking at all the different hardware solutions that were available.  As I was using my laptop, PCI capture cards were out of the question, so USB it was.  There were options ranging from 30 dollars up to around 120 dollars, and from forums I had seen trouble with all of them, and basically decided to just go with the cheapest option and cross my fingers.  So I picked up a Leadtek VC100U for about 31 dollars from MSY, my friendly neighbourhood computer store, and was pleasantly surprised for a device, I'm pretty sure is a couple years old.

Leadtek VC100U

Once the software was installed I hooked it up to the VCR via the RCA cabels and was good to go.  The interface was reasonably easy to use, and it didn't take long to start capturing video.

ArcSoft ShowBiz

For the first few attempts at capturing video I used MPEG-2 compression.  Turns out that the on-board compression was pretty woeful, so capturing uncompressed and processing the video later was the only option.  Configuring the device properly then took a bit of research.  Firstly I had to make sure that the video source was set as PAL/B video for Australia.  This means that the video has 576 active horizontal scan lines and is transmitted at 25 frames per second (fps).  From this it becomes obvious that the vertical capture resolution is best if set to 576 pixels.


The next part becomes a little tricky.  Analog TV in my opinion is partly digital from a signal processing perspective.  Although each scan line is represented with an anlaog waveform, the image it is discretely sampled in the vertical direction.  So the vertical resolution is easily obtained from the number of scan lines, but the horizontal resolution is based upon the bandwidth of the analog signal, which in the case of PAL/B is 5MHz.  To completely reconstruct a band-limited signal, it needs to be sampled at the Nyquist rate which is twice the bandwidth, ie 10MHz or 0.1 microseconds per sample.  The active video portion of a scan line lasts about 52 microseconds, which means that there needs to be 520 samples per scan line.  The device has options for the horizontal resolution of 480 or 720 pixels.  Given that the source is from long play video tapes, the bandwidth of the video signal should be well below 5 MHz, which means that sampling at 720 pixel is just oversampling and storing more than is needed. So we should be able to get away with 480 pixels which is OK up to 4.6 MHz.  There may be some subtle flaw to my interpretation of how this all works, but testing both resolutions and playing them back showed no perceptible quality difference.  I think if I was recording from a high quality source I would probably go with the 720 option, but not in this case.


You may now be thinking that the aspect ratio is all wrong.  The video is sampled at 576 pixels high and 480 pixels wide, giving an aspect ratio of 0.83 when the source is 4/3 or 1.33.  This doesn't matter at all.  As long as the software displaying the video knows that it will need to be displayed at a particular aspect ratio, it will interpolate the data itself and display it properly.  One point to note is that the AVI container doesn't actually have this ability.


So several boring hours later I had captured all the videos I needed to.  One thing to note that confused me at first is the file size. One file was 4,330,983,188 bytes and was 309 seconds long.  At a resolution of 576x480 at 25 fps that gives 2.027 bytes per pixel.  The 0.027 is the container and audio overhead, which leaves 2 bytes per pixel for the image, I was expecting to see 3, a byte for each of the red, green, and blue components of the image.  Turns out I didn't understand how video is handled.  I'm used to dealing with images of RGB, I haven't had much to do with video.  Video is transmitted in in YUV format instead.  The Y component is the luminance which is the same as black and white, the U is the blue luminance difference, and the V is the red luminance difference.  The historical reasons why it is done like this are quite fascinating (warning, my idea of fascinating may be mind numbingly boring to you).


Turns out that the luminance of an image is more important than the chrominance (UV) of it for our vision system to perceive it as a quality image.  So with a given amount of bandwidth, to get the best image you just have to have proportionally more information about the luminance than chrominance channels. This is what chroma sub-sampling does. It samples the chrominance channels with half the resolution of the luminance channel.  In my case, every pixel gets a luminance sample and chrominance sample.  However the chrominance sample alternates between the U and V channels.  This is called YUV 4:2:2, and gives 2 bytes per pixel.