To deinterlace or to not deinterlace...?

[kinneera]

If one has an interlaced MPEG2 source stream and wants to reencode it to interlaced MPEG2 at a lower bitrate using TMPGEnc, should the de-interlace filter be applied so that TMPGEnc will redo the interlacing as it sees fit, or will the interlacing information just be passed through as is?

[guillep2k]

I have the same doubt. I want to make a SVCD from my Neon Genesis Evangelion DVDs (as I will add Spanish subtitles, which they don't have). The source is already 29.97 interlaced NTSC, as they are made from a TV program. FlaskMPEG always **says** it will give progressive video (I just don't get what exactly progressive stands for), even if I uncheck the "deinterlace" option.
As I will process the videos with VirtualDub in order to add the subtitles, I must extract the MPEG stream with something like FlaskMPEG (or at least I think that).
Will I be losing quality through all the process? May I avoid deinterlacing at all, keeping all the intermediate versions interlaced? I don't know if it counts, but source is 720x480 and the final result will be 480x480.
A hint would be deeply appreciated.

Guille

[Guiboche]

If your source is 29.97 NTSC then you should leave it interlaced for sure. If your source is film, then you should choose 3:2 pulldown on playback.

As for what progressive stands for, it means every single line of the video is scanned, instead of scanning only half the lines (as in what happens during interlacing).

Guille, for your video you should definitely keep your source interlaced through the entire process as you will likely loose overall motion from one frame to the next in your video.

Thanks for your time.

Guiboche

[guillep2k]

Thanks, Guiboche.
BTW... Do you know why FlaskMPEG claims always to give a progressive video output, even when I uncheck the "deinterlace" option? Will that affect my output? Should I use another program?

Thanks a lot

Guille

[neto]

Look, when a video is in InTerlaced mode it means that it's mean to be played in a TV which will display the image correctly. And if it's progressive, it means that its meant to be played on a Computer screen.

Interlaced: Will display each line of the image "even and odd".
Progressive: Will display the entire image at once.

But right now i don't know how to detect of a DVD video comes with interlaced or progressive because i don't work with DVDs.

What i would do is: I suppose the DVD comes with interlaced video, so if you want to make a SVCD or whatever and this will be played only in the computer you have to deinterlace when encoding. Or if you want the SVCD be played on the TV you have to leave the "deinterlace" option uncheked so that it remains interlaced. But try each option with 1 minute of video before you do the entire movie.

[zzyzzx]

Always deinterlace when making a SVCD.

[guillep2k]

zzyzzx, why would that be? Give me some background, please.

PS: Remember I want the MPEGs to be seen on the TV.


<font size=-1>[ This Message was edited by: guillep2k on 2001-08-21 11:57:11 ]</font>

[KoalaBear]

I'm in a talkative mood today (don't worry, it won't last) and I like theoretical questions because one of the toughest tests of understanding something yourself is being able to explain it to somebody else.

To deinterlace, or not to deinterlace: that is the question. The answer involves understanding certain facts about analog television that are obsolete with regard to digital video, and interlacing happens to be at the top of that list.

Back in the 1930s when television was invented, the electronics of the era weren't fast enough to handle 60 frames per second, a frequency which was chosen because it's equal to North American household line current and therefore a handy synchronization reference. But 30 frames per second, within range of those electronics and a handy 1/2 the current frequency, was intolerably flickerish given the rapid decay rate of the phosphors they were working with at the time.

So somebody came up with the idea of transmitting 30 half-frames, composed of either the odd or even lines of a particular picture, 60 times a second. By the time the odd lines decayed the even lines were already drawn and the odd lines could be retraced, and so forth. This allowed television to have a frame rate high enough to sustain the illusion of motion and a refresh rate high enough to eliminate flicker simultaneously, using household electrical current as a time base and best of all, without the need for complex and expensive frame buffers which wouldn't be invented for another 30 years (or videotape, which Ampex gave the world in just 20).

But TV frames aren't really comparable to film frames. Each TV field is scanned independently from the others, so the motion it contains is 1/60th of a second in the future with respect to the last. A video frame contains information from the present in its odd fields, and from the future in its even fields, each field conveying 1/60th of the total motion per second to the display each instant. (Remember, frame buffers weren't invented yet. Where -- and how -- could a TV hold half a discrete picture until the other half arrived? It had to use those fields at the instant of presentation or lose them.)

Modern capture cards deliver 30 full frames per second containing both fields in their entirety, but the fields are time-displaced with respect to one another. Digital video is inherently progressive, much like film, and in fact the capability of dealing with interlaced frames didn't come along until the debut of MPEG-2, which was more closely tailored to commercial video production applications.

MPEG-2 handles interlacing using something called "the alternate scanning order" versus "the zigzag scanning order" of MPEG-1. Alternate scanning is intended to provide a mathematical basis for motion prediction when every other line represents the position of an object in the future, and if it's difficult to comprehend that description it's even more difficult to build a useful compression system that can make effective use of it. Nevertheless, it explains why CinemaCraft charges as much as it does for its MPEG-2 compression products, and why hardly any of those copies in use are properly licensed.

Be that as it may, interlacing is only really required for handling materials that originated on video versus materials that originated on film. Film sources can readily be converted back to its native 24 progressive frames per second using inverse telecine (IVTC), and in fact they should be, because both MPEG-1 and MPEG-2 handle progressive frames natively.

But video-originated sources are more difficult to handle, because every other line of the picture is inherently time-delayed. The only effective way to deinterlace these materials is to convert each field to a separate frame, resulting in 60fps video, and throw away every other picture so that the frame rate remains constant at 30fps.

Finally, DVD players are designed to regenerate interlaced fields from progressive frames whenever necessary, as most movies are recorded at their native 24fps. If you deinterlace your material regardless of its source it will look good either way, because PCs can only handle progressive frames and when you play it back on a TV the DVD player will take care of the interlacing if that's necessary.

Now that we have the how and why of interlacing out of the way, I can answer the original question: when transcoding interlaced MPEG-2 to interlaced MPEG-2, does selecting the deinterlace option allow the encoder to re-interlace the source video as it sees fit for the target?

The answer is no. A playback device like a DVD player will re-interlace video for TV display, but from the MPEG encoder's perspective it doesn't care whether interlacing is present or not. Whether the interlace structure is preserved across the transcode depends on the method in which the frame is reconstituted during the conversion process.

A program like re-MPEG will attempt to construct new frames from the motion vectors of the source. This would preserve the interlace structure if it was present and encoded in the original. A more traditional encoder would reconstruct each frame in memory and convert it as if it were a raw AVI, honoring the interlace preferences you specified with respect to the source.

Hope this helps, though I realize the background is purely tangential to the question.


<font size=-1>[ This Message was edited by: KoalaBear on 2001-08-21 16:05:01 ]</font>

[guillep2k]

KoalaBear (thanx for taking that time to write!), what I can get from what you wrote is: keep it interlaced if it comes interlaced and you want to play it interlaced. However, zzyzzx tells me I MUST deinterlace! What am I missing?

My maths look like this:

DVD is interlaced + I deinterlace it to make a SVCD + My SVCD player (Sampo DVE-620) re-interlaces it because it will be shown in a NTSC TV = Poor results

On the other hand:

DVD is interlaced + I make an interlaced SVCD + My SVCD player (Sampo DVE-620) plays it like it is = Good results

Of course, if I WOULD be authoring a PROGRESSIVE MPEG2 file (which is not the case), then I MUST deinterlace the source because deinterlace is the process that makes progressive an interlaced video.

Correct me if I'm wrong, please.




<font size=-1>[ This Message was edited by: guillep2k on 2001-08-21 15:59:47 ]</font>

[KoalaBear]

Hmmmm, this is really a more difficult concept to explain, but I'll give it a try.

Remember that interlacing isn't important or even necessary to motion picture reproduction. It's just an obsolete data compression technique somebody invented a long time ago that serves no useful purpose anymore, except that 200 million television sets think it's the only way to do things and if you want them to play something back you have to give it to them in exactly that format they require.

When DVDs are mastered from motion pictures, either the MPEG is generated directly from a movie print (24 fps progressive) or a digital videotape of a movie print (30 fps interlaced). The DVD player looks at the MPEG and if it's 24fps progressive, it slices-and-dices the frames in the order it needs to display the picture properly on a television set.

When you convert a DVD to VCD by capturing it, you capture the 30fps interlaced version whether it was encoded on the DVD as 24fps or not. It looks exactly the same as the 30fps version and in fact you cannot tell which is which. Both were created from a 24fps progressive-frame motion picture, but in one case the interlacing was performed before the DVD was mastered and in the other the interlacing is performed by the DVD player during playback. The important point is that regardless of the method, both look exactly the same to a TV.

Nevertheless, this 30fps interlaced version of the movie is totally bogus, and it can be converted back to 24fps progressive using inverse telecine. There is no need to preserve the interlacing because it's an unnecessary artifact to begin with. When you create an MPEG from a movie that has been restored to its original 24fps, the PC handles it correctly (because it's progressive) and the TV handles it correctly because the DVD player knows how to interlace it for that kind of display.

When you make a VCD from a DVD by transcoding it, the same is true. If the source is 24fps it's progressive, and if it's 30 fps it's interlaced but can be converted back to 24fps progressive the same way for the same reason.

The only time this isn't true is when the picture originated on videotape and not motion picture film. Because the picture was never progressive to begin with, it cannot really be undone. You have to either preserve the interlace structure, which MPEG-2 is capable of doing, or deinterlace the picture through blending or interpolation or a combination of both.


<font size=-1>[ This Message was edited by: KoalaBear on 2001-08-21 17:22:22 ]</font>

[guillep2k]

KoalaBear, this is different: the source is a true interlaced 29.97 fps source because it's not from a movie (24 fps) but from a TV series! In movies translated to 29.97 MPEG2 you have normally 24 fps + flags to repeat each frame. Instead, -I presume- I have 59.94 different interlaced fields per second (no tff/rff encoding). I might not know about MPEG encoding, but I know about TV encoding and I can tell you this: interlace (at least in TV) makes a difference, as the picture will be changing through time.
i.e.: If you are shooting a vertical bar moving fast from left to right, top lines of the first field may have the bar at the left, bottom lines of the first field may have the bar at the center left, top lines of the second field (conceptually the same frame, ¿ok?) will have it at the center right and finally, the bottom lines of the second field may have it at right. There's no chance to remove repeated fields (inverse telecine), because there ain't any. Every frame is meaningful and different. If you merge even and odd fields you get noise, because the bar moved during the scan (as opposite as movies, where every frame is a still picture taken every 1/24 sec.). Though it is true that interlacing is an old trick, it still behaves in it's own way and ignoring it may affect the results.

All this theorical television stuff is bugging me when I want to think about MPEG encoding. While I can walk firmly in TV ground, I cannot tell the same 'bout MPEG and SVCD.

However... come to think of it, I'm trying to convert ANIME (cartoons), and chances are that every line in a field contains information about a static picture (as opposite as live video recording)... The cuestion is... How anime editors mastered the original (you know, computer added special effects may be 50 fps with interlacing, whilst cartoon cells may be only 30 fps or 24 fps at the edition console)?

I found a page talking about this subject and I'm gonna give it a good reading:

http://www.inwards.com/~dbb/

Then I'll tell you.

Guille

<font size=-1>[ This Message was edited by: guillep2k on 2001-08-22 11:01:52 ]</font>

[guillep2k]

Well... finally I tried not deinterlacing it and it went VERY well. However I had to do this page's trick to find out which field (top or bottom) to start with. I tried to deliberatedly start with the wrong field to see how it looked, and the problem was very noticeable in high-motion scenes. I skept the IVTC processing because I didn't need more bitrate (I used real 29.97 fps encoding).

**And** this was the page that answered me all the interlacing questions.

Thank you all for the info. Hope this 2 cents help too.

Guille

[kinneera]

So just to make absolutely sure I understand everything... My video source is DVD, run through inverse telecine with DVD2AVI, so I have a 23.976 fps source. No de-interlacing, and progressive encoding in TMPGEnc, will produce the best results? Also, if this is the case, what is the benefit to MPEG2 over MPEG1? And whatever it is, does it apply at a bitrate as low as 2200Kbps VBR?

[KoalaBear]

If you're ripping VOBs from a DVD, the movie it contains might already be 24fps, in which case there's probably no need to do anything apart from maintain that framerate throughout the conversion. If it got telecined to 30fps prior to mastering, it's to your benefit to undo that process if you can. Sorry I can't offer more specific advice than this; I don't use DVD2AVI or TMPGenc, but it sounds to me like you get the idea.

The primary benefit of MPEG-2 is that it allows you to combine multiple program sources, each with a different time base, into a single stream. You can transmit multiple channels on the stream if you want to (like digital cable), or the same program in several different resolutions (like HDTV will do), or multiple angles of the same scene (like DVD is capable of). The syntax was relaxed to allow playback devices to enter the stream on any I-frame and start playback from that point forward, without many of the restrictions (sequence header, closed GOP) imposed by MPEG-1.

Take a look at The MPEG-2 FAQ for many very juicy details about the standard.

[kinneera]

It appears the DVDs are telecined, not enabling the iDCT in DVD2AVI produces video that TMPGEnc detects as 29.97, whereas enabling iDCT makes it 23.976.

On the subject of MPEG2, I see how some of those features are beneficial for broadcast oriented uses, but does the image quality itself really differ much between MPEG1 and MPEG2 at equivalent bitrates when its progressive video?

[rdad]

If I want to play my svcd in progressive mode (with a progressive scan dvd player and tv), should I convert the video to progressive format first before burning the SVCD? Or will a progressive dvd player convert interlaced video to progressive before outputing?

[Lamont Cranston]

<font size=-1>[ This Message was edited by: lamont cranston on 2001-08-25 12:30:55 ]</font>

[KoalaBear]

MPEG-1 and MPEG-2 use the same compression engine underneath. At identical resolution and bitrate there should be no difference in the output except what can be attributed to the quality of the encoder, bitstream syntax, packet overhead and so forth.

MPEG-2 applications allow for higher resolutions and bitrates than MPEG-1, but the pictures are encoded and decoded using the same algorithms. The idea that MPEG-2 is inherently more efficient than MPEG-1 is a myth. However it does contain extensions that make it more suitable to broadcast applications such as interlace support, extended chroma precision, and multi-program bitstreams.

What that means to us is that it's possible to use MPEG-2 as a workaround for things you would otherwise have to deal with in MPEG-1, like interlacing. Not deinterlacing your source is a perfectly legitimate (and certainly much easier) alternative to the deinterlacing problem, and in absolute terms it's probably no less efficient.

The question is one of what looks best in the playback environments you want to support versus the amount of pre-processing you're willing to perform.

With film source, IVTC is equivalent to getting a 20% increase in bitrate for free, so there's a big carrot dangling at the end of the stick. With video source, there is no comparable gain in efficiency, the pictures just look better when played back on a PC.

[rdad]

KoalaBear, what about the cases in which you want to watch the video in progressive mode on your TV? Do you deinterlace the video before burning on those occasion?

There is something I can't understand about SVCD plyback. SVCD and DVD both use mpeg2. I suppose that there is no difference in the encoding of the mpeg2 on both. We all know that DVDs can be played back in Progessive mode for better video quality. My question is: Can all SVCDs be played back in progressive mode? Or only the ones that were deinterlaced before burning?

Can u explain what is going on with dvd players that support progressive mode?

<font size=-1>[ This Message was edited by: rdad on 2001-08-25 16:17:08 ]</font>

[KoalaBear]

Rdad, I just don't know. I don't own any progressive playback equipment. I can make some educated guesses about the way that they work, but they're still just guesses.

Logically, a progressive scan DVD player should be able to detect whether the source it's playing back is progressive or interlaced and switch its method of handling the material accordingly. Even when you play back a 24fps progressive source on a regular DVD player, it "knows" it has to do a 3:2 pulldown to bring the material back to 30fps before it can interlace the fields for display.

Thus, a progressive scan system should always construct progressive frames regardless of the way the media is coded, the same way an interlaced system always constructs interlaced frames regardless of the way the media is coded. If you deinterlace the source in the process of making a recording your progressive-scan PC will thank you for it, but your progressive-scan DVD player probably won't care.

The principle of the interlaced-to-progressive mechanism isn't hard to understand. In fact, I use the technique to deinterlace NTSC video myself.

Basically, each frame gets separated into its two component fields. Each field is then line-doubled back to a full frame. You now have a 60fps progressive video. Field dominance is no longer an issue, so you throw away every other frame to bring the rate back to 30fps, and you're done. Here is an AviSynth script that does exactly this:

AVIFileSource("d:\capture.avi")
DoubleWeave
SelectEvery(2,0)

Simple, huh?

The part I'm not clear about is how a mechanical device would handle the process. Unless you own a special TV that can display 60 full frames per second, it would also have to throw away half the frames in order to match the standard display rate. Then it would be forced to re-interlace the frames into display fields, which brings it back to the exactly the same place it started from. I don't see the benefit in that case, but I'm obviously missing a few pieces of the puzzle.

What it boils down to is that your progressive scan DVD player should be happy with whatever you give it and produce comparable results either way.

<font size=-1>[ This Message was edited by: KoalaBear on 2001-08-26 08:08:36 ]</font>

[rdad]

Thanks for your input. Makes sense to me.

[pelles]

I'm really a newbie here and just have a question about something I recently captured.

I have a VHS and captured it at 29.97 fps (whoops?) in virtualdub. Should I convert it to VCD as it is or utilize a 3:2 pulldown filter or something of the sort? The only visible artifacts which could be from capturing it at 29.97 fps are some instances of 'ghosting' during motion.

Thanks for your help.

[Cart Wheel]

If your source is NTSC video, you were correct to capture it at 29.97 fps. You should attempt to inverse telecine if your video was telecined (run through 3:2 pulldown). You can tell if it was telecined by looking at your video (hopefully captured in 480 lines) and checked to see which frames have interlacing artfacts (horizontal lines during motion). If you see a pattern of 3 interlaced frames folowed by 2 non-interlaced frames, you can inverse telecine. If every frame is interlaced, you can deinterlace your video to remove the ghosting during motion. I suggest using the 'Deinterlace - area based' filter for VirtualDub. (Use interpolation mode if you want to prevent ghosting.)

-Cart
http://www.geocities.com/lukesvideo/index.html