Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Usage

Reply
 
Thread Tools Search this Thread Display Modes
Old 13th December 2009, 07:25   #1  |  Link
Eric69
Registered User
 
Join Date: May 2006
Posts: 242
1080 50i to 1080 60i

I've recently had a Blu Ray job which needed footage converted from 1080 50i to 1080 60i before the encode since it was to be distributed worldwide. I did the conversion in FCP with a Black Magic 1080 6Oi sequence and, to my surprise, was pretty darn happy.

I've recently started working with Avisynth was curious how a conversion like this were to be possible?

Thanks
E
Eric69 is offline   Reply With Quote
Old 13th December 2009, 09:39   #2  |  Link
Alex_ander
Registered User
 
Alex_ander's Avatar
 
Join Date: Apr 2008
Location: St. Petersburg, Russia
Posts: 334
An example:
Code:
LoadPlugin("LeakKernelDeint.dll")
LoadPlugin("mvtools2.dll")
MPEG2Source("video.d2v")
LeakKernelBob(order=1)#50p
super = MSuper(pel=2)
backward_vec = MAnalyse(super, isb = true)
forward_vec = MAnalyse(super, isb = false)
MFlowFps(super, backward_vec, forward_vec, num=60000, den=1001, ml=100)#59.94p
ConvertToYUY2()
DoubleWeave().SelectEvery(4,1)#59.94i, TFF here
The mvtools2 motion interpolation plugin works on progressive (bob) here; it is sometimes recommended to simply separate fields for it, but IMO that's not quite safe (for same reasons as with resizing).
Alex_ander is offline   Reply With Quote
Old 13th December 2009, 13:23   #3  |  Link
wonkey_monkey
Formerly davidh*****
 
wonkey_monkey's Avatar
 
Join Date: Jan 2004
Posts: 2,493
Are we still in the stupid situation where even some new TVs can't understand 50i? I thought we'd left that behind when we went to flat screens.

David
wonkey_monkey is online now   Reply With Quote
Old 13th December 2009, 15:59   #4  |  Link
TinTime
Registered User
 
Join Date: Jan 2009
Location: UK
Posts: 403
Not just TVs. US PS3s won't play back 50i material for example.
TinTime is offline   Reply With Quote
Old 13th December 2009, 17:39   #5  |  Link
Lyris
Registered User
 
Join Date: Sep 2007
Location: Europe
Posts: 602
DavidHorman: yes. The (former) NTSC territories still ignore the 50hz world, whereas everything new in Europe works with both.
Lyris is offline   Reply With Quote
Old 13th December 2009, 18:19   #6  |  Link
wonkey_monkey
Formerly davidh*****
 
wonkey_monkey's Avatar
 
Join Date: Jan 2004
Posts: 2,493
Well, that just boggles my mind,

Anyway, Alex_ander's script is what I'd suggest - I've had some great results doing SD PAL->NTSC conversions using mvflowfps2. It seems the "2" version isn't available with MVTools2 - not sure why.

Some shots with large, fast-moving objects showed too much corruption, so I just replaced those bits with a clip using convertfps.

David
wonkey_monkey is online now   Reply With Quote
Old 13th December 2009, 19:45   #7  |  Link
Lyris
Registered User
 
Join Date: Sep 2007
Location: Europe
Posts: 602
I have some 60i HDV footage here that has to go out to PAL DVD, and have been investigating Avisynth-based standards conversion. This footage was shot handheld with no optical image stabilization, and it seemed to be too overwhelming for MVTools2. I've used ConvertFPS for the whole thing and the results are lot better than I was expecting - only trouble is that it obviously pays no attention to scene cut transitions and ghosts over them at times; not good for compression.
Lyris is offline   Reply With Quote
Old 13th December 2009, 21:22   #8  |  Link
IanB
Avisynth Developer
 
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
@Eric69,

Of course if the content is genuine 50 unique fields per second i.e sport etc, then the above MVTools approach is a way to go. Depending on the content and your usage you may be able to cheat and just ChangeFPS the 50p to 60p then reinterlace to 60i.

However if the content is 4% sped up film, then a better approach would be to recombine the frames, undo the 4% speed up to recover a standard 23.976 progressive source and then apply 3:2 pulldown.
IanB is offline   Reply With Quote
Old 14th December 2009, 13:43   #9  |  Link
2Bdecided
Registered User
 
Join Date: Dec 2002
Location: UK
Posts: 1,673
If you're happy with the "fake film" look, 50i>25p>24p>60i avoids motion compensation artefacts.

Mflowfps is fine, except when it isn't...!


There was an "alchemist" thread a few years ago - it might be worth re-visiting. A process which uses Mflowfps where it works, and drops back to convertfps where it doesn't, would be worth looking at again. Didee (I think) made a nice suggestion - try re-calculating motion vectors for the final footage - if it doesn't get you back to the original, the motion compensation is probably garbage and should be dropped.

There are scripts which do this, but the block-based switching I saw gave its own artefacts.

btw, be warned - doing motion compensation on HD sources is slow. So is decent deinterlacing.

Cheers,
David.
2Bdecided is offline   Reply With Quote
Old 29th January 2013, 08:02   #10  |  Link
selina5856
Registered User
 
Join Date: Oct 2010
Posts: 1
60i is NTSC recording format, 50i is a the PAL recording format, they are all HD formats, maybe this is just the reason why they can be converted from one to another
selina5856 is offline   Reply With Quote
Old 29th January 2013, 11:46   #11  |  Link
TheSkiller
Registered User
 
Join Date: Dec 2007
Location: Germany
Posts: 632
There wouldn't even be a need to convert between the two if the equipment sold in 60 Hz terretories would finally begin to be compatible with both refresh rates natively. But that would be a perfect world...


Since unlike with a SD based conversion the resolution stays the same (only the refresh rate differs) the quality of the bob-deinterlacing part isn't all that important because the converted fields will be re-interlaced and put where they originally came from (spatially, not temporally).


I would use YadifMod, either with NNEDI3 interpolation or simply Bob(0,1) (which would be very fast).

Code:
YadifMod(mode=1, edeint=NNEDI3(field=-2))

Last edited by TheSkiller; 29th January 2013 at 15:16.
TheSkiller is offline   Reply With Quote
Old 29th January 2013, 13:34   #12  |  Link
nhope
partially-informed layman
 
Join Date: Jan 2002
Location: Bangkok, Thailand
Posts: 314
I was gobsmacked too when I realised that the NTSC world still wasn't going to support 50i in the age of HD. Pathetic really. I now wish I had only ever bought and used 60Hz cameras.

Here's a script that bobs 50i with QTGMC then re-uses its vectors in MFlowFps for a conversion to 60p, then reinterlaces to 60i. I posted a bunch of similar scripts on the Sony Vegas Pro forum.

Code:
#Frameserve from Sony Vegas Pro in RGB24 format
AviSource("d:\fs.avi")
AssumeTFF()
ConvertToYUY2(interlaced=true, matrix="Rec601") #Rec601 is correct for encoding Ut Video Codec or Lagarith in Vdub

QTGMC("faster", SubPel=2) #SubPel must match pel in MSuper below
super = MSuper(levels=1, pel=2)
#super = MSuper(levels=1, pel=2, hpad=16, vpad=16) #For very fast and quicker QTGMC presets
MFlowFps(super, QTGMC_bVec1, QTGMC_fVec1, num=60000, den=1001)

separatefields()
SelectEvery(4,0,3)
Weave()
nhope is offline   Reply With Quote
Old 29th January 2013, 17:36   #13  |  Link
wonkey_monkey
Formerly davidh*****
 
wonkey_monkey's Avatar
 
Join Date: Jan 2004
Posts: 2,493
Quote:
Originally Posted by TheSkiller View Post
Since unlike with a SD based conversion the resolution stays the same (only the refresh rate differs) the quality of the bob-deinterlacing part isn't all that important because the converted fields will be re-interlaced and put where they originally came from (spatially, not temporally).
What do you mean by "converted fields"? If you're interpolating motion to get from 50i to 60i, you still want a decently bobbed intermediate, don't you? I don't see how the fact that you're not changing resolution makes a difference to the choice of bob.

For instance, if you use plain bob, you could (in a contrived situation) end up with a (temporally) interpolated output frame in which an object was drawn solely with spatially interpolated lines.

In fact I'd argue that the SD case going from 576i50 to 480i60 is the one where you could consider using a cheaper bobber, since you're going to be throwing away ~20% of your hard-won resolution anyway.

David
wonkey_monkey is online now   Reply With Quote
Old 29th January 2013, 23:48   #14  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
If you're working in Final Cut professionally, do yourself a favor and get one of these bad boys:

http://www.blackmagicdesign.com/products/teranex

They used to cost way too much money, and are now incredibly inexpensive. Realtime, high quality HD-SDI standards conversion for under $2k. Not bad!
__________________
These are all my personal statements, not those of my employer :)

Last edited by Blue_MiSfit; 30th January 2013 at 00:07.
Blue_MiSfit is offline   Reply With Quote
Old 30th January 2013, 01:27   #15  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
Teranex is useless for fps conversion- it uses blended conversion. You rather need Alchemist, which cost a fortune
kolak is offline   Reply With Quote
Old 30th January 2013, 12:11   #16  |  Link
TheSkiller
Registered User
 
Join Date: Dec 2007
Location: Germany
Posts: 632
Quote:
Originally Posted by davidhorman View Post
What do you mean by "converted fields"? If you're interpolating motion to get from 50i to 60i, you still want a decently bobbed intermediate, don't you?
What I mean is you just need to create a decent progressive intermediate (decent is exactly right word, not "(almost) perfect") for the motion interpolation to chew on.

Because after that you're throwing half (yes, half) of the information away by re-interlacing it. And before the motion interpolation exactly half of that bob-deinterlaced progressive intermediate was already interpolated by the bobber anyway.

So my point is: something as elaborate as for example QTGMC for bobbing wouldn't pay off here (I mean it wouldn't hurt, it's your CPU cycles). Many if not most of the original fields from your 50i/25 source will be put more or less unaltered into your 60i/29.97 video. If you were to resize vertically somewhere in the process this would not be the case and original fields and interpolated ones would get mixed spatially (they are mixed temporally to some degree due to the frame rate change as well). That's why a better bobber pays off more if there's a frame size change, probably not so much for 576i to 480i though.
The temporal mixing however is not very obvious since it is only there as long as things move. A spatial mix of original and rather humbly interpolated fields would be more objective because it is there all the time.

Last edited by TheSkiller; 30th January 2013 at 12:18.
TheSkiller is offline   Reply With Quote
Old 30th January 2013, 12:28   #17  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
Very true- I use yadifmode with NNEDI3 and it's good enough.
kolak is offline   Reply With Quote
Old 30th January 2013, 15:43   #18  |  Link
wonkey_monkey
Formerly davidh*****
 
wonkey_monkey's Avatar
 
Join Date: Jan 2004
Posts: 2,493
Quote:
Because after that you're throwing half (yes, half) of the information away by re-interlacing it.
Yes, but which half? After a plain bob, half of your pixels are interpolated (and because it's a plain bob, they're badly interpolated). After motion compensation, 50% of your data will still be interpolated (albeit motion compensated and blended with motion compensated pixels from another bobbed field). If you're extremely lucky, and all of the objects in your scene happen to move at just the right speed and in the right direction, you could end up keeping all of the good data and chucking away all of the interpolated data. But, on average, after re-interlacing you're going to end up keeping 50% of the interpolated information and 50% of the real information.

David

Last edited by wonkey_monkey; 30th January 2013 at 15:47.
wonkey_monkey is online now   Reply With Quote
Old 30th January 2013, 17:23   #19  |  Link
nhope
partially-informed layman
 
Join Date: Jan 2002
Location: Bangkok, Thailand
Posts: 314
QTGMC in "faster" mode can be pretty fast, especially if you get multi-threading going.

TDeint would be a faster bobber. Not quite as fast as yadifmod but I slightly prefer the results:

Code:
tdeint(mode=1)
You can improve it by doing the interpolation with nnedi3:

Code:
interp = nnedi3()
tdeint(mode=1,edeint=interp)
...but then it's probably approaching QTMGC "faster" speed and you have to generate the vectors for MFlowFps because you can't reuse those from QTGMC.
nhope is offline   Reply With Quote
Old 30th January 2013, 18:27   #20  |  Link
TheSkiller
Registered User
 
Join Date: Dec 2007
Location: Germany
Posts: 632
Quote:
Originally Posted by davidhorman View Post
Yes, but which half?
Unless you change the field order in the process (on purpose or accidentally) the interpolated lines will be discarded – the lines that were interpolated by your bob-deinterlacer. As a side note, a bob-deinterlacer like Yadif(Mod) and TDeint keeps the original fields untouched, QTGMC doesn't unless you use "lossless" mode.

Quote:
Originally Posted by davidhorman View Post
After motion compensation, 50% of your data will still be interpolated
Correct, and now we're throwing away 50% of the data by re-interlacing via selecting those lines where all the original lines would be.
Like I've said, due to the motion compensated frame rate change our original fields (which are frames at that point) will still get mixed temporally with interpolated ones to some degree when things move. But if nothing moves there simply would be no improvement from a more elaborate bobber whatsoever.


Maybe this helps you understand
Code:
AssumeTFF()
Bob(0,1) #copies originals fields, interpolates the missing ones

AssumeTFF()
SeparateFields().SelectEvery(4,0,3).Weave()
This would be a NOP (well, not exactly for the chroma in case of YV12, but let's just ignore this). Exactly those lines that were interpolated are thrown away again leaving us with all the original data as if nothing happened.

Last edited by TheSkiller; 30th January 2013 at 18:31.
TheSkiller is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 18:24.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.