720p@59.94 to 480i@29.97

[yingx2]

Hi all,

I have limited avisynth skills and I need some help.
I want to convert a .TS HD progressive stream at 59.94 fps into a DVD-compliant stream. In order to keep the motion fluency, I think I have to interlace it so I can view it on TV with "full frame rate" (I don't know how to phrase this better...). I am sure the source itself is 100% progressive.

Here is my script:

directshowsource("HDsource.ts", fps=29.97 (59.94 also tried), convertfps=true)
lanczosresize(720,480)
SeparateFields()
odd = SelectOdd()
evn = SelectEven()
interleave(odd,evn)
weave()

Obviously I am just desparate and I don't know what I am doing. Can you provide a correct script to address this need please?

[scharfis_brain]

- use dgdecode & dgindex to load th .ts into avisynth.

SeparateFields()
odd = SelectOdd()
evn = SelectEven()
interleave(odd,evn)
weave()

is effectively an No-OP.

better use this script for true 60p:

MPEG2source("HDsource.d2v")
converttoyuy2()
bicubicresize(704,480)
assumetff()
separatefields().selectevery(4,0,3).weave()

or this for FILM (24p) contents:
MPEG2source("HDsource.d2v")
selecteven()
converttoyuy2()
bicubicresize(704,480)
tdecimate()

[yingx2]

It's absolutely working!!
Thanks a lot :cool:

One quick question:
Is it possbile to keep the same motion smoothness when converting 1080i HD source to DVDs?
I think not, but you are the expert. And if it's possible, what will the avisyth script look like? :thanks:

[scharfis_brain]

for 1080i with true interlace (60i) (remains ALL motion smoothness!)
Encode as NTSC interlaced

MPEG2source("HDsource.d2v")
crop(0,0,0,-8)
securedeint()
converttoyuy2()
bicubicresize(704,480)
assumetff()
separatefields().selectevery(4,0,3).weave()

for 30p in 1080i (no combing visible)
encode as NTSC progressive with 29.97fps

MPEG2source("HDsource.d2v")
crop(0,0,0,-8)
converttoyuy2()
bicubicresize(704,480)

for 24p (Film) in 1080i (combing visible in the 3:2 Pattern)
encode as NTSC-Film with 23.976 fps

MPEG2source("HDsource.d2v")
crop(0,0,0,-8)
tfm()
tdecimate()
converttoyuy2()
bicubicresize(704,480)

[yingx2]

MPEG2source("HDsource.d2v")
crop(0,0,0,-8)
securedeint()
converttoyuy2()
bicubicresize(704,480)
assumetff()
separatefields().selectevery(4,0,3).weave()

You are the man!
Now I have to bookmark this page :)
My idea was to crop the vertical res to 960 so that one would not screw up the picture by resizing it to 704/720x480...
Anyway you don't have to explain to me how this works. Still curious though... Thanks a billion!

[bairradino]

I used this script for converting screen captured video to make a PAL presentation.
I captured at FPS=50 to obtain a final interlaced PAL at FPS=25.
I got it but the video speed is the dobble.
What am I doing wrong?

[actionman133]

Scharfis, wouldn't it be faster and more accurate like this?

MPEG2source("HDsource.d2v")
crop(0,0,0,-8)
securedeint()
bicubicresize(704,480)
converttoyuy2()
assumetff()
separatefields().selectevery(4,0,3).weave()

By leaving the ConvertToYUY2 () until after the resize, it would surely speed up... Is there a reason you included it before the resize?

[scharfis_brain]

Cause only this way allows you to carry crisp chroma information to the encoder. Converting to YUY2 after resize will blur chroma in vertical after reinterlacerlacing and encoding (which introduces YV12 again) you'll get even more blurred chroma!

for much quicker processing while preserving full quality you may try this script:

MPEG2source("HDsource.d2v")
(last.height == 1088) ? last.crop(0,0,0,-8) : last
bicubicresize(704, height)
securedeint(type=0)
converttoyuy2()
(last.framerate == 50) ? last.bicubicresize(last.width, 576) : last.bicubicresize(last.width, 480)
assumetff()
separatefields().selectevery(4,0,3).weave()

- it scales down horizontally before deinterlacing
- it uses cubic instead of eedi2 interpolation during deinterlacing
- vertical downsampling only is done in YUY2. the script decides itself, whether to use 576 or 480 lines.

[bairradino]

And what am I doing wrong?
No ideas?

[scharfis_brain]

No.

You didn't gave us sufficient information.

[bairradino]

OK. Let me try to explain it better...
I made a computer screen capture of a presentation in order to make a PAL DVD later.
Having in mind the script you suggested I made the capture at FPS=50.
When I apply the script above mentioned I get a movie of the same time duration, with (of course) an half of frames... but at a speed that is 2x the original one, wich is not acceptable.
As it seems that for "yingx2" it worked well that's the reason I suppose that I'm doing something wrong.

[scharfis_brain]

still not enough information.

1) show the used script.
2) provide the unprocessed source.

[foxyshadis]

FPS s 25, not 50, correct? After reinterlacing you should have half the framerate.

[bairradino]

I knew that I was wrong somewere...
The problem was on recording from the screen.
Thanks to all that tried to help.

[pandy]

If You create presentation from progressive source ie computer always capture with 720x576x25 for PAL (720x480x29.97 for NTSC). There is no special need to capture this kind of sources as interlace.

[scharfis_brain]

There is no special need to capture this kind of sources as interlace.
Of course, there is!
i.e. if you want to preserve motion smoothness. This is only achievable using interlace 50i or 59.94i processing.

[foxyshadis]

Well, the best option is just to capture progressively at your monitor's refresh rate, whether it's 50,60,90, or whatever, decimate down to your desired final framerate, then use zmbv, ffv1, or msu screen (or if you must, wmv-screen) to encode it. Those codecs can handle 90 fps just as well as 10, they're made for screen captures.

[scharfis_brain]

704 offers true 4x3 or 16:9 (1.33:1 and 1.778:1) aspect ratio.
720 is a little bit wider (1.37:1 and 1.82:1), and it gets displayed distorted on most TVs.

704 is a valid resolution for DVD. I only create DVDs with 704 pixels width.

if you want to create 720 out of a 1280x720 HDTV source, you have to do something like this:

bicubicresize(704,576)
addborders(8,0,8,0)

because for 720 only adding borders preserves the true aspect ratio.

[pandy]

Of course, there is!
i.e. if you want to preserve motion smoothness. This is only achievable using interlace 50i or 59.94i processing.

A can't agree - most of the content (if not all) is progressive.
If we capture computer screen (ie not using a camera but using virtual capture driver) we have always progressive content. Smoothness of move is less important than visibility of details - 25 fps is more than enough to have smooth movement (presentation is not a soccer game).

[pandy]

704 offers true 4x3 or 16:9 (1.33:1 and 1.778:1) aspect ratio.
720 is a little bit wider (1.37:1 and 1.82:1), and it gets displayed distorted on most TVs.


In most knwon by me video hardware (digital video encoders) we have two setups:
- we use "analog" line - this line have approx 708 pixels but timing of video is very close to the norm ITU-R BT470 or
- we use use "digital" line which have 720 pixels - ie is compliant with ITU-R BT.601 and 656 standards.

Both formats are acceptable for modern TV receivers without any problems.
704 pixel is popular especially in USA, in Europe 720 pixels are prefered. Some little deviation from optimal aspect is not so important - many TV receivers distort much more aspect than
2,22%


704 is a valid resolution for DVD. I only create DVDs with 704 pixels width.

if you want to create 720 out of a 1280x720 HDTV source, you have to do something like this:

bicubicresize(704,576)
addborders(8,0,8,0)

because for 720 only adding borders preserves the true aspect ratio.

By using 704 than 720 ie create "analog" line You loose some quality (quality of typical video scalers inside DVD is much more worse than high quality rescaling done in software)

[bairradino]

For PAL system the size of a picture must be 702x576 (not 704), according to ITU-R BT601-5 Part A.

[scharfis_brain]

bairradino: I am aware of that. but I accept this error (702 vs. 704).
But I do not accept the error of 702 vs. 720.

pandy: you seem confused.

NTSC active image area is 711x486
PAL active image area is 702x576
both represent a proper 4x3 window

for the digital domain ntsc is cropped down to 480 lines.
if you want to get a 4x3 image with 480 lines you need this resolution: 702x480.

do you see the relationship now?

the black bars at the left an right sides are totallly irrelevant and do have nothing to do with analog blanking. It is just thecombination of correct aspect ratio and easy resizing without trouble.

example:
1280x720 to anamorphic NTSC 720x480:

1) easy and correct method:

xxxsource("720p.xxx")
bicubicresize(702,480)
addborders(9,0,9,0)

2) correct but troublesome method

xxxsource("720p.xxx")
bicubicresize(711,486)
crop(0,0,0,-6)
addborders(4,0,5,0)

3) incorrect method:
xxxsource("720p.xxx")
bicubicresize(720,480)

[dwoods99]

We have a good explanation of 1280x720 getting down to 704/480 but that ratio is still not a 4x3 ratio for regular TV, so what happens to the original 16:9 ratio of 1280x720 we started with ?

As well, am I correct that the proper resolution to maintain a 16:9 ratio for Widescreen TVs would be 704x400, so we would use
addborders(8,40,8,40)
?

[scharfis_brain]

1280x720 to letterboxed 16:9 for regular TVs:
bicubicresize(702, 360)
addborders(1,60,1,60)

1280x720 to anamorphic 16:9 for widescreen TVs:
bicubicresize(702, 480)
addborders(1,0,1,0)




you should make yourself familiar with pixel aspect ratio and display aspect ratio

a way to start may be ACRT:
http://www.haku.co.uk/ARCT.html

[Alain2]

I don't fully understand your example scharfis_brain or the way ratios are calculated..

1280x720 to letterboxed 16:9 for regular TVs:
pixel resolution of 1280x720 /2 = 640x360 + addborders = 640x480, which is then a pixel and display ratio of 4/3. So for ntsc dvd this is to be resized to 720x480 (ratio 1.5)
Where is the flow in my statement above ? Is it the letterbox thing ?

[scharfis_brain]

702x480 (NOT 720x480!) pixels on DVD equals to 640x480 pixels on your computer for 4x3 fromat (letterboxed 16x9)

702x480 pixel also equals 853x480 pixels on your computer for 16x9 format (anamorphic 16x9)

it is a matter of a flag within the MPEG2 file that tells the decoder in which proporitions the pixels are.

A pixel is not a square on DVD.

for 4x3 (or letterboxed) DVDs the pixels are wider than tall and
for 16x9 (or anamorphic) DVDs the pixels are taller than wide.
but the pixels never are square.

As I said: make yourself familiar with pixel and display aspect ratios.

http://www.mir.com/DMG/aspect.html
http://lipas.uwasa.fi/~f76998/video/conversion/

I wish you a happy reading, calculating etc without getting headache. (But I guess this is unavoidable ;) )

[pandy]

pandy: you seem confused.


No, lets do some quick math
ITU-R BT.470 says:
Nominal line period is 64 uS, Line-blanking interval is 12uS (-0.3uS)
Nominal sampling clock is 13.5MHz (ITU-R BT.601 & 656).
this give us a pixel time 1/13.5MHz ie 74.07nS
Then we have 64-12-0.3=52.3uS it is our active video, then we divide by 74.07nS we receive number of active video pixels ie over 706 pixel.
Ok, then in modern digital video encoders two modes are supported:
"analog" which is timing compatible with ITU-R BT.470,
"digital" which is compatible with ITU-R BT.656.
In "analog" mode digital video encoder produce video line which consist 706 - 710 active video pixels , in "digital" ie ITU-R BT.656 there is always 720 active video pixels.
Ok and at this moment we have most important part:
Before digital video encoder is scaler - scaler can rescale input video to the output - some scalers can be setuped with ease, some not.
If we have 704 pixel video then some scalers don't rescale data, digital encoder simply add black pixels and we have "analog" line with 2 - 6 more black pixels but some scalers rescale 704 to the 720 pixels, they do this sometimes in very simple bilinear interpolator, sometimes they have 5 tap (or more eg 7 or 9 or even more) filter.
For most of the video hardware is safe to have 720 pixels input data ie video scaler don't rescale.
Aspect as i say earlier difference between 702(704,706 etc) and 720 pixels is less than 3% - i can say only one - You can't see this.

[Wilbert]

No, lets do some quick math
ITU-R BT.470 says:
Nominal line period is 64 uS, Line-blanking interval is 12uS (-0.3uS)
Nominal sampling clock is 13.5MHz (ITU-R BT.601 & 656).
this give us a pixel time 1/13.5MHz ie 74.07nS
Then we have 64-12-0.3=52.3uS it is our active video, then we divide by 74.07nS we receive number of active video pixels ie over 706 pixel.
The line blanking interval (for PAL) is 12+/-0.3 uS. So the active video is (64-12) 52+/-0.3 uS, which equates 702+/-4 dvd pixels.

The line blanking interval (for NTSC) is 10.9+/-0.2 uS. So the active video is (63.555-10.9) 52.655+/-0.2 uS, which equates 711+/-3 dvd pixels.

So, Scharfis is right ...

By using 704 than 720 ie create "analog" line You loose some quality (quality of typical video scalers inside DVD is much more worse than high quality rescaling done in software)
What do you mean by this? In both cases they have to be resampled or scaled.

[pandy]

The line blanking interval (for PAL) is 12+/-0.3 uS. So the active video is (64-12) 52+/-0.3 uS, which equates 702+/-4 dvd pixels.


No - The line blanking interval (for PAL) is 12+0/-0.3 uS ie 12 - 11.7uS


So, Scharfis is right ...


Partially...
Modern video hardware use a BT.656 not 470 timing relations


What do you mean by this? In both cases they have to be resampled or scaled.

I mean that very strict 702 or 703 or 704 pixels rescaling is not necessary if video hardware do in most cases for Europe 720 pixels ie "digital" BT656 timing, also most of US video hardware prefer 704 than 720 pixels

[Wilbert]

No - The line blanking interval (for PAL) is 12+0/-0.3 uS ie 12 - 11.7uS
Ok, i see you are right. But that means an active video of 52+0/-0.3 uS, which equates 702+0/-4 dvd pixels (thus 698-702 dvd pixels).

Partially...
Modern video hardware use a BT.656 not 470 timing relations
Yes, in many cases this is true.

edit: pandy is correct below.

[pandy]

Ok, i see you are right. But that means an active video of 52+0/-0.3 uS, which equates 702+0/-4 dvd pixels (thus 698-702 dvd pixels).

No, 52 -0/+0.3uS - 702 +4 pix (average) - but digital encoders which i know (IBM, STM, BroadCom) create "analog" line between 702 - 710 pix (this was measured by me on TEK VM700)
Leaving deicsion to the video hardware what to do with video is unsafe. AFAIK all digital encoder accept on their inputs ITU-R BT.601, 656 digital YCbCr signal, AFAIK all TV receivers display 720 pix without any problem.

[bairradino]

Very interesting...
However I think that comercial TV's expand the image and we loose a variable (depending of the TV we're using) amount of horizontal pixels and vertical lines.
Is this true?
When I import to PC the video created with my DV camcorder I get an image of 720x576. Should it be (702-706)x576? Or must I shrink the 720x576 to 702x576 and add 9 pixels black for each border side?

[Alain2]

702x480 (NOT 720x480!) pixels on DVD equals to 640x480 pixels on your computer for 4x3 fromat (letterboxed 16x9)

702x480 pixel also equals 853x480 pixels on your computer for 16x9 format (anamorphic 16x9)

it is a matter of a flag within the MPEG2 file that tells the decoder in which proporitions the pixels are.

A pixel is not a square on DVD.

for 4x3 (or letterboxed) DVDs the pixels are wider than tall and
for 16x9 (or anamorphic) DVDs the pixels are taller than wide.
but the pixels never are square.

As I said: make yourself familiar with pixel and display aspect ratios.

http://www.mir.com/DMG/aspect.html
http://lipas.uwasa.fi/~f76998/video/conversion/

I wish you a happy reading, calculating etc without getting headache. (But I guess this is unavoidable ;) )
No headache but a long and careful read to understand all this, that is new to me ^^

I think I understand the analog signals now (thanks for the 2 links, they were very interesting!)

But I am still a bit puzzled by your initial statement "702x480 (NOT 720x480!) pixels on DVD equals to 640x480 pixels on your computer for 4x3 fromat"... For instance when I read a commmercial PAL DVD with MPC, and look at ffdshow info, it says for SAR=16/15 DAR=4/3 for 4/3 parts (menu etc) and SAR=64/45 DAR=16/9 for the film (anamorphique 16/9) ; thus the DAR/SAR ratio is equal to 720/576 in both cases. So if I understand correctly, mpc is thus making 720x576 -> 4/3 or 16/9 directly.. I don't see a 702 (or 704) resolution coming in there through the SAR... ?

[pandy]

Very interesting...
However I think that comercial TV's expand the image and we loose a variable (depending of the TV we're using) amount of horizontal pixels and vertical lines.
Is this true?
When I import to PC the video created with my DV camcorder I get an image of 720x576. Should it be (702-706)x576? Or must I shrink the 720x576 to 702x576 and add 9 pixels black for each border side?

All, known to me hardware sample analog video with ITU-R BT.656 timing relations - ie all sampled analog video have 720 pixels in line.

But most important is that all video hardware with fixed resolution (ie Plasma and LCD but also future OLED, SED etc) have one optimal resolution and other resolutions are simply crop/rescale (this especially important to the PAL - very small amount of TV receivers have PAL aspect ratio display - most of TV receivers are for US nad Japan market so they have 852x480, 1280x720, 1366x768 etc resolutions). Many of this receivers do crop ( to the broadcast so caled "safe area") and rescale by factor 1.5...2.
For me... i try to avoid touching source size (when i sampling analog source by 720 then on whole chain of processing i use 720) - especially when resize factor is very weird ie 702/720 etc...

[Wilbert]

All, known to me hardware sample analog video with ITU-R BT.656 timing relations - ie all sampled analog video have 720 pixels in line.
Most of them don't:

http://www.doom9.org/index.html?/capture/sizes_advanced.html (5.4 Active capture window)

[pandy]

Most of them don't:

http://www.doom9.org/index.html?/capture/sizes_advanced.html (5.4 Active capture window)

Most of them ie consumer devices (not PC with software changeable sampling speed). In digital world BT.656 (720) and downsampling to few horizontal resolutions are prefered - 352, 480, 544, 576, 704 and 720 pixels. For massproduct manufacture simplicity and uniformity are prefered.

[2Bdecided]

So pandy, you're saying that if I burn a 704x576 video onto a DVD and play it back, then significant numbers of DVD players will resample the pixel data 704>720 and blur the image, rather than just pad it with zeros and keep the original pixels?

I'll have to check!

FWIW non-720 related H pixel counts are quite common on terrestrial broadcasts in the UK. 704 is used for ITV1 and CH4 (millions of viewers each!): http://www.mymuxdata.tk/

Cheers,
David.

[scharfis_brain]

@pandy

a DVD with 704 pixels width will produce EXACTLY the same image as a DVD with 704 pixels centered within 720 pixels.
DVD-Players and DVB-Receivers won't scale anything. They only alter the timing window to be able to display different horizontal resolutions. For 704 vs 720 the width of the signal is altered, but not its pixel aspect ratio.
I can prove this to you using my TV-Card.

[Alain2]

it is a matter of a flag within the MPEG2 file that tells the decoder in which proporitions the pixels are.
Which tool can let me see what it written in the mpeg2 stream for SAR and DAR ? IfoEdit shows me DAR, but I don't see SAR... ?

[phatagnus]

I just tried to convert some 720p60 to DVD and while the video looks OK, the audio is out of sync...

I'm using this avisynth script:



Loadplugin("C:\Program Files\AVIsynth 2.5\plugins\DGDecode.dll")
MPEG2source("720p.d2v")
fdecimate(rate=29.97)
converttoyuy2()
LanczosResize(704,480)



After encoding the video length is 43 minutes and 44 seconds while the AC3 length is 43 minutes and 46 seconds.
Obviously the audio is out of sync...

So far, i couldn't find a solution to this. Maybe some kind soul in here could show me the right way...

Thank you!

[pandy]

2 scharfis_brain & 2Bdecided - i only say - 720 and 704 is not so obvious. In many cases 704 will be displayed as 704 in some cases as 720. I work in company which make STB, i know that all european STB which are constructed in my company are 720 pixels, for special request (mostly for US market) we made a software for 704 pix in line. This due of limitations of hardware (composition OSD, Video and Graphic planes)

[scharfis_brain]

at least for consumer devices you got a constant PAR of 1.094 for 704 as well as for 720.

in contradiction most software players on your PC will use differnt PARs:
704 -> ca. 1.094
720 -> ca. 1.066

so I do everything in 704 and have no problems at all. I get the correct AR on TV as well as on the PC.

[pandy]

so I do everything in 704 and have no problems at all. I get the correct AR on TV as well as on the PC.

Did You measures pixels on screen? ;)

Believe or not if we have MPEG-2 704x576 in TS we don't change setup of degital encoder but simply we load to the scaler new coeficient table and input 704 are resampled in 9-tap resampler to the 720 pixels. This is due of limitation of hardware (user applications assume that 720 pixels screen is available so we must rescale video plane to apps because video plane can be rescaled by hardware - graphic plane can't)

[scharfis_brain]

I don't exactly unterstand what you mean.

if the encoder resizes from 704 to 720,
it is implemented in a faulty way.
it has to pad eight pixels each side in this case.

also you shouldn't optimize for PC playback. (which is faulty for 720 pixels width)
TV playback is always like I posted before.

btw.: I won't stop suggesting the ITU-601 rule for aspect ratios.
It is the most correct way and it prevents culmulative increasing errors.

[pandy]

I don't exactly unterstand what you mean.

if the encoder resizes from 704 to 720,
it is implemented in a faulty way.
it has to pad eight pixels each side in this case.

also you shouldn't optimize for PC playback. (which is faulty for 720 pixels width)
TV playback is always like I posted before.

btw.: I won't stop suggesting the ITU-601 rule for aspect ratios.
It is the most correct way and it prevents culmulative increasing errors.

scharfis_brain - i only say that construction of hardware for digital video is sometimes very weird... for example in most popular IC family for DTV YCbCr<>RGB conversion is done 2 - 3 times..., on graphic hardware plan no scaler exist (even blitter don't work corectly...), but on video plane scaler exist, due construction of video compositor you can't mix different sizes of video and grapchics...(and you can't simply add 8 pixels on each side of video) there is many similar "bugs" in video hardware...
So i don't say stop telling people that 702 or 704 is correct from theoretical point of view but so many video hardware is simply no good...

[scharfis_brain]

regarding the stuff I can buy for home cinema (DVD Players and recoders, DV-Cams etc.) and video editing (TV-Cards, VIVO cards), the majority of them handles 704 pixels width correctly.
So I don't see a big problem in using 704.

[Blimblim]

I'm sorry for upping this topic, but I'm looking for a way to convert true 720p60 footage (or 30 after fdecimate since it's a 30 fps game) to PAL 576i25. I guess it's not very different from what's been mentionned here, but since I'm not the one who will use that PAL footage in the end I can't really be sure it's been done correctly or not.
Any help would be much appreciated :)

[halsboss]

... convert true 720p60 footage (or 30 after fdecimate since it's a 30 fps game) to PAL 576i25.

Doesn't quite help you, but here is a link for PAL 720p @50fps to PAL 576i @25fps ... some say downsizing HD p to SD i for DVD retains more perceived motion fluidity http://forum.doom9.org/showthread.php?p=893683#post893683

Given you have a p source, for framerate conversion I've seen recent positive references to MotionProtectedFPS eg from a search :-
http://forum.doom9.org/showthread.php?p=893352#post893352 =
Gives nice fluidity of motion without too much blurring of slower moving detail. The original mvfps (or mvfpsscd) function is less prone to structural distortions (see the images I put up in that thread) but is much slower.

http://forum.doom9.org/showthread.php?p=892821#post892821 =
NTSC tools: auto NTSC to PAL with 24p, 30p, 60i detection (v 0.93)

http://forum.doom9.org/showthread.php?p=889978#post889978 =
you either can use motionprotectedfps or mvflowfps for AVISynth ...

Re conversion, also came across http://forum.doom9.org/showthread.php?p=893934#post893934 which says the quote below, however the target is apparently p plus it seems to talk about deinting and there are newer deints around (including use of TDEINT with EEDI which seems extremely popular, do a search)... NTSC to PAL conversion ... I cannot judge the quality of the PAL to NTSC conversion, because I don't have an NTSC tv screen.... but the outcome of the NTSC to PAL conversion is, by far, the best I have ever experienced.

So, I suppose you could framerate convert from NTSC 720p@60fps to PAL 720p@50fps using motionprotectedfps and then do the convert of PAL 720p@50fps to PAL 576i@25fps per http://forum.doom9.org/showthread.php?p=893683#post893683

If I were you, I'd invite comments from experienced people on choosing from the latest versions of motionprotectedfps and its contemporaries ...

[WorBry]

I've seen recent positive references to MotionProtectedFPS eg from a search :-
http://forum.doom9.org/showthread.php?p=893352#post893352 =

Thanks for the mention, but the 'fluidity of motion' referred to in that post was in the context of 50p to 25p conversion with motion blur. I dont have any personal experience with MotionProtectedFPS in standards conversion.