Captured VHS to xvid?

[pyrohydra]

Hi,

I've just recently bought the Philips DVP642 player that plays mpeg4 avi files. I have been thinking about converting some old VHS tapes that I have to dvd. Player compatibility is not that important to me, so I have been thinking about converting these to xvid instead and burning them to DVD-R, so I can watch them on the DVP642.

I am wondering what sort of bitrate and resolution I should use to obtain decent quality without wasting bits. I'm inclined to encode at a resolution of 352x480 (interlaced), as I would do when converting to DVD. I'd be happy to fit 6 hours of xvid footage onto a DVDR (about 1500 kbps), but if I could fit more without sacrificing much quality, I'll go for it.

Any advice would be appreciated.

[Cobra]

MPEG-4 is brilliant at making video appear high-quality at bitrates as low as 1200kbps. Why don't you encode a sample using AutoGK (or Gordian Knot if you feel up to more complex procedures) and test it using a DVD-RW? This will allow you to both find your best quality/size balance and make sure your DVD player will be OK with it (saves you time if you have problems).

Resolution of these files does not matter, just do as AutoGK says and you should be fine.

There are plenty of guides to the left, have a read and have a go. I've picked out the AutoGK (recommended) and the Gordian Knot guides to save you a little time:

All AutoGK Guides
All Gordian Knot Guides

Best of luck with your project!

Cobra

(Edited once to add a little more)

[junkmalle]

I have been thinking about converting some old VHS tapes... to xvid

I do that at 704x480 (my capture card captures at that size, not the more common 720x480) and use two pass variable bit rate xvid encoding to get about 90 minutes in a 1 GB file (with 192 kbps mp3 audio). That's a little over 1300 kbps for the video, and meets your 6 hours on a DVD criteria.

VHS captures are pretty noisy so it helps to use a little noise filtering. Or you'll end up wasting bits encoding the noise.

If the source is a movie I inverse telecine back to 23.976 fps with VirtualDub's adaptive process. If I was archiving invaluable footage I wouldn't do this because the results aren't perfect (occasional interlace artifacts get through) but it's been good enough for these old movies.

I can also capture at 352x480 but I find the final result doesn't look quite as good -- even though VHS tape has less resolution than that. If you do want to use 352x480 anyway, you should consider capturing at 720x480 then reducing via software during the conversion. Software will probably do a better job of reducing the image.

If you haven't done so, check that your player will scale 352x480 XVID files properly. I have a Liteon 2002 and it automatically stretches that size to fit the screen.

[pyrohydra]

Thanks for the advice folks. Yeah, I usually capture at 720x480 using the huffyuv codec and then convert to what I need, throwing the noise and color/hue correction filters in for good measure. I had encoded some test clips in 352x480 using both divx and xvid (using CBR), and the Philips player played them ok. Unfortunately my capturing/burning system died, and won't be working at least until my new power supply arrives. Once I get working again I will certainly try out GKnot.

On a somewhat related note regarding VHS captures, I got my JVC-9911 a few days ago. I ordered from that bhphotovideo place lordsmurf likes. When I received the unit, part of the loading mechanism was out of alignment, causing it to refuse tapes. It likely got banged up during shipping. Anyway, I was able to open up the unit and correct the problem. Good thing, it would've been a pain in the ass to RMA it.

But...WOW! What a difference the TBC and digital noise reducer makes on my captures. Using my old vcr, I only got around 2:1 compression out of huffy, using the 9911 with the same footage I easily got 3:1 and above.

This is pretty old footage with lots of noise (mostly recorded news reports from the challenger disaster), so I'll take any help I can get.

[DJRumpy]

Huffman isn't affected by noise. It uses ZIP compression (which is why it's lossless). It should typically give you the same compression ratio of about 2.1:1. Use it to capture your initial recording from VHS to the PC, and then encode using Multipass for DivX or XviD. Don't use single pass for the mpeg-4 encode no matter what you do, as they tend to look awful on scene changes, even at high bitrates without multipass.

You should look at some of the custom noise filters available for VirtualDub, or even look at using AVISynth. Many of the custom filters will easily outperform the built in IVTC filter in VirtualDub. Many come with cleanup/post processing logic to find any missed telecined frames, which makes your output much easier on the eyes.

For noise, especially on VHS captures, make sure you tweak the filter settings, regardless of which noise filter you use. Spatial, Temporal, and Combination (spatial/temporal) filters are a good match for VHS sources. Make sure you view sample clips long enough to verify your testing results. You should also pick a single frame number, and examine it closely with each filter's test settings to see if the output is as you expect. Often times, just viewing a moving clips makes it hard to determine exactly what effect a filters settings has, while viewing a single frame will reveal much more detail (or loss of detail as the case may be). You can also capture a screen shot so you can view each filters settings side by side to see which you like best. VirtualDub is an excellent tool for that because the frame number is displayed at the bottom, making finding that same frame again much easier.

[junkmalle]

Huffman isn't affected by noise. It uses ZIP compression (which is why it's lossless). It should typically give you the same compression ratio of about 2.1:1.

Although HUFFYUV uses a lossless compression scheme, the amount of compression you get is effected by noise. A noisy signal doesn't compress as well as a nice smooth one. That is what pyrohydra was refering to.

[DJRumpy]

Huffman doesn't see a 'signal' or 'noise'. In essence, it's just zipping up a file on your hard drive. It doesn't care what images, noise, or content are actually in the video. I could capture a dead tv channel and get about the same compression ratio.

MPEG compression is affected by noise. Huffman just see's byte data for the file itself, not the contents as video. If you opened an MPEG file in wordpad, and viewed the text representation of the data, there is no noise. It's just characters in a file, and that's all that the Huffman compression scheme see's.

For example:
ü.Ñ£Fn4hц�4a†ãF�a¸Ñ£Fn4hц�4a†ãF�a¸Ñ£Fn4 hц�4a†ãF�a¸Ñ£Fn4hц�4a†ãF�a¸Ñ£Fn4hц�4a †ãF

There are a lot of repeating character sequences in here. This little snippit, pulled from a small MPEG clip, if encoded by huffman, would see the multiple repeating instances of 4a†ãF�a or even just the � pieces of the text. It would then assign a small code to that piece of the stream (say the letter 'm'). This is a very simplistic explanation, but you get the idea. Instead of saving the entire long stream, it could remove any repeating entries that have that same bit of code and replace them with the code representing those pieces. Noise, when listed out like this, looks just like video, and compresses at about the same compression ratio.

[junkmalle]

DJRumpy,

Your description of the Huffman algorithm is accurate as far as it goes. But your application of it regarding the HUFFYUV codec is off the mark.

First of all, your sample MPG stream viewed via wordpad is probably not showing a video segment of the mpeg file. Video segments have very little redundancy.

I don't know if you are aware of this but Huffman compression is a part of MPEG encoding. In any keyframe (I frame) the video data is broken down into 16x16 blocks, the blocks are compressed via a discreet cosine algorithm, then the results from that are further compressed with a Huffman algorithm.

In any case, all that is irrelevant to the HUFFYUV codec. HUFFYUV compresses YUV data. (It can also compress RGB data but since the name is HUFFYUV I'll restrict my discussion to YUV.) It does not take MPEG files and compress them further.

Here's a nice simple explaination of MPEG encoding for anyone who's interested:
http://www.digitalconnection.com/Support/cliffnotes_2.htm

In case you don't know exactly what YUV is I'll give a short desription. Like RGB, YUV is a method of represting colors using three components. One component is the intensity of the pixel (Y). The other two (U and V) encode the color. This type of encoding was originally developed to retain compatibility with black and white TV -- a B/W TV displays on the intensity component, color TVs display all three.

A YUV data stream usually doesn't include all three components for each pixel. There is usually less color resolution as intensity resolution to reduce bandwidth.

One of the most common YUV encodings is YUY2. This encoding reduces the U and V components by half. For each intensity component there is only on color component, and the color compenents alternate between the U and V values.

An eight pixel, full YUV stream would look like:

YUV YUV YUV YUV YUV YUV YUV YUV

expresed in YUY2 it would look like:

U Y V Y U Y V Y U Y V Y U Y V Y

Notice that there are still six Y values and you can construct a full YUV value at each by taking a U or V from either side of each Y.

HUFFYUV starts with a YUY2 stream like this and compresses it vai a Huffman algorithm.

Now, let's be precise by what we mean by "noise". Noise can take two forms in a video signal, repeating and random. Repeating noise is generally caused by interference from some electronic component. This can usually be eliminated by proper grounding and shielding of cables and internal components. Random noise is a function of the magnetic grains on the video tape and any brownian effects in the electronics. As the name implies, this type of noise is non-repeating, random.

Lets look at a nice clean YUY2 stream of a constant, medium intensity, single color, background:

U Y V Y U Y V Y U Y V Y...

50 100 180 100 50 100 180 100 50 100 180 100...

You can see that the same four byte pattern just repeats over and over. This would obviously compress very well with HUFFYUV. If all 720 pixels across the scanline looked like this you could simply say "repeat [50 100 180 100] 360 times". Even written out in plain english the original 1440 bytes comopressed down to 33 characters!

Lets inject some random noise into this signal by adding or subtracting a small random value to each one:

49 99 181 101 52 101 181 98 47 104 177 100...

It's pretty clear that this much less compressible.

Obviously, even the cleanest real-world video signal isn't going to generate a nice repeatable pattern like in the first example (although a computer generated picture might). But the cleaner the signal the more likely it is to genereate repeating sements that can be compressed by the HUFFYUV codec.

[DJRumpy]

Junkmalle, I-Frames use something akin to JPEG compression. They do not use Huffman compression. Totally different techniques.

Tell you what. Just to be thourough, when I get home from work, I will capture two different signals. Both using Huffman compression. One from a digital feed, and the other from an empty or noisy broadcast channel.

I'll post the results later today.

[junkmalle]

I-Frames use something akin to JPEG compression.

That is correct.

They do not use Huffman compression. Totally different techniques.

That is incorrect. Huffman compression is part of the JPEG compression process. As I describe above, JPEG (and MPEG I Frame) compression first does a discrete cosine transformation, it then follows that up with a Huffman compression. (Because the DCT results can be further compressed with the Huffman algorithm.)

On playback the process is reversed. The data is first Huffman decompressed then an inverse DCT function is performed.

You don't see these details because they are all internal to the codec.

Read the site I referenced in my previous post. Or any other site which describes the details of JPEG/MPEG compression.

And, as I also mentioned in my last post, JPEG/MPEG compression has nothing to do with the HUFFYUV codec. HUFFYUV starts with YUV data and produces Huffman encoded data which is then packaged into an AVI file.

[DJRumpy]

This is not exactly what I would think of as an official site. Especially considering the owners lack of basic MPEG architecture:

Before you ask, I have looked at many MPEG-2 FAQ's and have come up short-handed on how it compresses video for the most part, since I can't understand most of it. If someone can explain all the frame types (I-frame, P-frame, etc.), quantization, coded block patterns, 16x16, motion prediction, and whatever else you can in English, I would greatly appreciate it.

I'll just verify by testing myself. Much easier!

[DJRumpy]

Just following up. Sorry for the delay. I was busy yesterday with work

The huffman codec did indeed increase in compression rate, with less noise in the stream. Encoding a regular video clip gave the expected 2:1 ratio. Encoded white noise from an empty channel gave a 0.6:1 ratio. Encoding black screen gave 4.6:1

I stand corrected

[junkmalle]

Thanks for the update DJRumpy! Pyrohydra's reported increase from 2:1 to 3:1 is more than I would have expected. Maybe his old VCR was really bad!

[pyrohydra]

Thanks for the update DJRumpy! Pyrohydra's reported increase from 2:1 to 3:1 is more than I would have expected. Maybe his old VCR was really bad!

The "old" VCR was a JVC Hi-Fi VCR that was actually less than a year old. I guess it just couldn't handle old tapes well. Or it was just total shit. Whatever the case, it does perform well at its current job as a rewinder .