Video compression problems

February 3, 2009 2:53 PM

Does anyone have advice on video compression/transcoding formats, options, etc please?

I recently captured some old VHS tapes to my computer at high quality, which (naturally) resulted in giant files; 5.5gb for a two hour video. I'm trying to transcode/compress with ffmpeg and the results are still huge, and invariably look awful. There are huge blocks, artifacts, etc.

I know squat about video compression, but I know its possible to get decent video in small files because I download 'em all the time. Obviously I'm choosing the wrong format and/or compression options.

ffmpeg reports the video I got from my capture device as mpeg2 at 720x480 and 5999 kb/s. I tried ogg, avi, etc at 200kb/s (the default) and the result was unwatchable, so I boosted to 2000kb/s and the result was so so but not great and the file was still remarkably large.

I'm not wedded to ffmpeg if a different program would work better, though I'd prefer to stay in the free as in beer category, and ideally in the works with linux category.

Any help or advice would be greatly appreciated.

posted by sotonohito to computers & internet (14 comments total)

H.264 video currently offers the best quality video at reasonable bitrates. Avidemux is a cross-platform free software GUI that uses the excellent x264 encoding library and will automatically index and concatenate (if necessary) your MPEG files and allow you to use various filters with a preview option before recompression. Avidemux is also fairly versatile as far as handling audio and encoding it to different output formats.

In terms of heavier filtering, your best bet is Avisynth but I have no idea how well it works on Linux natively /under Wine/etc. The doom9 Avisynth forums will have the best up-to-date info on using it under *nix. Avidemux will accept Avisynth input through its AVSProxy.

For a 720x480 4:3 NTSC encode, I would think x264 at High Profile/Level 4.1 compatible options at 1200kbs would give very good quality. One way to find a good bitrate (if predicting filesize is a necessity) is to encode with various CRF presets from 20 to 26, find the one that just hits watchable quality, and use the bitrate of that encode as a rule of thumb for similar sources. Otherwise just stick with a CRF encode: I've found CRF 22 to be visually transparent without going overkill on the bitrate like, say, CRF 18.
posted by Inspector.Gadget at 3:03 PM on February 3, 2009

Remember that you're coming from a VHS source, not a DVD. While it may visually looks "good", there are going to be much more variations in the signal from the older source, so whatever video codec you have, it's going to have to work a lot harder to know what's just noise, versus what's important picture info.

that being said, I recently watched some DVDs made from merely passable VHS source tapes, that turned out quite watchable.

Are you using 2-pass? The extra time it takes makes a massive quality improvement.
posted by nomisxid at 3:06 PM on February 3, 2009

As a quick and dirty solution, I'd try Xvid, 512x384, between 800-1200 kB/sec. There are more modern and bit-efficient codecs out there, but Xvid encodes fast, decodes with relatively low overhead, and is pretty broadly supported. FFmpeg should be able to do that; I've done it with ffmpegx on OS X, and presumably there's a similar GUI that you can use in Linux.
posted by kid_dynamite at 3:08 PM on February 3, 2009

You haven't specified what size you want the movie to be. Enter your data in a bitrate calculator such as this and play around.

Remember, you can also abort an encode a few minutes into judge quality for the bitrate you specified.

I'd also recommend H.264 but simple profile, so at least you can play the video on portables devices/settop machines and arent limited to computers.
posted by wongcorgi at 3:19 PM on February 3, 2009

Take a look at virtualdubmod - while not terribly intuitive to use, it's incredibly versatile and handily free. Best method of getting quality while maintaining a low bitrate is to use multi-pass encoding. Anything above 800kb/s should give you a decent picture at that resolution.

That said, if you're not going to be doing any more videos after this it might be better advised to use something less versatile but more user-friendly. I'm no newb, and vdubmod confused the hell out of me at first.
posted by fearnothing at 3:25 PM on February 3, 2009

A recent and very relevant AskMe question, which was not associated with yours for some reason. My answer.
posted by Bora Horza Gobuchul at 4:13 PM on February 3, 2009

Frankly, I think you're up against the wall with this, unless you're prepared to do some heavy custom filtering. As Inspector.Gadget and nomisxid point out, your main problem is video noise - it's fast, transient, and unpredictable. Encoding algorithms can't tell the difference between this and important picture information, and so waste bits trying to encode all this fast unpredictable information at the expense of overall picture quality.

As an aside, the small files you've downloaded are likely from DTV, DVD, or good analogue sources, which is why they look OK - they just don't have all the chroma, luma, and pixel noise that VHS does.

However, there are some things you can do first. Crop the image until you have no flag-waving or pulling at the top and bottom, and no soft edges at the sides. Make sure that the resulting image size, before any rescaling, is a multiple of 16 (e.g 704x464, 688x448, etc) - most encoders deal with images in blocks of 16x16 pixels, so filling them up is most efficient.

If that doesn't do it enough for you, AVISynth and Virtualdub/Virtualdubmod have fairly good chroma/luma noise smoothing scripts/plugins available; Virtualdub also has a couple of plugins (e.g. temporal smoothing) for pixel dropouts and other noise. (Sorry, can't name them offhand, as I deal almost exclusively with digital sources these days, and don't need/use them anymore). Don't know of any good Linux equivalents offhand.

Do things in this order : cropping, filtering, resizing. Store any intermediate results in a lossless format, e.g. HuffyUV - not MPEG-2, DV, MJPEG, DivX, H.264/MPEG-4 AVC, as these all add their own noise and interpretation of existing noise. (Aside: you thought your MPEG-2 source file was big? Ha! Be prepared for files in the order of 5x~10x larger...). At the very least, if you can't manage a lossless format, save intermediate results in the highest bitrate least lossy codec you can use e.g. MPEG-2 @ 9~10Mbps or better. Resize your video to the target framsize; again, keep it at a multiple of 16 (and don't pad it with black to achieve this - encoding efficiency will drop as you then have movement up against a sharp unchanging black edge!)

Finally, encode the cropped/filtered/resized video to your target format e.g. H.264.

And, lastly: realise that, at best, your encode is never going to look any better than VHS, and most likely at least slightly worse. Each step removes some information; the trick is to balance the removal of annoying/interfering information against the loss of important information. At best, they're never going to look as good as a good DTV/DVD rip you downloaded.

(And, as I've said a few times before, recordings of VHS tapes made on a stand-alone DVD recorder almost always look better than what the average person can do with a cheap PC video capture card - they have better timebase correction and filtering circuits/algorithms than all but the most high-end PC video processing software or most dedicated amateur.)
posted by Pinback at 4:24 PM on February 3, 2009

On preview: after reading Bora Horza Gobuchul's answer in the other thread, there's a discrepancy between his suggestion of image sizes in a multiple of 4 and my suggesting image sizes as a multiple of 16. This comes about because of the successive-approximation-like technique that encoders use to 'describe' the image; each approximation provides finer detail than the previous. While most encoders can handle hard edges on 4x4 blocks fairly well, they're most efficient at their base block size of 16x16. Even for older codecs which used a base block size of 32x32 or even 64x64, 16x16 is a fair compromise.
posted by Pinback at 4:33 PM on February 3, 2009

Thanks everyone.
posted by sotonohito at 5:20 PM on February 3, 2009

What are you going to do with the video? I post 2-pass 2000kbit/sec xvid video from mencoder to Google Video & Vimeo, for instance. For my video - talking heads, usually - it uses some fraction of that.

Helpful GUIs for this include dvd::rip, acidrip, & handbrakegtk.

For DV, two hours is around 24 gigs. My mencoder scripts outputs around 1 gig for that long.
posted by Pronoiac at 9:38 PM on February 3, 2009

Oh yeah - on mencoder I use hqdn3d denoising, kerndeint to deinterlace, & 2-pass encoding. These help.
posted by Pronoiac at 9:41 PM on February 3, 2009

What's been said about video noise is correct; it's a problem and there's no good/great/perfect way to handle it. However, I've found that 2-pass H.264 handles noise incredibly well compared to other codecs I've used.

I've been using Quicktime for my H.264 encoding; you have to pay for the "pro" version, but it's not terribly expensive. I imagine that there are free/open source tools that probably do the job just as well by now.

If you want to try something quick and easy before using Pinback's (excellent) suggestions, you might give 2-pass H.264 a shot at 2000kbit/sec or so. Another thing you might try is reducing the resolution to 360x240 before encoding. Depending upon what you're going to do with the video and your subjective viewing preferences, you might find that this gives a more pleasing result. (Or it could well be the other way around.)
posted by Juffo-Wup at 1:44 AM on February 4, 2009

Pronoiac Just keep the videos for personal and family viewing; mostly just to get them off decaying VHS tapes and onto a more easily retained and copyable format. Which is why file size isn't my major concern. I'd like to get the files to a more manageable size, but quality is more important. For sharing in the family getting the biggest file down under the DVD limit is semi-necessary. Honestly, if it weren't for the fact that the two hour video came in at 5.6 gb I'd have just left them in the format that came out of the capture device and burned a few DVD's.
posted by sotonohito at 7:10 AM on February 4, 2009

You could use dual layer DVD+/-Rs, which hold 9 gig. Re-encoding is not necessarily an issue.

Right now, full-screen H.264 requires a relatively recent CPU. MPEG-4/XVID is a lot easier to decode, & there are DVD players & other devices that will play this now.
posted by Pronoiac at 7:54 AM on February 4, 2009