Interlace

http://nickyguides.digital-digest.com/interlace.htm

VCD's are interlaced, and sometimes it is done horribly wrongly.

Many recent NTSC dvd's are progressive 24fps, but a surprising number of NTSC dvd's are interlaced, and many of those from China are interlaced crazily, apparently to make them look like VCD's.

Fortunately, if you use '-x mplayer="-vf yadif"' you can get very good results from even crazily interlaced source.

Phil Ehrens

On Tue, 12 Sep 2006 16:51:37 -0700, Phil Ehrens wrote:

I thought so. Hmm, that means the traditional transcode agent mpeg2enc doesn't support VCD creating then, since VCDs are encoded as MPEG-1. correct? Ref:

**ERROR: [mpeg2enc] Interlaced encoding (-I != 0) is not supported by MPEG-1.

hmm… I read "even non-interlaced video will be written interlaced on the dvd" [1], now I've confirmed that it is wrong. Progressive 24fps? interesting, any luck to have burnt such DVD anyone? How did you do that, say we are converting from a 23.976fps avi? I remember when tried encoding without pulldown, I get the following when doing the dvdauth:

not a valid DVD frame rate: 24000.0/1001.0 (NTSC 3:2 pulldown converted FILM)

thanks

[1]avi to dvd converter http://www.linuxquestions.org/questions/showthread.php?s=&threadid=295947

Same problem here, I could never figure out how to get 24fps to work on an NTSC dvd either, though it would be great to be able to. I just make everything 30fps. BTW, every 24fps feature I have seen has had a short chunk of 30fps at the very beginning, but I can't see how that could qualify as any sort of "trick", I think it's just that the distribution companies all do their logos at 30fps.

By the way, I often see Chinese dvd's where there is a deluxe Hong Kong release at 24fps, and then a bunch of *ahem* other releases that are all at 30fps, and usually one with the interlacing backwards or sideways for good measure. There is also often one dvd that is "recovered" from a vcd that is a total throwaway.

Phil Ehrens

Found a good reference at

http://www.allformp3.com/dvd-faqs/34.htm

Seems quite complicated. Here is the extract:

T

documented on: 2006.09.15

http://www.linuxquestions.org/questions/showthread.php?s=&threadid=295947

Yes, several, but dvd creation needs some knowledge. It's easy to convert the avi to correct format for dvd, but creating menus for dvd is not yet very simple. Also you need to think the conversion also (interlaced video should be kept interlaced to preserve maximum information, even non-interlaced video will be written interlaced on the dvd), so do some googling about dvd and interlacing.

Easy gui-programs for format conversion:

command line:

wine programs:

For dvd creation:

simple gui frontends to dvdauthor:

nbd

documented on: 02-28-2005

To fully understand this (and why interlacing should be abandoned asap) you need to have a little insight in the technology behind this, which I will try to have a go at.

No, never do that (as the others already mentioned).

See #2 ;-)

Beside the other explanations, there is also the possibility that one field (half frame) was lost, so the pairing of the fields into frames is no longer valid; field #1a belongs to frame #1, field #1b belongs to frame #2, field 2a belongs to frame #2, etc.

Rationale about interlacing: back in the ol' days (~1940-1950) when the first television sets where produced, it was decided that a refresh rate of 50 Hz / 60 Hz (depending on country) was necessary to get fluent motion. That would mean that the resulting video signal would be > 15 Mhz, which apparently was not believed to be acceptable. Also it apparently was too expensive to make television sets that would be able to handle this. This is where the concept of interlacing was introduced; the even and odd numbered lines were to be broadcast separately, sequentially. The result is the required 50/60 Hz refresh rate, keeping the full resolution, BUT only when there is no motion. When there is motion, the actual resolution is only half of it. It was easy to implement this (= cheap!) by choosing tube phosphors that keep emitting light for roughly the time period the complete field is to be seen on the tube, after being "hit" by the electron beam.

So, this means you actually can only view interlaced material on a system that has exactly these characteristics. Computer monitors and TFT/Plasma screen do not have these characteristics. All their pixels are visible all of the time, they do not fade. Also their refresh rate is typically 60 Hz (exact, no 60001/1001 as used in ITU-R "M" TV broadcasting). In case of a computer monitor, there is also a VGA card between the computer and the screen, which may use it's own, different refresh rate (although this is not recommended).

This means that the two fields (= odd lines / even lines) always get send as a complete frame (= all lines) to the VGA card (in a computer) and to the screen (computer/TFT/Plasma). There is no sense in separating them because the digital screen won't be able to show them separately (as a tube does) anyway, all pixels are always visible AND the internal pixel update frequency is never coupled to the input signal.

The result is that on a digital screen (computer monitor/TFT/Plasma) you always see both fields at the same time, which really is not the intention, because the fields are recorded half a frame time from each other. This is where the comb effects come in. What you actually see is the same object, at two different points in time, half of it from time x, the other half from time x+1/2.

You can never get this completely right. There are several algorithms that try to minimise the loss of resolution and motion data, but the result is always more or less disappointing. The more resolution you try to preserve, to more motion data is lost and vice versa.

So, how does it come interlacing is still used? I honestly don't know. Especially using digital TV there is no reason at all to use interlacing, if it were only because digital screens cannot even display it properly! When I see interlacing is supported for mpeg4 and even mpeg4-avc (aka mpeg4-part10 aka h264, imho the future of digital TV), I get very very sad.

I consider myself lucky, in that I live in "25 hz land", so my DVDs are, although interlaced, in fact actually progressive (because both fields of all frames actually the same).

Erik Slagter

On Thu, 2006-01-05 at 09:30 -0600, Kenny Gow wrote: > > I would like to get a basic understanding about interlacing. Especially > > I have the following questions. > > > I found a nice website with many examples about interlacing > here: > > http://www.100fps.com/

Nice, informational pictures, but I do miss some basic, real technical stuff here to explain the whole. The whole story about the electron beam in a legacy tube is not mentioned while it is fundamental to the interlacing concept.

Erik Slagter

There's a fairly good description (written by yours truly, so IMHO ;) ) at http://www.transcoding.org/cgi-bin/transcode?Interlacing that covers most of these points; see it for more details.

Yes, that's correct; CRT-style TVs are interlaced, and newer LCD or plasma TVs have hardware that filters out the "comb" effect (essentially deinterlacing the video on the fly).

That's correct. Use the —encode_fields option to transcode to indicate that the source video is interlaced, and the output video will be interlaced as well.

Absolutely yes. By deinterlacing, you lose half of the original video data, which can make movement look visibly jerkier and still images look blurrier.

Assuming you're talking about commercial movies, such movies are originally recorded at 24 fps (frames per second) in progressive (non-interlaced) mode. In PAL countries, the video and audio are sped up slightly to match the 25-fps TV standard; in this case, there's no need to modify the video data, and it shows up on both TV and PC in its original progressive form. In NTSC countries, a process called "telecining" is used to convert the movie to the 29.97fps TV standard, which results in some frames being interlaced, but PC players are generally smart enough to reverse this. However, when you re-encode the video to another format, the video data is modified and the telecining process can no longer be detected, so you occasionally see interlaced frames show up on your PC.

Andrew Church

That's sort of like asking "why does only half a liter of water fit in this half-liter bottle?" ;) Interlaced TV sets are designed to produce the "proper" brightness given a certain input video.

Andrew Church

On Fri, Jan 06, 2006 at 12:13:41PM +0100, Erik Slagter wrote:

it's called fieldanalysis.

http://www.transcoding.org/cgi-bin/transcode?Filter_Plugins/Filter_Fieldanalysis

there has been discussion of the usage in the list before … maybe find it in the archives.

Jacob Meuser

0n 05/11/25 <at> 11:06 Jeff Hyche told me:

If the video is interlaced and you want to keep it interlaced (my advice, if you encode for CRT-TV) you just have to tell transcode which field is first (—encode_fields).

PAL is normaly (from TV) top-field first, ntsc bottom-field first. In case of DV source both are bottom-field first.

I guess Jeff wants to check whether the source is interlaced at all..

If in doubt (both whether interlaced and - if interlaced - what field-order), try the "fieldanalysis" filter.

Deinterlacing a non-deinterlaced source-material will degrade quality.

http://www.transcoding.org/cgi-bin/transcode?Filter_Plugins/Filter_Fieldanalysis

*Tags*: fieldanalysis — transcode plug-in/plugin/filter to detect progressive/interlaced/telecined video

fieldanalysis scans video for interlacing artifacts and detects progressive / interlaced / telecined video. It also determines the major field for interlaced video.

Usage Examples: No.

documented on: 2006.01.08

Hi folks!

I have another patch for you that adds a filter for detecting the field type of potentially interlaced video. Some of its parameters may need a little tweaking, and of course it cannot determine the field type on static scenes. It also is not extremely fast, but it is fast enough for me :-P .

There has been the filter 32detect (which is an odd name as it only detects interlaced video as well), but my analysis filter knows of more different field types and seems to have more stable algorithms. It also detects field shifted progressive video, though it currently identifies too many frames as shifted-progressive for truly interlaced video.

Due to the past issues with *_memcpy, I stick to libc memcpy right now, but there is already plenty of #if 0/#endif 'd code in there, if somebody has the nerve to test this with different architectures.

An example output looks as following:

Hoping that this is as usefull to others as it is to me :^)

Matthias Hopf