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?