60p to 25i need help! [Archive]

DIEGO7-5

9th June 2010, 22:15

I have the kodak playsport camera for testing and i prefer to shoot action scenes in 720p 60fps (h.264) with it. But i live in Germany so the video standard is PAL and there is no firmware update for 50p yet so i am stuck. The other thing is that i shoot with a second camera (PANASONIC) that does PAL Broadcast Standard 704 x 576 25i.

I would like to combine the footage of these two camcorders without jerky pictures from the kodak playsport. I´m an Avisynth newbie. I know how to use a script but i can´t figure out how to write one that will fullfill my needs.

The kodak playsport files need to be PAL standard after conversion to MPEG-2, matching the 704x576 16:9 25i resolution and file format of my Panasonic Camcorder.

Any help would be much appreciated! I am looking for a plain and simple script i can understand and comprehend. I hope it exists :-)

Guest

9th June 2010, 22:18

There is no good solution for clean nonjerky output, I'm sorry to tell you.

DIEGO7-5

9th June 2010, 22:27

Thanks for your quick Reply! The Kodak PlaySport also shoots 1080p 30fps. Any chance to go from there?

onesloth

9th June 2010, 22:56

MFlowFps() (http://avisynth.org.ru/mvtools/mvtools2.html) might be worth a try. It might produce acceptable results with your source. Worth a try.
lanczosresize(704,576)
super = MSuper()
backward_vec = MAnalyse(super, isb = true)
forward_vec = MAnalyse(super, isb = false)
MFlowFps(super, backward_vec, forward_vec, num=50, den=1, ml=100) # get 50 fps

Then interlace to 25i.

Blue_MiSfit

10th June 2010, 00:49

Yep. MFlowFPS is about as good as it gets without really throwing the kitchen sink at it - inside avisynth anyway.

Got $100k? Buy a Snell Alchemist PhC ;)

DIEGO7-5

10th June 2010, 09:38

onesloth

10th June 2010, 09:48

DIEGO7-5

10th June 2010, 10:06

That's great. MFlowFPS can be so frustrating sometimes. It's not like we expect magic from it </sarcasm> Did you happen to try putting the resize after MFlowFPS? I'm a little curious if this has a noticeable effect.

No, not yet. What i am currently using is this:

separatefields()
lanczosresize(704,288)
super = MSuper()
backward_vec = MAnalyse(super, isb = true)
forward_vec = MAnalyse(super, isb = false)
MFlowFps(super, backward_vec, forward_vec, num=50, den=1, ml=100) # get 50 fps
weave()

I hope i´m doing it right...IMPROVEMENTS ARE ALWAYS WELCOME!

Gavino

10th June 2010, 10:22

Your script will give incorrect field alignment.
Use onesloth's script and interlace by adding at the end

SeparateFields()
SelectEvery(4,0,3)
Weave()

onesloth

10th June 2010, 10:34

So the script segment would be:

lanczosresize(704,576)
super = MSuper()
backward_vec = MAnalyse(super, isb = true)
forward_vec = MAnalyse(super, isb = false)
MFlowFps(super, backward_vec, forward_vec, num=50, den=1, ml=100) # get 50 fps
SeparateFields()
SelectEvery(4,0,3)
Weave()

@Gavino: Should he put an assumeBFF()/assumeTFF() before the SeparateFields() to match the field dominance of the PAL standard source he wants to join to?

Gavino

10th June 2010, 10:42

Should he put an assumeBFF()/assumeTFF() before the SeparateFields() to match the field dominance of the PAL standard source he wants to join to?
Yes, you're right.

DIEGO7-5

10th June 2010, 13:27

Yes, you're right.

after a lot of testing, this script finally produces mpeg-2 25i TFF output. please let me know if i can improve the script. Encoding software is XVID4PSP.

LoadPlugin("C:\Programme\Winnydows\XviD4PSP5\dlls\AviSynth\plugins\MVTools2.dll")
ConvertToYV12(interlaced = true)
assumeTFF()
SeparateFields()
SelectEvery(4,0,3)
Lanczos4Resize(704, 288)
super = MSuper()
backward_vec = MAnalyse(super, isb = true)
forward_vec = MAnalyse(super, isb = false)
MFlowFps(super, backward_vec, forward_vec, num=50, den=1, ml=100) # get 50 fps
Weave()

Gavino

10th June 2010, 13:41

Didn't you read what I said, separated fields cannot be resized correctly that way and you must interlace after resizing (as shown in onesloth's last post).

You don't want interlaced=true on ConvertToYV12 either, since your input is progressive (isn't it? You said 60p).

DIEGO7-5

10th June 2010, 13:46

Didn't you read what I said, separated fields cannot be resized correctly that way and you must interlace after resizing (as shown in onesloth's last post).

I tried the script exactly as written by onesloth but i hat jerky video output when i hit the deinterlace button in VLC Media Player to see if i got smooth video. Probably just encoding settings in XVID4PSP. Will try HCENC next.

pandy

10th June 2010, 15:11

Alex_ander

10th June 2010, 15:14

Will try HCENC next.
Don't forget to correct the line order :) :

#60p input
LoadPlugin("C:\Programme\Winnydows\XviD4PSP5\dlls\AviSynth\plugins\MVTools2.dll")
Lanczos4Resize(704, 576)
super = MSuper()
backward_vec = MAnalyse(super, isb = true)
forward_vec = MAnalyse(super, isb = false)
MFlowFps(super, backward_vec, forward_vec, num=50, den=1, ml=100)
AssumeTFF()
SeparateFields()
SelectEvery(4,0,3)
Weave() #TFF

onesloth

10th June 2010, 17:22

Don't forget to correct the line order :)Yes.

There could be a couple reasons, besides the script, that might cause VLC to not deinterlace the output properly.
1) Are you sure your source is progressive?
2) Does XVID2PSP do interlaced encoding?
3) Does XVID2PSP require that you manually select the interlaced encoding mode?
4) Does XVID2PSP require that you manually specify TFF field dominance?

onesloth

10th June 2010, 17:39

In Europe we use TFF so instead BFF You can use TFF

#AssumeFrameBased().SeparateFields().SelectEvery(4,0,3).Weave().AssumeBFF()#BFF
AssumeFrameBased().SeparateFields().SelectEvery(4,1,2).Weave().AssumeTFF()#TFF

If you specify AssumeTFF prior to SeparateFields() (as in the first line), doesn't SeparateFields() place the top field in the first frame? Assuming it behaves this way, wouldn't SelectEvery(4,0,3) be the correct call?

I don't really see any reason to AssumeBFF/TFF *after* SeparateFields().SelectEvery(). Field dominance needs to be determined by which fields SeparateFields() puts in which order. SelectEvery(4,1,2) should only produce correct output (i.e. TFF) if SeparateFields() was by default assuming BFF in the absense of an explicit field dominance instruction.

pandy

11th June 2010, 10:09

AssumeTFF() or AssumeBFF() from my knowledge force Avisynth to particular field dominance flag - ie by Assume TFF or BFF we can in explicit way express expected Avisynth behavior. But i can be wrong - anyway personal experience conform that this syntax work good. but as i say earlier - im open for knowledge.

Gavino

11th June 2010, 10:28

personal experience conform that this syntax work good
Your method works because AssumeFrameBased resets the parity to BFF. You then use the appropriate SelectEvery and AssumeXFF to get either TFF or BFF as output.

I find onesloth's method simpler and easier to remember - set the desired parity before SeparateFields and then always use SelectEvery(4,0,3).

pandy

11th June 2010, 10:49

Your method works because AssumeFrameBased resets the parity to BFF. You then use the appropriate SelectEvery and AssumeXFF to get either TFF or BFF as output.

And this is important to me - in past i have some problems with some plugins that change XFF to oposite or in some mysterious and complicated pattern. After i start using this explicit method (which act like some workaround) all my problems with field dominance was solved.

I find onesloth's method simpler and easier to remember - set the desired parity before SeparateFields and then always use SelectEvery(4,0,3).

i agree that this is simpler and easier but i have some nasty experience from past then i start using a less automatic method.

If machine is not smart enough to deal with weird data then give machine no chance to decide how to deal with data.

2Bdecided

11th June 2010, 14:50

pandy, there's nothing "automatic" about setting the field order and then separating the fields. It's the absolutely correct way to do it. It can't fail to do exactly what you ask for.

Now, if you ask for TFF, and then tell your encoder that you're feeding it BFF, then you'll have a problem!

Cheers,
David.

pandy

11th June 2010, 16:14

I agree but everything working until you stay fully with Avisynth - i quite frequently use ffdshow as plugin and few years ago it was mystery behavior from ffdshow during processing some nasty video - from this moment i always use such structure and i don't have any problems

DIEGO7-5

13th June 2010, 10:05

Yes.

There could be a couple reasons, besides the script, that might cause VLC to not deinterlace the output properly.
1) Are you sure your source is progressive?
2) Does XVID2PSP do interlaced encoding?
3) Does XVID2PSP require that you manually select the interlaced encoding mode?
4) Does XVID2PSP require that you manually specify TFF field dominance?

1) yes
2) yes
3) it requires that you manually set the source to interlaced to do interlaced tff encoding even if source is progressive. otherwise output will always be progressive.
4) no - it will always output tff mpeg-2 interlaced video if i do the settings in 3)

Undead Sega

14th June 2010, 18:29

25i??? Dont you mean 50i? cause that would be more ideal and make alot more sense.

pandy

14th June 2010, 23:31

i50 means 100 fields per second...

um3k

15th June 2010, 03:07

25i = 50i

This discussion has been had far too many times.

MatLz

15th June 2010, 12:01

25i = 50iSo,

i = 0
or i = infinity
or i != i
or better, 25 = 50

???:confused:???

Gser

15th June 2010, 12:26

So,

i = 0
or i = infinity
or i != i
or better, 25 = 50

???:confused:???

IMO people should use the number to signify whole frames instead of fields so that it would concurrent with the way progressive video is implied. It is the frames that actually count these days as digital displays are unable to show fields and therefore have to deinterlace interlaced content into whole frames.

Hence,

25i means 25 whole frames split into 50 fields(interlace)
25p means 25 whole frames, no field spliting
etc.
etc.

The 60i/50i system is highly unintuitive especially in the future when framerates of digital video will increase (e.g. "3D")

wonkey_monkey

15th June 2010, 21:18

The 60i/50i system is highly unintuitive

I'd say it's more intuitive - 50i is twice as smooth as 25p - it seems to me that what you're arguing is that it's more technically correct, which is almost the opposite!

David

um3k

16th June 2010, 02:34

So,

i = 0
or i = infinity
or i != i
or better, 25 = 50

???:confused:???

It's not math, it is language. Thus your proof is invalid.

MatLz

16th June 2010, 15:25

It's not math, it is language. Thus your proof is invalid.

I don't think so....but if you want language to answer to your incorrect math :

25i and 50i are not the same thing.

2Bdecided

16th June 2010, 15:32

25i and 50i are not the same thing.If they mean something different, please quote the exacts specifications of both - and show where both different systems are defined as in-use video formats.

(1990s 100Hz CRT TVs don't count)

Cheers,
David.

Ghitulescu

16th June 2010, 15:32

25i??? Dont you mean 50i? cause that would be more ideal and make alot more sense.

i50 means 100 fields per second...

25i = 50i

IMO people should use the number to signify whole frames instead of fields so that it would concurrent with the way progressive video is implied. It is the frames that actually count these days as digital displays are unable to show fields and therefore have to deinterlace interlaced content into whole frames.

Hence,

25i means 25 whole frames split into 50 fields(interlace)
25p means 25 whole frames, no field spliting
etc.
etc.

The 60i/50i system is highly unintuitive especially in the future when framerates of digital video will increase (e.g. "3D")

25i and 50i are not the same thing.

Most of this issue was created [partly] by EBU, reaching the end user through video equipment manufacturers, older papers from EBU naming 25i what today is called 50i (ie a 25 frames/s interlaced video), only the advent of HDTV changing this into 50i (50 fields/s interlaced video).

It appears that today 50i is the most used term to describe eg the PAL system.

onesloth

16th June 2010, 15:44

I think what's relevant is that everyone understood what the OP meant by 25i. Seems like this debate is better off in its own thread.

Undead Sega

17th June 2010, 03:09

25i would technically be equilivant to 12fps, cause it would be 25 frames interlaced form, Interlace being Fields which can also be the same things as saying 'half a frame' from here, the maths can easily do and be the answer.

50i would have the motion or fluidity of 50p, but because it is Interlace video the true framerate would be 25 frames. Progressive video could've been the standard of every TV broadcast in the world and that field displaying on a television set would never exist, however as we all know that prgressive transmission can be relatively expensive, assumingly they probably wanted to display broadcasts of high quality in a similar way how film is projected, the technology at the time didnt allow for it, thus an idea came into fruition, this being that engineers where sorting out a way to deliver 'high quality' broadcast using less bandwidth, hence they came up with Interlaced video, where the idea of 'high quality' would be portrayed as 'smoother looking video' to the viewers, which evidently and ultimately became what we are all used to today with the term of 'Video Look.'

Also when one would mention to describe footage that is either displayed or captured at '50i,' it makes sense and proving it technically when this term is said, because Interlace video is made up of Fields, 50i is literally Fields being displayed 50 times, this can only come from Interlace video because Interlace video is made up of Fields :D

I hope this makes sense (as well as agreeable) and would end this talk. As for the OP, I highly doubt he would want it at 25i, he is probably wanting to take something from NTSC land to PAL land :D

2Bdecided

17th June 2010, 17:48

I hope this makes sense (as well as agreeable)Why would it be agreeable? Knowledgeable people have been arguing about this for many years. Just accept that both 25i and 50i refer to the same video format, neither name is going to disappear completely, and move on!

Cheers,
David.

pandy

18th June 2010, 11:23

25i = 50i

This discussion has been had far too many times.

nope - definition is clear - when i see 1920x1080i25 it means that i have:

1920 pixels in line
1080 lines

25 means that such bitmap structure appears 25 times per second
i means that it is interlaced - usually made from 2 fields (but it can be 3 field, 4 field etc - some medical imaging system produce interlace video with different interlace structure - ok usually ancient medical equipment made in times when electronics was slower)

what it really worse You can transmit progressive video as interlace so i25 is definitelly not a i50

GodofaGap

18th June 2010, 11:31

This reminds me of the debate about what PAR/SAR should stand for. :)

Sometimes different terms have the same meaning, and sometimes one term has different meanings.

IMO it is more than intuitive that 25i means 25 interlaced *frames* per second and not 25 *fields* per seconds, because the latter doesn't really exist in the real world.