25p to 60i (using pulldown technique)

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