Quality obtainable in PAL/NTSC conversion for DVDs.

[opoman]

I have printed and carefully read, marked and learned the eight videohelp guides. I am drowning in material printed off the net from such sources as afterdawn, doom9, animemusicvideos etc. This really is a superb community in respect of its expertise and generosity.

I have based my efforts on the contributions by Xesdeeni because he once offered a script in response to a series of reports by people who had obtained jerky results. He seemed to imply that this was due to unsatisfactory scripts and that his own script would give more professional results.

After fighting my way through the consequences of revisions of TMPGEnc which undermined a number of published scripts, I finally got the following script, derived from XESDEENI's inputs, to work. I used DVD2aVI and Besweet with Avisynch and made the final test DVD-RW with TMPGEnc DVDAuthor, playing it back to my PAL TV via a Pioneer 5100 recorder with the TV output set for NTSC (I checked that PAL gave a monochrome picture).

__________________________________________________ __________

MPEG2Source("E:\Temp4\rugbyclip.d2v")
AssumeFrameBased()
AssumeTFF()
KernelDeint(order=1)
LanczosResize(720,480)
ChangeFPS(59.94)
AssumeFrameBased()
AssumeBFF()
SeparateFields()
SelectEvery(4,1,2)
Weave()
ConvertToRGB()

__________________________________________________ ________

However, the results are disappointing, even when I have made high quality choices which led to 2 hour encoding sessions (Pentium III at 1 gig)on a four and a half minute test clip. The source materials are UK PAL recordings from satellite broadcasts of rugby matches (DGIndex reports them to be TFF, interlaced), in which the output from a rapidly swinging camera (to follow the ball) is, no doubt, a tough test of compressed digital video - and presumably also an even tougher test of the video when converted from PAL to NTSC. The conversions result in significant jerkiness and some rather odd intermittent blurring and ghosting.

OK - finally my questions:

1) Is there a basic imperfection in the FPS change which will always introduce a measure of jerkiness in the final NTSC 'product' or is something going wrong with my processing?

2) Is my test method giving rise to the jerkiness, I wonder. How good or otherwise is the converter in the Pioneer recorder? Would my rugby-mad son in California find my efforts playing much better on his TV?

I should mention that I have played, at length, with the many suggestions I found for the parameters used in TMPGEnc. I have also tried using the wizard, but the results are pretty much all the same.

I'm sorry this is so long but it seems necessary for a newbie to this forum, and to video processing, to show clearly that I have done a reasonable amount of homework on this well-hammered topic. Well-hammered indeed but I haven't found too much on the subject of the quality of the final result.

[MOVIEGEEK]

This thread might help:
www.videohelp.com/forum/viewtopic.php?t=255392&highlight=

The fps differance is the hardest problem to resolve,I always get jerkiness.

[bugster]

So, you are trying to convert 25fps PAL to NTSC, correct?

Your script includes this:

ChangeFPS(59.94)

I don't use avisynth but this looks like you are trying to change the 25fps to 29.97fps for NTSC. Ami I right?

If so, don't.

Convert 25fps PAL to 23.97fps NTSC film by simply slowing down the framerate, then slow down the audio to match. Resize and reencode the video at 23.97fps with 3:2 pulldown flasg.

How to do this?

Demux the video with TmpGenc mpeg tools.
Change the framerate of the video with DVDPatcher
Change the audio length with the presets in BeSweet (not the easiest program in the world to use, but powerful).

Use whatever resize method you prefer (avisynth) and feed it into TmpGenc for re-encoding. On TmpGenc's video tab, set Encode mode as 3:2 pulldown when playback. Set the frame rate to 23.976fps (internally 29.976fps). Encode video only, re-multiplex with the audio from BeSweet.

The change in speed/playing time is not noticeable to the average viewer.

[junkmalle]

I don't think slowing the frame rate down to 23.976 will work because this is live video of a rugby game -- it should be fully interlaced PAL (ie, every field is from a different point in time, as opposed to a film source where pairs of fields are from the same film frame).

I don't think there's any way to convert it without a jerky end product.

[lordsmurf]

I don't think there's any way to convert it without a jerky end product.

My conclusion too. I've done conversion about every way imagineable. Even hardware (the best method) can sometimes leave aliasing artifacts (due to resize).

[groyal]

Bugster was spot-on in his advice.

If you properly progressivize your PAL video, you can treat it as film for NTSC purposes, e.g.

MPEG2Source("E:\Temp4\rugbyclip.d2v")
AssumeFrameBased()
DoubleWeave()
SelectEvery(2,0)
LanczosResize(720,480)
AssumeFPS(23.976,true)

After encoding you'll use the PULLDOWN utility to bring the frame rate up to 29.97, and the conversion is flawless.

Film is shot at 24fps on either side of the Atlantic. To prepare a film for European broadcast they speed it up 1 fps so that it matches the PAL frame rate. This script does essentially the same thing, but in the other direction -- PAL televison cameras are 25fps native, so by deinterlacing the video and slowing it down 1.04 fps we can treat it the same as NTSC-FILM.

[junkmalle]

by deinterlacing the video and slowing it down 1.04 fps we can treat it the same as NTSC-FILM.

So you're recommending losing half the spatial and temporal resolution for smoothness. I suppose that will work though I'm not sure it's the lesser of the two evils.

[lordsmurf]

Motion artifacts traded for visual artifacts.
Not a good trade-off.

[groyal]

by deinterlacing the video and slowing it down 1.04 fps we can treat it the same as NTSC-FILM.

So you're recommending losing half the spatial and temporal resolution for smoothness. I suppose that will work though I'm not sure it's the lesser of the two evils.

Yes, we do it all the time. The highest quality DVD to DivX transfers (for example) use exactly this method of deinterlacing, and nobody complains about it.

Consider: film is shot at 24fps, NTSC video at 30; nobody refuses to go to the movies because television is "smoother" than film. Above a certain rate (about 12fps I believe) the brain ceases to perceive individual frames and sees continuous motion: this is the illusion that makes the entire industry work. Loss of temporal resolution is therefore no big deal, because the net frame rate is still above the fusion rate.

As for spatial resolution, it doesn't matter that you have two fields interleaved to form one frame, each field is a separate picture. The brain sees no difference in line-doubling each field to a full frame than it does if the frames were progressive to begin with. The object of interlacing has to do with flicker, again not a problem because we're comfortably above the fusion threshhold.

Bottom line is, you can take the advice and accomplish what you say you're looking for, or ignore it and take the best of what you've done until now; you can lead a horse to water, but you can't make him drink.

[Motion artifacts traded for visual artifacts.
Not a good trade-off.

You literally don't know what you're talking about, my friend.

[lordsmurf]

[Motion artifacts traded for visual artifacts.
Not a good trade-off.

You literally don't know what you're talking about, my friend.

Don't even try to pull that card on me.
Go here and get educated: http://www.digitalfaq.com/capture/interlace.htm

DE-INTERLACING IS EXTREMELY DESTRUCTIVE !!

A good bit of your experience is null and void in this situation too. So much flawed logic here, it's not even funny. Sadly, I don't have time tonight to pick it apart. DVD->DIVX is bunk. It's idiot-proof. When you start to deal with TRULY INTERLACED sources, you're in a WHOLE DIFFERENT REALM of video conversion. Some of that other stuff you wrote is total nonsense, and much of it completely incorrect.

[OutSiderBR]

I had exactly the same problem : converting a PAL DVD to NTSC. I tried all scripts I could find, including the ones in this thread and had no success at all. Then, I just loaded the project in TMPGEnc and told it to create a NTSC DVD compliant .m2v. The results are much better than I expected. So, unless I have to do some weird filtering, I will stick to TMPGEnc. Just an opinion, which lordsmurf could comment as he has great experirence.

Regards

[lordsmurf]

My initial thought remains: CONVERT? WHY?
Most DVD players play both PAL and NTSC these days (or at least quasi formats that can be viewed on the tv). Only people that should worry about TRUE conversions is studios. And they have the equipment to do it properly, none of this software goo.

Procoder can also, to some degree, more or less, also handle format conversions. Even though I dislike it, BJ_M likes it, so there must be something to it. Worth a try, at least.

[groyal]

[Motion artifacts traded for visual artifacts.
Not a good trade-off.

You literally don't know what you're talking about, my friend.

Don't even try to pull that card on me.
Go here and get educated: http://www.digitalfaq.com/capture/interlace.htm

DE-INTERLACING IS EXTREMELY DESTRUCTIVE !! :evil:

A good bit of your experience is null and void in this situation too. So much flawed logic here, it's not even funny. Sadly, I don't have time tonight to pick it apart. DVD->DIVX is bunk. It's idiot-proof. When you start to deal with TRULY INTERLACED sources, you're in a WHOLE DIFFERENT REALM of video conversion. Some of that other stuff you wrote is total nonsense, and much of it completely incorrect.

Just some points that ought to be made here:

(1) I happened to be converting PAL to NTSC when I responded to this message; I'm not in the habit of doing meaningless work, so you can assume for argument's sake my opinion has some validity.

(2) If you have time to respond, you have time to pick it apart. Go ahead. Do whatever tests you deem valid, compare the results, comment; the "I just know you're wrong because you're wrong" helps nobody.

(3) Don't talk to me about interlacing. 'nough said.

(4) I'm very, very, very careful that everything I write "makes sense". If you think I can be more clear, do tell me how I might have written something more plainly. As for being completely incorrect, again, don't spare the details. Explain how and why: I respect that. Don't refer me to a source that (if it informed you) I already disagree with -- just state the objections and I'll respond to them.

(5) This is the very thing I dislike about VCD/[S]VCD/DVD/Video help.com: nothing is peer-reviewed, so the loudest mouth -- wrong or not -- is the one that gets heard. Sometimes people just want to know the right answer without downloading someone's "guide" to something or the other as gospel.

[opoman]

I'm truly grateful to all of you for your suggestions, most of which will take me some time to follow up, in tandem with doing more reading.

One that I can answer straight away is the suggestion that I give up on software and get my son to buy some hardware. Believe me, when I was struggling for a whole day to get AVSedit to accept the first line of my script (ie, until I learned that the plug-in that DGIndex had placed in the TPMGEnc plug-in folder had to be removed), I was tempted to email my son and tell him to go out and spend in order to save me hassle.

However, the temptation soon passed - I'm 70, been retired for ten years from physics research into flat panel displays, liquid crystals and infrared lasers. My mind *needs* excercise like this - and I really love a challenge.

So I really appreciate the response and the vigorousness of the debate - only, please folks, don't get personal - the spirit of cooperation and generosity on this forum is too good to even think of getting hot about it all.

I'll be back when I've tried some more things. I just don't have a clue as to how the rugby will look when I throw away information.

Incidentally, I spent a couple of hours in the middle of the night reading up a tutorial on the advanced settings in TMPGEnc for rate control mode and GOP structure:

www.dvdhelp.us/html/tuttmpgencadv.html

and was amazed at the number of options available in this application. It seemed to me that the choices could crucially affect the smoothness of the result and yet much of the advice available seems to ignore these options.

Don't give up on me folks - I'll be back!

[bugster]

Question for Lordsmurf (or anyone else for that matter).

Forgetting framerate for the moment, any conversion from PAL to NTSC (or vice versa) is going to require resizeing. How can this be done when you have an interlaced source, without de-interlacing?

AFAIK, it can't, but will happily be corrected.

If I am correct, then the de-interlace or not question becomes irrelevant.

[lordsmurf]

Resizing never effects interlace. (Although it might affect it.)
Run a home test: crop a video by 25 pixels from all sides.
Still interlaced just fine.

The framerate is the interlace killer, making it difficult.

Of course, deinterlace kills image quality, so not an option.

Neverending circle of mistakes, in software.

Hardware has enough filters to overcome this, but it DOES leave some aliasing artifacts quite often, at least on the stuff that is $500 or less.

[bugster]

Resizing never effects interlace. (Although it might affect it.)
Run a home test: crop a video by 25 pixels from all sides.
Still interlaced just fine.

Thats cropping, not resizing without losing any of the image. Cropping from 576 to 480 loses too much info. Resizing requires de-interlacing AFAIK as it has to be done on a frame basis, not fields.

I am not saying de-interlacing is good, far from it. I agree it is to be avoided wherever possible, but as far as I can see, in this case it is required.

[lordsmurf]

But it's not required ... that's the issue.

Resizing/cropping ... same philosophy to the encoder. Cropping is merely "resizing" downwards using a select portion of the image. In this scenario of PAL-NTSC conversion, you are choosing ALL of it as the portion and then resizing. 576 down to 480, or 480 up to 576. Same scenario.

Deinterlace is not required.

Hardware can convert just fine.

Resizing's only affect is aliasing. That is unavoidable, period.

[dphirschler]

Here is my script. It worked well for me. I created it based on the sample found in AVIsynth's documentation (under AssumeFPS / ChangeFPS / ConvertFPS) and a guide found on this site.

I struggled with jerkiness too (in pans), but discovered I had the field order wrong. There are two ways around it. One is to change the selectevery line and encode for BFF. The other (and my preferred method is to use assumeBFF and then selectevery for TFF so that your mpeg encode will be TFF.

LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\SmoothDeinterlacer.dll")

v= AVIsource("test_pal.avi") # source is PAL 25i (BFF)

return pal2ntsc(v)

function pal2ntsc(v)
{
	last=v

	assumeBFF
	SmoothDeinterlace(doublerate=true)
	LanczosResize(720,480)
	ChangeFPS(59.94) # crisp but slightly jerky
	#ConvertFPS(59.94) # smoother but slightly blurry
	SeparateFields
	SelectEvery(4,1,2) # TFF
	#SelectEvery(4,0,3) # BFF
	Weave
	ConvertToRGB

	return last
}

Note that I used an external plugin called smoothdeinterlace. I believe you can achieve great results using bob instead.

I believe that deinterlacing/resizing/re-interlacing gives great results with minimal artifacts. It's better than cropping in my opinion. You do get the slight "shimmering" artifacts found in any bob deinterlace. However, it is minimized since you do a resize before re-interlacing. And also, you are throwing away some of the shimmering frames in the selectevery step.

Good luck!


Darryl

[junkmalle]

I'm not sure what Smurf is trying to say, but most people will resize interlaced PAL video by separating the fields, resizing the fields, then weaving the fields back together. So you split a 720x576 frame down to two 720x288 fields, resize the fields to 720x240, then weave the two fields back together to get 720x480. The result isn't perfect but it's perferable, obviously, to just resizing the whole frame, or performing a blend deinterlace (bluring the fields together) and resizing.

This isn't necessary with film based PAL material because both fields are from the same film frame. You can resize directly.

[opoman]

OK - first trial report:

This is a literal copy of groyal's suggested script although I had to add the ConvertToRGB because the script wouldn't preview in AVSEdit without it. Perhaps there is a simple explanation of this but I am not in a position to even hazard a guess.


MPEG2Source("E:\Temp\groyal.d2v")
AssumeFrameBased()
AssumeTFF()
DoubleWeave()
SelectEvery(2,0)
LanczosResize(720,480)
AssumeFPS(23.976,true)
ConvertToRGB()

The .avs script was run in TMPGEnc, as simply as possible, using the Project Wizard for NTSC/DVD. When the video was loaded the type was shown to be non-interlace, 4:3 525, 704x 480 (film movie). Nothing was checked on Page 3 of the wizard but in other settings I accepted the suggested Constant Bit Rate (7998) and Encode mode of 3:2 pulldown when playback. Motion search precision was the suggested motion estimate search(fast). I also added the sound, with the assistance of Besweet's conversion to 23.976.

The simplest encode that a newbie could do, in other words.

I used TPMGEnc DVDAuthor to produce the output and used the same application to burn a DVDRW.

The result of playing it on my Pioneer 5100 recorder (o/p set to ntsc) was markedly different to anything I had produced before. There were jaggies round player-outlines when they moved rapidly across the camera field of view, and occasional shimmering and horizontal stripe effects. With the prompting of lordsmurf, I've looked up 'aliasing' and I assume that the aforesaid are the effects which he/she suggested were inevitable.

On the plus side, the action was much smoother, without some of the curious break up effects I had seen before, altogether more watchable but, you know how it is, when things are good you want better. So I am strongly motivated to keep going. Incidentally, the run on the Pioneer really bucked me up as I'd been disappointed by frequent hesitations in the action when I first played the DVDRW in the DVR107 via Roxio Player.

Meantime you folks have had my email alarm tonking away and I've kept an eye on developments without being able to concentrate enough on the implications for what I should do next.

I'll spend some time with your further comments, right now, and then decide what to do next.

A million thanks to you all for a really stimulating morning, here in the UK

[bugster]

But it's not required ... that's the issue.

Wether you agree with it or not, PAL to NTSC conversion (and NTSC to PAL) is wanted by some members of this board, like the OP of this topic.

Resizing/cropping ... same philosophy to the encoder.

No its not. The mpeg encoder engine will be fed material that is already resized, possibly by another piece of SW embedded in the encoder product or possibly externally. Cropping deletes part of the image, resizing retains the full image but at a different resolution. Your a pro photographer I believe, you should understand the difference. Besides, you can't crop Upwards (480 to 576 for instance!)

Cropping is merely "resizing" downwards using a select portion of the image. In this scenario of PAL-NTSC conversion, you are choosing ALL of it as the portion and then resizing. 576 down to 480, or 480 up to 576. Same scenario.

Disagree. Cropping is removing part of the image to get the resolution you want. resizing retains the whole image. Maybe just a different use of terminology, but what else should I call it when I take an image that is X * Y and change the res to A * B (up or down) without cutting any of it off.

Deinterlace is not required.

Not if cropping the image no, but how do I resize 720 * 480 to 720 * 576 on a field when only 1/2 the data is there to work with. If it was a still picture, say an uncompressed bitmap, you can use many different techniques to resize up or down whilst minimizing artefacts. The same can be said of a full frame, but can this be done with fields? If you know that it can, and how, I would appreciate a link to some info on this.

Hardware can convert just fine.

I don't dispute that, but much of this HW is working in analog signals. Thats quite a different ball game and not comparable to what we can do with digital data and software.

[junkmalle]

MPEG2Source("E:\Temp4\rugbyclip.d2v")
AssumeFrameBased()
DoubleWeave()
SelectEvery(2,0)
LanczosResize(720,480)
AssumeFPS(23.976,true)

Groyal, I don't use AVISynth a lot so I ran your script. I opened the script with VirtualDubMod so I could easily examine each resulting frame. As a source I used a short, uncompressed, interlaced AVI file. Obviously, I had to change the first line to AVISource("filename.avi").

I don't think your script does what you think it does. Asserting AssumeFrameBased() caused DoubleWeave() to just duplicate each frame. Following that with SelectEvery(2,0) then threw out every other frame. The final result was a stream of the original frames, at the original frame rate, and still fully interlaced. LanczosResizing that lead to severe interlace artifacts.

I suspect replacing DoubleWeave() with SeparateFields() will get the result you were expecting.

[opoman]

dphirschler's script is the same as the xexdeeni one I posted at the start of this thread, with the replacement of the more recent KernelDeint by SmoothDeInterlace and with BFF rather than the TFF appropriate for my source.

dphirschler's evident satisfaction just goes to show that source material, and maybe the eye of the beholder, and possibly the playback machine can make quite a difference.

[dphirschler]

Possibly. But there are two considerations. One is that you can achieve smoother action by using convertFPS instead of changeFPS. The other point to consider is your field order. Not just within the script, but when you go to encode.


Darryl

[opoman]

Right, I'll make the change (!) from change to convert (I'll have to use a YUY2 input, I gather from AVSEdit's preview, and I don't yet know what that entails).

I'm trying to work out what are the practical implications of your comment about field order (pardon my ignorance but is that the same question as top or bottom frame first?

[dphirschler]

yes. TFF and BFF refer to field order. Sometimes called even and odd field, however, I can never remember which is which. So I refer to them as top and bottom field.

You have to be so careful. You first have to know the input field order, then your output field order. Then you have to tell the encoder the field order. You can get it completely right in your script and get it wrong in the encoder.


Darryl

[bugster]

As I ahve said before, I don't use avisynth, so can't claim to understand the scripts. But I am confused by the "AssumeFrameBased() " line at the start of each script. The avisynt website says:

AssumeFrameBased throws away the existing information and assumes that the clip is frame-based, with the bottom (even) field dominant in each frame. (This happens to be what the source filters guess.) If you want the top field dominant, use ComplementParity afterwards.

But opoman is taking a DVD recorded from a TV. In this case it is field based not frame based, or am I missing something here?

[opoman]

My head is sinking below the surface at the moment - I just can't read the explanations of terms (which I find on the net), quickly enough to keep up with this discussion.

Nevertheless, I am also getting a sinking feeling about my slavish adoption of xesdeeni's original script. If SelectEvery(4,1,2) is tantamount to converting my original from TFF to BFF, then I may already be in trouble. DPHirschler may be on to something here. In the absence of understanding on my part, there is a decision to make about whether to read and think or just try things. When my colleagues and I got to discover and develop the world's first stable room temperature liquid crystal we got there first by thinking

Phew - this is like a hard day back at work but it sure is fun.

[adam]

You can't use assumeframebased if your source is actually interlaced. If you want to go this route you need to run an actual deinterlacer. FieldDeinterlace works well, SmoothDeinterlace is probably better.

Personally, I think this is probably the best way to handle interlaced PAL->NTSC as well. Deinterlacing is always to be avoided, but with some sources its the only way. You can still get good results, I've done it.

bugster, you can resize interlaced footage all you want horizontally, but you're right about a vertical resize. Unless you separate the fields it will screw up the interlacing big time.