Interlaced film versus TV content

[BizUser]

As I tackle my 'project' of converting PAL TV-show DVDs to NTSC SVCDs and VCDs, I got into the whole issue of interlacing. I've read faq's, web pages, etc until my head spins. I 'think' I know what's going on. If someone could please confirm, and answer the odd question, that would be appreciated!

Question: does the MPEG2 spec require video information to be stored as field data (half-frame), as frame data, or is it flexible enough to store either type of data? I'm guessing both - video sourced material (TV-shows, etc) is interlaced and thus field based info will be stored. Film based material is inherently progressive and thus frame based info will be stored.

The latter assumption - that film based material will be stored frame based (progressive) was contradicted by several web sites I viewed. The following quote is from one such site, and the essence of it is is that even film based material is stored interlaced (field based). http://www.dvdinternational.com/480P.htm

DVD is specifically designed to be displayed on interlaced-scan displays, which covers 99.9% of the television sets worldwide. However, most DVD content comes from film, which is inherently progressive. To make film content work in interlaced form, the video from each film frame is split into two video fields -240 lines in one field, and 240 lines in the other- and encoded as separate fields in an MPEG-2 stream

Here is another site (which, by the way, must have the BEST demonstration of interlacing artifacts!) -
http://www.plasma.com/classroom/Proscanexplained.htm


sources which are truly progressive in nature are hard to come by right now. Movies on DVD are almost always decoded as interlaced fields yet all of the film's original frames are there, just broken up. What we're going to talk about next is how we take the interlaced content of DVD and recreate the full film frames so we can display them progressively.

So this is clearly suggesting that even progressive movie sources are stored interlaced, is it not? Or is it that the datastream is always field-based, which is 'interlaced TV' friendly - but not the same thing? Come to think of it, when I play a movie in my regular (el-cheapo, not progressive scan) DVD player, and view it on my regular (not progressive) TV screen, something is doing the interlacing... so the information 'must' be interlaced on the DVD??? (I'm not getting into the telecine /pulldown process here, which I understand).

So when I run that Movie DVD through dvd2avi, and it says 'progressive', what is it telling me (I've read the guide "Force Film, IVTC, and Deinterlacing - what is DVD2AVI trying to tell you and what can you do about it? " but for some reason I can't quite get my answer there!)? When it says 'progressive', it can't be that the info is stored purely in a frame based, progressive manner, can it - if so, how can I play that DVD on my TV? I'm sure I'm missing some fundamental point here ...

My more fundamental question is with a truly interlaced source.

If the content of a DVD is a TV show (video source) - can it ever be meaningfully de-interlaced to a 'frame' for processing in an editor? What I'm wondering is - does a professional (studio) video camera shoot successive fields, temporally, or does it shoot successive frames temporarly, then split the frame into two temporally-consistent fields? That is - does it shoot Frame1/Field1 Time1; Frame1/Field2 Time2; Frame2/Field1 Time3; Frame2/Field2 Time4 .... or, does it shoot Frame1/Time1; Frame2/Time2, then create Frame1Field1, Frame1Field2 for Time1, then Frame2/Field1, Frame2/Field2 for Time2, etc.

If it's the latter, then you COULD reconstruct a perfect source frame, but if it's the former, then you can't reconstruct a perfect source frame (can't avoid motion distortion) (my theory!).

Reason I think this matters is, as I try to do frame rate conversion for PAL->NTSC, I'm trying to decide is it better to work at the frame or the field level. The material I'm trying to convert is TV-show material - created using studio video cameras, presumably. If each field is temporally different, then it seems better to work at the field level (convert to 50 fps, etc); but if adjacent fields are from the same time slot (and therefore not subject to motion distortion relative to each other), I may as well reconstruct (de-interlace) the frames and work with them.

I realize this may belong in another forum, but I started here since I'm trying to convert stuff to SVCD!

EDIT: I've searched the web extensively, and pretty much concluded that MPEG-2 indeed does support both frame and field based content. Most conclusive info was here http://www.broadcastpapers.com/sigdis/Snell&WilcoxMPEGVideo07.htm, which included this snippet "The picture header again has a unique start code and contains picture-specific control information, for example whether the picture is a field or a frame, its picture coding type (I, P or B), ".

I also found a site that pretty much convinced me that fields in video sourced data are indeed temporally different - that is, the 'even' field is time 'x', the 'odd' field is time 'y'. Thus, you cannot create a 'perfect' de-interlaced frame of such material.

My question above about dvd2avi and it's 'progressive' indication still remains, though! Thanks!

[htc10825]

A DVD movie may be encoded as progressive but also interlaced(in this case you waste many bits). But not "must"!
A video source(TV show/concert) usualy should be encoded as interlaced.

A regular DVD player displyed the dvd contect always in fields(interlaced) regardless the source progressive or not.

A regular Camcord record the video contect always in fields(interlaced) regardless the source type.

Only the very rare HDTV video camera can record the video content in prograssive frames, which could be found in the next-generation dvd. The so-called blue laser dvd.

[Xesdeeni]

@htc10825

Many standard definition DV camcorders (including mine) can record in progressive as well.

@BizUser

Apparently many DVDs of films are encoded as interlaced fields, although they could just as well be encoded progressively. If they were encoded progressively, the DVD player can easily handle the telecining (for NTSC, just plain interlacing for PAL) on playback. As htc10825 mentioned, it seems silly to encode progressive content interlaced, since the quality would be better if they were encoded progressively. But it could be worse if they encoded full-fledged telecined video for NTSC DVDs. Thankfully, they normally only encode 48 fields per second and tell the DVD player how to repeat a field to telecine the output....does a professional (studio) video camera shoot successive fields, temporally, or does it shoot successive frames temporarly, then split the frame into two temporally-consistent fields...Yes :) As I mentioned above, my camera can record either interlaced or progressively. How that is handled when editing is a bit more complicated.

For NTSC, the DV stream is encoded as frames. When the camera is capturing interlaced video, the bottom field occurs before the top field in time.

For PAL, there is an option for the DV stream to be encoded as fields. And I believe the encoder can actually switch between fields and frames on-the-fly. But again, when the video is interlaced, and the encoding is done as a frame, the bottom field occurs before the top.

Most editing packages deal in frames, so if there is part of one scene in one field and part of another in the other field, you may run into a problem editing.

With regards to standards conversion, if the input video is actually interlaced, you are best to keep with a field-based domain. In my conversion script (http://forum.doom9.org/showthread.php?s=&threadid=35387) I use my AVISynth port of Gunnar Thalin's SmoothDeinterlacer to convert the incoming fields to frames. But that's 60 fields to 60 frames (or 50 fields to 50 frames), not 60 fields to 30 frames (or 50 fields to 25 frames). Then the frame rate is converted by either dropping/duplicating frames (ChangeFPS()) or interpolation (ConvertFPS()). Finally the frames are converted back to fields by throwing away half of each frame.

If the input is progressive, then it should be reconstructed (just interleaved for PAL, or inverse telecined for NTSC). Then the recommended approach is to speed up or slow down the video (23.976->25 for NTSC to PAL, 25->23.97 for PAL to NTSC). Normally 24 fps film is sped up (to 25 fps) for PAL and slowed slightly (to 23.976 fps) for NTSC (before being telecined) when converted to video. So doing this yourself is similar to what is already out there.

Xesdeeni

[BizUser]

Thank you SO MUCH for your reply! It never occurred to me that the DVD player itself would be doing the interlacing - I assumed that was not something that could be done real-time on a cheap box (well, the 2:3 pulldown is obviously done real time...).

I visited the thread regarding standards; looks like you and I are doing the same thing - converting British comedy DVDs (I just got 'The Office', 'The Royle Family', 'French and Saunders', and 'Allo Allo' DVDs from the UK) to play on my NTSC system here in the US.

The thread looks very interesting and 'exactly' what I need - working on fields not frames - I will definitely try it!!! And best of all, unlike most programs or scripts on the planet, it has more comment lines than code lines - A LOT more!!! The thread extends to about 30 or more messages, and some messages discuss possible problems and possible solutions. For my purposes, I'm simply planning to use avisynth as a frameserver to tmpg; if I follow the instructions in the basic post, should I be OK, or do I need to take note of any subsequent posts (I read them already; I mean ... do I need to do anything about them...:) )?

I tend to make both SVCD and VCD copies; SVCD because it's better quality, VCD because it's more compatible. SVCD is obviously MPEG2, and can be interlaced or progressive. What's the deal with VCD (MPEG1 format)?; is that restricted to interlaced only, progressive only, or what?

Thanks again!

[htc10825]

VCD is always progressive - in fact it uses only one of the two fields.Many standard definition DV camcorders (including mine) can record in progressive as well.But have you ever seen a broadcasted TV-program or a DVD with the video recorded by progressive DV?

[Xesdeeni]

@BizUserI visited the thread regarding standards; looks like you and I are doing the same thing - converting British comedy DVDs (I just got 'The Office', 'The Royle Family', 'French and Saunders', and 'Allo Allo' DVDs from the UK) to play on my NTSC system here in the US.So far I've only worked with 'Porridge' and a Dr. Who episode ('The Five Doctors'). From speaking with some British folks, I worry that I wouldn't get most of the jokes in 'The Royle Family,' since they told me that they are heavily slanted toward domestic and political events and people. I haven't heard of 'The Office.' I'd love to see some 'French and Saunders,' but I don't know if I love 'Allo, Allo' enough to take the time.And best of all, unlike most programs or scripts on the planet, it has more comment lines than code lines - A LOT more!!!So that's one vote FOR the comments and one vote AGAINST the comments (on www.VCDHelp.com) :)I tend to make both SVCD and VCD copies; SVCD because it's better quality, VCD because it's more compatible. SVCD is obviously MPEG2, and can be interlaced or progressive. What's the deal with VCD (MPEG1 format)?; is that restricted to interlaced only, progressive only, or what?For the SVCDs, I think you can do basically what I am doing for DVDs. However, you might want to see if your players can deal with an xSVCD encoded at 352x480. If it will, I suggest you use this resolution for your conversions, since this is a legal DVD resolution and will make it easy to copy your xSVCDs to DVD*Rs once you move up to a DVD burner ;)

For VCDs, which are strictly progressive (352x240), I'd suggest an alternate approach. I'm working on a matrix of standards and format conversions (sorry, I haven't done PAL DVD to NTSC SVCD yet). Here is an excerpt for PAL DVD to NTSC VCD (you can be my guinea pig :) ):

Tools
The following tools are used by the methods outlined below. Please consult the installation instructions of the tools specified. TMPGEnc (http://www.tmpgenc.net/) – MPEG 1 and 2 encoder (MPEG 2 encode requires purchase after the initial trial period expires).
AVISynth (http://www.avisynth.org/) – A script-based video processing application.
...
DVD2AVI (http://www.doom9.org/Soft21/Decoders/DVD2AVI_176.zip) – A tool for extracting the video and audio from DVD VOB files.
MPEG2DEC.dll (http://www.doom9.org/Soft21/SupportUtils/mpeg2dec_dll.zip) – An MPEG 2 decoder.
......
III. PAL (Video) DVD (25i Fps) -> NTSC (Film) VCD (23.976 Fps)
1. Run DVD2AVI and load the decrypted VOBs using the “Open” item in the “File” menu (you need to choose only the first one of a sequence).
2. Check the “None” item in the “Field Operation” sub-menu of the “Video” menu.
3. Choose the desired audio track number (usually “Track 1”) in the “Track Number” sub-menu of the “Audio” menu.
4. Check the “Decode” item in the “Dolby Digital” sub-menu of the “Audio” menu.
5. Check the “Auto Select” item in the “Channel Format” sub-menu of the “Audio” menu.
6. Check the “Off” item in the “48 -> 44.1 KHz” sub-menu of the “Audio” menu.
7. Select the “Save Project” item in the “File” menu.
8. Choose a location and filename for the DVD2AVI project name. A small text file with the D2V extension will be created, and the audio track specified above will be extracted from the VOB and decompressed to a wav file in the same location.
9. Create and open a new text file with an AVS extension (to be used with AVISynth), using your favorite text editor.
10. Add the following lines, filling in the location and filename of the file you created above:WAVSource("DRIVE:\PATH\AVSEQxx.wav")
ResampleAudio(Round(44100 * (25 / 23.976)))
AssumeSampleRate(44100)11. Save the AVS file.
12. Load the D2V file into TMPGEnc as the “Video Source.”
NOTE: Cancel the Wizard dialog box which appears when you run TMPGEnc.
13. Load the AVS file created above into TMPGEnc as the “Audio Source.”
14. Load the “VideoCD (NTSCFilm)” template into TMPGEnc.
15. Specify the location and name of the “Output file name” with an MPG extension.
16. Choose “Motion estimate search (fast)” or “Highest quality (very slow)” in the “Video” tab of the “Setting” dialog.
17. Double-click the “Deinterlace” item in the “Advanced” tab of the “Setting” dialog.
18. Choose “Even field (adaptation)” from the pulldown menu and click “OK.”
19. Check “Do not frame rate conversion” in the “Advanced” tab of the “Setting” dialog.
20. Press “Start” to convert and encode the video.

Author and Burn Your VCD
At this point your MPEG file has been created. However, in most cases it will be too large for a single VCD and must be split. Various methods exist for splitting the file and burning the VCD, but they are beyond the scope of this Standards Conversion document.

@htc10825VCD is always progressive - in fact it uses only one of the two fields.Technically, VCDs don't know anything about fields at all. How the 352x240 video is created and how it is viewed determine its relationship to fields.

For creation (assuming you are creating a 30fps VCD), you can indeed throw out one field of a standard video to create your VCD-formatted content for encoding. A better way, however, is to actually deinterlace the input and then scale the resulting frames down to 240 lines. You'll gain 1) better quality/smoother images due to scaling rather than decimation, 2) better noise suppression by combining adjacent lines, and 3) better compression because of 1 and 2.

For viewing (assuming a 30fps VCD):
1. You can output the 30 frames as 60 fields per second, repeating each frame twice. You can flag every field as the same polarity (odd or even). TVs actually support this non-interlaced format, but the separation between the lines will be much more apparent as horizontal black lines (older video game systems and computer modulators used to do this).
2. You can output the 30 frames as 60 fields per second, repeating each frame twice. In this case you could alternate the flags between even and odd. This will cut down on the black horizontal lines seen above, but now each line will appear taller since it's actually two lines. Some flicker will also be visible.
3. You can output a field and then output a field made of interpolated lines from the original field. This is the way most DVD players do things, and the results are quite good. In fact many people (although I must admit I don't agree) think this output method makes VCDs equivalent to VHS in quality.But have you ever seen a broadcasted TV-program or a DVD with the video recorded by progressive DV?Actually, I think I have. I haven't actually captured the video to take a close look and be certain, but I have seen programs that appear to have fewer then 60 "instants of time," but which don't appear to have the jutter or gamma of film. As for DVDs, I don't have that many myself (20 or so), but I have created DVDs with 30 fps progressive content that play fine. I suspect I'm not the only one:

http://www.ccgnv.net/admitone/filmlook.htm
http://www.adamwilt.com/DV-FAQ-etc.html#filmlook
http://www.epinions.com/content_60743061124
http://www.camcorderinfo.com/content/sony_dsrpd150_camcorder_review.htm
http://www.urbanfox.tv/production/p15filmlookshoot.htm#camera
http://www.cyberfilmschool.com/columns/saylor_DV101_4.htm

Xesdeeni

[htc10825]

VCD is always progressive - in fact it uses only one of the two fields.The fields in VCD - I did not say that there is field in VCD. I've only meened: by encoding(we do the conversion DVD->VCD) only the data of one field out of the two fields are mostly/likely used. The avisynth function "ReducedBy2" does this. And this is the fastest way to get resized and deintelaced. But your comment:Technically, VCDs don't know anything about fields at all. How the 352x240 video is created and how it is viewed determine its relationship to fields.says everyone except you are technically fool. Such assumption is not very cool.Actually, I think I have. I haven't actually captured the video to take a close look and be certain, but I have seen programs that appear to have fewer then 60 "instants of time," but which don't appear to have the jutter or gamma of film... blablabla...We all have seen many "hybrid" sources in last years. My request "have you ever seen a broadcasted TV-program or a DVD with the video recorded by progressive DV?" to you meens you should proof the the progressive sources in published DVB or DVD were recorded by DV-Camcorder, not a conversion of film scanner(like the produce in a dvd production). So important is "proof made by DV-Camcorder", not your asumptions. You can proof them if the producer said(published!) "we've made this dvd only with DV-Camcorder" and the video data on the DVD is progressive! But again, your asumption was everyone except you are technically fool and put many absurd comments. Have you a (mental) problem?

[Xesdeeni]

VCD is always progressive - in fact it uses only one of the two fields.The fields in VCD - I did not say that there is field in VCD. I've only meened: by encoding(we do the conversion DVD->VCD) only the data of one field out of the two fields are mostly/likely used. The avisynth function "ReducedBy2" does this. And this is the fastest way to get resized and deintelaced.Perhaps you choose to throw out one field when you convert from DVD to VCD, but that is not the only way to make the conversion. As I mentioned above, there are several benefits to deinterlacing and downscaling instead, and that's what I recommend whenever possible.

Also, from looking at the last AVISynth code I downloaded, if the input is an interlaced frame, VerticalReduceBy2() does not simply throw out one field, it still interpolates between adjacent lines: for (int x=0; x<row_size; ++x)
dstp[x] = (line0[x] + 2*line1[x] + line2[x] + 2) >> 2;In this case, the best way to throw out a field is to:SeparateFields()
SelectEvery(2,0)But your comment:Technically, VCDs don't know anything about fields at all. How the 352x240 video is created and how it is viewed determine its relationship to fields.says everyone except you are technically fool. Such assumption is not very cool.I'm sorry you took the statement that way, it was not my intention. Your comment implied (whether you meant it or not) that there was a definite relationship between the VCD content and fields (you didn't state whether during encode or decode). I was simply trying to clarify that there is no field information on VCDs and that because of this there are various relationships which can exist between the frames of a VCD and the input or output fields of standard interlaced video.My request "have you ever seen a broadcasted TV-program or a DVD with the video recorded by progressive DV?" to you meens you should proof the the progressive sources in published DVB or DVD were recorded by DV-Camcorder, not a conversion of film scanner(like the produce in a dvd production). So important is "proof made by DV-Camcorder", not your asumptions. You can proof them if the producer said(published!) "we've made this dvd only with DV-Camcorder" and the video data on the DVD is progressive!Yes, you obviously asked this in order to respond that I must provide proof that I had seen such a thing. I'm not sure why the existence (or not) of such content is relevant to this discussion. I admitted that I hadn't seen these things (for sure) in practice, but I did point out above that many professional videographers are very interested in the "film look," and that they use progressive cameras at 30fps as one way of achieving this. I strongly suspect that all of those professionals are doing something with their progressive content, either broadcasting it or distributing it on DVD.But again, your asumption was everyone except you are technically fool and put many absurd comments. Have you a (mental) problem?I'm not sure why you are choosing to add personal personal attacks to your post. This is most inappropriate for such a friendly and helpful site.

Xesdeeni

[BizUser]

Xesdeeni - thanks for the follow up. I will be your guinnea pig! (see below).

htc10825 - xesdeeni was very diplomatic and polite in his assertions/comments; he's not saying he knows it all, or 'this is fact'; he says, for example, (quote) (bolding by me) : "I haven't actually captured the video to take a close look and be certain, but I have seen programs that appear to have fewer then 60 "instants of time," but which don't appear to have the jutter or gamma of film. As for DVDs, I don't have that many myself (20 or so)... ". These are not the words of someone who is taking an aggressive stance on a topic. For you to respond that he is 'mental' or a 'fool' seems to be way out to balance to me. Since you are both long standing members and I'm a mere noob, I'll say no more.

Xesdeeni - I'll try your process shown above and let you know the results. It looks very close to the process I'm already using - to drop framerate from 25 to 23.976, then resample audio. Ironically, I was doing the framerate conv. in avisynth (assumefps), and the audio conv. in BeSweet, but it looks like the same overall method. Actually, I had to do a deinterlace in avisynth before the assumefps, which I don't see above. But maybe it's there ... let me play with it and give you feedback. The method both you and I are using does have the one downside that it alters the 'pitch' a little; not a biggie but if this were a live concert, that would be an issue.

I also tried the process you described in the other forum (linked to in this thread), using your port of the smoothdeinterlacer, hoping to get better results. To my dismay, the result was not as good. Since I'm a noob, I'm probably making a mistake. Basically, interlace artifacts are quite visible, and - worse- scene transitions are interlaced in the final result (that is, in the output stream, half of one scene is mixed with half of the next scene). I switched the "TFF" flag in the script, and basically, 'other' scene transitions now suffered from this effect. I then looked at the raw source, and confirmed that in the source, the scenes always transitioned on even boundaries, but in the output, transitions were occurring on odd frame boundaries. My hunch is that the frame rate conversion (in that script, you are duplicating/decimating fields to make up the difference, I believe) is introducing an odd number of fields, perhaps? Again, I'm a noob at this so I could be doing something dumb. This is definitely interlaced source, though, and the same show I've been testing with for weeks. If you like, I can post the VOB (it's a 146 Meg file - 3.5 minute extract I'm testing with) and any other stuff you may need to look at on a site I have access to - just temporarily of course!

We could also take this off-line; either PM each other or email (I think I saw your email address somewhere....). I could then go through your guides and provide feedback (I'm a noob at this, but have 20 years in software as programmer, DBA, IT, etc). I have family in UK and I want, ultimately, to be able to send / receive video in all kinds of formats so this is something I'm willing to spend gobs of time on!

Thanks again ...

[Xesdeeni]

Ironically, I was doing the framerate conv. in avisynth (assumefps), and the audio conv. in BeSweet, but it looks like the same overall method.I have been trying to simplify the process as much as possible. Part of that was to cut down on the necessary tools. I suspect that AVISynth + TMPGEnc isn't the highest quality solution for the audio, and that BeSweet would probably do a better job. But as you've no doubt noticed, BeSweet can be daunting.Actually, I had to do a deinterlace in avisynth before the assumefps, which I don't see above.(In my own twist of irony) Only the audio is actually processed through AVISynth in the process above. The video processing is done in TMPGEnc. I found that the "Even field (adaptation)" deinterlacing in TMPGEnc was very good, especially when you are going to then downscale to VCD resolution, so I opted to use that instead of my own SmoothDeinterlacer (port of Gunnar Thalin's VirtualDub plugin), again in the interest of minimizing tools.The method both you and I are using does have the one downside that it alters the 'pitch' a little; not a biggie but if this were a live concert, that would be an issue.Yes, I've always wondered about that myself. As I mentioned above, it appears that most film->PAL conversions are actually done that way. I watched a couple of movies in Europe the last time I was there and I didn't notice the pitch difference. And a friend got a music-heavy PAL DVD that I took a look at, and I didn't notice. Then again, I don't have "perfect pitch" (aka absolute pitch: http://www.m-w.com/cgi-bin/dictionary?book=Dictionary&va=absolute+pitch+).

When I get to NTSC film DVD to PAL DVD conversions, I'm considering including both speed up and non speed up methods, although I worry about the complications this will add. PAL film DVD to NTSC DVD is a bit more tricky. I think it is likely that the film source was already sped up. So slowing it back down is more likely to reverse the process, which might not be a bad thing. Without the change in speed though, the resulting video needs interlacing for smooth motion. That's why I didn't consider it for VCDs.I also tried the process you described in the other forum (linked to in this thread), using your port of the smoothdeinterlacer, hoping to get better results. To my dismay, the result was not as good....Basically, interlace artifacts are quite visibleIf you are referring to the conversion script for AVISynth, keep in mind that this is designed for interlaced to interlaced conversion. This isn't a good solution for VCDs. For SVCDs and DVDs, the interlacing is fine, and in fact you want it there in this case to help cut down on "jutter....I could then go through your guides and provide feedback (I'm a noob at this, but have 20 years in software as programmer, DBA, IT, etc). I have family in UK and I want, ultimately, to be able to send / receive video in all kinds of formats so this is something I'm willing to spend gobs of time on!I tried to see if we could get a standard conversion forum started, but Doom9 didn't think it was necessary. He suggested that we use the "New A/V Formats" forum. Perhaps we should start the thread there and we can begin working through the conversions.

Xesdeeni

[BizUser]

On the one hand, you want to cut down on tools, but on the other, if you've already downloaded and figured out DVD2SVCD, it would be good to use it's front-end since it does handle some of the funky stuff for you - like calculating total CDs, bitrates, etc. By checking the 'edit avisynth script', I'm able to insert my avisynth changes. There's also a way to supply additional parameters to the BeSweet command automatically; The only thing remaining is that, in my approach, I have to do a 'pulldown', and I have not yet got that integrated in the dvd2svcd process - but I'm sure it can be done.

Anyway - to your avisynth script - you say:

If you are referring to the conversion script for AVISynth, keep in mind that this is designed for interlaced to interlaced conversion. This isn't a good solution for VCDs. For SVCDs and DVDs, the interlacing is fine, and in fact you want it there in this case to help cut down on "jutter.

I was using it for conversion of my interlaced PAL source (TV show) and my intended output was SVCD.

Your comment in the script is this:

# This script works by first converting the input video from
# interlaced fields to progressive frames using an adaptive
# deinterlacer. Then the progressive frame rate is converted.
# Finally the progressive frames re-interlaced for output


I simply took your avisinth script 'as is', (pointed to my source, set output framerate to 29.976), and viewed the 'output' (the stream supplied by the avs file) in TMPG's 'interlace' screen (settings/advanced/interlace) - this lets you single step through each frame (I later did the same in VirtualDub and saw the same results). Maybe this is the wrong expectation? In TMPG, I saw frames created from clearly 'wrong' fields (highlighted by scene transitions). If I changed the value of the InputTopFieldFirst variable, it 'fixed' the scene transition in question, but other scene transitions suffered. I then simply removed the 'weave' statement close to the end of the script so I could see the un-weaved output, for 'debugging' purposes. This caused the individual half-frames (fields) to be displayed in the TMPG 'Deinterlace' window, and I could step through them field by field, with 'frame' (field) numbers displayed at the top. In this mode, since I'm dealing with 'doubled' output, the scene transitions should always occur on even boundaries, but they don't. If I take out the frame rate conversion (actually, set output = input) I see that scene transitions occur on even boundaries.

I'd be happy to make my source material avail. to you. I could chop it way down - I try not to test with real small clips because synch problems get hidden, but for this purpose, I could make it quite small I guess. The source I'm working on is, by the way, the comedy show 'Gimme Gimme Gimme', which is quite funny!

Regarding 'pitch change' - the show has a musical intro. I can definitely hear the pitch change in this intro (on my 'assumefps' approach), but not during the regular dialog. I was surprised I could hear this.

Thanks!

[Xesdeeni]

I simply took your avisinth script 'as is', (pointed to my source, set output framerate to 29.976), and viewed the 'output' (the stream supplied by the avs file) in TMPG's 'interlace' screen (settings/advanced/interlace) - this lets you single step through each frame (I later did the same in VirtualDub and saw the same results). Maybe this is the wrong expectation?It seems as if you are expecting the output fields to be related to one another on a frame basis. This is not necessarily so. In fact, as far the the TV is concerned, there is no set relationship between a pair of successive fields known as a "frame" (well, technically there is some relationship in the analog encoding of the color signal, but we aren't dealing with this in the digital domain). This is why DV contents can be "bottom field first," while (interlaced) DVD content can be "top field first," and both are compatible with the TV. All the TV sees is a sequence of fields. It's just more convenient for us to think of frames sometimes.

So when you look at two fields, even on actual broadcasts, there is no guarantee they will both come from the same scene/shot. This is especially evident on telecined film, where two out of four video frames has fields from two film frames, which may also span cuts.

This same thing can happen in PAL footage. Another way they can convert 24 fps film to PAL, instead of speeding it up, is to do what I call 3:2:2:2:2:2:2:2:2:2:2:2 pulldown :) (I have no idea what the correct technical term for this is). This shows one frame for three fields, and the next 11 frames for two fields, similar to the NTSC 3:2 pulldown (aka telecine). This sequence lasts half a second, so each time the frame is held for the extra field, the contents of the next set of video frames switches from containing the same film frame to having part from two film frames. I guess this can show a slight hesitation every 1/2 second on moving shots, so I don't know how common this is. Plus, I've read that PAL users like being able to watch a movie in 24/25 the time it takes in the theater ;)

Anyway, I think what you are seeing is correct. You can choose to encode the fields individually, or you can encode pairs as frames. But as you noted, since some frames contain parts of two "instants of time" (and even different scenes/shots), it's usually better to encode the individual fields for truly interlaced material.Regarding 'pitch change' - the show has a musical intro. I can definitely hear the pitch change in this intro (on my 'assumefps' approach), but not during the regular dialog. I was surprised I could hear this.Given no point of reference, I couldn't tell, but I can definitely tell on my conversions. I'm sure most people can hear the 4% difference side-by-side. I guess they are relying on the fact that you seldom see the movie in the theater and then come home and see it, or see the NTSC version and then immediately see the PAL version.

Xesdeeni

[BizUser]

Mistaken post - please delete