Tweaks in using ConvertFPS() for PAL-to-NTSC conversion???

[scharfis_brain]

the choice of the deblocker or deinterlacer has NO influence on the motion smoothness.

You shouldn't judge the motion smoothness on your PC, because PCs aren't made for it. Burn the stuff on a DVD-RW and check it with a standalone player

[castellandw]

the choice of the deblocker or deinterlacer has NO influence on the motion smoothness.

You shouldn't judge the motion smoothness on your PC, because PCs aren't made for it. Burn the stuff on a DVD-RW and check it with a standalone player

scharfi, not motion blur, I'm talking about regular picture blur for both the luma and chroma deblockers. You're right though, a standalone player seems the best way to test.

Even at 60 Hz though, commercial DVDs which are 29.97i that I play on my laptop don't really show as much jerky motion as the clips I tried to convert from PAL to NTSC on Avisynth, and those commercial DVDs in particular don't show any frame jitter as those clips I converted from PAL to NTSC. Also, because of the frame jitter from playing those clips I converted, it seemed to have an effect on the video chipset(ATI Radeon 9000 IGP) on my laptop. I had to resize the resolution or switch between LCD, CRT or TV outputs on my laptop to somehow refresh the graphics hardware in order to get rid of frame jitter during playback of normal commercial DVDs.

[mg262]

He wasn't talking about motion blur.

I had to resize the resolution or switch between LCD, CRT or TV outputs on my laptop to somehow refresh the graphics hardware in order to get rid of frame jitter during playback of normal commercial DVDs.This tells you that it's not the conversion mechanism or content of the clips but the playback mechanism that is causing the jitter. How at you playing back the two things you are comparing -- converted clip and commercial DVDs?

[castellandw]

He wasn't talking about motion blur.

This tells you that it's not the conversion mechanism or content of the clips but the playback mechanism that is causing the jitter. How at you playing back the two things you are comparing -- converted clip and commercial DVDs?

Well, I've used Intervideo WinDVD 7 in general, but I used Media Player Classic recently to play back the clips. I also burned the clips to DVD to test them out as well. I'm not sure if the playback mechanism is at fault because before I played the converted clips, I never experienced any sort of frame jitter at all before when I played commercial DVDs whatsoever.

[scharfis_brain]

of course, you will experience uneven motion with blend-conversions such es witj convertfps. They cannot be supersmooth. this can only be achived with motion compensation techniques.
But those are terribly slow (1hr video == 1 day processing time) and are eating up all your memory (500 MBs).

[castellandw]

of course, you will experience uneven motion with blend-conversions such es witj convertfps. They cannot be supersmooth. this can only be achived with motion compensation techniques.
But those are terribly slow (1hr video == 1 day processing time) and are eating up all your memory (500 MBs).

Well, I'm not looking for stupendously supersmooth motion, but when I played back the converted clips on a VGA monitor, I don't see any problems with smooth motion because the results did seem satisfying enough to me.

In the case of frame jitter, perhaps I haven't explained it properly. When I meant frame jitter, this has nothing to do with the jerky motion I experienced where frames seemed to drop, which I managed to solve now by using a monitor with a higher refresh rate than 60Hz. The frame jitter I'm experiencing is basically the frame jumping up and down a small bit, which is noticeable at the top and bottom of the picture. Also, the only time you don't see frame jitter on applications like WinDVD 7 during playback of the converted clips is when you resize to full screen. When I tried using the HuffyYUV AVI format to preview the video output at 59.94 progressive frames per second after using ConvertFPS(59.94), I never saw any frame jitter. So it seems to me that the frame jitter seems visible after reinterlacing it. I've read that SeparateFields() does produce jitter on a clip, and so I'm wondering if the use of SeparateFields() causes frame jitter?

[scharfis_brain]

so, up and downwards jitter is a problem of your playback setup. not of the conversion.

[Wilbert]

interestingly, there's a PAL only "FILM" flag that can be set when authoring DVDs. nobody i've spoken to has the slightest clue what it's for though...

(...)

Oh, wait a minute, 3:2 pulldown is for NTSC. 2:2 pulldown is for PAL.
Looking at dvddemystified.com (3.4) you are indeed right. It's 23.976 with 2:2 pulldown (so playback is at 25 fps - PAL Video) applied to it.

You can also set this option in DGPulldown from neuron2.

----------

Regarding PALplus, which is analog so it has nothing to do with this dvd authoring option above. However, it does have such an option stored in the WSS data, which a PALplus TV can use:


4.3: Film Mode & Camera Mode:

Some of the bits of the WSS data tell a PALplus decoder whether the signal originated from a 50Hz interlaced camera source or from a telecine. The Clean PAL encoding/decoding process, and the derivation of the helper signal are slightly different in these two modes. A PALplus TV also has the option of de-interlacing a "Film Mode" signal and displaying it on a 50Hz progressive-scan display (or using ABAB field repeat on a 100Hz interlaced display) without risk of motion artefacts. This is because it is guaranteed that in Film Mode, both odd and even fields of a frame came from the same image, so no motion artefacts will be obtained from such reprocessing.

from http://tallyho.bc.nu/~steve/palplus.html.

[castellandw]

Well, as of now, we finally found out that ConvertFPS() is no longer the problem, and that jerky motion was a problem of my playback setup because I needed to use a monitor with a faster refresh rate. So I don't think converting between different standards on Avisynth has anything to do with the frame jitter, but I wonder if I tried to use a smart bob deinterlacer on my PAL source and then (without any framerate conversion) reinterlaced back to PAL using SeparateFields().SelectEvery(...).Weave(), then I'll get the same frame jitter.

[scharfis_brain]

if you are pleased with the convertfps results, what do you think about this http://home.arcor.de/scharfis_brain/mvbob/halfD1-mocomp.m2p then?

it took 13 minutes on my 1.4 GHz machine to convert this 20 seconds sample.

[castellandw]

OK,

#1 : I made an HuffyYUV avi file of the original PAL source converted to NTSC at 59.94 progressive frames per second using the following script:
MPEG2Source("PALMPEG2CLIP.d2v")
LeakKernelBob(order=1, threshold=4)
ConverttoYUY2()
ConvertFPS(59.94)
Lanczos4Resize(320, 240)

HuffyYUV avi Results #1: No frame jitter for converting to 59.94 fps.

#2: Next, I used this script to Convert the PAL source to MPEG-2 NTSC on Tmpgenc:
MPEG2Source("PALMPEG2CLIP.d2v")
LeakKernelBob(order=1, threshold=4)
ConverttoYUY2()
ConvertFPS(59.94)
Lanczos4Resize(720, 480)
SeparateFields()
SelectEvery(4,0,3)
Weave()

After converting to MPEG-2 NTSC, I used the final MPEG-2 NTSC converted clip to output the clip to a HuffyYUV avi file at 59.94 fps using this script:
MPEG2Source("NTSCConvertedFromPALMPEG2CLIP.d2v")
LeakKernelBob(order=1, threshold=4)
Lanczos4Resize(320, 240)

HuffyYUV avi Results #2:No jitter up and down, but extremely jerky motion with frames moving back and forth.

Shouldn't Results #1=Results #2 because if they're supposed to, I think there should be an alternative way to using SeparateFields().SelectEvery(...).Weave()?

[castellandw]

if you are pleased with the convertfps results, what do you think about this http://home.arcor.de/scharfis_brain/mvbob/halfD1-mocomp.m2p then?

it took 13 minutes on my 1.4 GHz machine to convert this 20 seconds sample.

scharfi, what was the script you used to convert this?

[castellandw]

OK mg262, I'll be as concise as I'll get to tell this problem:

Note: Viewing output for HuffyYUV was mainly done on a VGA monitor at a refresh rate of 100 Hz. Viewing output for MPEG-2 DVD content was mainly done on a TV DVD Player, but the problem lies more in the HuffyYUV results than in the MPEG-2 content).

Test #1 (Viewing 50 progressive fps after ConvertFPS() without reinterlacing):
Here's the avisynth I used to output to HuffyYUV AVI format:
loadplugin("leakkerneldeint.dll")
LoadPlugin("DGDecode.dll")
MPEG2Source("H:\PALMPEG2Clip.d2v")
LeakKernelBob(order=1, threshold=4)
ConverttoYUY2()
ConvertFPS(59.94)
Lanczos4Resize(320, 240)

I opened the Avisynth script using VirtualDub 1.6.11, and encoded the avi output using the ffdshow HuffyYUV codec with Colorspace: YUY2 and Predictor: Left.

Test # 1 Results: Smooth motion. No jitter whatsoever.

Test #2 (Viewing 59.94 progressive fps after ConvertFPS() and reinterlacing the clip):
Step 1: Here's the script I used to output NTSC video for MPEG-2 encoding in TMPGEnc:
loadplugin("leakkerneldeint.dll")
LoadPlugin("DGDecode.dll")
MPEG2Source("H:\PALMPEG2Clip.d2v")
LeakKernelBob(order=1, threshold=4)
ConverttoYUY2()
Lanczos4Resize(720, 480)
ConvertFPS(59.94)
AssumeTFF()
SeparateFields()
SelectEvery(4,1,2)
Weave()

For MPEG-2 encoding in TMPGEnc, I first loaded the avisynth script, and saved the encoded MPEG-2 file as PALToNTSC.mpg choosing the option System(Video Only). As for encoding setting, I loaded the DVD(NTSC).mcf profile template as well as the unlock.mcf profile template. I also made sure the encoding settings were to my specifications as see on these screenshots attached to this post on these two links below:
http://forum.doom9.org/attachment.php?attachmentid=4974&stc=1
http://forum.doom9.org/attachment.php?attachmentid=4975&stc=1

(Step 1 Results: No jerky motion, but frame jitter when not showed at fullscreen on a PC.)
Step 2:Once I finished creating PALToNTSC.mpg, I used the following Avisynth script on PALToNTSC.mpg to output into a HuffyYUV avi file at a progressive 59.94 fps:
loadplugin("leakkerneldeint.dll")
LoadPlugin("DGDecode.dll")
MPEG2Source("H:\PALToNTSC.d2v")
LeakKernelBob(order=1, threshold=4)
Lanczos4Resize(320, 240)

I used the same VirtualDub settings in Test #1 to open the Avisynth script in order to create my HuffyYUV avi file.

Test #2 Results: Extremely jerky results. Frames moving backing and forth.

So judging from these results here, shouldn't I getting same sort of smooth motion results (aka Test #1 Results=Test #2 Results) before and after reinterlacing the video? (It seems to me after reinterlacing the clip that if you apply a smart bob deinterlacer on the newly reinterlaced clip, the smart bob deinterlace won't be able to properly deinterlace the clip at all.)

[mg262]

AssumeTFF()
SeparateFields()
SelectEvery(4,1,2)
Weave()This will give you bottom field first output. Unless you have set your DVD encoder to encode this, you will get a mess. I recently read a suggestion that some encoders may encode as TFF regardless of what flags you set. Therefore: try (4, 0, 3).

By the way, the interlaced content output by test 2, step 1 can't be meaningfully checked on a PC.

Edit: note this:
LeakKernelDeint() and LeakKernelBob() take the following named parameters:

order (0-1, default none!) This parameter defines the field order of the clip. It is very important to set this correctly. Use order=0 for bottom field first (bff). Use order=1 for top field first (tff). You must specify order; LeakKernelDeint throws an exception if you omit this parameter.
So if you are going to feed it bottom field first video, you need to change this parameter. But I would recommend switching to top field first.

N.B.: Please reply to this message rather than editing the above post... it can be hard to find what has changed in an edit.

[castellandw]

This will give you bottom field first output. Unless you have set your DVD encoder to encode this, you will get a mess. I recently read a suggestion that some encoders may encode as TFF regardless of what flags you set. Therefore: try (4, 0, 3).

By the way, the interlaced content output by test 2, step 1 can't be meaningfully checked on a PC.

Edit: note this:

So if you are going to feed it bottom field first video, you need to change this parameter. But I would recommend switching to top field first.

N.B.: Please reply to this message rather than editing the above post... it can be hard to find what has changed in an edit.


OK, that's an absent-minded mistake of me not putting order=0 instead of order=1 in LeakKernelBob(), sorry about that, and so for test #2 results, I see no frame jitter. As for bottom field first video, I think if I use AssumeTFF().SeparateFields().SelectEvery(4, 1, 2).Weave() or SeparateFields().SelectEvery(4,0,3).Weave(), I'll get bottom field first video either way. In any case, well, it seems that whether you use PC DVD players at fullscreen or TV DVD players, you don't notice any frame jitter up and down(no jerky motion). However, what really bugs me, mg262, is that at a non-fullscreen resolution for any of my Avisynth PAL-to-NTSC converted clips, you get frame jitter on a PC DVD player software, but commercial DVDs which have PAL TV footage converted to NTSC don't show any frame jitter on a PC DVD player whatsoever. So I'm wondering, what is it that is used on commercial DVD MPEG-2 that any of our PAL-To NTSC clips converted on AviSynth don't use to avoid that sort of frame jitter on a PC DVD player?

[mg262]

If you use AssumeTFF().SeparateFields().SelectEvery(4,0,3).Weave(), you will get top field first content out.

You now have a way of making non-jittery content for either PC (use progressive) or for TV (use interlaced). IMO, you should pick one of these and stick with it; interlacing and then deinterlacing info PC playback will never be as smooth as using progressive content in the first place.

As a separate question, it is interesting that your software DVD player isn't deinterlacing the material you create. I've said it more than once, so I'm going to assume that you are using comparable material -- i.e. that you have burnt a DVD with interlaced MPEG 2 content at a bit rate comparable to that of commercial DVDs and that you are playing this DVD back on your PC and you are getting jitter. In this case it might be something to do with the content, or it might be something to do with the flags on the DVD. Pretty hard to tell...

Edit: I don't think this is it, but it could even be that the deinterlacer built into the software deals with bottom field first material badly. Try top field first. (I'm assuming you have a DVD-RW at hand... they're useful for this kind of thing.)

[castellandw]

If you use AssumeTFF().SeparateFields().SelectEvery(4,0,3).Weave(), you will get top field first content out.

You now have a way of making non-jittery content for either PC (use progressive) or for TV (use interlaced). IMO, you should pick one of these and stick with it; interlacing and then deinterlacing info PC playback will never be as smooth as using progressive content in the first place.

As a separate question, it is interesting that your software DVD player isn't deinterlacing the material you create. I've said it more than once, so I'm going to assume that you are using comparable material -- i.e. that you have burnt a DVD with interlaced MPEG 2 content at a bit rate comparable to that of commercial DVDs and that you are playing this DVD back on your PC and you are getting jitter. In this case it might be something to do with the content, or it might be something to do with the flags on the DVD. Pretty hard to tell...

Edit: I don't think this is it, but it could even be that the deinterlacer built into the software deals with bottom field first material badly. Try top field first. (I'm assuming you have a DVD-RW at hand... they're useful for this kind of thing.)

Oh, no, mg262, it is bob deinterlacing to full 59.94 fps (I can practically tell by the fluidity of the motion, and it is actually deinterlacing.) Only at the top and bottom borders of the frame, you notice some sort of frame jitter, and what's even weirder, is that the motion isn't jerky, but the frame jitter I'm talking about is at the top and bottom borders of the frame looks as if the fields are shifting up and down during the motion. For the software DVD player(WinDVD 7), you can only be able to bob deinterlace at best performance if you enable Hardware DVD acceleration, but you can't control bottom and top fields first for bob deinterlacing on WinDVD. Oh yes, I'm using DVD-RW. I wouldn't dream of using DVD-R unless it was the final result. What software PC players do you have because if you have something like WinDVD with DVD hardware acceleration enabled, perhaps you're able to see the problem for yourself to see what I mean if I post the clip I converted online?

[mg262]

Please try changing everything to top field first. Even if it doesn't make a difference, it rules out certain possibilities.

[Boulder]

Oh, no, mg262, it is bob deinterlacing to full 59.94 fps (I can practically tell by the fluidity of the motion, and it is actually deinterlacing.) Only at the top and bottom borders of the frame, you notice some sort of frame jitter, and what's even weirder, is that the motion isn't jerky, but the frame jitter I'm talking about is at the top and bottom borders of the frame looks as if the fields are shifting up and down during the motion.
Isn't that what bobbing by definition is? Fields separated, resized to full height and slightly nudged.

[castellandw]

Isn't that what bobbing by definition is? Fields separated, resized to full height and slightly nudged.

Yeah, but I don't think anyone has ever seen a TV program bob that way before that I described it even if it's converted to NTSC from PAL?

[mg262]

The effect you describe sounds like the sort of thing that happens when you news of the incorrect top field first/bottom field first setting.

[castellandw]

Please try changing everything to top field first. Even if it doesn't make a difference, it rules out certain possibilities.

Do you mean use PAL source and then reinterlace it back into PAL again, because there's no such thing as top fields first 29.97i NTSC video that can be played on a DVD player?

[castellandw]

The effect you describe sounds like the sort of thing that happens when you news of the incorrect top field first/bottom field first setting.

That's what I mean, but if it was incorrect field setting, I would be getting extremely jerky motion with frames moving in a mixed backwards.forwards motion, wouldn't I?

[mg262]

That's what I mean, but if it was incorrect field setting, I would be getting extremely jerky motion with frames moving in a mixed backwards.forwards motion, wouldn't I?Not necessarily.

[castellandw]

Not necessarily.
mg262, do you have WinDVD software or what graphics hardware do you have on your PC?

[castellandw]

@scharfi, if you're there, I tried out your PAL-To-NTSC clip at 352x480 you converted from my PAL MPEG-2 clip I uploaded online. Your clip has no frame jitter when played on my software DVD player, and yet all my converted PAL to NTSC clips played I've done have frame jitter. So I really like to know what AviSynth script and what MPEG-2 encoder you used?

[scharfis_brain]

try this clip http://home.arcor.de/scharfis_brain/mvbob/halfD1-blending.m2p

and then tell me, whether it shows the jitter problem, too, or not.

[castellandw]

try this clip http://home.arcor.de/scharfis_brain/mvbob/halfD1-blending.m2p

and then tell me, whether it shows the jitter problem, too, or not.

Downloading your clip as I type this, I forgot to mention that all my NTSC converted clips are 720x480, and so I'm wondering if resolution size plays a part in causing frame jitter because your 352x480 didn't produce jitter and when I plays those clips on my WinDVD software DVD player at fullscreen, no jitter at all.

[scharfis_brain]

the resolution isn't responsible for judder if your Computer is fast enough (1GHZ should be sufficient).

As other persons mentioned earlier: watch your fieldorder!
Please do not forget those things:
1) setup the correct fieldorder for your deinterlacer (or use TDeint, which selects it automatically with MPEG-sources)
2) re-set the Fieldorder to TFF with AssumeTFF() directly before the separatefields() command
3) Ensure that your MPEG2 encoder is set to TFF (UFF), too!

also provide a converted MPG sample. I'll have a look on it.

[castellandw]

the resolution isn't responsible for judder if your Computer is fast enough (1GHZ should be sufficient).

As other persons mentioned earlier: watch your fieldorder!
Please do not forget those things:
1) setup the correct fieldorder for your deinterlacer (or use TDeint, which selects it automatically with MPEG-sources)
2) re-set the Fieldorder to TFF with AssumeTFF() directly before the separatefields() command
3) Ensure that your MPEG2 encoder is set to TFF (UFF), too!

also provide a converted MPG sample. I'll have a look on it.

Wait a minute, the MPEG-2 Encoder set to TFF?? But, scharfi, it's NTSC that I'm outputting, so shouldn't that be Bottom Fields First that should be set on a MPEG-2 encoder like TMPGENC? In other words, since the Avisynth script is outputting 720x480 at Bottom Fields First for the NTSC standard, shouldn't the video input source(which is the output of the Avisynth script I'm using) for the MPEG-2 encoder be Bottom Fields First(BFF)?

By the way, I just tried your blending clip: no frame jitter, but some blocky artifacts which I guess is normal since you're using an encoding bitrate of 4-5 Mbps (Out of curiosity, what is the Avisynth script you're using for both the motion compensated clip and the blending clip you uploaded for me?)

[scharfis_brain]

TFF and BFF are both valid. TFF is more common on DVD.

I used an AVG bitrate of 2300 kbps. not 4 to 5 mbps.

for the blending, I used this script:

mpeg2source("PALMPEG2Clip.d2v",cpu=0)
#crop(8,0,-8,0).horizontalreduceby2() #only for 352 pixels width
TDeint(mode=1,type=3)
converttoyuy2()
convertfps(59.94)
lanczosresize(width,480)
assumetff()
separatefields()
selectevery(4,0,3)
weave()

then I fed it iinto an encoder. the script puts Out TFF. if you want BFF, use AssumeBFF() instead of AssumeTFF(). But I strongly suggest you to use TFF.


the motioncompensated video was made this way:
DL this Package (highly experimental!): http://forum.gleitz.info/attachment.php?attachmentid=76619&d=1131804163

and the use this script:
import("mvbob~.avs")

MPEG2Source("PALMPEG2Clip.d2v")
mvbob(convfps=true)
bicubicresize(width, 480)
reinterlace()

this puts out TFF, too.

But be careful with this method. it takes huge amounts of your Systems RAM and will make the CPU sweat. My PC needed 13 minutes for your 20 seconds clip to render. MPEG2 encoding not included, cause simultaneous encoding would have killed the encoder due to memory shortages (I have 768 MB)

[castellandw]

TFF and BFF are both valid. TFF is more common on DVD.

I used an AVG bitrate of 2300 kbps. not 4 to 5 mbps.


Yikes, I hope you're not using bitrates of 2300 kps or resolutions of 720x480 for actual stuff that you want to permanently put on MPEG-2 DVD to view on TV. Resizing to resolutions as low as 352x480 will definitely create blocky artifacts especially with bitrates as low as 2300kps and especially with Bicubic or Lanczos filters. For resolutions of 352x480, I really suggest the faster Bilinear filter because it's the least likely to create blocky artifacts being the softest resize filter from my experience of using those types of resizing on Avisynth or Virtualdub. I'm not surprised that it took 13 minutes to convert my clip.
Also, you could have used a bitrate as high as 8-9 MBps because I wouldn't have minded the larger filesize and with a bitrate a low as 2-3 MBps, you're always going to need more compression which you know as well I do requires more CPU time. I've learned that no matter what the resolution size you use, you're always gonna notice that the lower your video encoding bitrate is, the more block artifacts on your video that you get.


mpeg2source("PALMPEG2Clip.d2v",cpu=0)
#crop(8,0,-8,0).horizontalreduceby2() #only for 352 pixels width
TDeint(mode=1,type=3)
converttoyuy2()
convertfps(59.94)
lanczosresize(width,480)
assumetff()
separatefields()
selectevery(4,0,3)
weave()


I've noticed this interesting thing between LeakKernelBob and TDeint.
For using LeakKernelBob(), you should use for reinterlacing the video for top fields first video (TFF) output:
AssumeTFF()
SeparateFields()
SelectEvery(4,1,2)
Weave()

For using TDeint(), you should use for reinterlacing the video for top fields first video (TFF) output:
AssumeTFF()
SeparateFields()
SelectEvery(4,0,3)
Weave()



the motioncompensated video was made this way:
DL this Package (highly experimental!): http://forum.gleitz.info/attachment.php?attachmentid=76619&d=1131804163

and the use this script:
import("mvbob~.avs")

MPEG2Source("PALMPEG2Clip.d2v")
mvbob(convfps=true)
bicubicresize(width, 480)
reinterlace()


Do you want to see my modified version of your mvbob.avs which applies the Block Overlap plugin created by Fizick for block overlapped motion compensation(It's slower, but when I tried it, it definitely removes blocky artifacts produced by block matching motion compensation)?

You know, come to think of it. We really should have a YV12 ConvertFPS() function in-built on Avisynth because first of all, the MPEG-2 source is YV12, and after ConvertFPS() uses it, the Avisynth script output will be in YUY2, and the MPEG-2 Encoder will convert it back to YV12 again. So with two different colorspace conversions, won't that degrade the image quality more?

[scharfis_brain]

Yikes, I hope you're not using bitrates of 2300 kps or resolutions of 720x480 for actual stuff that you want to permanently put on MPEG-2 DVD to view on TV. Resizing to resolutions as low as 352x480 will definitely create blocky artifacts especially with bitrates as low as 2300kps and especially with Bicubic or Lanczos filters. For resolutions of 352x480, I really suggest the faster Bilinear filter because it's the least likely to create blocky artifacts being the softest resize filter from my experience of using those types of resizing on Avisynth or Virtualdub. I'm not surprised that it took 13 minutes to convert my clip.
Also, you could have used a bitrate as high as 8-9 MBps because I wouldn't have minded the larger filesize and with a bitrate a low as 2-3 MBps, you're always going to need more compression which you know as well I do requires more CPU time. I've learned that no matter what the resolution size you use, you're always gonna notice that the lower your video encoding bitrate is, the more block artifacts on your video that you get.

Uhm, I wanted to create small files so my webspace could hold them.
You do NOT need to tell me how to create good MPEGs. Here Coding quality wasn't of any matter. Only motion quality was.

I've noticed this interesting thing between LeakKernelBob and TDeint.
For using LeakKernelBob(), you should use for reinterlacing the video for top fields first video (TFF) output:
AssumeTFF()
SeparateFields()
SelectEvery(4,1,2)
Weave()

For using TDeint(), you should use for reinterlacing the video for top fields first video (TFF) output:
AssumeTFF()
SeparateFields()
SelectEvery(4,0,3)
Weave()


NO! NO! NO!

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()


long story short:
before assume?ff() we have progresive video with
1) BFF assumed, when (leak)kernelbob() or bob() is used (which is a known bug, but the author don't want to cahnge this behaviour). Assume?ff() will overwrite the setting.
2) TFF or BFF, dependant to the source, when you use TDeint.

4,0,3 leaves the previously assumed fieldorder
4,1,2 reverses the previously assumed fieldorder

Do you want to see my modified version of your mvbob.avs which applies the Block Overlap plugin created by Fizick for block overlapped motion compensation(It's slower, but when I tried it, it definitely removes blocky artifacts produced by block matching motion compensation)?
No I did not. Produced it noticeably better results?

You know, come to think of it. We really should have a YV12 ConvertFPS() function in-built on Avisynth because first of all, the MPEG-2 source is YV12, and after ConvertFPS() uses it, the Avisynth script output will be in YUY2, and the MPEG-2 Encoder will convert it back to YV12 again. So with two different colorspace conversions, won't that degrade the image quality more?

As most MPEG2 encoders only accept YUY2 or RGB24, and reinterlacing NEEDS YUY2 to not destroy chroma alignment, I don't see a problem with YUY2.
The only encoders I know, that only accept YV12 are IMO Qenc and/or HCenc. But it is rather difficult to work with YV12 especially in interlaced mode, cause one can mess up things pretty quick.
Also, when there are becoming YUY2 capable mvtools available, I'll rebuild it to work completely with YUY2 internally, because with YV12 one cannot handle chroma properly.

[castellandw]

Uhm, I wanted to create small files so my webspace could hold them.
You do NOT need to tell me how to create good MPEGs. Here Coding quality wasn't of any matter. Only motion quality was.


Well no, I can't tell you how to create good MPEGs, but you said it took up a lot of RAM and CPU time (making up 13 minutes) to convert 20 seconds. I mean I feel bad hogging too much of your resources for too long a amount of time. That's why I suggested Bilinear filter and a higher bitrate for faster performance since it wouldn't take up more CPU cycles and RAM. Besides, I wouldn't have mind if you picked out a few seconds out of the 20 seconds from the clip, but that's no big deal since you used a lesser resolution and lesser bitrate to use lesser webspace. I understand.


NO! NO! NO!

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()

long story short:
before assume?ff() we have progresive video with
1) BFF assumed, when (leak)kernelbob() or bob() is used (which is a known bug, but the author don't want to cahnge this behaviour). Assume?ff() will overwrite the setting.
2) TFF or BFF, dependant to the source, when you use TDeint.


Oh yeah, that's absent-minded. When I tested top-fields first output between LeakKernelBob and TDeint, I didn't use AssumeTFF() or AssumeBFF() so you're right.

A bug in LeakKernelbob, eh. Aah, so that's why I had to change between SelectEvery(4,0,3) and SelectEvery(4, 1, 2) when I didn't use Assume?FF().


4,0,3 leaves the previously assumed fieldorder
4,1,2 reverses the previously assumed fieldorder


Oh, ok, now, that explains the pattern between 4,0,3 and 4,1,2. Thanks.


No I did not. Produced it noticeably better results?


Oh, do you mean you already have modified your mvbob script with the Block Overlap plugin or did you modify the script with something better than Block Overlap to produce better results? If you did modify your script, I would like to know the URL to try it out.


As most MPEG2 encoders only accept YUY2 or RGB24, and reinterlacing NEEDS YUY2 to not destroy chroma alignment, I don't see a problem with YUY2.
The only encoders I know, that only accept YV12 are IMO Qenc and/or HCenc. But it is rather difficult to work with YV12 especially in interlaced mode, cause one can mess up things pretty quick.
Also, when there are becoming YUY2 capable mvtools available, I'll rebuild it to work completely with YUY2 internally, because with YV12 one cannot handle chroma properly.

Really?? I see, chroma alignment is not handled well. It's strange though because when I use mvfps() which doesn't require YUY2, the video output does look like the video has better color and image quality than using ConvertFPS() with ConvertToYUY2(Or maybe the lesser quality in YUY2 I'm seeing is a result of the blending with ConvertFPS()). I don't know, what do you think?

[foxyshadis]

Well no, I can't tell you how to create good MPEGs, but you said it took up a lot of RAM and CPU time (making up 13 minutes) to convert 20 seconds.
He actually said that was the avisynth time, due to mvbob2 alpha (pardon my terminology), and that he encoded as a separate step. The link was also in the post, http://forum.gleitz.info/attachment.php?attachmentid=76619&d=1131804163

Scary stuff. Reminds me of something phaeron said once, "If your encode times are better measured in spf than fps, don't bother tweaking the pipelining." =D

[castellandw]

He actually said that was the avisynth time, due to mvbob2 alpha (pardon my terminology), and that he encoded as a separate step. The link was also in the post, http://forum.gleitz.info/attachment.php?attachmentid=76619&d=1131804163


Oh, ok, I didn't look at it yet. I can't be available right away at home all the time to look to be able to access files. Besides, how was I supposed to know before clicking the link that it was his latest version on his mvbob.rar file. It's vague when you all you see is an attachment ID on the URL. In any case, before I try mvbob out, I'm gonna try out AssumeBFF() and AssumeTFF() with LeakKernelBob() and TDeint() to see which is best. It's kind of weird though that you can input a 4:3 NTSC resolution(720x480) video with top fields first from the output of a standards conversion Avisynth script into a MPEG-2 encoder like TMPGEnc because from my understanding, NTSC is bottom fields first.

[castellandw]

scharfis_brain, it seems to me that not using AssumeTFF().SeparateFields().SelectEvery(4,0,3).Weave or AssumeBFF().SeparateFields().SelectEvery(4,0,3).Weave was responsible for the frame jitter which also affected the bob deinterlacing in the MPEG-2 Hardware of my graphics chipset for playback of even commercial DVDs. I never realized that you could set NTSC video with top fields first as input to your MPEG-2 encoder, which is weird and scary stuff. I think it's a good lesson that it's best to use Assume?FF() and SelectEvery(4,0,3) or otherwise, playback of your Avisynth output could cause bad side effects on your MPEG-2 hardware for bob deinterlacing like frame jitter. Also, after careful testing, it seems that it doesn't matter whether or not I use TDeint or LeakKernelBob. So I'll use TDeint, but I'll test both on bigger footage if TDeint causes some problems.

By the way, I found out in your mvbob.rar that you're using an older version of TDeint from April 2005 and the latest one I have is from August 2005. May I ask, scharfis, why you don't have the latest version of TDeint in your mvbob package?

[mg262]

So, have you finally reached the conclusion that ConvertFPS can be made to give reasonable output? Or not?

[castellandw]

mg262, didn't I reach that conclusion earlier in this thread? In any case, I cornered the problem to jerky motion where frames dropped to monitor with lesser refresh rate, and so I should use a monitor with a refresh rate better than 60 Hz. Also, to solve frame jitter, I just had to make sure I use AssumeTFF() or AssumeBFF() with SelectEvery(4,0,3), although it's weird that you need to set NTSC video input with top fields input on the settings of an MPEG-2 encoder which actually works. So yes, I reached the conclusion that ConvertFPS() gives reasonable output. However, between requiring to output in the YUY2 colorspace for ConvertFPS() and being able to output in the YV12 colorspace using frame-rate conversion, especially motion-compensated ones like mvfps(), I noticed that YV12 output from the Avisynth script gives off better image color quality than YUY2. On the other hand, I learned from scharfis that using YV12 for reinterlacing causes problems with chroma alignment. So I don't know. What do you think, mg262, between the two colorspace, YUY2 and YV12?

[mg262]

mg262, didn't I reach that conclusion earlier in this thread?
I don't know. Your posts can be a little hard to read. Sometimes shorter is better.
What do you think, mg262, between the two colorspace, YUY2 and YV12?I use YV12 for everything, excepting only Dust. But a) I nearly always deal with progressive animation and b) I code more than script and coding for non-planar colourspaces is painful and generally unrewarding.

scharfis and neuron2 had an extensive discussion about interlaced YV12 chroma; IMO it contained some of the most advanced pure video stuff (as opposed to maths, coding stuff, etc) on these forums or perhaps anywhere I know on the Internet... but it simply grew too large for me. If I had any real interest in interlaced material I would read it (hint ;)).

[castellandw]

scharfis and neuron2 had an extensive discussion about interlaced YV12 chroma; IMO it contained some of the most advanced pure video stuff (as opposed to maths, coding stuff, etc) on these forums or perhaps anywhere I know on the Internet... but it simply grew too large for me. If I had any real interest in interlaced material I would read it (hint ;)).

Well, it seems that scharfi's conclusion is clear of that extensive discussion as scharfis seemed to point out in this thread which iss that it's better to use YUY2 for interlaced material than use YV12. By the way, now, I dealt with jerky motion and frame jitter, I finally feel free to play with your Motion dll. Right now, I'm using scharfi's new version of mvbob() which uses the latest version of MVTools modified by Fizick.

[mg262]

scharfis seemed to point out in this thread which iss that it's better to use YUY2 for interlaced material than use YV12.As said above:
No! No! No!

You can't just grab the conclusion like this. You have to understand the underlying reason if you want to do things properly.

It's never as simple as a matter of better or worse -- that's why asking what is best is forbidden. What is appropriate depends on what you are trying to do -- and the only way to find what is appropriate is to understand the underlying arguments. If you had simply decided that motion-converted FPS change was 'better' than ConvertFPS, you would still be getting out junk because you didn't understand the field order issue.

[castellandw]

As said above:
No! No! No!

You can't just grab the conclusion like this. You have to understand the underlying reason if you want to do things properly.

It's never as simple as a matter of better or worse -- that's why asking what is best is forbidden. What is appropriate depends on what you are trying to do -- and the only way to find what is appropriate is to understand the underlying arguments. If you had simply decided that motion-converted FPS change was 'better' than ConvertFPS, you would still be getting out junk because you didn't understand the field order issue.

Oh,no, I'm not grabbing scharfi's statement just like that until I look at that discussion and reason it out for myself. By the way, do you know where that discussion on YV12 interlaced chroma with neuron2 and scharfis is (Like my messages, it seems the discussion by scharfis on interlaced YV12 chroma is scattered all over the place.)?

[mg262]

No, except that I think it was on the AVISynth development Forum. Try search.

[Wilbert]

Perhaps you mean this thread? http://forum.doom9.org/showthread.php?t=97987

[castellandw]

You know, after looking at that extensive discussion, if upsampling and downsampling on interlaced content has to depend on finding static areas in interlaced content, then I might as well use a smart bob deinterlacer like TDeint or LeakKernelBob to make the content progressive before any possible colorspace conversion.

You know, one thing is certain after looking at my video, there is some apparent combing artifacts in various areas of my video. I've noticed the same sort of combing artifacts in my PAL source when played on a software DVD player, but I course, I can't play a PAL source on an NTSC aka Region 1 TV DVD player to be certain if they're apparent. I can post this in a new thread since this one is too long.

[seunosewa]

Two words: frame order.