|
You are here: The Oldskool PC/Who is this guy?/Trixter: The Compleat Works/Helpful Resources/MPEG-1/Trixter's Desktop MPEG-1 Authoring FAQ |
This FAQ is six years out of date and contains incorrect information. It will not be updated or corrected; it is included here for historical/archival purposes only. You are urged to instead check out the much better guides at doom9.org and dvdhelp.com.
This FAQ attempts to answer some of the more common questions about authoring MPEG files (with emphasis on Video CDs) that crop up on rec.video.desktop. While the questions and answers listed here are Windows/Premiere-centric, there are many concepts presented that apply to all OS platforms and editing packages.
Disclaimer: I am not a video editing professional; I don't do this for a living. But I have worked with digital video on the desktop for almost a decade and MPEG-1 for over half a decade, and have come to several conclusions about creating MPEGs that make sense. Maybe you agree with me; maybe not. Write me and let me know if you find a glaring error in my conclusions (or if I'm leaving something major out).
Disclaimer #2: To make this document easier to understand, I assume that you're using NTSC. To wit:
If your country's broadcast standard isn't NTSC, you'll have to substitute your country's numbers for what's listed in this document. For example, PAL is 576 full lines of res, 288 "half" lines of res, and a framerate of 25 ("fieldrate" of 50).
Core Idea #1: The quality of most MPEG encoders is directly tied to the quality of the input you give them. Remember the old adage, "Garbage in, Garbage out?" It's most evident when encoding MPEGs. If you give an encoder a noisy signal with lots of weak broadcasting artifacts, the encoder will try to include all of that in the output, which makes for a noisy bitstream. If your source is extremely clean (or live, like the live output of a video camera), your end result will be clean. Some encoders are much better than others, but the primary factor affecting the output is the quality of your input.
Core Idea #2: Frames vs. Fields. Video is 30 frames a second, right? Wrong. Video has a framerate of 30, but each frame consists of two interlaced fields. A field is a completely new picture. Here's another way to understand it: Each NTSC "image" is made up of 240 lines. A 480-line capture, therefore, has two "images" in it--the odd scanlines (1, 3, 5, etc.) make up the first image, and the even scanlines (2, 4, 6, etc.) make up the second image. The second image is displayed 1/60th of a second after the first image, then you move onto the next frame. If you still have trouble understanding this, try playing a video with high motion in it in your VCR and then hit "pause". Notice how the freezed-frame tends to "flicker" or "jitter" quickly between two different images? That's because only one frame is being displayed, and is quickly alternating between the two fields 60 times a second.
Core Idea #3: Software MPEG encoding takes a really, really long time unless you have a 500MHz (or faster) machine. Hardware encoders are either real-time (they encode the video as fast as it comes in) or faster than real-time (they encode off of .AVI files at about 3:1 or faster--a minute of video gets encoded in 20 seconds).
The above information seems useless right now, but you may find it useful later.
It depends on what your needs are, but what most people in in rec.video.desktop want to do is create Video CDs (MPEG-1, about 170Kbytes/second, up to 70 minutes of video+audio on a CDROM) that are as close to the original video source as possible. Here's a generic overview of what to do:
This will get you the best possible output quality. For a specific process using Premiere 4.2, here's what I do to create my Video CDs:
There are some probably some time-saving shortcuts you could apply to the above, like making a virtual clip and applying all of the operations to that one clip, but I wanted to keep it simple for people who want to duplicate the process with other editing packages.
It depends on the price, but the general answer is no. Consumer hardware encoders only encode the first field of a video frame and completely ignore the second field, so you lose motion quality. And because they have to encode in real time, there usually isn't enough processing time left over to do noise filtering, so the output can be noisier than a software encoder if your input is noisy.
Of course, software encoding takes forever and a day, so there is still a valid reason to buy hardware encoders. If you have very clean source material, the output of a hardware encoder matches (and sometimes exceeds, in special cases) the output of a software encoder.
Darim sells a product called the M-Filter, which greatly pre-processes video and assists MPEG compression with any encoder. However, like the other professional-grade MPEG products they manufacture, it has a price that is beyond most consumers' budgets.
General consensus points to the Broadway being the best, with all others trailing slightly in terms of output quality. It's a bit pricy at $800, but it can deal with marginal source material much better than the others, and can also output back to TV (the Dazzle DVC can also output to TV). I am unsure if it captures and/or takes into consideration both video fields, however.
If I had to rank them, I'd rank the Adaptec VideOh (which is a repackaged, OEM'd Futuretel Video Sphynx) 2nd after the Broadway, the Videonics Python ranking third, and the Dazzle DVC after that. But they're all acceptable if you have clean source material. I own a Python myself, and use it to encode live feeds from my video camera and images generated from PCs with results comparible to software encoders.
General consensus points to Ligos' LSX-MPEG encoder. It's one of the fastest of the bunch, has a ton of options, and even has support for MPEG-2 if you want to experiment with DVD bitstream creation.
Xing's encoder is just as fast, but doesn't handle low bitrate or high-motion clips quite as well as Ligos' encoder does. On the other hand, Xing's encoder comes with a free Premiere plug-in, which is an enormous time saver. You can do the same with Darim's DVMPEG because it installs as a VFW CODEC, but I believe it costs the most out of all three encoders listed.
For short projects, I render to an .AVI file and use LSX-MPEG. For long projects, I export via Xing's Premiere plug-in. YMMV. I strongly suggest you download the trial version of all three encoders listed and test them out for yourself.
There are several encoders for multiple platforms at www.mpeg.org, but the easiest one to use for Windows is AVI2VCD located at http://www.mnsi.net/~jschlic1/.
One word: VirtualDub. I cannot recommend VirtualDub highly enough (you can find it at http://www.geocities.com/virtualdub/index.html); it was expressly created for the purpose of editing and converting video. It supports OpenDML long-format .AVI files, has an optimized capture routine, and lets you apply filters to process the video as you save it to another file. You can do inverse-telecine to turn captured 3:2 pulldown'd film back into 24 fps source. You can store a list of actions and then batch-process an entire directory of video with those actions. It even contains features not found in commercial products like Media Cleaner Pro, like being able to adjust levels, and even act as a "frameserver" so that larger-than-2GB files can be passed into programs that don't support them, like .AVI MPEG encoders. This thing kicks major ass and belongs in everyone's software library.
How much ass, you say? Well, here's a quick way to take 720x480 video and create the best possible output for encoding to Video CD:
That's it -- no more steps, and you have decent output suitable for encoding. Did I mention this program was free? Send the author a donation or two.
See Core Idea #2 listed at the beginning of this document. If your source material was captured at 240 lines (352x240, for example), you're missing half of the images. Capturing at 480 lines and then deinterlacing ensures that you are encoding as much of the original video signal as possible.
A single deinterlaced frame will indeed look more blurry than the same image captured at 240 lines. But if you play the two captures side by side, you'll notice that the 240-line capture doesn't look as "smooth" during playback than the 480-line capture that was deinterlaced and resized down to 240 lines.
It won't be as good as a 480-line capture, but there's nothing preventing you from doing it. :-) 240-line captures aren't bad--they're just not as good as 480-line captures that have been deinterlaced and resized properly.
It sounds like you captured at 480 lines, but either forgot to resize cleanly or you're letting the encoder resize for you. Review the process listed above in the question "What process should I follow to create the absolute best possible MPEGs?".
Two ways: You can either generate many MPEG files from different clips and later join the MPEGs together, or you can generate the entire thing from your editing program.
Joining clips together is the cheap method; you can find several programs to do this at www.mpeg.org, but one popular program that does this under Windows is Camel's MPEG Joiner. Note: If you are creating a Video CD, you might not have to join video clips together at all. Most VCD authoring programs allow you to create a "simple video sequence" that plays the MPEGs one right after the other.
There are a couple of ways to do a long, unbroken sequence. The method I use is to put together my entire project in Premiere, then use Xing's Premiere plug-in to export the entire timeline to a single MPEG file. You can also use Darim's DVMPEG to output an entire timeline to a single MPEG.
If you have a "prosumer" package, such as the Miro DC30+, you probably already have a special version of Premiere that can either work with files larger than 2gig, or can play multiple files from the timeline seamlessly after rendering transitions. In the Miro product, this appears as a plug-in called "Miro InstantVideo". For those of us without the budget for such a product, there is an excellent shareware program that, in addition to being a powerful real-time NLE program, can string multiple pre-rendered clips together on a timeline and play them in sequence without dropping a single frame. This product is called DDClip, and is well worth the registration money. I've used it to string together multiple Iomega BUZ-captured clips with the same resolution and audio parameters, and it played them one right after the other without any dropped frames. I was able to output 10 2gig clips to tape (about 24 minutes of video) using DDClip without having to touch the VCR.
AVI_IO (see next question) has this capability as well.
AVI_IO was written by Markus Zingg expressly for this purpose: It is a better VidCap32 than VidCap32. You can capture to multiple files--even on multiple drives--and it won't drop a single frame. I have used it myself and can verify its effectiveness; I routinely use it to put together 30 minute and 60-minute VideoCDs.
You can simulate a low framerate by encoding blank B-frames; this leaves more bits for the encoding of I- and P-frames. Ligos' encoder can be configured to do this; check the help file for exact configuration options. The Xing encoder can do this as well, but it does so automatically under low-bitrate conditions and it's exact behavior cannot be specifically controlled. (I've found the results to be perfectly fine--I just like to tweak options ;-)
Unless you have professional hardware, no. Consumer encoding hardware and software usually don't allow you to arbitrarily specify where I (key) frames go. (If you're willing to pay for professional hardware, then they will do this automatically. Jason Livingston had this to contribute: "The professional MPEG encoders (Heuris, Philips/Sun, the high end C-Cube chips) will automatically insert I frames when there is a significant change in the scene (called auto-scene change detection), and will even choose whether a I, B, or P frame would be more appropriate based on the current frame content. It wouldn't be unusual to see a professionally encoded MPEG stream look like IBBPBIBBBBBBBPP...")
The best way to avoid the "blocky scene-change" effect you correctly described earlier is to either use a better/different encoder (Xing and Ligos are best, IMHO), or to encode at a higher bitrate. If you're already using VideoCD bitrates, then try a different encoder.
Another thing to try is to apply a low-pass filter, median filter, or a very soft Gaussian blur (no more than a 1-pixel radius) to the entire video as the last filter in any filter sequences you have. (Apply this as a filter if you're doing the Make Movie->Xing MPEG Export function, since it will *not* be applied if you specify it in the Make Movie special/advanced options.) This removes random noise and softens the entire image, which aids compression. This may not eliminate the "blocky sudden scene-change" effect, but it may help reduce it to the point that only trained eyes can see it.
One excellent reference by Chris LaRosa entitled Dec 21, 2015 4:31 pm
.