25p to 60i (using pulldown technique)

[kolak]

I've been told that there is a pro solution which does 25p to 60i conversion over 13 steps cadence.
I assume this is can be done with avisynth as swell?

[colours]

Anything involving interlacing is evil and you should not use interlacing ever. That said:

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

[feisty2]

Irregular pull down

[johnmeyer]

There is absolutely nothing evil or wrong about interlacing. It works great, and has been in use for longer than most people on this planet have been alive. It is still used today, and you watch interlaced TV all the time, and it looks wonderful.

That said, it does require more skill and knowledge to work with in the digital realm. In particular, any resizing or change in cadence does require deinterlacing, a step that always degrades the video. But, since re-sizing and frame rate changes ALSO degrade the video, deinterlacing, when used for those operations, isn't necessarily an "evil" thing. (I would advise never to deinterlace for any other reason.)

However, I will agree that interlacing appears to be a bad thing since so many people screw up their video because they don't understand how to handle it properly. This forum is filled with hundreds of posts that perfectly illustrate this point.

As for your request, the answer will depend on what you are trying to do. If you are trying to put it on a DVD, there are some pretty nifty solutions that have been posted in this forum which involve creating some unique pulldown flags. I didn't even know such a thing existed until I "went to school" in this long thread:

How to de-interlace 25i coming from 8 mm film transfer (http://forum.doom9.org/showthread.php?p=1693022#post1693022)

Despite the heading, this person wanted to do something very similar to what you are doing. I linked to the post in that thread where I learned something I didn't know, namely that you can use something called DGPulldown (http://www.videohelp.com/software/DGPulldown) to accomplish this feat, without any re-encoding. The result will play on an NTSC DVD player. Some people don't like the solution because it is interlaced (see my comments above) and also because they don't like the effect of pulldown (repeated fields). However, having tried all the other alternatives to pulldown, and since I deal with film transfers every day of my life, it is my opinion that this gives you the best-looking, sharpest results, and without any problems that you get doing speed changes or de-interlacing using motion estimation, bobbing, etc.

[wonkey_monkey]

It works great, and has been in use for longer than most people on this planet have been alive. It is still used today

You could say the same about fossil fuels and snail mail ;)

Interlacing only "works great" because everyone was forced to come up with ways to handle it when we started to move away from CRTs.

you watch interlaced TV all the time, and it looks wonderful.

You watch a progressive reconstruction from an interlaced source, and it can look terrible if it isn't done right - and doing it right costs, computationally.

[johnmeyer]

I am certainly not going to get into a discussion about whether I'd rather have 60p as a standard rather than 60i. We are not supposed to talk about "better" in this forum, but I think I'm on safe ground saying that we'd all prefer 60p to 60i. However, as an engineer, I understand the fact that broadcast bandwidth, computing horsepower, computer memory, and many other constraints make interlaced video the best way to get a better picture than would otherwise be available to the customer, given these constraints.

It is true that most (but not all) viewing devices do create a "progressive reconstruction" (I like that term) for displaying the result, but I think most of the ones I've seen actually do a remarkably good job compared to 90% (or perhaps 99%) of the attempts to "do it yourself." There are clearly a few people in this forum who know how to do it right, but based on the video people send to me for restoration, I'd say that is the exception, and not the rule.

[feisty2]

Interlacing chroma subsampling color space other than CIE precision less than float
Should all go fuck themselves and be dead immediately

[colours]

There is absolutely nothing evil or wrong about interlacing. It works great, and has been in use for longer than most people on this planet have been alive. It is still used today, and you watch interlaced TV all the time, and it looks wonderful.

If it works great for you, cool. I hardly even watch TV, much less interlaced TV, but on the rare occasion I do switch on my television set, I'm greeted with Moiré and shimmer, thanks to interlacing.

My objection isn't so much to deinterlacing (which is a restorative step) as it is to interlacing (which is a destructive step). Without interlacing, deinterlacing wouldn't be necessary. I think I've read papers showing that interlacing doesn't actually save bandwidth when lossy compression is used, but I can't find a link and it's apparently very difficult to search for this because all I get are descriptions of H.264 instead, so maybe I'm misremembering.

Maybe I should conduct some tests of my own when I'm feeling less lazy.

Some people don't like the solution because it is interlaced (see my comments above) and also because they don't like the effect of pulldown (repeated fields). However, having tried all the other alternatives to pulldown, and since I deal with film transfers every day of my life, it is my opinion that this gives you the best-looking, sharpest results, and without any problems that you get doing speed changes or de-interlacing using motion estimation, bobbing, etc.

I dislike this not because it's interlaced or because it's pulldown; I dislike this because it's unnecessary munging of the video. Maybe use something a bit less ancient than DVDs, like H.264 in Matroska with literally any frame rate you want, and you don't even have to do any destructive operation to your video (other than the lossy compression). Otoh, if you do need it to be a DVD for whatever reason, I second johnmeyer's suggestion.

feisty2: Don't cut yourself on that edge, bud.

[feisty2]

@johnmeyer
1080p30 looks definitely way better than 1080i60
So yeah, interlacing is an evil b**ch

[poisondeathray]

1080p30 looks definitely way better than 1080i60
So yeah, interlacing is an evil b**ch

Depends on what the content is

I'd rather watch 1080i60 for sports like hockey, football, UFC etc... than 1080p30

[kuchikirukia]

@johnmeyer
1080p30 looks definitely way better than 1080i60
So yeah, interlacing is an evil b**ch

Get with the times, grandpa. Miku hasn't been projected at under 60fps in years. There's a reason for that. 30fps just doesn't work in a 60fps world:
https://www.youtube.com/watch?v=4CEcEJxPDsk

60fps is how it should be
https://www.youtube.com/watch?v=4VP1YPL4VWc

[feisty2]

Get with the times, grandpa. Miku hasn't been projected at under 60fps in years. There's a reason for that. 30fps just doesn't work in a 60fps world:
https://www.youtube.com/watch?v=4CEcEJxPDsk

60fps is how it should be
https://www.youtube.com/watch?v=4VP1YPL4VWc

60p is better than 30p, fact
And I'm talking about 60i and 30p
Not 60p and 30p
Great grandma

[kuchikirukia]

60p is better than 30p, fact
And I'm talking about 60i and 30p
Not 60p and 30p
Great grandma

How do you think those went out in 60fps? Bluray doesn't do 60p.

[feisty2]

1. Motion flowed to 60p
2. Native 60p, what bluray supports != the only thing a camera can do

[kuchikirukia]

1. Motion flowed to 60p
2. Native 60p, what bluray supports != the only thing a camera can do

They're 60i Blurays.
Mikupa Tokyo and Sapporo 2011 were released in 1080p30. Totally ruined them.

[Sharc]

@johnmeyer
1080p30 looks definitely way better than 1080i60
So yeah, interlacing is an evil b**ch
Nope. Not in general. I recall the many (blind) tests and debates during the introduction of digital broadcast TV on this subject.

[feisty2]

If it was shot at 60i, then yeah, it destroyed the vid, I'm talking about NATIVE 30p, not bullshit deinterlaced from 60i

[Sparktank]

Ultra HD Blu-ray will support (up to) 60p.
James Cameron will love that when he films the next Avatars in >48fps.

[kuchikirukia]

I'm talking about NATIVE 30p, not bullshit deinterlaced from 60i

60i > native 30p. You can interpolate 60i's missing fields much better than you can 30p's missing frames.

[Sharc]

The battle for digital broadcast TV was actually between 1080i or 720p. No clear winner.

[feisty2]

Better my ass
Even 4k doesn't actually hit the limit of human vision of spatial resolution, and 1920x540??? You gotta be kidding me
And yet 24fps already looks kinda smooth to human eyes

[kuchikirukia]

30fps doesn't come close to the limit of human visual temporal resolution.
540 lines spaced 1 pixel apart and with two references just 16.6ms on either side can be interpolated to 1080p60 better than a 1080 line frame with nothing on either side within 33ms. We can bridge a pixel. Things tend to get lost across 33ms, though.

[feisty2]

Yeah, and movies are 24fps PROGRESSIVE, cuz 48i is just way too fancy for movies

[feisty2]

How about we take one line out of 4 lines and make it 120fps?

[Sharc]

30fps doesn't come close to the limit of human visual temporal resolution.

Absolutely. The "remedy" was controlled motion blur .....

[DarkSpace]

This seems to have devolved into a thread about how evil interlacing is when the source is progressive. While I agree about that, in general, this is only on the assumption that you have a choice between e.g. 60i and 60p. Once it comes down to 60i vs 30p, I have no clear opinion on the topic (I'd need to either read some papers on it, or conduct some tests myself), because in that case, you actually lose something in either case (spacial resolution for 60i, temporal resolution for 30p) while in 60i vs 60p you only lose in the case of 60i (spacial resolution).
About BD not supporting 60p: I have no sources on this at the moment, but I think I've read that BD does support 60p video, but only 720p60, not 1080p60. I may be wrong here, though, but 720p60 vs 1080i60 is something where I can easily imagine preferring the 720p version.

Anyway, you're all missing the most important part: johnmeyer suggested using pulldown flags on the final encode (which may well already be the source file). This means that the discussion about how the evils of interlacing is actually rather meaningless, because when using pulldown flags, what's encoded is a progressive video at a certain framerate, and the flags (which may, of course, be ignored if the player wishes to do so) only tell the player how to output the video in a framerate (fieldrate?) that is compliant with the playback medium's spec (e.g. 60i for DVD). And that, in my opinion, is a very good and very sensible suggestion, because it makes the video compliant to the DVD spec while still keeping it in its original progressive framerate. So there's no destruction going on at all. And restoration to its original form is also simple - just ignore the pulldown flags.

Edit: If you're using x264 for encoding (e.g. because your target is not DVD, but BD, and you want to convert 25p to 60000/1000i (as opposed to 60000/1001i), you can also use --pulldown euro, I believe. That should set the flags properly for this case. (I may be wrong, or misremembering things, though. Check this before doing it, lest you waste a lot of time!)

[Music Fan]

I've been told that there is a pro solution which does 25p to 60i conversion over 13 steps cadence.
I assume this is can be done with avisynth as swell?
You can make interpolation to get 60p then interlace to get 60i (actually 30i, see below why*) with a script like this ;
source(25p...)
assumefps(25)
InterFrame(NewNum=60000, NewDen=1001, cores=2)#to get 59,94... fps
assumeTFF()#or ComplementParity()
separatefields()
selectevery(4,0,3)
weave()#29,97i (also called 30i and 60i)


* The term 60i is a nonsense widely spread, 30i (or 29,97i) should be used instead because the number should always refer to the framerate and not the fieldrate to avoid confusion, then the i or p is enough to tell if it's interlaced or progressive.


About 60p in 1080p : it's not officially supported by BD but I've read on another forum that a guy made a 1080p60 (or 1080p50) BD with Pinnacle Studio 17 and read it successfully on a Sony BDP-S4200.
But there is another solution that will work with more Blu-ray players : AVCHD, because AVCHD supports 50p and 60p in 1080p since 2011 (AVCHD 2.0) ;
http://en.wikipedia.org/wiki/AVCHD
https://en.wikipedia.org/wiki/AVCHD#Specification_addendum_.28AVCHD_2.0.29
I tested it successfully on 2 players (h264 @ 28 Mbps in 1080p50 burnt with ImgBurn on dvd+rw in AVCHD format created with TSMuxer).

[colours]

* The term 60i is a nonsense widely spread, 30i (or 29,97i) should be used instead because the number should always refer to the framerate and not the fieldrate to avoid confusion, then the i or p is enough to tell if it's interlaced or progressive.

I take it that you're into prescriptive linguistics, which unfortunately (or fortunately!) isn't how English works. In my opinion, "60i" is more appropriate a description when there are 60 temporally distinct pictures than "30i", convention be damned. I'd spell out "30 frames/s" or "60 fields/s" if there was any risk of confusion, though.

[kolak]

It's not about liking interlaced or not, but be able to deliver "NTSC" friendly masters from 25p sources.

I don't like interlaced at all, but try to create high quality 23.976p, 29.97p master from 25p source (without speed change!) with motion adaptive technique. Not a single solution can do it at acceptable level for a random source, that why people use 60i.
There is a huge need for it in a real world! It's for broadcast, which is crap quality anyway. The problem is that motion adaptive artefacts are visible, where a bit jerky video is more acceptable.

[kolak]

You can make interpolation to get 60p then interlace to get 60i (actually 30i, see below why*) with a script like this ;
source(25p...)
assumefps(25)
InterFrame(NewNum=60000, NewDen=1001, cores=2)#to get 59,94... fps
assumeTFF()#or ComplementParity()
separatefields()
selectevery(4,0,3)
weave()#29,97i (also called 30i and 60i)


* The term 60i is a nonsense widely spread, 30i (or 29,97i) should be used instead because the number should always refer to the framerate and not the fieldrate to avoid confusion, then the i or p is enough to tell if it's interlaced or progressive.


About 60p in 1080p : it's not officially supported by BD but I've read on another forum that a guy made a 1080p60 (or 1080p50) BD with Pinnacle Studio 17 and read it successfully on a Sony BDP-S4200.
But there is another solution that will work with more Blu-ray players : AVCHD, because AVCHD supports 50p and 60p in 1080p since 2011 (AVCHD 2.0) ;
http://en.wikipedia.org/wiki/AVCHD
https://en.wikipedia.org/wiki/AVCHD#Specification_addendum_.28AVCHD_2.0.29
I tested it successfully on 2 players (h264 @ 28 Mbps in 1080p50 burnt with ImgBurn on dvd+rw in AVCHD format created with TSMuxer).

I know about interframe, but it's way not good enough for 25p source. 50i or "better" in terms of motion source is ok, but anything <30p is far from being solid.
Everyone here knows what 60i is- it's quicker to type :)

I'm after a pattern which will do 25p to 60i by 13 steps (used in pro solutions) cadence. Because 25p already has a "limited" motion apparently using this technique doesn't really make it much worse after conversion.

[kolak]

I take it that you're into prescriptive linguistics, which unfortunately (or fortunately!) isn't how English works. In my opinion, "60i" is more appropriate a description when there are 60 temporally distinct pictures than "30i", convention be damned. I'd spell out "30 frames/s" or "60 fields/s" if there was any risk of confusion, though.

I agree with this, but try to convince BBC guys:) They use i29.97, which is is apparently the correct way.

[kolak]

Anything involving interlacing is evil and you should not use interlacing ever. That said:

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

As I said- way not good enough for a random source. To many motion adaptive artefacts! I've used interframe a lot, but only for 50i+ sources in terms of motion.

I need irregular pulldown- apparently something with 13 steps.
Would file with frame count converted this way help?

update: sorry I saw interframe word here :) Yes, something like this. I this the best what can be done?

[colours]

As I said- way not good enough for a random source. To many motion adaptive artefacts! I've used interframe a lot, but only for 50i+ sources in terms of motion.

I need irregular pulldown- apparently something with 13 steps.
Would file with frame count converted this way help?

The only Google search result for "13 steps cadence" is just this thread, so I'm not entirely sure what exactly you mean, but if you meant 3:2:2:2:2:2:2:2:2:2:2:2:2, that's for converting 24p to 50i, not for converting 25p to 60i.

The pattern for 25p to 60i pulldown is 3:2:3:2:2, which is what the script does. For 60000/1001 fields/s output, you can either convert to 60 fields/s first then slow it down by a factor of 1.001 (watch out for audio desync, etc.), or just convert to 60000/1001i directly.

[Music Fan]

I know about interframe, but it's way not good enough for 25p source.
What did you expect ? Of course there are artifacts with interpolation, but how do you hope to transform 25p in "60i" without interpolation or duplication and without creating artifacts ?

[Music Fan]

I take it that you're into prescriptive linguistics, which unfortunately (or fortunately!) isn't how English works. In my opinion, "60i" is more appropriate a description when there are 60 temporally distinct pictures than "30i", convention be damned. I'd spell out "30 frames/s" or "60 fields/s" if there was any risk of confusion, though.
I understand that the word frame can have a larger signification and may refer to the number of instants captured by a camera, which are thus fields in the case of cameras making only interlaced videos.
But in the video encoding world, it's confusing ; all videos have a framerate, and as its name stands for, framerate is about the number of frames (which include top and bottom fields), not the number of fields (I mean for Avisynth, Virtual Dub, MediaInfo and all tools that display the framerate).
If it contains interlaced material, just type 30i, there is nothing more shorter and easy to type than this when speaking about a video containing 30 frames with 60 fields (I mean with the fluidity of interlaced videos, because we can of course also separate the fields of progressive videos).
I don't find good reason to speak in framerate about progressive videos and in fieldrate about interlaced videos, especially when calling it framerate in both cases.
60i is kind of pleonastic.

[kolak]

What did you expect ? Of course there are artifacts with interpolation, but how do you hope to transform 25p in "60i" without interpolation or duplication and without creating artifacts ?

Duplication is different than artefact. Duplication only affects motion, it doesn't break frame itself. It's about minimising visible artefacts. Interframe and other solutions create way to many for low fps sources at the moment, so not very usable in this case. You may find some 25p source which convert quite well, but we're talking about 'universal' conversion.

The only way is to play with pulldown- make it as smooth as possible.

[kolak]

The only Google search result for "13 steps cadence" is just this thread, so I'm not entirely sure what exactly you mean, but if you meant 3:2:2:2:2:2:2:2:2:2:2:2:2, that's for converting 24p to 50i, not for converting 25p to 60i.



No, I need 25p to 60i to be as smooth as possible.

What about this one:

https://www.wetransfer.com/downloads/fc4c9d2a717a185953ad4aac2baa04e920150922130743/6dad346b3cec211e6557bca0d0bc8e2820150922130743/cd3e12

Is this not 3:2:3:2:2?

[Music Fan]

Duplication is different than artefact. Duplication only affects motion, it doesn't break frame itself. It's about minimising visible artefacts. Interframe and other solutions create way to many for low fps sources at the moment, so not very usable in this case. You may find some 25p source which convert quite well, but we're talking about 'universal' conversion.

The only way is to play with pulldown- make it as smooth as possible.
Ok, but I believed you wanted to avoid duplication too.
So actually you want to find a good duplication pattern.
I don't believe in miracle, if the new framerate is not a multiple of the original framerate, you will see judder (I mean with duplication).

[kolak]

I know, but this is better than all motion artefacts.
Question is: can it be done in many ways or just 3:2:3:2:2 (I think this is what I have been told as 13 step cadence)?

[kolak]

Anything involving interlacing is evil and you should not use interlacing ever. That said:

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

This will cause problems on some scene changes, no?

Is there a way to avoid it?

[Music Fan]

Question is: can it be done in many ways or just 3:2:3:2:2 (I think this is what I have been told as 13 step cadence)?
You could maybe try to double one frame all 5 frames (and you will get 30p that you can interlace), but I'm not sure it will be better than what you propose, this could even be worse.

[Sharc]

@kolak
You may want to check out this:
http://rationalqm.us/dgpulldown/dgpulldown.html

The 13 step cadence has been discussed somewhere along this thread:
http://forum.doom9.org/showthread.php?s=&threadid=88031

which finally lead to the development of the DGpulldown tool.

[kolak]

This unknown 13 step cadence is 2:2:3:2:3, so nothing fancy.

[kolak]

@kolak
You may want to check out this:
http://rationalqm.us/dgpulldown/dgpulldown.html

The 13 step cadence has been discussed somewhere along this thread:
http://forum.doom9.org/showthread.php?s=&threadid=88031

which finally lead to the development of the DGpulldown tool.

Thanks, yes I figure it out.
My last question is about scene changes- can it create bad scene cuts?

[Sharc]

Thanks, yes I figure it out.
My last question is about scene changes- can it create bad scene cuts?
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?)

[kolak]

Yes, this can cause problems when watched don TV with flashes on scene changes (or not). This is my remaining question.

[Sharc]

Perhaps you can get more help when you post in Donald Graft's (DG...) forum:
http://rationalqm.us/board/index.php

[johnmeyer]

Better my ass
Even 4k doesn't actually hit the limit of human vision of spatial resolution, and 1920x540??? You gotta be kidding me
And yet 24fps already looks kinda smooth to human eyesThere is a lot of strong opinion, and coarse language being voiced, but not a lot of factual information.

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.

As for 4K not hitting the limit of human visual resolution, that is a perfect example of the narrow filter being used to make such statements. It completely fails to take into account the most important element in any discussion of resolution, which of course is screen size. I spent a decade in the desktop publishing revolution, and in the print world, resolution is usually expressed in dots per inch or lines per inch, not in terms of total pixel count. When talking about video, DPI is seldom used, but for this discussion it is a more important measure than pixel count.

Why?

Well, as an obvious and irrefutable example, 4K video on a hand-held device will be indistinguishable from even 720p because the human eye cannot see the difference when all those dots are crammed together in a small space. This continues to be true even as you go to larger displays like small (13 "- 19") TV sets and computer displays. However, when you get to the lower end of current "big screen" TVs, let's say 55" diagonal size, you begin to see differences, but they are subtle. As you watch on displays larger than that, most people will begin to see the differences.

So, when the discussion is about 4K vs. 1920x1080 (interlaced or progressive), the spatial differences don't really become apparent or important, until you get to pretty big displays, and therefore 4K really is not important -- and never will be important -- unless the customer is watching on a really large display.

We've had this discussion over at the Sony forum, and the general consensus there is that, for display in the home, 4K is not going to be a big deal, but that it is a fantastic acquisition format, and that it is also a major innovation for theatrical projection. Having been to many 4K demonstrations, I completely agree: on small screens, it is not compelling, and in fact, no one tell the difference. We can debate at what screen size the difference becomes important, but I don't have any good, objective measure to offer to help define that. My general sense is that under ideal conditions, you can begin to see a difference at around 45" displays, but for most people (and that is key when talking about market size and commercial viability), the difference won't be important until you get to much larger displays.

Oh yes, seating distance from the display is also important.

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.

I really do not understand the hostile tone in so many of these posts. We have some great choices in how we acquire our own video, and 60p 1920x1080 is easily available to everyone, so if you don't like some of the other standards, you don't ever have to deal with them. You can also easily get 4K camcorders. Use those and be happy.

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.

[johnmeyer]

No, I need 25p to 60i to be as smooth as possible.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.

[Music Fan]

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.
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=153035

[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).

[huhn]

That's not so far from 2,1,1,1,1 (25p to 30p).

that's why it should be 3:2:3:2:2 and that is used in broadcast.

but i high recommend using 720p60 for it...

which is by the way part of the BD spec too.

frame bending is an option too works great in madVR.

[TheSkiller]

While quite uncommon when speaking of digitally edited videos without pulldown, scene changes in interlaced video may occur in the same frame without any problems whatsoever.

When applying pulldown for 29.97i output this is simply going to happen. It happens with traditional 3:2 pulldown all the time as well.

[kolak]

Is it going happen or not is not the problem, but will it create issues when watched on TV over proper interlaced chain. I can't reproduce any problems.
These sort of files are rather for last stage (watching) not editing etc.

[huhn]

older digital TVs deinterlaced 60i with 24 hz contest to 60p there was no IVTC.

so with other words the TV doesn't really care if it is 2:2, 3:2, 3:2:3:2:2 or true interlaced. if it doesn't know what to do it will blob and everything is "ok".

the 3:2 judder was totally normal in the past a 3:2:3:2:2 judder no real difference.

[Sharc]

For old infrastructure playback scenarios which may not handle IVTC or pulldown properly, Music Fans proposal should produce better results as opposed to bobbing fallback scenarios. It's a pretty robust approach I think. For compliance reasons the 30fps should be slowed down to 29.97 at the end (assumefps(29.97)).

Edit:
Does Changefps(59.94) as opposed to Changefps(60) break the cyclic 3:2:3:2:2 pattern every 1000 frames? Could this cause playback issues? In other words, is it safer to go with Changefps(60) and add the slowdown with Assumefps(29.97) in the script?
(I know audio and sup sync is a different subject when one changes the playback duration).

[Sharc]

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.

It depends on how it is played back.
- When IVTC is applied to the 3:2:3:2:2 pattern, playback will be at 30 (29.97) fps with 1 duplicated frame out of 6. So both methods produce the same judder (long frame = 2*short frame duration, happening once every 200ms)
- When bobbing is applied to the 3:2:3:2:2 pattern the judder amplitude is lower (long frame = 1.5 * short frame, but the change happens 3 times within 200ms), which I feel is smoother to watch.
But I agree that both methods (your 30p and the 60p re-interlaced) produce acceptable results.

[vivan]

It depends on how it is played back.
- When IVTC is applied to the 3:2:3:2:2 pattern, playback will be at 30 (29.97) fps with 1 duplicated frame out of 6. So both methods produce the same judder (long frame = 2*short frame duration, happening once every 200ms)IVTC is field matching + decimation. The latter should restore nominal framerate. At least it does in madVR.

[huhn]

3:2:3:2:2 in 720p60 is possible too there is no bob needed at playback.

an 30p encode doesn't stand a chance in term of smoothness.

after creating the 3:2:3:2:2 pattern (with interlacing or without) you should only use assumefps(60000, 1001)

never use 29.97 or 23.976 they are both wrong.

[Sharc]

after creating the 3:2:3:2:2 pattern (with interlacing or without) you should only use assumefps(60000, 1001)

never use 29.97 or 23.976 they are both wrong.
When the 3:2:3:2:2 pattern are fields at 60 fields per second, weaved (re-interlaced) to frames of 30 frames per second, shouldn't these frames be frame-served to the player or encoder with assumefps(30000,1001)?

[huhn]

When the 3:2:3:2:2 pattern are fields at 60 fields per second, weaved (re-interlaced) to frames of 30 frames per second, shouldn't these frames be frame-served to the player or encoder with assumefps(30000,1001)?

yes of course sorry.

the encoder should get 30000/1001 weave FPS

[luquinhas0021]

Kolak, I assume that you convert 25p to 30p, before convert to 60i. Am I right about your proceedment?

[huhn]

it's pointless to convert 30p to 60i that's PsF so a simple fake interlaced flag for the encoder is all that's needed for this.

[Sharc]

Kolak, I assume that you convert 25p to 30p, before convert to 60i. Am I right about your proceedment?

See the script proposals of Colour and Music Fan further up in this thread.

[Sharc]

it's pointless to convert 30p to 60i that's PsF so a simple fake interlaced flag for the encoder is all that's needed for this.
Hmmm...AFAIK he wants NTSC DVD compliant final format which is always encoded field-interlaced, even for progressive footage (means both fields may originate from the same picture or same point in time). The term "Fake-interlaced" has been introduced for BD / x264 encodes only; I doubt that it exists the same in DVD world (?).

[kolak]

It does- there are tons of 25p DVDs encoded as 50i.

[Sharc]

It does- there are tons of 25p DVDs encoded as 50i.
I know, but I thought these are encoded as interlaced (scan is different), not just flagged to be interlaced; but I may be wrong. Long time since I dealt with DVD encoding....

[kolak]

Masters are 25p, not interlaced.

[Sharc]

Yes, but how is it encoded for DVD?
- split in 2 (temporal equal) fields of half hight each (even/odd scanlines)
- interlace (weave) => 25 interlaced frames per second = 50 fields per second (sometimes called 50i, i50, i25 .... whatever)
No?
or is it put on DVD as progressive frames, and just flagged as interlaced (for the TV)?

Sorry for going out of topic ....

[kolak]

25p jus flagged as interlaced.

[Sharc]

Thanks.

[wonkey_monkey]

It does- there are tons of 25p DVDs encoded as 50i.

Aren't they all encoded as 50i?

Or is that just Blu-ray, where 25p isn't even in the spec?

[johnmeyer]

Does 25p encoded as 50i actually produce a different effect on the screen than would that same content encoded and played at 25p? Since there is no temporal difference between the two fields in a 50i encode that originates from 25p material, part of me thinks that the person viewing the screen would not be able to tell the difference.

[huhn]

Does 25p encoded as 50i actually produce a different effect on the screen than would that same content encoded and played at 25p? Since there is no temporal difference between the two fields in a 50i encode that originates from 25p material, part of me thinks that the person viewing the screen would not be able to tell the difference.

in worst case scenario it is bob deinteralced and this is visible.

nearly all TV have some kind of field matching and will notice that the fields match and it will look the same.

BD and DVD doesn't support 25p only 50i.

you can just treated a 25p/30p stream as interlaced and nothing will happen with it it's just deintelaced and the result from a pretty normal deinterlacer is 50p with 2:2

[wonkey_monkey]

nearly all TV have some kind of field matching and will notice that the fields match and it will look the same.


Chroma is also encoded (not in the sense of video compression; what's the word I really mean?!) slightly differently for interlaced video, though you wouldn't be able to tell unless you look really closely.

[kolak]

Aren't they all encoded as 50i?

Or is that just Blu-ray, where 25p isn't even in the spec?

Yes and same for DVD and BD due to lack of 25p support in the spec.

If payer/TV is good enough than you get back original 25p, in other cases it may be treated by player/TV as 50i, which is of course not the best, but not the end of the world neither.

[Music Fan]

Chroma is also encoded (...) slightly differently for interlaced video
Could you develop this point please ?

[kolak]

Chroma placement for progressive and interlaced is different, but I never saw this be a problem when watched even on big TV (maybe it actually gets "corrected" by TV filtering system).

Maybe encoders knowing that source is progressive already "correct" it, eg. when x264 encodes as fake interlaced.

[Sharc]

Aren't they all encoded as 50i?
That's what I thought as well, but kolak wrote that they are encoded as 25p and just flagged as interlaced.

[kolak]

It depends on the master. If master is originally interlaced than it's encoded as interlaced, but many movies etc are shot at 25p (or 24p and speed up, which also happens in Europe) and these are encoded as fake interlaced.
For the Blu-ray is similar thought I always use to ask for 24p masters. When possible I use to speed up/slow down extras to match main movie fps, so such a disc causes less TV switching, which sometimes is slow and annoying.

[Sharc]

Going back to my earlier question:
Does changefps(60000,1001) applied on a 25p source break the 3:2:3:2:2 pattern? If so, does it cause playback issues say every 1000 frames?

[Music Fan]

It depends on how it is played back.
- When IVTC is applied to the 3:2:3:2:2 pattern, playback will be at 30 (29.97) fps with 1 duplicated frame out of 6. So both methods produce the same judder (long frame = 2*short frame duration, happening once every 200ms)
- When bobbing is applied to the 3:2:3:2:2 pattern the judder amplitude is lower (long frame = 1.5 * short frame, but the change happens 3 times within 200ms), which I feel is smoother to watch.
Interesting, it probably depends on players.

There is another solution quickly mentioned on 1st or 2nd page : DGPulldown (if the encoding is for dvd).
I believe it allows to encode 25p and play it at 29.97 fps without speed change, thanks to a flag.
The main advantage is that the bitrate is higher by frame (compared to 30p or 60i), because there are less frames to encode by second (the maximal bitrate allowed on dvd is always the same, whatever the framerate).
Other advantage : the encoding is simpler, there is nothing to do with Avisynth about framerate.

[kolak]

Yes, but as I said- this is mainly for broadcast transmission.

Saying this- they could do this on the headers level themselves during last stage before transmission :)

[Sharc]

DGPulldown is found here:
http://rationalqm.us/dgpulldown/dgpulldown.html

As I understand it uses soft-pulldown based on flags and timecode, as opposed to hard-pulldown produced by changefps().
DGPulldown hence preserves the original video.

[kolak]

Yes, but this is strictly for mpeg2. What if I need to deliver AVC-I (which is now becoming new standard) file as master or HDCAM tape ? :)

[Sharc]

Right, for mpeg-2 only. But I thought from your original post that's what you need.

[Sharc]

Interesting, it probably depends on players.

There is another solution quickly mentioned on 1st or 2nd page : DGPulldown (if the encoding is for dvd).
I believe it allows to encode 25p and play it at 29.97 fps without speed change, thanks to a flag.
The main advantage is that the bitrate is higher by frame (compared to 30p or 60i), because there are less frames to encode by second (the maximal bitrate allowed on dvd is always the same, whatever the framerate).
Other advantage : the encoding is simpler, there is nothing to do with Avisynth about framerate.
I should add that correct IVTC will include decimation, as mentioned by vivian. Means playback will be restored at the original rate, means no duplicated frames = no judder.

[Music Fan]

I should add that correct IVTC will include decimation, as mentioned by vivian. Means playback will be restored at the original rate, means no duplicated frames = no judder.
This also means a Ntsc dvd would be displayed in 50 hz, that's strange.
The DGpulldown trick allows to encode in 25p with the mpeg-2 encoder, but as the framerate for the player is 29.97 fps (thanks to DGpulldown's flag), the resolution has to be 720*480, not 720*576.
But it's maybe possible if player's resolution is set on 1080p. Because if it's set on 480p, I don't believe the player will be able to send 480p with a 25p (or 50p actually) framerate.


edit : actually I believe that the mpeg-2 encoder needs the final framerate (29.97 in this case), thus it has to be fed with 720*480 @ 29.97 fps, not 25 (unless the encoder accepts to encode 720*480 @ 25 fps). But don't use changefps() in avs script to convert 25p in 29.97, use assumefps(30000, 1001), but not for the sound which will keep its 25p speed.
DGpulldown's flag will change it (as if assumefps(25) was done) and will add the 29.97 fps flag.
It also means the encoding bitrate can be higher than 10 Mbps because of the slowdown made by DGpulldown : 11,5 Mbps @ 29.97 fps means 9,59 Mbps when slowed down @ 25 fps.

[Music Fan]

Going back to my earlier question:
Does changefps(60000,1001) applied on a 25p source break the 3:2:3:2:2 pattern? If so, does it cause playback issues say every 1000 frames?
I would say yes, but make a test and look around the 1000th frame and compare with changefps(60) to be sure.

[Sharc]

I would say yes, but make a test and look around the 1000th frame and compare with changefps(60) to be sure.

ChangeFPS(60000,1001) breaks the cyclic pattern of the fields, like
...3:2:3:2:2:3:2:3:2:2:3:2:2:3:2:3:2:2:3:2:3:2:2......

or in case of ChangeFPS(30000,1001) the frame pattern becomes
....2:1:1:1:1:2:1:1:1:1:1:2:1:1:1:1:2:1:1:1:1 .....

I don't know if and how these hickups affect the playback, I didn't test on player + TV.

It is definitely better to do the pulldown with ChangeFPS(60) or ChangeFPS(30) respectively, and add the slight slowdown AssumeFPS(...) for standards compliance at the end of the script. But kolak wrote that he does not want any speed change, if I remember correctly.

[manono]

This also means a Ntsc dvd would be displayed in 50 hz...
No it doesn't. It'll be output by the DVD player at 59.94 fields per second, just like any other NTSC DVD.
I don't believe the player will be able to send 480p with a 25p (or 50p actually) framerate.
It doesn't. It sends 59.94 fields per second, just as any other NTSC DVD.
actually I believe that the mpeg-2 encoder needs the final framerate (29.97 in this case), thus it has to be fed with 720*480 @ 29.97 fps,
No, it can encode at a number of progressive framerates, including 25fps. I've encoded 720x480@25fps many times. And even if your own MPEG-2 encoder doesn't allow it for one reason or another, you can make it come out alright in the end by a proper use of DGPulldown.
It also means the encoding bitrate can be higher than 10 Mbps
If you encode at 25fps, you use the 'normal' bitrate settings. Yes, if you encode at some other framerate with the intent of changing it afterwards when using DGPulldown then, yes, you can 'adjust' the bitrates. For example, if you want to encode as progressive a silent film at 19.98fps, you can't because 19.98 isn't allowed by an MPEG-2 encoder. You encode at 23.976fps and adjust all the bitrates upwards by 20% (23.976/19.98=1.2). Then when done get the framerate correct again by applying DGPulldown set for 19.98->29.97. I don't know why, though, you'd want to encode a 25fps source at 29.97fps when you can just as easily encode for 25fps, at least when using the MPEG-2 encoders with which I'm familiar (CCE and HCEnc).

[TheSkiller]

Yes and same for DVD and BD due to lack of 25p support in the spec.BD and DVD doesn't support 25p only 50i.I disagree. BD does indeed not support 25p at all, but DVD does. I'm not talking about encoding 25p interlaced.
You can use Zig-Zag scan for the actual encoding, progressive chroma sampling and have both the "Frametype progressive" and "Progressive sequence" flag set to true, as well as the "Film" flag in the IFOs, and still have a compliant DVD. A hardware player will recognize this and won't even try to deinterlace anything, which it would if the video was encoded interlaced, because the player would expect interlaced video then.

I'm not talking theoretically here, I have authored dozens of 25p DVDs in exactly this manner over the years, they all playback fine in old and new players, cheap and expensive ones.


Does 25p encoded as 50i actually produce a different effect on the screen than would that same content encoded and played at 25p?Yes, if encoded interlaced the player, of course, expects interlaced video and will try to deinterlace it. This will hurt the video quality more or less, how much depends on the deinterlacer and field matcher, as noted by huhn.in worst case scenario it is bob deinteralced and this is visible.


Chroma is also encoded (not in the sense of video compression; what's the word I really mean?!) slightly differently for interlaced videoI think the term you were looking for is "sampling".

Speaking of it, this is a "gotcha": if you are encoding 25p interlaced but with progressive chroma sampling, you are risking the infamous CUE (chroma upsampling error), because the progressive sampled chroma may be upsampled by the player as if it were interlaced (also depends on how exactly the player handles the upsampling, so it may not happen).
If you're encoding 25p progressive this won't happen.

This means: if you are encoding 25p interlaced you must use interlaced chroma sampling to completely avoid the CUE on all players!

[kolak]

If I remember well Cinemacraft encoders don't set Progressive sequence (you can set Frame type progressive=1), because there is no real 25p support in DVD spec. Progressive sequence=1 means whole file is purely progressive.
Having just Frame type progressive=1 indicates file which may be progressive, but possibly there are also interlaced frames in the file, so overall whole file is treated as interlaced. This is how most "25p" retail DVDs are flagged, which I think is the correct way (per spec).

I've seen only 1 or 2 DVDs with Progressive sequence=1.

Words of Jim Taylor (DVD guru):

In MPEG-2 encoding, the decision between progressive and interlaced format can be made all
the way down at the macroblock level.The DVD-Video specification limits MPEG-2 video to nonprogressive
sequences, which can include both progressive and interlaced frames.
Progressive frames are still encoded for display as two fields, but they are identified as progressive.
Interlaced frames can further include both progressive and interlaced macroblocks. Since progressive
macroblocks are more efficient (using one motion vector instead of two), even interlaced source
is often encoded with more than 50 percent progressive macroblocks. However, each frame is represented
as two fields of 720 x 240 pixels each for NTSC or 720 x 288 pixels each for PAL/SECAM.

Different source:

https://books.google.co.uk/books?id=Pa7pAwAAQBAJ&pg=PA399&lpg=PA399&dq=Progressive+sequence+for+dvd&source=bl&ots=IdUDgvNNcu&sig=ERs0ZqqLH5m-NHdItwONjeAGQqM&hl=en&sa=X&ved=0CEEQ6AEwA2oVChMInPjT0oOSyAIVI6HbCh14nQ_d#v=onepage&q=Progressive%20sequence%20for%20dvd&f=false

by well known here Ben Waggoner

Which is in line with Cinemacraft encoders behaviour (they are probably the most DVD compliant on the planet).
I think you can still use Progressive sequence=1 ( I've also done it) and have proper playback on most players anyway, but it's against DVD spec.


There may be also possibility that this "subject" is not covered in DVD spec for 25p based sources, but mentioned resources say quite clearly that DVD is limited to nonprogressive sequences.

As I side note: there are many "bad" discs which for 23.976p+pulldown use GOP>12 (should be 12 or less) , which is out of DVD spec (GOP<0.606 sec) and this can cause real playback issues on some players.

[Music Fan]

No it doesn't. It'll be output by the DVD player at 59.94 fields per second, just like any other NTSC DVD.
Does it mean Sharc was wrong ?

I should add that correct IVTC will include decimation, as mentioned by vivian. Means playback will be restored at the original rate, means no duplicated frames = no judder.


I don't know why, though, you'd want to encode a 25fps source at 29.97fps when you can just as easily encode for 25fps
That's what the OP needs.

[kolak]

I don't really want to encode 25p as 29.97p for DVD, as someone mentioned (but answer would be- for eg. USA market).
I need conversion on the master level. I never said in original post anything about DVD or other delivery method (until later).

We're very out of topic now :)

It's for broadcast, so it will be hard coded and probably never restored to original fps, just played as 60i.
As I mentioned- my last worry are potential flashes on scene changes when watched through proper interlaced chain on a TV.

[Sharc]

.... We're very out of topic now :)
Nice refresher and tutorial, though. :)

[TheSkiller]

As I mentioned- my last worry are potential flashes on scene changes when watched through proper interlaced chain on a TV.I don't understand what you mean by flashes.

When you pulldown 25p to 29.97i for broadcast, the TV will bob-deinterlace to 59.94p (unless maybe it detects the cadence, but 25p-in-29.97i is so uncommon it'll probably end up being bob-deinterlaced).

[kolak]

When scene change happens on bottom field (which in case of 'normal' interlaced file never happens).

[TheSkiller]

So basically you mean comb artefacts at the scene change, as if the frame is weaved (not deinterlaced at all)?
Shouldn't happen, and if it does it's the TV's deinterlacer failing.

If you connect any home made analog tape format to a TV there will be plenty of scene changes that occur within the same frame (about 50% actually). Plus, every field blended NTSC<->PAL normconversion (so LOADS) has plenty of scene changes at bottom fields (for a TFF video). I have never witnessed a problem with that, except maybe that it's harder for the encoder to detect it as a scene change.

[huhn]

if you need it for broadcast you need both 720p60 and 1080i60.

so for 720p 3:2:3:2:2 frame cadence should clearly win alternative is frame blending...

[colours]

Speaking of it, this is a "gotcha": if you are encoding 25p interlaced but with progressive chroma sampling, you are risking the infamous CUE (chroma upsampling error), because the progressive sampled chroma may be upsampled by the player as if it were interlaced (also depends on how exactly the player handles the upsampling, so it may not happen).
If you're encoding 25p progressive this won't happen.

Using interlaced chroma sampling is exactly the same as not doing anything special to the chroma, unless we're talking about one of those formats with oddball interlaced chroma sampling. (DV is one of them, I think?) If potential chroma aliasing from bad deinterlacing is a concern, you could always low-pass the chroma vertically first.

(Also, I just did a search on CUE and the first few results were from like 2001. How is this still a concern in 2015?)

[manono]

Does it mean Sharc was wrong ?

To tell you the truth, I was puzzled by that, too, and figured he was referencing something earlier in the thread and I didn't feel like going back through the whole thing to figure it out. I also figured he was speaking of something else and we're not contradicting each other. In any event, any 60 (59.94) Hz display will have to output the video at either 59.94 fields per second or 59.94 frames per second. That's what pulldown, either hard or soft, is all about.

[Music Fan]

Thus it means players can't make IVTC with decimation with this kind of video.
But I still have doubts because, by comparison, 3:2 pulldown flag is supposed to create 29,97 fps, but some players can make IVTC and output 23.976 hz (when resolution is set on 1080p). So the flag is used but the reverse operation is done just after, inside the player, as if there was no flag.
Why wouldn't it be possible too with 25p flagged as 29,97 fps ?

[poisondeathray]

Thus it means players can't make IVTC with decimation with this kind of video.
But I still have doubts because, by comparison, 3:2 pulldown flag is supposed to create 29,97 fps, but some players can make IVTC and output 23.976 hz (when resolution is set on 1080p). So the flag is used but the reverse operation is done just after, inside the player, as if there was no flag.
Why wouldn't it be possible too with 25p flagged as 29,97 fps ?


Cadence reading setups that have 3:2:3:2:2 support can read it. 100% for sure.

When you look at hardware reviews, they test varous cadence tests. 3:2:3:2:2 is one of the (fairly) common patterns tested. Most newer players in the medium to more expensive range can. Cheapo models usually cannot. "FAIL" means they are deinterlaced (jaggies)

But you should understand that over here, 99.99% of the TV's run at 60Hz. Even a successfully IVTCed 3:2 "24p" will have judder because you 're seeing frame repeats. Even on a native 24p Blu-ray (no pulldown), you will see 3:2 repeats because the display is running at 60. Only those "24p" capable TV's that have a refesh rate of an integer multiple of 24 (e.g. 120hz, 240) can display them properly without any judder.

So you will see the same thing pattern wise. 3:2:3:2:2 on a 60Hz display, whether or not you have a smart IVTC or dumb deinterlacing setup. The difference is the picture quality

[Sharc]

....Why wouldn't it be possible too with 25p flagged as 29,97 fps ?
It's possible provided that the player can handle the 2:1:1:1:1 cadence. You would have to watch the "inverse telecined" stream on a PAL TV (50Hz) however to enjoy it judder-free.
Strictly, the 25<->30 (29.97) fps conversion with the 2:1:1:1:1 pattern is not Telecining or IVTC respectively. It's pure pulldown and decimation respectively. Telecining always involves fields and interlacing.

[manono]

...by comparison, 3:2 pulldown flag is supposed to create 29,97 fps, but some players can make IVTC and output 23.976 hz
Sort of. Flag readers (the vast majority of the NTSC DVD players out there) can make progressive 23.976fps for soft telecined material. Cadence readers can both do that as well as perform an IVTC on-the-fly, so to speak - return hard telecined DVDs to progressive 23.976fps. But, if it's a 60Hz progressive display (a nice 60" LED television, for example) that progressive 23.976fps video still has to be displayed in the 3232323232 sequence. As pdr says, it's not being deinterlaced so the picture quality is better, but it still has that 3-2 judder (is that the correct word?). The 120 and 240 Hz displays can play it smoothly, though,

[Sharc]

.... but it still has that 3-2 judder (is that the correct word?).
I think so. In the context of framerate conversion and pulldown it is the commonly used term for unequal display durations of individual frames on the screen ("pulldown-judder").
There are other sources of judder of course, e.g. due to motion and camera sweeps which are not synchronized with the TV playback framerate whatever this is. Modern TV's do a lot to mitigate these effects (e.g. by interpolating), more or less successfully.

[Music Fan]

It's possible provided that the player can handle the 2:1:1:1:1 cadence. You would have to watch the "inverse telecined" stream on a PAL TV (50Hz) however to enjoy it judder-free.
Of course, I'm not talking about 60hz only TV's. European TV's support 50 and 60hz, and also very often 24 hz (which is generally displayed in 96 hz, with or without motion compensation).
If a european player connected to a european TV (both supporting 50 and 60hz) can't make decimation with 25p flagged as 29.97, it's perhaps due to a choice (to stay in the Ntsc logic and display only 23.976 or 29.97 fps when the flag is 29.97), not a technical limit (admitting the player can make decimation).

@ poisondeathray and manono : I understand, but that does not really answer my question about the possibility to display in 50hz on a 50/60hz screen this kind of dvd (25p flagged as 29.97).

[Sharc]

.....
@ poisondeathray and manono : I understand, but that does not really answer my question about the possibility to display in 50hz on a 50/60hz screen this kind of dvd (25p flagged as 29.97).
Not sure whether I interpret your question correctly, but:
- by "25p source flagged as 29.97" you mean soft-pulldown i.e. every 5th frames is flagged to be pulled down (repeated) by the player at playback time. The original 25p stream is otherwise untouched, the pulldown is done at playback time by the player. Correct?
- A 50Hz (PAL) system will ignore the pulldown flag and play every 25p frame twice, or in a multiple of 50Hz depending on TV with/without "smart" motion interpolation.
- A 60Hz system will normally play it at 60 (59,94) Hz in a 4:2:2:2:2 pattern with judder. Smart systems may apply some interpolation to smoothen the playback
- A multi-norm system should recognize the pulldown flag and the 2:1:1:1:1 cadence, ignore it and display it in 50 Hz (or a multiple 100, 200 ....thereof).
I think these are the options, no?

[Music Fan]

Yes, but I wonder if a 50hz or multi-norm system can really ignore the flag (or use it then make the reverse operation because I believe the flag can't be ignored) and display this kind of dvd in 50hz.
But I'm not talking only about 29.97p but also 29.97i (what is usually called 60i). Thus whatever 3:2:3:2:2 or 2:1:1:1:1, if the video is in 25p and flagged with DGpulldown (to be displayed in 29.97 fps), the ideal framerate to display it is 50hz (50p). But that's maybe not possible with standalone players. I'm gonna try.

[Sharc]

Looking forward to your test results .... :)

[Music Fan]

Here are the results : I encoded in 720*480 @ 25p, added pulldown with DGpulldown (I checked the line 25 --> 29.97) and made a dvd with Muxman.
Tested on 3 players all set on 1080p : none displayed 50 hz !
Oppo and Pioneer output 60p, Sony outputs 24p !?

edit : if I disable 24p in Sony's setup (no instead of auto, there is not yes or force), it outputs 60p.
I can force 50p in Oppo's setup (which calls it PAL) ; that's probably the best way to look this kind of dvd but curiously I didn't notice difference compared to 60p output (when Multi-system is selected in Oppo's setup).

[Sharc]

Interesting. Not much smartness then.
It seems like the Sony applies standard IVTC with decimation.

[Music Fan]

I don't know what it does but 24p has no sense, that should be 50 or 60p.
I edited my previous post to add some informations.

[Sharc]

Hmmm.... Isn't your 25p source a speed-up 24 film?
Maybe the Sony is smarter than we thought... ;-)

At the end, the answer may again be: "It depends on the player".

[huhn]

Here are the results : I encoded in 720*480 @ 25p, added pulldown with DGpulldown (I checked the line 25 --> 29.97) and made a dvd with Muxman.
Tested on 3 players all set on 1080p : none displayed 50 hz !
Oppo and Pioneer output 60p, Sony outputs 24p !?

edit : if I disable 24p in Sony's setup (no instead of auto, there is not yes or force), it outputs 60p.
I can force 50p in Oppo's setup (which calls it PAL) ; that's probably the best way to look this kind of dvd but curiously I didn't notice difference compared to 60p output (when Multi-system is selected in Oppo's setup).

is this like soft telecine?

broadcast doesn't support this AFAIK.

[Music Fan]

Hmmm.... Isn't your 25p source a speed-up 24 film?
Yes.

Maybe the Sony is smarter than we thought... ;-)
No because it was encoded in 25p (with assumefps(25) in the script) and nothing can tell the player that the orignal speed was 24p, even the mpeg-2 encoder has no way to know it.
The script ouputs the same kind of signal than if I had de-interlaced 50i to 25p.
If I had done changefps(25) instead of assumefps(25), in this case ok, a frame would be duplicated and the player could detect it, but it's not what I did.

[Music Fan]

is this like soft telecine?
Yes, DGPulldown don't re-encode, it only add flags.

[Sharc]

Yes.


No because it was encoded in 25p (with assumefps(25) in the script) and nothing can tell the player that the orignal speed was 24p, even the mpeg-2 encoder has no way to know it.
The script ouputs the same kind of signal than if I had de-interlaced 50i to 25p.
If I had done changefps(25) instead of assumefps(25), in this case ok, a frame would be duplicated and the player could detect it, but it's not what I did.
I can only guess that the Sony player has seen the flags and then defaulted straight to 24, assuming that this is the most likely case. Just speculating.

[Music Fan]

I also believe this.

[Sharc]

Did you inspect the .ifo and .vob with e.g. ifoedit? Anything unusual? These contain also instructions for the playback.

Edit:
Just as a sidenote: When I do a 2:1:1:1:1 hard-pulldown (Changefps(30)) in avisynth and decimate it with tdecimate() without specifying the framerate explicitly it also defaults to 24 fps. In order to get 25fps output I need to specify tdecimate(mode=2,rate=25), or fdecimate(rate=25).

[TheSkiller]

Using interlaced chroma sampling is exactly the same as not doing anything special to the chroma, unless we're talking about one of those formats with oddball interlaced chroma sampling. (DV is one of them, I think?)It's not the same, I am not talking about chroma placement (like DV vs MPEG2). It's about how the chroma was downsampled from (usually) 4:2:2 to 4:2:0 for DVD encoding. I'm sure you know this can be done in two ways

ConvertToYV12(interlaced=false)
and
ConvertToYV12(interlaced=true).

For a progressive video, one would use interlaced=false, right? The problem is, if you encode (or rather flag) the video interlaced the player might do something like this to upsample the chroma for playback:

ConvertToYUY2(interlaced=true)

Now that will result in the CUE (chroma upsampling error) if you used ConvertToYV12(interlaced=false) rather than ConvertToYV12(interlaced=true) for downsampling to 4:2:0.



(Also, I just did a search on CUE and the first few results were from like 2001. How is this still a concern in 2015?)At that time it was a concern because many hardware players were simply lacking a progressive chroma upsampling method. They used an interlaced one, no matter what.

It is potentially still a concern today in the case described above, but this time it's not the hardware's fault but user error.


CUE (down: p; up: i)
https://picload.org/infonail/pdodgdp/cue.jpg (https://picload.org/image/pdodgdp/cue.png)

Correct (down: p; up: p)
https://picload.org/infonail/pdodgcp/correct.jpg (https://picload.org/image/pdodgcp/correct.png)

Also correct (down: i; up: i)
https://picload.org/infonail/pdodgwo/all_interlaced.jpg (https://picload.org/image/pdodgwo/all_interlaced.png)

[colours]

It's not the same, I am not talking about chroma placement (like DV vs MPEG2).

Neither was I—I was pointing out that if we assume that we can just Weave() together fields and have correct chroma siting (this is true of the "standard" 4:2:0 interlaced chroma siting), then there's nothing special that needs to be done if we can assume the playback setup isn't completely broken.

Okay, that's actually a huge bunch of "if"s chained together and we all know playback setups can be broken in very creative ways, but honestly I think the solution should be to fix them (or at least get people to stop buying shitty DVD players etc.) rather than messing with things on the mastering side.

It's about how the chroma was downsampled from (usually) 4:2:2 to 4:2:0 for DVD encoding. [snip] Now that will result in the CUE (chroma upsampling error) if you used ConvertToYV12(interlaced=false) rather than ConvertToYV12(interlaced=true) for downsampling to 4:2:0.

My ten minutes of Googling led me to believe that the term "CUE" is meant specifically for the problem of upscaling the chroma fields with the wrong offsets, not for a mismatch of interlaced/progressive resampling. The latter's not as big a problem and can be worked around on the mastering end just by using a low-pass filter prior to interlacing (or widening the support of the downscaling filter when converting from 4:2:2/4:4:4/RGB to 4:2:0).

A playback setup is not required to be able to detect and reverse pulldown, so this application of a low-pass filter is the only way to guarantee that the chroma will correctly render on playback, regardless of whether the content is really interlaced (50/60 temporally distinct fields) or pulled-down. In practice it's probably safe to assume some sort of field matching will be used and that progressive chroma upsampling is done after all the deinterlacing and field matching nonsense, so you could just ignore this issue entirely. If it still uses interlaced chroma upsampling after deinterlacing or field matching, then that obviously falls under the category of "your setup is broken so we won't support it".

[Music Fan]

And how to apply a low-pass filter with Avisynth ?

[kolak]

blur(1).sharpen(0.3).blur(1).sharpen(0.3)

[TheSkiller]

Neither was I—I was pointing out that if we assume that we can just Weave() together fields and have correct chroma siting (this is true of the "standard" 4:2:0 interlaced chroma siting), then there's nothing special that needs to be done if we can assume the playback setup isn't completely broken.I agree, nothing needs to be done.


In practice it's probably safe to assume some sort of field matching will be used and that progressive chroma upsampling is done after all the deinterlacing and field matching nonsense, so you could just ignore this issue entirely. If it still uses interlaced chroma upsampling after deinterlacing or field matching, then that obviously falls under the category of "your setup is broken so we won't support it".Yes, but if you are using a traditional plain ol DVD-player without any progressive scan, just Scart, the player wouldn't do anything more sophisticated than ConvertToYUY2/RGB(interlaced=true) whenever the stream is flagged as interlaced.
Now my point is, the player is not doing anything wrong there, really. Whenever you put something non-interlaced on a DVD and yet flag it interlaced, you should downsample the chroma to 4:2:0 the "interlaced way". I'm rather sure in the end that's probably almost the same as applying a vertical low-pass on the chroma, so we kind of agree that something needs to be done.

[Music Fan]

blur(1).sharpen(0.3).blur(1).sharpen(0.3)
Ok, and why does it act as low-pass ?

[kolak]

Ask Didee, it's his idea and it works.

[Sharc]

blur() reduces details and sharp transitions by removing high frequencies = lowpass filtering

You could also downscale (and then upscale) the picture. Scaling applies a lowpass filter in order to prevent aliasing.

[colours]

Whenever you put something non-interlaced on a DVD and yet flag it interlaced, you should downsample the chroma to 4:2:0 the "interlaced way". I'm rather sure in the end that's probably almost the same as applying a vertical low-pass on the chroma, so we kind of agree that something needs to be done.

I'm not entirely convinced by this, actually. Going by the very same pictures you uploaded, it's clear that even with the stronger colour fringes, the p-down/i-up pic looks less bad than the i-down/i-up pic.

Let's disregard the idea of using a low-pass filter for the time being. By using interlaced downscaling, there would be two steps causing aliasing in the whole chain (both downscaling and upscaling), whereas with progressive downscaling, the only step that causes aliasing is the interlaced upscaling step. There's no obvious reason to believe that the aliasing caused by interlaced upscaling and by interlaced downscaling should magically cancel out, so progressive downscaling should be preferred.

With a low-pass filter applied, all of this becomes moot if we use a sinc filter (zero aliasing in either step!), but since we don't actually use sinc filters for low-pass filtering or resampling (lolringing + lolslow), to minimise aliasing we should still use progressive downscaling. (Also, we can combine the resampling and low-pass filtering steps into one by adjusting Dither_resize16's fv parameter.)

I think there might be a better way of downscaling than either normal progressive downscaling or interlaced downscaling if we know that it'll be interlace-upscaled later on, but I'm a bit too busy to work out the details at the moment.

[TheSkiller]

I'm not entirely convinced by this, actually. Going by the very same pictures you uploaded, it's clear that even with the stronger colour fringes, the p-down/i-up pic looks less bad than the i-down/i-up pic.OK, those lines I drew in Paint aren't very good at showing the aliasing. So I re-did the test with this chroma zone plate.


down: p; up: i
https://picload.org/infonail/pdllpir/p-i.jpg (https://picload.org/image/pdllpir/p-i.png)

down: p; up: p
https://picload.org/infonail/pdllpcw/p-p.jpg (https://picload.org/image/pdllpcw/p-p.png)

down: i; up: i
https://picload.org/infonail/pdllppc/i-i.jpg (https://picload.org/image/pdllppc/i-i.png)