PAL to NTSC and NTSC to PAL

[scharfis_brain]

with yv12 the fields only have the halved vertical chroma resolution.

this means, looking at the U or V plane of an YV12 image show interlacing on moving objects!

a deinterlacer handles those chroma planes, like they were Y planes.
The only difference is that they are width and height reduced.

if you deinterlace and afterwards convert to yuy2 (progressively), the static and high detailed parts are retaining their best possible chroma detail.

but if you convert to yuy2 interlaced before the deinterlacer, high detailed vertical chroma immediatelly gets destroyed!

that's why I am hoping for a motion-adaptive YV12 -> YUY2 conversion plugin.

converttoyuy2(interalced=true) only does fieldbased upsampling, which means static areas are handled fieldseparated, too!

[Kika]

converttoyuy2(interlaced=true) only does fieldbased upsampling, which means static areas are handled fieldseparated, too!

I see, good point.
I really hate this YV12 interlaced stuff... ;)

I'm not sure how to go about analyzing this, but I suspect if ProCoder does it, CinemaCraft (which I use) does as well. Maybe you know of a way to verify this?

No, CCE or TMPGEnc aren't able to do a Field based or mixed Encoding. Same for variable GOP Pattern. Hard to belive, but there is no Consumer MPEG2-Encoder out which supports all Features of MPEG2.
To check this, you can use some Analysis Tools like Bitrateviewer or MPEG Repair.

[scharfis_brain]

@KiKa: I haven't read the whole thread (I am just checking in here occasionally...

Are there any software MPEG-2 encoders, that are able to decide theirselves whether they do progressvie or interlaced encoding like seen in DVB-Streams?

low motion=progressive frames (even if interlaced content!)
heigh motion = interlaced for interlaced content or proigressive for progressive content.

even fieldblended conversions have an alternating cyclic pattern of progressive and interlaced encoded frames.
As found in the DVB-S Stream of Sat.1's Fahrenheit 9/11 examining the preview of DGIndex/DVD2AVI.

[Zeul]

well it seems like everyone has a different opinion :D But i get the consensus that going from PAL(p) -> NTSC(p) is not recommended. PAL(p) -> NTSC(i) IS recommended. On my tests converttoyuy() appears to have no apparant effect on the output. On a HDTV this may be different, but here in the UK, we do not have access to HDTV and it doesn't seem likely we ever will :(

Zeul

[Kika]

Are there any software MPEG-2 encoders, that are able to decide theirselves whether they do progressvie or interlaced encoding like seen in DVB-Streams?

Um, hard to answer... Let's try. ProCoder is able to do a field based interlaced Encoding. This means, every field will be encoded separatly and not weaved, like most of the Encoders do. But ProCoder can't encode in mixed mode. Maybe this option was a little too hard for the programmers? ;)
In mixed mode, the Encoder has to decide which Part of the Video is interlaced and which part is progressive. But, and that's the problem, the mode (interlaced or progressive) can only change GOP by GOP. That's because varible GOP Pattern Encoding is necessary for encoding in mixed mode.
Variable GOP-Pattern is an other feature of MPEG2. It means, the Encoder can change the Structure of the GOP - ANY aspect of the Structure. GOP-Lenght, the Pattern (IBP instead of IBBP) and so on.
Like i wrote earlier: I don't know a consumer MPEG2 Encoder which supports all these Features, only mpeg2enc has all these modes.
Unfortunatly, mpeg2enc isn't a good Encoder... :(

low motion=progressive frames (even if interlaced content!)
heigh motion = interlaced for interlaced content or proigressive for progressive content.

That's how mixed Mode should work. But again, i don't know an Encoder which is able to do that. I don't even know a Muxer or DVD-Authoring-Program which accepts encodings like this (maybe Scenarist, but without am Encoder for this mode, i can't check this). Some of the Authoring Tools do have problems with field based interlaced Encodings...(TDA can handle it, also all Tools from Canopus, Ulead DVDPowerTools can't), and mixed mode is much more complicated.

I know, mixed mode is part of the Specs, but i've never seen a stream encoded this way.

[Xesdeeni]

Originally posted by scharfis_brain
with yv12 the fields only have the halved vertical chroma resolution.

this means, looking at the U or V plane of an YV12 image show interlacing on moving objects!

a deinterlacer handles those chroma planes, like they were Y planes.
The only difference is that they are width and height reduced.OK, I took a look at this page (http://www.hometheaterhifi.com/volume_8_2/dvd-benchmark-special-report-chroma-bug-4-2001.html) has some information on DVD players that incorrectly decode the chroma. If you compare http://www.hometheaterhifi.com/volume_8_2/images/chroma-figure-3.jpg to http://www.hometheaterhifi.com/volume_8_2/images/chroma-figure-4.jpg, I think that may be where the key lies.

If we don't have a deinterlacer that can handle 4:2:0 natively, it seems the conversion should be done before the deinterlacing. At that point the 75:25 weighted conversion would be done. (I don't grok MMX, so I can't quite figure out whether ConvertToYUY2() does this correctly, by looking at the source. There is different code for interlace vs. non-interlaced, but I don't see this weighting.)that's why I am hoping for a motion-adaptive YV12 -> YUY2 conversion plugin.I assume this means it doesn't.

SmoothDeinterlacer doesn't support YV12, so this makes sense. But KernelDeint does. But does it handle this correctly? From what I see in the source, it looks like it does. It cycles through all three planes, and handles the U and V planes the same as the Y plane, with 1/4 the size, but deinterlacing as appropriate.

So now I think I see why you recommend deinterlacing first...at least with KernelDeint :)converttoyuy2(interalced=true) only does fieldbased upsampling, which means static areas are handled fieldseparated, too!I'm not sure what you mean by fieldbased, but I assume you mean it's being done wrong :) Have you let the AVISynth team know this?

Xesdeeni

[Wilbert]

assuming clip has combing:

I'm not sure what you mean by fieldbased, but I assume you mean it's being done wrong Have you let the AVISynth team know this?
It's not really done right or wrong, but there's improvement possible. What you want is that the upsampling in "static frames" is done progressively (and in "dynamic frames" field-based with alternating 3/4-1/4 weighting). This is possible (but not with ConvertToYUY2(interlaced=true/false)), and described here

http://www.avisynth.org/FieldBasedVideo (ConvertHybridToYUY2)

But what you actually want is that the upsampling in "static areas" is done progressively (and in "dynamic areas" interlaced-based). Such a filter doesn't exist yet.

[emdiem]

Wonder if this topic is active. I tested some script that was posted, smootdeinterlacer script i cant use in 2,5

i save the script and then make a fake avi with ffvfw and promt:
Plugin SmoothDeinterlacer.ddl is not an AviSynth 2,5 plugin

SCRIPT:
# NTSC (29.97fps) to PAL (25fps)
LoadPlugin("SmoothDeinterlacer.dll")
AVISource("juniorjack_d2v_vfapi.avi") # Change to your filename
SeparateFields()
Weave()
SmoothDeinterlace(doublerate=true,lacethresh=1,staticthresh=20)
LanczosResize(720,576)
ChangeFPS(50)
SeparateFields()
SelectEvery(4,1,2) # Change to SelectEvery(4,0,3) if output video looks very jerky
Weave()
ConvertToRGB() # Might not be essential


I tested at a friends work to open my NTSC vob file and save it to PAL with ProCoder 2, i get same jerky images on the video as when i tested another script i found in this thread in the first pages.

Smoothdeinterlacer only work on lower versions of AviSynth?

I also wonder how the resize is made? I mean, why not just add black borders to evenout the height? Why stretch the videostream when you can add black borders to fill the extra space. Is this possible to make instead of resize?

[Zeul]

@emdiem
There are different versions of SmoothDeinterlace for the different avisynth versions. However, useing kerneldeint seems to be a better plugin.

[emdiem]

I can only find one at http://biphome.spray.se/gunnart/video/AVSPorts/SmoothDeinterlacer/

i downloaded the latest one.

[Xesdeeni]

But what you actually want is that the upsampling in "static areas" is done progressively (and in "dynamic areas" interlaced-based). Such a filter doesn't exist yet.Isn't that just deinterlacing and then color space conversion (interlace=false)?I can only find one at http://biphome.spray.se/gunnart/vid...thDeinterlacer/Check out http://www.avisynth.org/warpenterprises/ for all your AVISynth plugin needs.

Xesdeeni

[scharfis_brain]

Isn't that just deinterlacing and then color space conversion (interlace=false)?

it is similar to deinterlacing the UV planes, but it is NOT the same.

deinterlacing the UV planes halves vertical resolution by two.

motion adaptive chroma upsampling uses exactly the same comb-mask like deinterlacers are using to decide whether interlaced (combs are detected) oder progressive (no combs) upsampling is used.

[Zeul]

I am interested to know your recommendations for a hybrid NTSC -> PAL conversion script, keeping the length the same. Is the std hybrid avs script used before the conversion to pipe a steady 29.97 stream? ie

import("C:\Build\new.avs\addaudio.avs")
LoadPlugin("C:\Build\new.dvd2avi\mpeg2dec3dg.dll")
Mpeg2Source("001.d2v" ,Idct=0)
LoadPlugin("decomb.dll")
Telecide()
Decimate(mode=1,threshold=3)
LoadPlugin("kerneldeint.dll")
Kernelbob(order=1, sharp=true, twoway=true, threshold=0)
LanczosResize(720,576)
ConvertToYUY2(interlaced=true)
ConvertFPS(50)
SeparateFields()
SelectEvery(4,0,3)
Weave()
AddAudio()

OR is this first bit unneccessary

LoadPlugin("decomb.dll")
Telecide()
Decimate(mode=1,threshold=3)

The same question applied to a telecide source.

[Mug Funky]

here's my latest plaything:

bob with Tdeint (very good quality - the best so far without going into absurdly slow motion-compensated methods... for that see "mvbob").

convertfps to 50

then scale up with lanczos4resize (need later version of avisynth to get this internal scaler), select fields, then weave.

script:


assumetff() # sanity check - change it for DV source
tdeint(1,1,cthresh=4) # 1,0 for bottom-first, like DV
converttoyuy2()
convertfps(50)
lanczos4resize(720,576)
separatefields().selectevery(4,1,2).weave() # 4,0,3 if order is bork
converttoyv12(interlaced=true) # because QuEnc takes yv12...

assumetff() # sanity check for field-order
#bob() # uncomment this to check field-order in Vdub.


tdeint can be found in the avisynth development forum ("another motion adaptive ..." should be near the top)

this does a field-blend conversion, so it's only good for high-bitrate stuff. note also that output will be interlaced, and hopefully top-first.

i find that any kind of smart-bob plus field-blend will look slightly better than a standalone converter box - they seem to work either by dumb-bob or field-separation, which gives very slight jaggyness. usually this is less than the inherent blur of the source, so it's not a big deal.

[scharfis_brain]

afer some analysis of fieldblended FILM->NTSC->PAL crap, I found, that mostly two methods are used.

the first applies very low thresholded kernelbobbing with blending to 50i
(was determineable, because there are kernelel-ghosts already in such sources)

for the 2nd I think, they are using some kind of mocomped deinterlace with mocomped framerate conversion for 60i-stuff.
with 24p telecined contents such converter falls back to traditional deinterlacing with an unknown non-kernel interpolation (no kernelghosts!). the framerate conversion is done via blending, because mocomped framerate conversion will produce terrible results motionwise with 3:2 stuff.

as you can see:
they are breaking a butterfly on a wheel
(mit Kanonen auf Spatzen schiessen ?!? in German)
with such overcomplex, for 60i tought converters...

this is, why I asked trictical for modding his in-developement TFM()

of course there are other methods doing a improperly conversion:
- do a stupid bob with pointsampling or bilinear and then knock out every 6th frame. then reinterlace.

- do a stupid bob with pointsampling or bilinear and then do fieldblending.

both methods suffer extremely wobbling static details and lacking resolution.

[spase]

In converting some PAL DVD (progressive I believe) sources to NTSC DVD I am using the following script:

LanczosResize(720, 480)
ChangeFPS(59.94)
SeparateFields()
SelectEvery(4,0,3)
Weave()

which yields an interlaced NTSC stream at 29.970 fps which should sync up fine with the audio (i.e. no audio time shifting is necessary).

Am I correct in these assumptions?

Also, is this the best way to go from PAL (progressive) to NTSC (either progressive or interlaced... whichever yields better results)?

The only reason I ask is because there seems to be a lot of different ways to do this (even by only looking at this thread) and I am a little confused.

[Xesdeeni]

Originally posted by spase
In converting some PAL DVD (progressive I believe) sources to NTSC DVD I am using the following script:

LanczosResize(720, 480)
ChangeFPS(59.94)
SeparateFields()
SelectEvery(4,0,3)
Weave()

which yields an interlaced NTSC stream at 29.970 fps which should sync up fine with the audio (i.e. no audio time shifting is necessary).

Am I correct in these assumptions?If the source is progressive, then this will work well. And yes, the audio will remain sync'd. But be careful that the source fields don't get out of sync. Pairs of fields in each frame should be from the same "instant of time," but rarely the fields can split across frames. The frames can still be reconstructed, but not as easily. Decomb works well for this.Also, is this the best way to go from PAL (progressive) to NTSC (either progressive or interlaced... whichever yields better results)?As with anything, "best" is in the eyes of the beholder. There are two basical ways to convert 25fps progressive PAL to NTSC:

1. As above.
Pros: No speed change; no audio manipulation necessary
Cons: Telecine-like artifacts; Interlaced NTSC (harder to compress); More difficult to deinterlace for progressive playback

2. Change the speed to 23.976 fps progressive.
Pros: Progressive NTSC (easier to compress); no telecine artifacts on PC playback (multiple of 24 Hz refresh; otherwise, there are still telecine artifacts)
Cons: Audio manipulation (slowed with pitch change, or slowed with pitch adjustment artifacts); Program runs slower; Program lengthens

Xesdeeni

[OutSiderSP]

Xesdeeni,
I tried all possible configurations with your scripts and others' without great success. I could always see the interlacing. My source was a PAL movie, which DGEdit pointed as interlaced, and I wanted to convert to NTSC. I gave up and loaded the .d2v project into TMPGEnc 2.524 and guess what ! No artifacts at all, perfect conversion ! So, unless I´ve got to do weird filtering, TMPGEnc is the way I will go.

Regards

[Xesdeeni]

Interlaced artifacts will be visible on a progressive PC screen. They are supposed to be there. The destination is an interlaced video, and should be viewed on an interlaced display (or one designed to take an interlaced intput and deinterlace it). To create a purely progressive destination, you must either:

a) slow down the video, or
b) replicate on a frame basis.

If you do a), you'll need to also process the audio to slow it down. A straight conversion will cause a pitch shift. BeSweet and AVISynth can convert while doing a pitch correction, but the techniques used can have mixed results, and might not be acceptable on audio with large frequency ranges (i.e. music).

If you do b), your video will be more jumpy. That's because you'll be extending the duration of a particular frame on the screen more than its neighbors. That same is true for the interlaced version, but the frame version will have a larger difference, which will be much more apparent.

Xesdeeni

[OutSiderSP]

Xesdeeni,
Thanks for the reply. I understand the two methods and my preferred onr is a), because I cannot tell the pitch is lower without comparing with the real pitch; and I do not care if the film becomes 2 minutes and 34 secs longer. The fun will last longer. :D

What really bugged me was the fact that after your script the film was not interlaced anymore in TMPGEnc. If I loaded the .d2v it was interlaced. I was using

<code>
SeparateFields()
LanczosResize(720, 240)
Weave()
ChangeFPS(59.94)
</code>

What is wrong with it ? I copied your geocities script and it also gave me non-interlaced results... I do not understand it...

[Xesdeeni]

Originally posted by OutSiderSP
Xesdeeni,

What really bugged me was the fact that after your script the film was not interlaced anymore in TMPGEnc. If I loaded the .d2v it was interlaced. I was using

<code>
SeparateFields()
LanczosResize(720, 240)
Weave()
ChangeFPS(59.94)
</code>

What is wrong with it ? I copied your geocities script and it also gave me non-interlaced results... I do not understand it... I'm not sure where you got that script, but I'm pretty sure it's not from me. There are just so many things wrong in those few lines ;)

To convert a progressive PAL to NTSC, you don't necessarily need AVISynth, but you'll have to process the audio separately. TMPGEnc can convert the frame rate from 25p to 23.976p. Counterintuitively, you must check the "Don't do framerate conversion" when you do the encode. This keeps TMPGEnc from dropping frames to get from 25p to 23.976p, but with the same duration. Instead, it encodes the frames 1:1, lengthening the duration due to the slower frame rate. Then you can use BeSweet to convert the audio.

Alternatively, you can use AVISynth to convert the video and audio simultaneously. I think the script would be something as simple as:

xxxSource("PAL_25p.xxx")
LanczosResize(720, 480)
AssumeFPS(23.976, true)

I believe you also must run Pulldown.exe on the result to insert the flags to make it DVD-compliant.

Xesdeeni

[Paulcat]

I have attempted to read through this entire post and make sense of it at the same time, but no luck. What I am doing to convert PAL to NTSC is as follows

(1) Use DVD Decrypter in IFO mode, decrypt and demux the individual streams, .m2v video and .ac3 audio (usually)

(2) Use TMPGEnc to process the .m2v file, under the DVD NTSC template to make a new .mpg file

(3) Use TMPGEnc DVD Author (or IFO Edit) to re-author the new mpg with the original ac3 and no problems. Everything remains in sync and the picture quality is good enough for me.

If you want better, buy a better DVD Player :-)

p.s. Is PAL DVD always progressive?

[Xesdeeni]

Originally posted by Paulcat
p.s. Is PAL DVD always progressive? No. PAL can be interlaced as well.

I don't know if there was a question in the rest of your post, but if it works for you, that's all that counts.

Xesdeeni

[Paulcat]

Originally posted by Xesdeeni
No. PAL can be interlaced as well.

I don't know if there was a question in the rest of your post, but if it works for you, that's all that counts.

Xesdeeni

There wasn't a direct question, but I will ask one now. With all the hundreds of people here who know a hell of a lot more than I do, why can't someone come up with a stand-alone piece of software that can extract the video, convert it and author it all on it's own?

It seems doing it in a script is iffy at best, especially after reading all the DIFFERENT scripts for doing the same thing!

Each piece of software seems to be good at one thing, and to get a decent result you have to have so many of them (only some of them free) it's almost not worth attempting...

[Xesdeeni]

I'd say there are four reasons:

1. There is a large group of tasks that need to be performed. As you say, there are separate tools that do each one. To create a stand-alone, all that functionality would need to be built into one tool. And it would require an understanding of every piece.

2. As you also said, there are many ways to perform this conversion. There are disagreements about what looks better. And even that depends on the format of the source. Converting progressive material is different than converting interlaced material. So once a stand-alone tool chose one method, many people would complain about the process.

3. There really isn't a large market for the product. Because of 1 above, it is unlikely that this would be a free application. But in spite of a number of us posting here and elsewhere on the subject, the number of people interested is quite low. We have just been lucky enough to find one another.

4. There is a much easier alternative. A cheap DVD player that will play and convert PAL and NTSC is easy to find.

I prefer to do the conversion myself, because I have control. I have always been fascinated by the challenge and the process. But if all you are after is a one-click solution, it's available at your local Wal-Mart. The quality may or may not be what you want, but it is easy.

Xesdeeni

[OutSiderSP]

Xesdeeni,
I did not put the whole script here and forgot to ask you one question. My PAL source was interlaced (visually) and DGIndex pointed that out, too. I got confused because after the script is loaded into TMPGEnc, it was not interlaced ! That's why I got all confused. Your script has Smoothdeinterlace, which I used, but I thought it became interlaced again after Weave.

Thanks a lot for your patience in answering my newbie dumb questions. I am still to learn the deinterlace and reinterlace methods. I thought that to apply any filter I should first deinterlace, apply the filters and only then reinterlace, but it seems I am wrong in my reasoning.

Regards

[vhelp]

I hope this is not considered t-jacking or OT ...

Hi Xesdeeni and others..

I've ben following this thread for a while now. Not for it's PAL to NTSC
or vise versa, but for ideas to incorporate in my 30p source files from
my DV cam. In short, it can shoot footage in 30p full frame with no
bad deinterlacing artifacts (in my past tipicle delinterlaced methods
through AVIsynth scripts, there were odd (normal) artifacts) But, I'm back
on the scripts wagon, to turn DV home footage into Film-like speed and
quality, as well as its respective fps.
.
I've ben checking out Xesdeeni's scripts throughout the pages and varied
a little of his (and others) code snips as experiments, but I'm not getting
smooth playback. What I am looking for is a 30p to 24p Film (minus the pal
to ntsc) but with more smooth (less strobing) from my 30p source.
.
I always thought that the reason for the strobing was because on TV's,
they are interlaced fields at 1/60th second, and when two fields are
split and displayed on TV, the result is smooth motion throughout.
But, when the source is 30p (every frame) and displayed on TV, the final
result at 1/60th is now strobing. Very good quality, but stobing. I know
that people refer to this as Film-effect, but this is IMO, close to 1/2
Film-effect, because Film is 3 (strobe) frames, plus 2 frames split and
displaced to give a smooth look, and the results is smooth, barely
un-noticable strobing, except for when panning, which is minimal.
.
I'm trying to take my 30p and turn it into 24p, but with a Film spec
of 23.976 fps w/ a pulldown effect. So far, it's been very tricky,
and wearing (if I can say that) on my mental brain.

Can anyone give me some hints (I don't mind the hard work) or nudge,
to bring me closer ??

Thanks,
-vhelp

[scharfis_brain]

30fps to 24fps (or more precisely 29.97 to 23.976)
will ALWAYS result (EDITED) in jerkyness when using blending. No way out.

You need to use a motion compensated framerate converter.
Like mvtools from manao.
be sure to get mvtools 0.9.6.2.

or try motionperfect. But this gives a very wobbly image, which looks like water sometimes.

[vhelp]

Thanks scharfis_brain :)

I have tried some more over last night, but still jerks (I new and
exptect that)

I will look into by manao's mvtools.
-vhelp

[Grafdude]

I have a PAL interlaced movie, which I wish to convert into an NTSC movie. I saved my project with DGindex within the vob's, and I also wish to not touch the audio, so I don't want to alter the movie's time. DGindex gave me this info about the stream:

-Frame type: Interlaced
-Frame structure: Frame
-Field order: Top

Here's my avisynth script:

MPEG2source("___.d2v")
AssumeFrameBased()
AssumeTFF()
LanczosResize(720,480)
ChangeFPS(59.94)
SeparateFields()
SelectEvery(4,0,3)
Weave()
ConvertToYUY2(interlaced=true)

After the encoding, I imported the untouched ac3 track and the encoded stream into DVD-lab, and the duration of both matched exactly! The problem is, the audio is out of sync, it plays a little bit earlier from start to finish. What did I do wrong?

[scharfis_brain]

@vhelp: I edited my post above. It now makes more sense.
(My attention was drawed of while writing my post, sorry)

@Grafdude:

your script WILL mess up everything, if you are processing laced contents with it.

The Info of DGindex must NOT be used for identifying interlacing/progressive.

Use your eyes instead! They are far more better in judging interlaced/progressive!

PAL-interlaced to ntsc-interlaced will always result in this sequence:

xxxsource("blah.xxx")
assume?ff()
motionadaptivebobber(paramters) #kernelbob, tdeint
converttoyuy2(interlaced=false)
lanczosresize(last.width, 480)
convertfps(59.94) #if you like stutter, go for changefps
separatefields().selectevery(4,0,3).weave()

replace the bold parts with your preferred thingies.

[Grafdude]

@scharfis_brain:

I proceded like you directed, but made small modifications since I realized my source was partly interlaced. Now the problem is, the audio is still not syncing, even though they both have the same duration! I even tried a small delay on the audio track, it did sync at the beginning but it doesn't take too long before it gets out of sync.

assumetff()
Telecide(order=1)
converttoyuy2(interlaced=false)
LanczosResize(720,480)
ConvertFPS(59.94)
selectevery(4,0,3).weave()

[a2j]

mp3dom asked a question and no reply since then... if any body there?

[Mug Funky]

// the video is by default in YUY2 since it's a 50 Mbps MPEG-2!

hot dang! where do you get those? are they i-frame only or regular? i think if they're not i-frame only you'll be getting pretty damn close to (maybe better than) digibeta quality. otherwise it's still a cut above DV50, which aint bad at all :)

[mp3dom]

The Mpeg-2 is an I-frame based coming from a Pinnacle ChromeHD system. This is a result from an acquisition from Digibeta. I prefer MPEG over DV50 or DVCPro 50 because MPEG is better in interlaced (at least, is better handled by Pinnacle) and doesn't require field change or chroma upsampling.

[Xesdeeni]

I think only PAL DV25 is inherently bad at interlacing. It's 4:2:0, but I believe the rest are all samples within a line. NTSC DV25 is 4:1:1, DV50 is 4:2:2, and DV100 is 4:4:4. Too bad about the Pinnacle's handling of it.

Xesdeeni

[bellyman]

I understand that during the PAL to NTSC method, that a DEMUX process (split audio from video then process the video then MUX back together) is required.

Can someone please suggest where I might find a few good apps for this?

My step is to take a VOB (one movie may have 4-5 VOBs); convert to MPG then DEMUX into their own pieces. Assumes keeping AC3.

Someone a page back, apparently uses DVD Decrypter in IFO mode. Was wondering if there were any other good ones. At one point I d/l and used an app that created mpv and mpa files - command line perhaps, and for the life of me can't determine the program/file/directory etc of the app.

thanks
belly

[Guest]

One option for VOBs -> M2V + audio is DGIndex, part of the DGMPGDec package.

[magic144]

just thinking out loud here,
please explain away my ignorance

from this thread of discussion
I understand that the 'bobber' (be it bob, tdeint, whatever) interpolates each source field into an entire frame and that you therefore end up with a stream of frames at twice the frame-rate of the original (since originally it took two fields to make a frame)

is this not progressive video? and if so, is there no value in trying to keep it progressive at this point instead of making it interlaced again (which I presume is what's happening with the SeparateFields().SelectEvery().Weave() combo?

one more question I have is that when using the SelectEvery() function (which is called after the ConvertFPS() call), how do we know at that point to use fields 1 and 2 (or 0 and 3), since the fields have presumably been altered by the ConvertFPS() routine and don't strictly relate to the source TOP or BOTTOM fields anymore???

any answers to help my understanding would be much appreciated

cheers for all the info in this thread about TDeint and converting NTSC to PAL interlaced video - it seems to give much better results than using Procoder!

[Xesdeeni]

is this not progressive video? and if so, is there no value in trying to keep it progressive at this point instead of making it interlaced again (which I presume is what's happening with the SeparateFields().SelectEvery().Weave() combo?PAL and NTSC are interlaced. The closest thing to progressive you could create would be 25 fps PAL or 30 fps NTSC. But this will show only 25 or 30 "instants of time" per second. 50 or 60 would be more fluid. Interlacing is a compromise between resolution and fluidity of motion. If the scene isn't moving, you get the higher resolution (480 or 576 lines). If the scene is moving, you get 50 or 60 "instants of time" for smoother motion.one more question I have is that when using the SelectEvery() function (which is called after the ConvertFPS() call), how do we know at that point to use fields 1 and 2 (or 0 and 3), since the fields have presumably been altered by the ConvertFPS() routine and don't strictly relate to the source TOP or BOTTOM fields anymore???It has to do with the ordering of your destination format. Most destination formats store frames. A frame is made of two fields. But which field came first in time? There isn't a standard across all formats. DVDs expect the top field to have come first. DV expects the bottom field to have come first. The choice of 1 & 2 means the upper field is first (1 is the upper field). 0 & 3 means the lower field is first (3 is the upper field).

Xesdeeni

[scharfis_brain]

The choice of 1 & 2 means the upper field is first (1 is the upper field). 0 & 3 means the lower field is first (3 is the upper field).

This is not entirely true!

This returns TFF
assumetff().separatefields().selectevery(4,0,3).weave()

This returns BFF
assumetff().separatefields().selectevery(4,1,2).weave()

This returns BFF
assumebff().separatefields().selectevery(4,0,3).weave()

This returns TFF
assumebff().separatefields().selectevery(4,1,2).weave()

this means:

4,0,3 leaves the previously assume fieldorder untouched, while
4,1,2 reverses the previously assumed fieldorder.

that's why I always suggest to use assumetff/bff() and to avoid 4,1,2!
also this method is much more intiutive and predictable (do you really exactly KNOW which Fieldorder AVISynth assumesnternally?)!

[magic144]

think I need to explain my questions more

thanks to both Xesdeeni and scharfis_brain for your responses - you two are the masters of this universe as far as I can work out, Xesdeeni started this whole pal<->ntsc avisynthing going I think, and scharfis_brain just seems to have a great breadth of knowledge!

I appreciate that , e.g., my NTSC source is interlaced (it was recorded from hockey on the TV)
what I was asking though was that if each FIELD is expanded to a full frame (by guessing/interpolating the other vertical half of the frame) by the 'bobber' (is this not true?) then don't you effectively end up with the output of the bobber as 60 FRAMES-per-second (couldn't this be called progressive?) - so rather than hacking this back up into fields (discarding 1/2) and weaving it back into an interlaced clip, couldn't you somehow keep it as progressive (and wouldn't that be more straightforward)???

I'm not sure how the video is denoted as progressive or interlaced - I presume there are flags. Is the immediate output of the bobber interlaced or progressive? I assume that since each field is now a full frame, this is progressive... (albeit at a non-standard 60 frames-per-second)

maybe someone can explain this to me first, before I try and expand on my second question again...???

cheers in advance guys

[scharfis_brain]

- after a bob-deinterlacer (boober) you got progressive video at full rate (50 or 59.94 fps) with a image quality depending on the bobber and settings used.

- for DVD (SDTV), one needs to re-interlace the full rate progressive video to interlaced, cause DVD (SDTV) only supports 23.976, 25.0, and 29.97 fps being progressive. higher framerates (50.0 and 59.94) can only be represented by using interlacing.

If you really want to preserve the progressive structur, you cansave it as 50 or 59.94 fps AVI with XViD, or as MPEG-2
or upscaled to 720p HDTV.

but expect the first both(AVI &the MPEG-2) being unusable in Standalone players.
720p HDTV will work in suited players.

also this stuff needs HUGE amounts of CPU time and a properly setted up system.

[magic144]

ok, so we're saying the output of a TDeint BOB is (with an interlaced NTSC source)
59.94 FRAMES per second progressive intermediary (where each frame in this intermediary directly corresponds to one of the source's fields)

now what exactly happens to these progressive frames in the ConvertFPS(50) command?

does this generate a 50 FRAMES per second progressive stream?
and if so, what is the relationship between each of these frames and the 59.94fps input frames?

sorry for the questions being in such small steps, I'm just trying to follow this through
because I then want to know how the SelectEvery() function knows which frames (or should I say fields?) to discard

I can understand how you could decide from the original 59.94fps set, because the FRAME sequence would be:

t1 b1 t2 b2 t3 b3 t4 b4

i.e. FRAME 1 is generated from top FIELD 1 from the source
frame 2 is generated from bottom field 1 from the source
frame 3 was generated from top field 2 from the source, etc...

SeparateFields would presumably then generate a 119.88 fields/sec stream

tt1 bt1 tb1 bb1 tt2 bt2 tb2 bb2, etc

i.e. the t1 FRAME has been split into 2 interlaced FIELDS tt1 & bt1, and so on)

then, with a cycle of 4 and choosing only elements 0 and 3, your outputs from SelectEvery() would be
tt1 bb1 tt2 bb2, etc, at 59.94 fields per second

thus the first field DIRECTLY corresponds to the first source frame's top field
the second field directly corresponds to the first source frame's bottom field, etc

and Weave would presumably give you something very much like the original source, denoting (or somehow flagging) that tt1 and bb1 together represent interlaced frame 1, tt2 and bb2 together represent interlaced frame 2, etc..., with an output stream that is now 29.97fps

OBVIOUSLY tt1 is NOT the same as the source's frame 1 top field, since it has gone through the Bobber!

but I'm wondering what the relationship between source (frames and fields) and output (frames and fields) is when the ConvertFPS() function is used, and how you can know to choose the 0th and 3rd elements as the output fields from this function?

[scharfis_brain]

after convertfps there is no direct relation between output and input anymore.
It is a completely NEW video.
also you need to resize for astandards conversion between480 and 576 lines.

convertfps and resize totallt alter the video so, you end up selecting totally different lines in sepfields().selevery().weave().

that's the reason, why we need to deinterlace the stuff in order to do a standards conversion.

[magic144]

Scharfis - thanks for your continued attention - I value your opinion:

do you agree with my points from the last post? particularly about the transitions in the process between fields and frames? am I talking sense?

I realize a new vertical res is req's to satisfy PAL, so I understand the reason for the LancsozResize
btw, what is Lancsoz4Resize - is that better in some way???

so then I guess my question becomes

why choose 0 and 3 (or 1 and 2) and not some other pairing for the SelectEvery call

it seems very arbitrary

and why all the concern about TFF or BFF at the point of choosing, if the fields/frames are so skewed from the original source by that time??? what is the difference?

like what would be the problem with choosing 0 and 1 for example???

After ConvertFPS(), is there still some top/bottom field ordering in the output - is it still a cycle of 4 then??

[Xesdeeni]

Think of it this way:

You get a 50 frame-per-second progressive video. Perhaps it's from an HD feed that you scale down to 576 lines.

How do you encode this for a standard PAL DVD?

1. You could discard every other frame and get 25 progressive frames. You can encode a DVD this way, although when it is played back, each frame will be separated into fields that are fed to a (normal) PAL TV (for a progressive player, things will be different, but let's keep focused on normal PAL TVs). But now you only have 25 individual positions of the objects in the video every second. Particularly for fast motion, like in sports, things will be jerky. This will be worse than if you had actually filmed with 25 frames per second, because the shutter speed will not have been designed for 25 fps, it will have been designed for the 50 fps, because that's what was filmed.

2. You can convert to 25 interlaced frames, which is the same as saying you create 50 fields from the 50 frames. You started with:T1 T2 T3 T4 T5
B1 B2 B3 B4 B5...So you could create your interlaced version in a variety of ways, the most obvious of which are:T1 T3 T5
B2 B4 ...or T2 T4
B1 B3 B5...As a result, you could have:T1 T3 T5
B2 B4 B6...which is top field first. This is because T1 is the top field of the first frame, and it comes from the first "instant of time" (i.e. the first progressive source frame), while B2 is the bottom field and comes from the second "instant of time." Alternatively, you could haveT2 T4 T6
B1 B3 B5...You should be able to see that this is bottom field first.

In this case, you'll get all 50 "instants of time" covered by your video, which is more fluid and matches the original shutter speed. And if things are not moving, you'll full vertical resolution. A good compromise

---

Now think of the source as a ConvertFPS(50)/ChangeFPS(50) result from a 59.94 fps progressive source. Then think of the 59.94 fps progressive source as coming from a 59.94 fps interlaced source that has been passed through a smart deinterlacer (something a bit better than a bobber).

Wait, I see something that might be confusing you. A bobber would interpolate between the lines of one field to create the lines of the other. And maybe you're wondering how you avoid using the interpolate lines instead of the actual source lines when you SelectEvery(). That's a good point for bobbers, but for smart deinterlacers, things are much better.

If there is no motion, then a smart deinterlacer will not interpolate to fill in the missing lines. It will instead borrow the lines from the fields before or after the supplied one. In this case, choosing any lines from this progressive frame with SelectEvery() will get genuine original lines.

OTOH, if things are in motion, there is interpolation. But it turns out that this interpolation isn't really all that bad. There are so many other artifacts floating around, and things are in motion after all, that the eye isn't as bothered by choosing interpolated things over originals in this case.

Maybe that's what you meant?

Xesdeeni

[magic144]

thanks guys

I think I get it!

you basically have to treat the output of the bobber/smart-deinterlacer as a whole new progressive stream - forget about the ORIGINAL fields and whether or not they were top or bottom

then interlace traditionally using the 0,3 selection (subsampling one from the top fieldset, one from the bottom fieldset to get the right field rate) for weaving into a TFF output interlaced stream

so is TDeint a smart deinterlacer? (in bob mode)
it does all the good things you said about borrowing lines where appropriate, Xesdeeni? hence the output looks so good?

and I'm hearing that we want to keep the output interlaced because we want to preserve the fluidity of motion from the original interlaced stream

thanks again guys - you helped my understanding out a lot

[Xesdeeni]

I think TDeint is a smart deinterlacer. Honestly I haven't used it. I ported Gunnar Thalin's Smoothdeinterlacer from VirtualDub to AVISynth and used that. Now I use LeakKernelBob, which is an MMX optimized version of KernelBob. There may be newer/faster/better ones, but I haven't had time (or the need) to work with this lately. Ideally, the motion compensated deinterlace work being experimented will get somewhere. But I didn't have much luck with it myself, so I gave up on it.

Xesdeeni

[a2j]

Xesdeeni, I've used yor script to convert NTSC DV to PAL DV from somewhere in this forum for quite a long time. The script is this:
=============================
loadPlugin ("c:\SmoothDeinterlacer.dll")
DirectShowSource("g:\03-04.avi",audio=false)
SeparateFields() # Correct for bug...
Weave() # ...in SmoothDeinterlacer
SmoothDeinterlace(doublerate=true)
ConvertFPS(50) # or ChangeFPS(50)
LanczosResize(720,576)
SeparateFields()
SelectEvery(4,0,3)
Weave()
=============================
And now all of the sudden on one of the files I need to process quite fast, the script gives me following: "Weave: Weave should be applied on field-based material: use AssumeFieldBased() beforehand (c:\ntsc_pal_script.avs, line 5)"

If I do it this way
=============================
loadPlugin ("c:\SmoothDeinterlacer.dll")
DirectShowSource("g:\03-04.avi",audio=false)
SeparateFields() # Correct for bug...
AssumeFieldBased()
Weave() # ...in SmoothDeinterlacer
SmoothDeinterlace(doublerate=true)
ConvertFPS(50) # or ChangeFPS(50)
LanczosResize(720,576)
SeparateFields()
SelectEvery(4,0,3)
Weave()
=============================
It gives me the same problem... Frankly speaking, I don't even know how the whole thing works - I just use it, so I can't fix it myself... Alas.

Please, give me some advice on how to get this working?.. Thank you.