25p to 60i (using pulldown technique)

[johnmeyer]

If it's for an Ntsc dvd, one don't even need to create 3:2 pulldown ; feed the mpeg-2 encoder with 23.976 fps and encode in soft pulldown, the encoder will create the 3:2 pulldown flag (most of movies are encoded this way on Ntsc dvds).
To change audio speed and/or pitch, I use Hybrid (which uses Sox for audio changes) ;
http://forum.doom9.org/showthread.php?t=153035Yes, that's what I meant to say. Thanks for the correction.

[Music Fan]

In case of interlaced frames one field may be taken from scene A and the second field may come from scene B, I think
(If this is what you mean by bad scene cuts?)
In this case, my idea to create 30p and simply encode it as interlaced (fake) is maybe not so bad because all the fields are kept, thus different frames won't be mixed.

[kolak]

As others have said, there is no "magic" pattern that is going to be better. If you want to reduce the problem, you can do what the "pros" have been doing for years, which is to change the playback speed of the original, without altering the frame at all, and then do your pulldown on that. This has been suggested in many other similar threads in this forum, but I don't think it has been mentioned here (I may have missed it). What you do is use assumefps(24) to change the playback speed, and then apply a standard 3:2 pulldown what results from that. You then adjust the audio speed, without changing pitch. I do that in Vegas, but others may know of a way to do it in AVISynth. Yes, the result will play a little slower, but that "artifact" may be more agreeable to you than the judder you get from pulldown needed to go from 25p.

There are many case when you can't touch speed.

I'm not looking for "other" ideas (I know all of the possibilities), but strictly asking for pulldown method.

[colours]

Finally, the whole issue of interlacing comes up because the human brain really can tell a difference -- and it is not a subtle difference -- between 24 temporal events per second and 60 temporal events per second. As has already been mentioned, it is not as fun to watch sports at 24p or even 30p, as ESPN streams on the web. Therefore there is a lot of incentive to design a system that can transmit and display 60 temporal events per second, but at a price that most people can afford, and with technology that can actually be mass-produced.

This is a very funny statement to make because it's a lot easier to just do away with interlacing and go with 60 frames per second, progressive. Sure, bandwidth is doubled, but only in terms of sample count. This is literally not a problem with lossy compression. I'm all ears if you can find a study proving me wrong.

Far as I can tell, feisty2 is the only person in this thread claiming that 24 fps is good enough. I think everyone else agrees that having 60 pictures per second allows for far more fluid motion than just 24 or 30.

Finally, the people here in this forum who seem to "hate" interlacing also claim to never watch TV. I am truly puzzled as to why they even care about something that they don't have to deal with.

This is so far off base I don't even know how to reply to this, but lol, you tried.

[johnmeyer]

There are many case when you can't touch speed.

I'm not looking for "other" ideas (I know all of the possibilities), but strictly asking for pulldown method.I am glad you know of all the possibilities. I wish I could be that good.

Sorry for trying to help.

[johnmeyer]

Far as I can tell, feisty2 is the only person in this thread claiming that 24 fps is good enough. I think everyone else agrees that having 60 pictures per second allows for far more fluid motion than just 24 or 30.So do I. See my post earlier in this thread where I also agreed that 60p is always preferable to 60i: johnmeyer agrees that 60 is preferable to 24 or 30, and 60p trumps 60i (http://forum.doom9.org/showpost.php?p=1739621&postcount=6)


Finally, the people here in this forum who seem to "hate" interlacing also claim to never watch TV. I am truly puzzled as to why they even care about something that they don't have to deal with.This is so far off base I don't even know how to reply to this, but lol, you tried.This is a long thread, so perhaps you missed post #8: I hardly even watch TV, much less interlaced TV, (http://forum.doom9.org/showpost.php?p=1739651&postcount=8).

So, actually, not off base at all. Also, if I wanted to spend the time, I could keep going and show you the posts where people imply that they don't watch "regular" TV very often.

[wonkey_monkey]

Therefore there is a lot of incentive to design a system that can transmit and display 60 temporal events per second, but at a price that most people can afford, and with technology that can actually be mass-produced.

There was a lot of incentive. Digital video is perfectly capable of transmitting 60 temporal events per second without resorting to interlacing, which is only clinging to existence thanks to a self-perpetuating loop of legacy support. Look at the amount of computing power required to run QTGMC, then consider that your TV - if it's a good one - has to do something similar just to give you a nice picture.

The collective wisdom of the engineers who designed both the original NTSC standard, and then the different set of engineers who designed our current set of international digital standards beats my knowledge of the subject, and also trumps everyone else in this forum. They understand the broad scope of all the engineering tradeoffs far better than anyone here.


Then it should interest you to know that: "The European Broadcasting Union has argued against interlaced video in production and broadcasting. They recommend 720p 50 fps (frames per second) for the current production format—and are working with the industry to introduce 1080p50 as a future-proof production standard.

"Broadcasters are still using interlacing so it must be a good thing" is really shaky logic. They seem to want rid of it just as much as everyone else.

Interlacing was a brilliant idea when it was conceived, but without it the entire broadcasting chain would be much more efficient.

[Sharc]

There are many case when you can't touch speed.

I'm not looking for "other" ideas (I know all of the possibilities), but strictly asking for pulldown method.
In this case this plugin may also be out of your interest, so never mind I mention it. It seems to have some parameters to control scene changes and it claims maximum playback fluidity. I have no experience with this plugin, so I can't tell how it copes with the "soap opera" effect etc.
https://www.svp-team.com/wiki/Plugins:_SVPflow

[colours]

This is a long thread, so perhaps you missed post #8: I hardly even watch TV, much less interlaced TV, (http://forum.doom9.org/showpost.php?p=1739651&postcount=8).

Do you want an award in selective reading? I think you deserve it.

[johnmeyer]

Digital video is perfectly capable of transmitting 60 temporal events per second without resorting to interlacing, which is only clinging to existence thanks to a self-perpetuating loop of legacy support. Yes, digital video can handle 60 temporal events per second. We have 60p, so that is not in dispute.

What IS in dispute is whether either broadcast TV or DBS (e.g., DirecTV), within the spectrum they are allocated, have the bandwidth to do that and still offer the same number of channels. I think we could all make the argument that 80% of the channels could be eliminated, but there are strong business reasons that push broadcasters in the other direction. So, even today, 1080i is being used in order to provide a "temporally pleasing" experience, without consuming too much bandwidth.

One other point that is obvious, but bears repeating, is that our current North American HD standard was finalized in 1993. That was the same year that the Intel Pentium processor was introduced, but almost all sales that year were 486 computers.

Think of the truly unbelievable increase in computing power in that time.

As this chart shows:

Instructions Per Second (https://en.wikipedia.org/wiki/Instructions_per_second)

the processing power these engineers had to work with was around 25 MIPS at 66 MHz.. In actuality, it was considerably less than that because consumer electronics have to sell for a low price, and the "horsepower" shown in these charts was out of that price range.

In 1996, the year before the DVD (an SD device) was introduced, the Pentium Pro got us to 541 MIPS at 200 MHz.

By the time the first consumer HD players arrived in stores (2004) Intel architecture chips were around 10,000 MIPS at 3 GHz.

Today, Intel i7 chips at over 100,000 MIPS at over 3 GHz.

The point is that many things that we can easily do today, were not even conceivable when these standards were developed.

So, "change the standards!!" you say.

Unfortunately, standards cannot be changed quickly. The best example of that is the changeover from SD to HD. In this country, that happened exactly seven years ago this month. Despite that time, and despite a mandate from Congress, we still have a sizeable number of channels broadcasting in SD (about 100 on my system).

[kolak]

Guys, I've been using interframe and pro tools for ages and know all possibilities of motion estimation techniques.

I'm not interested in debate about progressive v interlaced neither. It's for broadcast/Blu-ray/DVD so forget about 50p/60p. This is not thread what could be done- end result has to be clean of visible artefacts and meet all restriction in terms of supported standards etc. It's very restricted "request". No speed change is allowed also.

As I said- I'm only interested in this thread about pulldown method (I already went through everything else).
I'm happy in debate how to get smooth 60i from 25p over pulldown, everything else is out of topic.

[johnmeyer]

Do you want an award in selective reading? I think you deserve it.No, but I'd appreciate an acknowledgement that I backup up my claims with actual facts, in this case a link to a post which states exactly what I said I had read.

And, I don't read "selectively," whatever that is supposed to mean. Instead, I read everything and try to understand all points of view.

Finally, I don't shoot from the hip, without first researching and thinking about the answer.

[kolak]

I am glad you know of all the possibilities. I wish I could be that good.

Sorry for trying to help.

Your posts are out out of topic and bring nothing productive to the discussion.
If you wish to discuss interlaced v progressive please create new thread.

[colours]

exactly what I said I had read.

Yeah, I guess omitting some words in a sentence is no big deal. No one ever cares about what's in a sentence after the second comma, right?

But, y'know, back to topic. kolak, we still have no clue what exactly your requirements are, other than that you have a 25 fps source and you want to convert it to 60 fields/s. Or is it 60000/1001 instead of 60? We don't know that either.

To answer your question about scene changes, no, there shouldn't be any problem with that, assuming that the playback setup isn't broken.

[kolak]

25p to 59.94i (or i29.97 by BBC naming) precisely, no speed change allowed.
I've tried your script and it worked fine. Looks like refresh rate synced payback on TV had no problems with scene changes, so yet again avisynth proved to be great :)
Is lack of scene change problem guaranteed (can be perfectly explained by math)?

[jmac698]

Using pulldown only, there's not really much to debate here, or any further "best" to find, it's simply not possible - the pulldown pattern has to be basically the same no matter what. Changing phase of the pattern based on scene change is about the only improvement I can see. There can't be some mythical "pro" method that's any better than this.

[kolak]

Using pullup only, there's not really much to debate here, or any further "best" to find, it's simply not possible - the pullup pattern has to be basically the same no matter what. Changing phase of the pattern based on scene change is about the only improvement I can see. There can't be some mythical "pro" method that's any better than this.

Well, I thought there is (based on some name which I was passed), but it was false alarm. Pattern is exactly the same as presented here. Cinemacraft SP3 also uses the same pattern.
I'm only now bothered with scene changes. My test video was 2min and full of cats ever few seconds and I haven't noticed any problems.

jmac698, any quick script to avoid possible scene changes problem?

[jmac698]

I don't see anything special about no combing on a scene change as opposed to combing on the other frames, visually, the only advantage I see is if the encoder puts an I frame there, it might be more data to correct in the following frames, unless the encoder is using an interlaced mode. So this is more about understanding the behavior of encoders. I need some help here. If encoders can start a new GOP on a scene change, then I make the scene changes always not combed. However take mpeg2 for example, with a 15 frame GOP, you're better to make every 15 frames not combed, starting with the first. It would depend on the output codec or more generally the GOP settings you use with the output codec. So you'd have to set this manually. If you encode with the right settings anyway, it won't matter (say, a matching 12 GOP). The worst that could happen without this effort, is a few frames every LCM(12,15)* look a little worse. I hardly think it's worth it.

It's complicated. Anyone else have thoughts?

least common multiple.. put simply, 3 seconds

[kolak]

This is not my worry.
I'm worried about flashes on scene changes (mixed fields) when watched on TV or broadcast monitor.
I think when scene change happens on bottom field (when file is top) than this is not good? Can this actually happen?

Regarding encoders- today many have adaptive GOP placement and adaptive GOP lengths (and structure), so pattern is not fixed. In most cases you define max GOP size.

[jmac698]

simple enough to try it! let me know

[feisty2]

@johnmeyer
nah, I heart 1080p60, think that's pretty cool
What I actually hate is 1080i60, interlacing has to commit a suicide instantly
And yeah, the good ol interlacing stuff has been discontinued in uhd standards
Interlacing was designed to be a trade off (sacrificing quality to, whatever), not something to improve the quality
Wanna see some real fancy fluid stuff? Go get 60p, not 60i, not a chance, like ever, it just has to die, vanish from this planet
And, I wasn't even comparing 1080p and 4k, I was comparing 1080p30 and 1080i60, 1080p60>1080p30>>>>>>>1080i60
Cuz, spatial resolution plays a bigger part at something like, only 1920x1080 or 540

[colours]

I think when scene change happens on bottom field (when file is top) than this is not good? Can this actually happen?

That can't happen. The fields' timestamps are necessarily nondecreasing. (Unless you do post-pulldown processing that messes with that like cropping by an odd number of pixels or whatever, so don't do that.)

[Music Fan]

any quick script to avoid possible scene changes problem?
I tried the method I suggested yesterday, that's not so bad ;
You could maybe try to double one frame all 5 frames (and you will get 30p that you can interlace)
But of course it creates 30p, not 29.97p.
SelectEvery(5,1,2,3,3,4,5)#duplicates 3rd frame in a group of 5

[kolak]

I think this will be less smooth.

[kolak]

That can't happen. The fields' timestamps are necessarily nondecreasing. (Unless you do post-pulldown processing that messes with that like cropping by an odd number of pixels or whatever, so don't do that.)

Well, my real life test shown no problems over 2min video with cuts every few seconds, so I think it's all good.
Power of avisynth :)

[Music Fan]

I think this will be less smooth.
What script did you use finally ?

[kolak]

source
ChangeFPS(60) # or ChangeFPS(60000, 1001) depending on what you need
AssumeTFF() # or AssumeBFF
SeparateFields()
SelectEvery(4, 0, 3)
Weave()

I don't think that there is a better way (of course except perfectly working motion estimation technique).

[Music Fan]

I believed you had used a script that creates 2:2:3:2:3, the pattern you were talking about earlier.
If you simply use ChangeFPS(), you could maybe try ChangeFPS(30) (or 29.97) and encode it as interlaced, you won't even have to SeparateFields() and re-interlace in this case.
When using ChangeFPS(60) with 25p, is there a predictable behavior (a repetitive pattern) or is it aleatory ?

[kolak]

There is a pattern, no?
This is the whole idea.


With change to 30 I think it will give less variation (it will repeat frames, not fields). This is why many post houses do 25p to 60i not 30p, as it gives smoother end result.

[feisty2]

No const pattern
Changefps repeats frames with minimal differences, or delete frames likewise

[Music Fan]

Ok, but actually I just made the test (ChangeFPS(60) with 25p source) and I observe that this pattern repeats (I verified frame by frame until n°74) ;
3,2,3,2,2
And I have no doubt because I put showframenumber() before changeFPS(60).

[Music Fan]

With change to 30 I think it will give less variation (it will repeat frames, not fields). This is why many post houses do 25p to 60i not 30p, as it gives smoother end result.
I made another test with showframenumber() ;
25p source
showframenumber(size=200)
ChangeFPS(60)
assumeTFF()
separatefields()
selectevery(4,0,3)
weave()
This shows clearly a lot of blended frames (n° 1,2, 7,8, 13,14, 19,20, 25,26...), which doesn't happen with changefps(30) (by the way, it duplicates the first frame all 5 frames, as SelectEvery(5,1,1,2,3,4,5) would make).

This is also interesting ;
25p source
showframenumber(size=50)
ChangeFPS(60)
assumeTFF()
separatefields()
showframenumber(size=200)
selectevery(4,0,3)
weave()
In addition to the blending, it also shows in small the numbers of original frames (from 25p) and in large the numbers of the fields (from 60p) that are kept.

[Gavino]

This shows clearly a lot of blended frames (n° 1,2, 7,8, 13,14, 19,20, 25,26...)
That's not blending, it's just normal interlacing, where the two fields represent different points in time..
Or is that what you meant?

[Music Fan]

Yes, but with this method, some frames are progressive (because the source is too), others are interlaced (because they contain the top field of a frame and the bottom field of another frame) ; I wonder how a player or a tv can handle it correctly.
I'm afraid it creates problems on scenes changes if some frames contain the top field of the last frame of a scene and the bottom field of the first frame of the next scene.
When you film in interlaced, this problem can't happen because the camera doesn't stop after the top (or bottom) field, it films both fields.
And in video editors, cutting is always done after a complete frame (2 fields), thus there is no risk to gather 2 non consecutive fields with truly interlaced videos.


edit : I tested with a 25p video and my fear was justified, a lot (but not all) first or last frames of some scenes contain 2 fields that are not supposed to be displayed together (2 scenes in 1 frame).

[kolak]

This was my worry, but it seams to not happen.

[colours]

Yes, but with this method, some frames are progressive (because the source is too), others are interlaced (because they contain the top field of a frame and the bottom field of another frame) ; I wonder how a player or a tv can handle it correctly.

The same way they handle usual interlaced content, or if they're smart enough to detect pulldown, by doing field matching.

I'm afraid it creates problems on scenes changes if some frames contain the top field of the last frame of a scene and the bottom field of the first frame of the next scene. [snip]

edit : I tested with a 25p video and my fear was justified, a lot (but not all) first or last frames of some scenes contain 2 fields that are not supposed to be displayed together (2 scenes in 1 frame).

This is not a problem. Stop thinking of an interlaced clip in terms of its frames. Think in terms of fields instead.

[Music Fan]

This was my worry, but it seams to not happen.
You are lucky, look at the edition in my previous post.

[Music Fan]

The same way they handle usual interlaced content
No, that's different ; interlaced content never mix 2 scenes in 1 frame.

or if they're smart enough to detect pulldown, by doing field matching.
If they're smart enough, yeah.

This is not a problem. Stop thinking of an interlaced clip in terms of its frames. Think in terms of fields instead.
I don't understand what it changes to think in terms of fields.
If a frame contains 2 half of 2 scenes, there is a problem, and that happened, I just tested it (see my edit above).

[Sharc]

MusicFan's method:
All frames remain progressive. Progressive frame #3 is just duplicated, which creates a slight judder.

Color's Method:
Frames consist of interlaced fields like 22323, cyclic fields pattern. Judder is less than above. A frame can however have fields from 2 scenes, like top field from scene A and bottom field of scene B. A player should restore the original frames properly, similar to standard telecined material (standard = slow down, then 3:2 pulldown). Unless the deinterlacer which does the de-telecining is broken, one should not get blended or otherwise messed up frames, I think. But perhaps not all players will handle the non-standard "telecined" 22323 pattern correctly; I don't know. One would have to test.

[vivan]

No, that's different ; interlaced content never mix 2 scenes in 1 frame.Never? And you expierence of never is based on?

I've some VHS captures that do this and QTGMC deals with it just fine.

If they're smart enough, yeah.And if they are not... That's how anime gets destroyed. While I don't really have anything against interlacing, telecine is the worst thing that ever happened to anime.
The best part is when interlaced and progressive content are mixed (in one frame). Or content with different fps. Or content with same fps but shifted patterns.

I don't understand what it changes to think in terms of fields.Fields are frames.

If a frame contains 2 half of 2 scenes, there is a problem, and that happened, I just tested it (see my edit above).And the problem is...?
TFM and madVR handle it fine.

[kolak]

I would say almost none will handle it. For players, TVs, decoders this is 60i content, only some good video processors may detect this pattern.
I still don't know how c9me my 2min video with maany cuts did not show a problem.

MusicFan- did you watch your clip on TV through proper 60i chain?

[Sharc]

How do you guys test? Author to DVD, burning to disc and then play via DVD player + TV? I think this should be the ultimate verification test.

Edit:
Has anyone tried soft-pulldown? If the flags are correctly set and the player acts accordingly it should work, I guess .... but well, maybe to many "ifs" .....

[poisondeathray]

It doesn't matter - "smart" cadence detecting hardware setup will remove the pulldown correctly . "dumb" HW setup will bob deinterlace - either way you don't get "blends" unless you blend deinterlace . In scenario "A" you get the progressive frames, no blends. In scenario "B" you still get progressive frames no blends, they are just lower quality from deinterlacing. Eitherway, you get 3:2:3:2:2 frames * 5 for each 60 frame cycle - each field "becomes" a frame. You get frame repeats. You're not "field matching" in that scenario - so you never get a top field from one frame and bottom from another

The problem he's worried about is a different issue. It occurs when you edit progressive content afterwards without removing pulldown and disrupt the cadence.

[Music Fan]

Never? And you expierence of never is based on?
On my experience in video editing ; I never saw 2 scenes in 1 frame while I cut hundreds of interlaced videos for years.
Cameras and video editors have a frame precision, not a field precision (cuts are always done between 2 frames, not 2 fields coming from the same frame).

And the problem is...?
TFM and madVR handle it fine.
Let's be logical, if we talk about 25p to 60i conversion, it's not re-encode the 60i to 25p with a pc. The OP seems to need a Ntsc dvd or a broadcast diffusion in 60hz.

Reverse 3:2 pulldown is something known for years and very common in 60hz zones, most of mpeg-2 decoders are probably programmed to handle it correctly (especially with soft pulldown encodings whose flag helps the decoder), which is not the case of this 60i video that might not be decoded properly by a standalone player.

[Music Fan]

MusicFan- did you watch your clip on TV through proper 60i chain?
No, but I'm sure 30p encoded in 60i won't create problem (it's like 25p encoded in 50i), all fields from 30p are kept. The original fields will be displayed together, even with a basic decoder, there is no need to make a smart field matching.

[colours]

If a frame contains 2 half of 2 scenes, there is a problem, and that happened, I just tested it (see my edit above).

Yes, it happens. Of course it does. We're just saying that this is expected and there's absolutely nothing wrong with it happening.

What is a problem (albeit a tiny one) is that if you do post-pulldown splicing, it can be the case that it's impossible to field-match the fields around the splice. But this is not a playback issue; it can be handled by deinterlacing said problematic fields; and gosh darn it, you're not supposed to splice videos post-pulldown in the first place!

[Music Fan]

MusicFan's method:
All frames remain progressive. Progressive frame #3 is just duplicated, which creates a slight judder.

Color's Method:
Frames consist of interlaced fields like 22323, cyclic fields pattern. Judder is less than above.
Actually, I'm not even sure my method (30p) does create more judder than the other (60p re-interlaced).
It's 2,1,1,1,1 or 3,2,3,2,2, both are strange but acceptable for human eyes.

[Music Fan]

Yes, it happens. Of course it does. We're just saying that this is expected and there's absolutely nothing wrong with it happening.

What is a problem (albeit a tiny one) is that if you do post-pulldown splicing, it can be the case that it's impossible to field-match the fields around the splice. But this is not a playback issue; it can be handled by deinterlacing said problematic fields; and gosh darn it, you're not supposed to splice videos post-pulldown in the first place!
How can you be sure it won't be a problem when displayed on a TV screen ? Why would this effect disappear ?
That will be ok if a good field matching is done, otherwise I have doubts.

[colours]

The "effect" merely stems from what the video looks like if you use weave deinterlacing. Please reread poisondeathray's post until you understand this.

If you're really so worried about it (which is quite weird, because kolak's totally fine with it and this is his/her thread), there's also the option of doing 3:3:2:2:2 pulldown, which I believe should solve your problem.

[Music Fan]

The "effect" merely stems from what the video looks like if you use weave deinterlacing. Please reread poisondeathray's post until you understand this.
The behavior he describes is maybe true for progressive screens, but what about CRT tv ?
I guess it doesn't matter because fields are never displayed together on CRTs (except perphaps some progressive models).

If you're really so worried about it (which is quite weird, because kolak's totally fine with it and this is his/her thread)
I have already seen people happy with a solution until they realize there is better (but I don't profess it's the case here, that's just an eventuality).

there's also the option of doing 3:3:2:2:2 pulldown, which I believe should solve your problem.
That's not so far from 2,1,1,1,1 (25p to 30p).