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

[castellandw]

I've been using various motion compensation plugins, bob deinterlacer plugins for converting PAL MPEG-2 to NTSC MPEG-2. I used Tmpgenc with highest quality motion search precision to encode the MPEG-2. I've had various problems with jerky motion (dropping frames during playback) for the NTSC MPEG-2 output. The original PAL MPEG-2 source never showed any signs of jerky motion during playback whatsoever. I finally deduced from using a couple of deinterlacers without frame rate conversion that frame rate conversion functions (ConvertFPS() or ChangeFPS()) seem to be responsible for the jerky motion in the final MPEG-2 NTSC output. So am I wondering if anyone used any tweaks with parameters in ConvertFPS() or ChangeFPS() to change the frame rate to eliminate jerky motion for frame rate conversion?

[Boulder]

If your source is progressive, encode the video in NTSC resolution but leave the framerate at 25fps. Then use DGPulldown to do a 25->29.97fps pulldown.

[castellandw]

Oh yeah, film stuff is a lot easier when it involves 3:2 pulldown, but this is a whole different situation because it's the sort of interlaced video that involves being dependent on interlaced lines (that is, it's originally shot on interlaced video cameras at 50 or 60 half-fields per second (25i or 30i) and can interpolated by bob deinterlacing to full frame at 50 or 60 progressive frames per second)

[mg262]

This is going to be quite a long post, and I'm going to suggest you load a few programs if you don't have them already. I've gathered them here for convenience with example download locations:

VirtualDubMod
http://www.free-codecs.com/download/VirtualDubMod.htm

ffdshow
http://www.afterdawn.com/software/video_software/codecs_and_filters/ffdshow.cfm

HuffYUV
http://neuron2.net/www.math.berkeley.edu/benrg/huffyuv.html

Right... let's go.
1. I believe that like most other filters, ConvertFPS/ChangeFPS don't check for interlaced input (though I might be wrong here). So if you want to use them, you should apply a bobber (which doubles the frame rate), convert to twice the target frame rate, and then reinterlace [SeparateFields.SelectEvery(4,0,3)].

2. Having said that, I don't think that ConvertFPS is responsible for the jerkiness (though ChangeFPS would cause it). There is an easy way to check. Rather than encoding the output from your AVISynth script directly, we can watch it in a media player (.avs files can be used anywhere you would use .avi files). Just open up the .avs file in any media player. If it plays back at the correct speed, brilliant, we can check whether its jerky or not. Two things could go wrong here:

a) It won't play at all.
Installing ffdshow should fix this.

b) It plays back too slowly.
This will happen if you're using heavy filtering, so your computer can't generate the frames fast enough. There is a way around this. Install VirtualDubMod and HuffYUV. Open up the .avs file in VirtualDubMod. Go to File, and select Save; then look down to the Video controls near the bottom of the dialog. Click on Video Mode and select Fast Recompress; click on the Change button at the bottom right and select HuffYUV. Save the file. If you don't have many gigabytes of free space, watch the frame count, and stop it after you have 2000 frames or so.* Now open up the file on a media player; it should playback in real-time.

*2000 is not exact... you don't have to sit in front of your PC watching it count up!. This step is just necessary because the generated file gets very large; we could equally well have added a trim command to the end of your script, or used VirtualDubMod to select a section to save (feel free to try either). The reason the file gets so large is because HuffYUV is a lossless codec -- the decompressed output is the same as the input, bit for bit.


3. Until the results from that come back, I can only speculate, but I think the following may be the cause of your jerkiness. Most NTSC material is stored at 23.976 frames per second (and I would guess that this is what you were encoding at) but is played back at 29.97 frames per second. This is done by (essentially) repeating every fourth field. This causes a definite jerkiness which people who grow up in NTSC countries seem to be immune to but PAL users can find grating. The name for this repetition is pulldown or telecine, and there are guides explaining it properly on the main site -- it's particularly worth clicking on The Basics on the left and reading the Video Basics guide.


4. ChangeFPS duplicate frames, just like pulldown, so it can cause jerkiness. But ConvertFPS uses blending, and the blend weights are calculated so that (insofar as this makes sense) each original frame persists for the same length of time. So the kind of artefacts you expect from ConvertFPS are blurring, ghosting, excessive softness... not jerkiness. (Though it's possible that misusing it on interlaced material would cause jerkiness.)


Hope that helps!

Edit: just caught your last post...

[castellandw]

Does it matter whether it's VirtualDub or VirtualDubMod? Also, there's various option for HuffYUV, and so I just chose Predict Median (best) for best YUV compression method, and Convert to YUY2 for RGB compression method which is said to be lossy, is that alright?

Here's the avisynth script I have for PAL-To-NTSC Conversion:

LeakKernelBob(order=1, threshold=4)
ConverttoYUY2()
Lanczos4Resize(720, 480)
ConvertFPS(59.94)
SeparateFields()
SelectEvery(4,0,3)
Weave()


Does it matter if I resize the frame before or after ConvertFPS(59.94)?
I also tried to tweak ConvertFPS() to ConvertFPS(numerator=60000, denominator=1001) and ConvertFPS(numerator=60000, denominator=1001, zone=480, vbi=45).

[Boulder]

Use ffdshow's HuffYUV and use YV12 colorspace as that's the native colorspace of MPEG2. Just make sure you've got fast recompress enabled as mg262 told you. Use 'plane' as the predictor, predict median is quite slow when decompressing.

[mg262]

Does it matter whether it's VirtualDub or VirtualDubMod?Not as long as you can find the relevant options to set.

[castellandw]

Use ffdshow's HuffYUV and use YV12 colorspace as that's the native colorspace of MPEG2. Just make sure you've got fast recompress enabled as mg262 told you. Use 'plane' as the predictor, predict median is quite slow when decompressing.

But ConvertFPS() requires the input to be in the YUY2 colorspace, so shouldn't I use YUY2 instead of YV12 in this case because I'm just looking at a HuffyYUV compressed avi and not MPEG-2 right now?

By the way, there's two FourCC codes for options since I installed the non-ffshow HuffyYUV codec: HFYU and FFVH? Which FourCC code should I choose?

[mg262]

It shouldn't matter too much in this case... colour space conversions introduce a little noise, but they won't affect the phenomena you're looking for (jerkiness). If the output colour space of the script is YUY2, then using YUY2 compression is fine.

[I had a YV12 version of ConvertFPS somewhere, but it's not relevant for now.]

[Boulder]

But ConvertFPS() requires the input to be in the YUY2 colorspace, so shouldn't I use YUY2 instead of YV12 in this case because I'm just looking at a HuffyYUV compressed avi and not MPEG-2 right now?
I always forget that ConvertFPS is YUY2 only :o

Nevertheless, use 'predict left' for faster decompression. This is just to make sure the processing power required to decompress doesn't cause extra jerkiness.

[mg262]

On your edit:
Resizing... shouldn't matter whether you do it before or after, so long as you are applying it to progressive content (which you are in your script). There might be some slight advantage to one rather than the other, but I can't think of it at the moment.

On the other hand: when you're trying to diagnose the cause of a problem, you want to start with the problematic script and reduce it as much as possible (by stripping things out) to get the shortest possible script that causes the problem. So in this case, from a methodological point of view, I would comment out the resizing step.

Last thing: when you're playing back interlaced content on your computer, you may see some combing, because computers aren't designed to play interlaced content. But this is true of your source material as well... so just play back the source material on your computer directly by using this kind of AVISynth script inside a media player:

MPEG2Source(" ... ")

and tell us whether it looks okay to you.

[In this case I want you to use an AVISynth script rather than feeding the MPEG2 file directly to a player because I don't know whether the players try some kind of post processing to make the interlaced content look better on a computer.]

Edit:
On your other edit... I always use plain HuffYUV, (HFYU) and I've never had any speed problems or other issues... but it may be that the version inside ffdshow is more efficient. Can I ask what system you have?

[castellandw]

On your edit:
Resizing... shouldn't matter whether you do it before or after, so long as you are applying it to progressive content (which you are in your script). There might be some slight advantage to one rather than the other, but I can't think of it at the moment.

On the other hand: when you're trying to diagnose the cause of a problem, you want to start with the problematic script and reduce it as much as possible (by stripping things out) to get the shortest possible script that causes the problem. So in this case, from a methodological point of view, I would comment out the resizing step.


Oh, definitely, that's what I always do when I try to do debug code many times. Narrow down the script which is how I cornered ConvertFPS() to be the problem. I found out that just by eliminating ConvertFPS. (By the way, when I saved to HuffyYUV format, I had to resize to 320 by 240 on Avisynth, to get the best smooth motion playback because to leave it at 720 by 480 or 576 will not be able to give smooth motion playback at all in HuffyYUV format which I think is due to 50-60 fps being played.)


Last thing: when you're playing back interlaced content on your computer, you may see some combing, because computers aren't designed to play interlaced content. But this is true of your source material as well... so just play back the source material on your computer directly by using this kind of AVISynth script inside a media player:

MPEG2Source(" ... ")

and tell us whether it looks okay to you.

[In this case I want you to use an AVISynth script rather than feeding the MPEG2 file directly to a player because I don't know whether the players try some kind of post processing to make the interlaced content look better on a computer.]


The only way I can actually get interlaced MPEG-2 to playback in proper, deinterlaced 50-60 progressive frames per second is by converting the MPEG-2 file as a VOB file in it's proper DVD/VIDEO_TS folder format and put it at the root of the drive (e.g. C:\VIDEO_TS). And then load a normal DVD player software like Intervideo WinDVD to automatically load the MPEG-2 video in that VIDEO_TS folder. To load the MPEG-2 file in Windows Media Player or use MPEG2Source() in Avisynth directly will just ignore the interlaced lines and thus have the video play at 25 frames per second instead of the normal 50 frames per second.


Edit:
On your other edit... I always use plain HuffYUV, (HFYV) and I've never had any speed problems or other issues... but it may be that the version inside ffdshow is more efficient. Can I ask what system you have?


Sure, it's a Toshiba Laptop with WinXP Pro with an Intel P4 3.33 GHz Hyper-Threading CPU. Oh yeah, laptop hard drives using 4200 rpm or 5400 rpm are not that fast for high-quality MPEG-2 Video, and so I use USB 2.0 7200 rpm drives to view the MPEG-2 video.

[castellandw]

You know instead of a PAL source where 50 progressive frames per second is involved, I'll try to find an NTSC MPEG-2 source where 59.94 frames per second is involved. Perhaps playing at 60 progressive frames per second instead of 50 does start to create jerky motion.

[Wilbert]

To load the MPEG-2 file in Windows Media Player or use MPEG2Source() in Avisynth directly will just ignore the interlaced lines and thus have the video play at 25 frames per second instead of the normal 50 frames per second.
Some misconceptions. AviSynth does not ignore the interlaced lines, it just plays the stream unprocessed. This is done at 25 frames per second (pal), because the video consists of 25 frames per second. 25 frames per second is equivalent with 50 *fields* per second. Software players deinterlace your video, and play it back at 25 frames per second (not 50 frames).

Only on your tv you will see 50 fields (aka half frames) per second.

[scharfis_brain]

@castell.... : provide a short clip, please, cause there maybe are other weirdnesses.

[castellandw]

Some misconceptions. AviSynth does not ignore the interlaced lines, it just plays the stream unprocessed. This is done at 25 frames per second (pal), because the video consists of 25 frames per second. 25 frames per second is equivalent with 50 *fields* per second. Software players deinterlace your video, and play it back at 25 frames per second (not 50 frames).

Only on your tv you will see 50 fields (aka half frames) per second.

I agree with you, Wilbert. (God, it's hard to decide using the term progressive frames or 50 fields(aka half-frames) when I discuss it to people). However, you can also see the 50-60 fields (aka half frames) per second effect beyond your TV and onto your computer if your computer supports MPEG-2/DVD Hardware Decoding Acceleration and you are able to enable that option on your software DVD player. In the case of AVISynth, I'm not talking about AVISynth that ignores the interlaced lines, but just using only MPEG2source() (I use DGDecode by the way) to open the video will ignore the fields when it plays back because there's no bob deinterlacing involved whatsoever. So when I open that Avisynth script on Windows media player for example, there's no handling of any sort of smart bob deinterlacing on Windows Media Player, and so you need to put a smart bob like LeakKernelBob() to try to get that 50-60 fields effect just like on your TV. So basically, Avisynth doesn't ignore interlaced lines, but to use MPEG2Source() without any sort of smart bob deinterlacer will not give you the same TV 50-60 fields(half-frames) per second effect that you're supposed to get on interlaced sources when you enable MPEG-2/DVD hardware acceleration on your computer.

[scharfis_brain]

you just explained again, what wilbert already wrote.

to view 50 or 60 fps stuff properly on a PC you need to set your monitors refresh rate to a multiple of the refreh rate!

50 fps : 50, 100 or 150 Hz
60 fps : 60, 120 or 180 Hz

every other refresh rate will cause motion judder.

that's why I hate flat panel displays. there is no support for 50 or 100 Hertz (I am living in PAL land)

[castellandw]

@castell.... : provide a short clip, please, cause there maybe are other weirdnesses.

OK, I might do that, but being clips from a TV program, I don't want to break any copyright posting it online, although if I do make it available, what format do you want of the clip? The NTSC output MPEG-2 (Of course, I might have to provide you with a VIDEO_TS version because that's the only way your software DVD player (with Hardware DVD acceleration enabled of course) could play the MPEG-2 file with the 50-60 fields per second effect. Or I could supply two clips converted to HuffyYUV avi format both resized with Lanczos4 to 320x240 and converted to YUY2 and 50-60 progressive frames per second with LeakKernelBob(order=1, threshold=4) (One clip without convertfps() making it 50 progressive frames per second( for PAL) and the other clip uses Convertfps() to become 59.94 progressive frames per second(for NTSC).)

But first, I want to test using an NTSC MPEG-2 Source with LeakKernelBob() and output it in YUY2 to 320x240 HuffyYUV avi format. (I already had my original PAL MPEG-2 Source tested today with and without ConvertFPS(59.94) using a Lanczos4resize(320,240), ConverttoYUY2() for the HuffyYUV AVI format, and LeakKernelBob() to get the 50 progressive frames per second. So the results still seem to point to ConvertFPS() as the cause of jerky motion in places.)

[Boulder]

A small clip should fall into Fair Use category. People do it all the time here to provide as much information as possible. You should upload a clip of the original, non-processed source.

[castellandw]

you just explained again, what wilbert already wrote.

to view 50 or 60 fps stuff properly on a PC you need to set your monitors refresh rate to a multiple of the refreh rate!

50 fps : 50, 100 or 150 Hz
60 fps : 60, 120 or 180 Hz

every other refresh rate will cause motion judder.

that's why I hate flat panel displays. there is no support for 50 or 100 Hertz (I am living in PAL land)

No, I'm not talking about setting the monitor's refresh rate. Of course, you need to set the refresh rate to a minimum of 50-60 Hz to play 20-30i fps on your PC, but I was saying to Wilbert that I know that your video chipset hardware on your PC must be able to support DVD hardware decoding acceleration, and your software DVD player must support and have enabled DVD hardware decoding acceleration to get the full proper 50-60 fps effect.

[castellandw]

A small clip should fall into Fair Use category. People do it all the time here to provide as much information as possible. You should upload a clip of the original, non-processed source.

OK, but to best offer the original PAL clip when I upload it, do you think it's best to put the clip in VOB/VIDEO_TS Folder format, to be able to view the 50 fields(half-frames) per second effect on your software DVD player?

[scharfis_brain]

No, I'm not talking about setting the monitor's refresh rate. Of course, you need to set the refresh rate to a minimum of 50-60 Hz to play 20-30i fps on your PC, but I was saying to Wilbert that I know that your video chipset hardware on your PC must be able to support DVD hardware decoding acceleration, and your software DVD player must support and have enabled DVD hardware decoding acceleration to get the full proper 50-60 fps effect.

I am able to playback any MPEG2 stuff in full fieldrate using software only decoders like the internal decoder of Media PLayer Classic (set it to BOB) or the Dscaler decoder Filter, which is imo a very nice one.

I always watch video this way.
also one can also use 100 or 120 Hertz, they are even better than 50 or 60 hertz rate cause of lesser flicker and better judder stability when the CPU load is too high (or occupied by some background processes)

OK, but to best offer the original PAL clip when I upload it, do you think it's best to put the clip in VOB/VIDEO_TS Folder format, to be able to view the 50 fields(half-frames) per second effect on your software DVD player?
Doesn't matter to me, cause I can view any MPEG2 content with above mentioned decoders in its full motion.
Also I'll need to run it through DGindex anyway, so just provide it as you want to. But do NOT apply any reencoding.

[castellandw]

I am able to playback any MPEG2 stuff in full fieldrate using software only decoders like the internal decoder of Media PLayer Classic (set it to BOB) or the Dscaler decoder Filter, which is imo a very nice one.

I always watch video this way.
also one can also use 100 or 120 Hertz, they are even better than 50 or 60 hertz rate cause of lesser flicker and better judder stability when the CPU load is too high (or occupied by some background processes)


Doesn't matter to me, cause I can view any MPEG2 content with above mentioned decoders in its full motion.
Also I'll need to run it through DGindex anyway, so just provide it as you want to. But do NOT apply any reencoding.

Do you need any audio in the clip or just the video stream?

[castellandw]

I am able to playback any MPEG2 stuff in full fieldrate using software only decoders like the internal decoder of Media PLayer Classic (set it to BOB) or the Dscaler decoder Filter, which is imo a very nice one.

I always watch video this way.
also one can also use 100 or 120 Hertz, they are even better than 50 or 60 hertz rate cause of lesser flicker and better judder stability when the CPU load is too high (or occupied by some background processes)


Doesn't matter to me, cause I can view any MPEG2 content with above mentioned decoders in its full motion.
Also I'll need to run it through DGindex anyway, so just provide it as you want to. But do NOT apply any reencoding.

Hmm, Windows Media Player Classic. I usually thought that was the older Microsoft Windows Media Player, but I think it's a reasonable player. I just tried out Dscaler, which seems just as OK, although I had to avoid using the MoComp deinterlacers because I did experience some jitter. I think though that if it wasn't for my high-speed CPU, Dscaler or Windows Media Classic isn't as useful. Since my graphics hardware supports DVD acceleration, I just use InterVideo WinDVD because it reduces CPU load with DVD hardware acceleration. However, if i want to test out regular MPEG-2 files that aren't converted to VOB/DVD format, I'll use Dscaler or Media Player Classic.

[LocalH]

Media Player Classic is different from MS's WMP6.4, although MPC is a visual clone of WMP6.4.

[scharfis_brain]

I didn't meant the dscaler-application, I meant the dscaler-mpeg-decoder-filter (dscaler5), which can be used within MPC.

I would prefer a MPEG-Program stream (MPG, VOB) over a demuxed m2v, cause m2vs sometimes are a pain to playback smoothly.

but if making a m2v is easier to you, just upload it somewhere. btw. filesize is not of much importance.

[castellandw]

I didn't meant the dscaler-application, I meant the dscaler-mpeg-decoder-filter (dscaler5), which can be used within MPC.

I would prefer a MPEG-Program stream (MPG, VOB) over a demuxed m2v, cause m2vs sometimes are a pain to playback smoothly.

but if making a m2v is easier to you, just upload it somewhere. btw. filesize is not of much importance.

I have to admit. I just used Media Player Classic at fullscreen, and it seems it's better at resizing DVD video at fullscreen without any combing artifacts at resolutions of 1024x768 and 1280x800 unlike WinDVD. What the heck does WinDVD use to resize the video at fullscreen to get combing artifacts for goodness sake and what does Media Player Classic use to decode MPEG-2 (Is it DScaler and if it is Dscaler, which version is being used because I saw a lot of them?)

I don't seem to upload the MPEG-2 clip on the doom9 forum, and so I put it on another site for download. So here it is:
https://home.comcast.net/~castellandw/PALMPEG2Clip.mpg

If anyone has had trouble downloading this clip, let me know.

[scharfis_brain]

have fun:

# load source
mpeg2source("D:\FORUM\castellandw\PALMPEG2Clip.d2v",cpu=4)

#bob-deinterlace with ELA interpolation
tdeint(mode=1,type=3,ap=20)

#blend two fields together to get smoother motion.
#use with care. for video content only.
#Film content (25p) will be destroyed
#mergeluma(trim(1,0),.5).mergechroma(trim(1,0),.5)

#change resolution and framerate
converttoyuy2()
bicubicresize(width,480)
convertfps(59.94)

#reinterlace
assumetff()
separatefields()
selectevery(4,0,3)
weave()

only uncomment the merge... line if it is too jerky for you.

[castellandw]

scharfis, I have some questions:

a)I noticed that you used bicubicresize instead of Lanczos resize. Does that mean Bicubic does a better job at resizing video than Lanczos, particularly in reducing resolution size?

b)In mpeg2source(), don't I need to set ipp=true in order for Avisynth to not ignore interlaced fields in the mpeg-2 file?

c)Is the reason you prefer TDeint because of ELA interpolation used rather than kernel-based interpolation?

d)In the case of hybrid video aka video composed of video and film portions, should I do anything different with the script?

[scharfis_brain]

a) test yourself. not a big difference here
b) do NOT use the iPP parameter, mpeg2source already chooses the correct one.
c) yes
d) yeah, one *should* do something, but this probably is a tough job, cause one needs to correctly detect film and video sections and afterwards applying the appropriate conversion method.
but if you do not make usage of the merge line, the film stuff won't be destroyed totally.

can you upload a sample, where film(25p) and video(50i) alters often?
maybe I can do something to improve the conversion quality

[castellandw]

b) do NOT use the iPP parameter, mpeg2source already chooses the correct one.

What MPEG2 plugin are you using because I'm using DGDecode.dll?


can you upload a sample, where film(25p) and video(50i) alters often?
maybe I can do something to improve the conversion quality

I'm not sure if I can get a small clip where film(25p) and video(50i) alters often because usually from TV programs I have, there's long scenes shot on video just as much as there's long scenes shot on film. So during a program, they'll take a long time to switch between film and video portions during the program. Do you want me to try to find a small clip which is:
a) Near the end of a film portion going into the beginning of a video portion
(Video scene->Film scene)
b)Near the end of a video portion going into the beginning of a film portion
(Film scene->Video scene)
or
c)Having a film or video portion in the middle
(Film scene->Video scene->Film scene or Video scene->Film scene->Video scene)

[Wilbert]

What MPEG2 plugin are you using because I'm using DGDecode.dll?
Yes, that's fine.

d)In the case of hybrid video aka video composed of video and film portions, should I do anything different with the script?
...

edit: Sorry i misunderstood you. I thought your source was ntsc (not pal), because you were talking about film and video. The terms film and video have a specific meaning (23.976 and 29.97 stuff).

I'm curious. This 25i, is this trully interlaced (ie 50 *different* fields per second), or a result of a 29.976 ntsc -> 25i conversion?

[mg262]

castellandw,

Are you now content with the results you have got? In particular, are you still of the opinion that ConvertFPS is causing jerkiness?

[scharfis_brain]

@Wilbert. he has PAL source.

All I wanted to achive is:
- deinterlacing & blending during 50i scenes
- fieldmatching & frame duplication during 25p scenes (3:2:3:2:2 Pulldown)
in an automated script to achive a much better video quality during Film scenes.

@castell...
I use dgdecode, too.

as a sample clip I'd like to get option c)

[castellandw]

Yes, that's fine.


...

edit: Sorry i misunderstood you. I thought your source was ntsc (not pal), because you were talking about film and video. The terms film and video have a specific meaning (23.976 and 29.97 stuff).

I'm curious. This 25i, is this trully interlaced (ie 50 *different* fields per second), or a result of a 29.976 ntsc -> 25i conversion?


@Wilbert,The source is totally interlaced dependent PAL video, but I put in the thread title PAL-to-NTSC for both ways. I was talking to scharfi about other scenarios where you would have to convert video that is a mix of film and video portions which is basically hybrid video (In the case of a PAL source, 25p shot film portions and 25i or 50 half-fields shot video portions.)

@mg262, I'm gonna have to try scharfi's script for myself later today before I can give any opinion yet. So as soon as I get results, I'll let you guys know.

[scharfis_brain]

The terms film and video have a specific meaning (23.976 and 29.97 stuff).
No, these terms aren't reseverved for NTSC only.
They are fully valuable for PAL, too. (FILM=25p, Video=50i)

[Wilbert]

They are fully valuable for PAL, too. (FILM=25p, Video=50i)
Any reference for this usage?

[scharfis_brain]

Me. ;)

what speaks against the usage of FILM and VIDEO for PAL, too?
There is no difference in main structure at all.
FILM = progressive, near to Film framerate (23.976 < 24 < 25)
Video = true interlaced camera video with the standards field rate.

[castellandw]

@scharfis, I forgot to ask one more thing about DGDecode (My PAL video is encoding with your script as I write this). I noticed that you set chroma and luma deblocking (cpu=4), and so do you think there's any need for deringing?

[Boulder]

Deringing usually blurs the image too much.

[Mug Funky]

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... it's possible that it could slow down the 25p and audio on the DVD player side, but to what end i don't know (projectors? certainly not TVs).

[scharfis_brain]

@wilbert. now I remember where Film & Camera (Video) Mode is used. In the PALplus descriptions.
The PALplus line marks aspect ratio (4x3 Fullscreen, 16:9 Letterboxed, 16:9 Anamorphic) and Frametype (Film or Video)

[castellandw]

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... it's possible that it could slow down the 25p and audio on the DVD player side, but to what end i don't know (projectors? certainly not TVs).

could it be to slow down to the usual film framerate of 23.976 or 24 fps, and so basically the flag might be used for footage that were given the 3:2 pulldown?

[Mug Funky]

nope, it's a PAL only setting. 3:2 pulldown to pal would be 20 frames per second :)

[edit]

AFAIK this setting is not even accessible in DVDmaestro. it's in DVDAfterEdit (mac) though. not the slightest clue what it's for (scharfi?)

[scharfis_brain]

I don't know what this flag is about. I also saw a FILM/CAMERA checkbox in IFOedit.

Maybe it is used to alter the WSS (PALplus) Line.
This line contains a flag that signalizes progressive (FILM) or interlaced (CAMERA) stuff. so that the MACP (motion adaptive colour plus) and the deinterlacing can be done properly in PALplus TV sets...

but this is just a guess. nothing more.

[castellandw]

nope, it's a PAL only setting. 3:2 pulldown to pal would be 20 frames per second :)

[edit]

AFAIK this setting is not even accessible in DVDmaestro. it's in DVDAfterEdit (mac) though. not the slightest clue what it's for (scharfi?)

Oh, wait a minute, 3:2 pulldown is for NTSC. 2:2 pulldown is for PAL.

[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...
Perhaps you can author such a dvd (just a small vob) and ask neuron2 to analyze it (ie the flags which are presumably added)?

[castellandw]

Ok, I think I got enough results.
@scharfi, I don't think chroma and luma deblocking (not even mergeluma and mergechroma as well) helps in decreasing jerky motion. As a matter of fact, chroma and luma deblocking practically causes even more blurring to the video. But you mentioned earlier in the message thread about monitor refresh rates, and so do you think because my frame rate is converted to 59.94 fps which is close to my laptop's refresh rate being only 60 Hz has something to do with the jerky motion(where some frames look like they dropped in places in the video)?

By the way, I'm still working on finding a short clip with film and video portions.

[mg262]

because my frame rate is converted to 59.94 fps which is close to my laptop's refresh rate being only 60 Hz has something to do with the jerky motionThis seems very possible... why don't you check by resampling to a few different frequencies? I would try 50, 60, and something which is not close to 60 multiplied by any small fraction -- so e.g. 73.6.

[castellandw]

OK, I just tried different frequencies on a regular tube VGA monitor hooked up to my VGA port on my laptop since laptop LCD screens seem to support for the most part only one frequency(in my laptop's case, 60 Hz). I used my VGA monitor which supports up to 100Hz. So I tried different frequencies and it seems that at 60 Hz, you get jerky motion somewhat(although not as much as on a laptop LCD screen which isn't surprising as LCD screens aren't as fast in refreshing as regular tube monitors), but at 100 Hz, you get no jerky motion whatsoever(It could be possible that at 60Hz on a VGA monitor which can go up to more than 60 Hz, it does happen to use a bit more frequency that's available even if the frequency is set to 60Hz for the refresh rate which is possibly another reason why there's less jerky reason on a VGA monitor than on an LCD screen). As for chroma and luma deblocking, the blur is not very noticeable on a VGA monitor except for when you resize the video to fullscreen. I also compared LeakKernelBob and TDeint results on a VGA monitor, and it seems that TDeint did have a few instances at 100 Hz where jerky motion was apparent, but with LeakKernelBob, I didn't notice anything.

I think there should be something on any Doom9 forum FAQs for info involving testing video with framerates of at least 50 to 60 fps with monitors that have much higher and faster refresh rates, especially beyond 60 Hz in order to get less biased results. What do you guys think?

[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.