How to de-interlace 25i coming from 8 mm film transfer ?

[Music Fan]

Hi,
I have to de-interlace a video for someone who made transfer by a company his 8 mm films (maybe Super 8 actually) onto Pal DV tapes and who needs a better quality to make dvd.
I don't know what is the original framerate, here is an extract ;
http://enfroy.free.fr/video/zoocut.avi
I tried Srestore() (default settings) preceded by tdeint() (25 fps) and also tdeint(mode=1) (50 fps) but in both cases the result is far to be perfect, there are still blended and doubled frames, I guess there are better settings and/or filters.

I know that qtgmc is better than tdeint but I needed something fast for the test, I will use qtgmc in the final script.

I'd like to remove blended frames and keep only the original frames if possible and then increase the framerate to 25 fps with assumefps (if it's 24fps) or make interpolation with interframe (if it's 16 or 18 fps, and maybe also if it's 24fps to get 48 fps).
Thanks for your help ;)

[TheSkiller]

Actually you don't need to deinterlace anything at all to make a DVD.

However, in theory, you can improve encoding efficiency if you remove the pulldown, leaving you with the raw frame rate of the video, encode it to DVD compliant MPEG2 video at that frame rate and then apply soft-pulldown for 25i.

The problem in your case is the pulldown is not clean. There are brightness jumps in the "fake" fields inbetween the real motion, and the original frame rate (probably 18 fps, definitely not 24!) was unfortunately not simply adapted to 25i via clean pulldown (duplication), but blending. That's not good. :scared:

Field matching (TFM) fails because of the blending. So you would need to bob-deinterlace and de-blend, which is a real bummer considering if transferred properly there is nothing to deinterlace and de-blend at all with 8 mm film.


My attempts at deblending and restoring the original frame rate failed. Maybe someone else has better luck. So far my advice is therefore, don't bother, just encode it as is because the risk of making it just worse is high.

[Music Fan]

Ok, thanks for your help.
But actually if I add Tdecimate() after Srestore(), that looks better, but there are still some duplicate images : 14 = 13, 22 = 23, 33 = 34, 39 = 40, 53 = 54, 59 = 60, 70 = 71, 79 = 80, 84 = 85, ...
If I add again Tdecimate(), there are no more duplicate images but some good images are perhaps removed too, that's not easy to verify.

Here is my script ;
ffvideosource("F:\Zoocut DV bff.avi")
assumefps(25/1)
assumebff()
tdeint(mode=1)#50 fps
Srestore()#23.976 fps
TDecimate()#19.18 fps
TDecimate()#15.34 fps

[colours]

Try TDecimate(mode=2,rate=18.0) instead of using TDecimate twice.

[Music Fan]

Thanks, much better but there are still some blended and duplicate frames : 0=1, 29=30, 55=56, 63=64 ... and 16, 46 ... are blended.
But strange thing : I exported twice this script in Lagarith yv12 and the second export has less problems than the first.
Before the first export I moved a lot in the file in Virtual Dub's window, but normally it shouldn't affect the export.:confused:

[TheSkiller]

The problems start with the deblending already. No matter how I tweak SRestore (different modes, threshold, etc.) it just won't deblend all frames even at ridiculous aggressive settings.

Edit: @ Music Fan
It doesn't make much sense to let SRestore do some Decimation (50 -> 23.976) and then use TDecimate afterwards for 23.976 -> 18 fps...
Better use SRestore omode <6 to let TDecimate alone do the Decimation.
But like I've said, I didn't get any satisfying results because the deblending fails.

[Music Fan]

It doesn't make much sense to let SRestore do some Decimation (50 -> 23.976) and then use TDecimate afterwards for 23.976 -> 18 fps...
Maybe in theory but actually the result is better with Srestore() before TDecimate(mode=2,rate=18.0).

By the way, did you also use tdeint(mode=1) before deblending ?

[TheSkiller]

I just used Bob() for testing.


Maybe in theory but actually the result is better with Srestore() before TDecimate(mode=2,rate=18.0).I think you misunderstood me. By default, SRestore tries to restore to 23.976 fps because that's the most common "base" frame rate for it's general application. In your case the base frame rate is 18 fps or close to that, so it would make sense to prevent SRestore from decimating (because TDecimate does that afterwards) and use it just as a deblender. Another option would be setting SRestore's "frate" parameter to 18 (which makes TDecimate superfluous). If "omode" is set to a value <6 (6 is default) it will not decimate but only deblend (keeping 50 fps).

[Music Fan]

I think you misunderstood me.
No, I had understood, but the result was better with SRestore, even if it shouldn't be the case.

Another option would be setting SRestore's "frate" parameter to 18 (which makes TDecimate superfluous). If "omode" is set to a value <6 (6 is default) it will not decimate but only deblend (keeping 50 fps).
Ok, but I discovered a few minutes ago that the result was very good with 16 instead of 18 in TDecimate's line (keeping Srestore() before).
When Srestore() is removed, there are more blended frames.

edit : I tried you idea (but I changed 18 to 16) and that's very good too ;)
Here is the script ;
ffvideosource("F:\Zoocut DV bff.avi" )
assumefps(25/1)
assumebff()
tdeint(mode=1)#50 fps
Srestore(frate=16)#16 fps

[johnmeyer]

First of all, you do not want, nor do you need deinterlacing. QTMG is the wrong tool for this.

Instead, what you are doing is inverse telecine (IVTC). IVTC does not involve any motion estimation or reconstruction of fields and frames, but instead is entirely oriented towards removing redundant fields.

If you do a "separatefields()" on the original video, you will see that you always have two good fields, without blends, which match each other. The blends are only happening on fields, not across the entire frame. Therefore, because you always have a good pair of matching fields, there is no need for a deblender, and SRestore is the wrong solution to this problem.

Instead, you simply need to use IVTC, and set the TFM and TDecimate parameters correctly. The following script removed all of the blended fields, and matched all the good fields correctly.

loadPlugin("c:\Program Files\AviSynth 2.5\plugins\TIVTC.dll")

Final_Framerate = 16

AVISource("E:\Documents\Dnload\UNPACK\zoocut.avi").killaudio()
AssumeBFF()
assumefps(25)

tfm(display=false,mode=2,pp=1,cthresh=15,micmatching=3,mmsco=false,metric=1)
tdecimate(mode=0,display=false, ssd=true,noblend=false,hint=true,cycle=86,cycleR=27 )

assumefps(Final_Framerate).ConvertToYV12(interlaced=false)

#separatefields()

[johnmeyer]

P.S. I re-read the original post and realized that this is Super 8 film. Therefore the Final_Framerate should be set to 18 fps, not 16.

[Music Fan]

I said maybe super 8, I don't know what it is (8 or super 8 = 16 or 18 fps), I will ask to the owner of this video.
Anwyay, with my script the result is better with frate=16 instead of 18.

First of all, you do not want, nor do you need deinterlacing. QTMG is the wrong tool for this.

Instead, what you are doing is inverse telecine (IVTC). IVTC does not involve any motion estimation or reconstruction of fields and frames, but instead is entirely oriented towards removing redundant fields.

If you do a "separatefields()" on the original video, you will see that you always have two good fields, without blends, which match each other. The blends are only happening on fields, not across the entire frame. Therefore, because you always have a good pair of matching fields, there is no need for a deblender, and SRestore is the wrong solution to this problem.

Instead, you simply need to use IVTC, and set the TFM and TDecimate parameters correctly. The following script removed all of the blended fields, and matched all the good fields correctly.

loadPlugin("c:\Program Files\AviSynth 2.5\plugins\TIVTC.dll")

Final_Framerate = 16

AVISource("E:\Documents\Dnload\UNPACK\zoocut.avi").killaudio()
AssumeBFF()
assumefps(25)

tfm(display=false,mode=2,pp=1,cthresh=15,micmatching=3,mmsco=false,metric=1)
tdecimate(mode=0,display=false, ssd=true,noblend=false,hint=true,cycle=86,cycleR=27 )

assumefps(Final_Framerate).ConvertToYV12(interlaced=false)

#separatefields()

Thanks, that's great.:)
If I don't specify assumefps, the final framerate is 17.1512 fps :confused:
But of course, I can add assumefps(16) or 18.
By the way, why do you write the framerate in 2 lines (Final_Framerate then assumefps(Final_Framerate)) instead of assumefps(16) ?
And as the source is already in YV12 and becomes progressive with tfm and tdecimate, I guess ConvertToYV12(interlaced=false) is optional.

I didn't know that the term inverse telecine could be applied in this case, I believed it was used only for 60 hz source coming from 24p movies.

If you do a "separatefields()" on the original video, you will see that you always have two good fields, without blends
Actually that's the first thing I did but some fields seem blended : 14, 17, 20, 23, 40 ...
The blends are only happening on fields, not across the entire frame. Therefore, because you always have a good pair of matching fields, there is no need for a deblender
Ok, so it means that a deblender has to be used only when entire frames are blended, but how does it look like ? I believed it was the case with this video.

edit : What filter do you use for DV ? I used to use ffdshow but I didn't install it yet on my new pc because this project seems abandoned, that's why I used ffvideosource instead of AVISource. Does LAV support as many codecs as ffdshow ?

[TheSkiller]

I stand corrected. I honestly didn't expect it is possible to restore this video without bob-deinterlacing + deblending. :o

For DV sources the free Cedocida DV Codec (http://forum.doom9.org/showthread.php?t=94458) is very recommendable (usage via AviSource()). I don't know if ffdshow's DV decoder has changed it's behaviour but it used to decode DV with it's native DV chroma placement which causes slight color fringes if it's not changed to the common MPEG2 chroma placement manually afterwards. Cedocida does this for you upon decoding.

[Music Fan]

Thanks for this information, I'm gonna download this codec. ;)

[johnmeyer]

I said maybe super 8, I don't know what it is (8 or super 8 = 16 or 18 fps), I will ask to the owner of this video. Anwyay, with my script the result is better with frate=16 instead of 18.Super 8 is always 18 fps. Regular 8mm is usually 16 fps.


If I don't specify assumefps, the final framerate is 17.1512 fps :confused:If you understand what the function is doing, it is not confusing at all. "cycle=86,cycleR=27" means that out of every 86 fields, 27 fields are removed. This means that 59 are left. 59/86 = 0.686. If you then multiply 25 fps by 0.686 you get 17.1512.

This is how many frames are left out of each original 25 frames.


But of course, I can add assumefps(16) or 18.
Right. The 17.1512 frames is what remains from each 25 frame. You could plays these in one second, in half a second, or whatever. The "assumpfps()" function tells the video playback software how quickly to play the list of frames, but without adding or deleting any frames.



By the way, why do you write the framerate in 2 lines (Final_Framerate then assumefps(Final_Framerate)) instead of assumefps(16) ?This is how software is usually written. When writing commercial software, you supply some sort of UI with dialog boxes into which the user types or selects values which then control how the software works. In this simple script, I didn't bother with dialog boxes, but instead simply put the input values at the top of the script where they are easy to find and edit. With a short script like this, doing it this way isn't really necessary, but when you have dozens of lines of code, and perhaps several external modules, it is good practice to put all the variables which can be changed, all in one place at the beginning of the script.


I didn't know that the term inverse telecine could be applied in this case, I believed it was used only for 60 hz source coming from 24p movies."Telecine" is the name given to the process of transferring movies to video. Since most people's experience with this process only concerns sound film, which is 24 fps, those of you in the PAL world have not experienced first-hand the practice of adding "pulldown fields" in order to get 24 fps progressive material to play back at the correct speed on a 29.97 interlaced television. In the PAL world, the movie is instead just sped up slightly to 25 fps, and the audio adjusted accordingly.

However, when dealing with 12, 15, 16, or 18 fps silent film (common speeds), you in PAL-land do have to add "pulldown fields" (i.e., duplicate fields) in order for those amateur movies to play at the correct speed on a playback device (your PAL television) that is hard-wired to play everything at 25 frames per second. Therefore, when those fields have already been added, you need to remove them before performing more edits. If you don't remove these duplicate fields, many filters, like those used with AVISynth, will not work correctly because they see no motion at all between certain fields, and this kills their motion estimation algorithms.

The process of removing redundant fields that have been added in order to get the video to play at 25 fps is called "inverse telecine" which is often abbreviated IVTC.


Actually that's the first thing I did but some fields seem blended : 14, 17, 20, 23, 40 ...

...Ok, so it means that a deblender has to be used only when entire frames are blended, but how does it look like ? I believed it was the case with this video.I sense you are still confused about what is going on. The inverse telecine software (i.e., the combination of tfm() and tdecimate()) looks for pairs of fields that match each other, meaning that they come from the same instant in time. This matching involved finding fields that look almost the same, but are offset by one scan line (they simply bob up and down when you view the individual fields). Your transfer process managed to capture occasional fields which are a blend of two adjacent frames of film. Fortunately, because of how this particular transfer worked, there were always two additional fields which matched, and which didn't have blends. Therefore, the software you use can simply throw away the blended field. Therefore, you don't need to use SRestore. That function actually creates fields which didn't exist, and uses those fields to replace all the blended fields. It is a very, very clever function, but because it produces motion estimated fields, those will never be "perfect," and therefore the result will not be as clean as what you can get with your particular transfer by correctly doing nothing more than a "simple" field decimation.

You only need to use SRestore when you don't have two clean fields which already match.

In your case, the software simply has to identify the "odd man out" which is the blended field that doesn't match either of its neighbors, and get rid of it.

For transfers where one or more of the fields in some frames are blended, and where there is no additional "good field" from that frame to choose from, there is another script here in the forum (besides SRestore), based on some ideas Didée gave someone, which let you take a simple transfer done by pointing a video camera at a projection screen, and recover (more or less) the original frames.

The power of Avisynth: salvaging "botched" transfers of old 8mm films to DVD (http://forum.doom9.org/showthread.php?t=161493&highlight=8mm)

It works very well, but it still involves compromises. In your case you don't need it.

I built a very complex telecine machine that I use for transferring 16mm film from a shutterless 16mm projector. This produces results which are identical to your film, which is why I immediately realized what had to be done. The blended fields from my transfer system are, unfortunately, much more difficult to detect (some of the blends are very, very subtle), and so I end up having to do a lot more work than simply finding the correct cycle and cycleR parameters to use.

But that's a story for another time ...

BTW, once you have recovered the original fields, and have 18 fps video, and once you have edited that video, if you are going to play on a device that can natively play 18 fps (which includes all computers, and also many TV sets that can accept thumb drives and computer input via VGA or HDMI), you can leave the video at 18 fps, without adding pulldown fields. As we move away from videotape, which was hard-wired to a specific playback rate, pulldown is no longer required, even here in NTSC land.

[manono]

BTW, once you have recovered the original fields, and have 18 fps video, and once you have edited that video, if you are going to play on a device that can natively play 18 fps (which includes all computers, and also many TV sets that can accept thumb drives and computer input via VGA or HDMI), you can leave the video at 18 fps, without adding pulldown fields. As we move away from videotape, which was hard-wired to a specific playback rate, pulldown is no longer required, even here in NTSC land.

If he's making a PAL DVD, he can make it for anything above 16.667fps (2/3 of 25fps) and then apply a soft pulldown using DGPulldown so that it outputs interlaced 25fps. That way nothing has to be hard telecined. Or maybe that's what you were saying, not sure.

[Music Fan]

Thanks a lot for all these explanations, this is very interesting ! :goodpost:

The guy told me his movie was 8mm, not super 8, so the original framerate should be 16.
Anyway, as he wants a Pal dvd, I got the idea to use Interframe with this script to triple the framerate ;
avisource("F:\Zoocut DV bff.avi" )
assumefps(25/1)
assumebff()
tfm(display=false,mode=2,pp=1,cthresh=15,micmatching=3,mmsco=false,metric=1)
tdecimate(mode=0,display=false,ssd=true,noblend=false,hint=true,cycle=86,cycleR=27)#17.1512 fps
assumefps(17/1)#17 fps
InterFrame(NewNum=51, NewDen=1, cores=2)#51 fps
assumefps(50/1)#50 fps
Then I have to interlace it by adding ;
assumetff()
separatefields()
selectevery(4,0,3)
weave()
Or to keep 50p, I can upscale it in 720p (in pillarbox) and put it on AVCHD (720*576 in 50p maybe works on some players but this is out of standard).
What resize filter is recommended ? I always use lanczos but there is maybe better now.

By the way, here is the video encoded with your script, I just added assumefps(18) at the end (this was before to know the source was 16 fps but it doesn't matter) ;
http://www59.zippyshare.com/v/68994484/file.html
And in 50p with the script I gave a few lines above ;
http://www2.zippyshare.com/v/29161308/file.html
They are encoded in Lagarith ;
http://lags.leetcode.net/codec.html

edit : I forgot to ask you how you found the values, especially cycle=86,cycleR=27. Are they common or you had to observe the video carefully to find it ?

[johnmeyer]

I forgot to ask you how you found the values, especially cycle=86,cycleR=27. Are they common or you had to observe the video carefully to find it ? I did a "separatefields()" on the original video, and simply counted how many frames I saw. Sometimes I had to press the frame advance key three times, sometimes four times before I incremented my frame count. When I finished the clip, I looked at the field counter in VirtualDub (it is a frame counter, but since I was looking at a "separatefields()" video, it is actually counting fields). For your clip there are 30 frames, but 86 fields. For 30 frames, the video should have 60 fields, so 26 fields must be discarded.

As for your choice to use Interframe, that is strictly a matter of personal taste. The result of interpolating frame will yield something that looks totally different than normal film, and more like video. Some people like this, others derisively call it the "soap opera effect" because it reminds them of the live video look that they associate with daytime TV soap operas. The one advantage is that horizontal camera pans will no longer "judder." The disadvantage is that you get morphing artifacts when objects enter and leave the frame; when the camera pans across vertical objects, like a picket fence; and when people walk across the field of view (their legs break).

I am generally a fan of just using traditional pulldown, repeating fields, not entire frames, and encoding to interlaced.

[johnmeyer]

If he's making a PAL DVD, he can make it for anything above 16.667fps (2/3 of 25fps) and then apply a soft pulldown using DGPulldown so that it outputs interlaced 25fps. That way nothing has to be hard telecined.I don't think this works very well for this frame rate.

To make sure, I first re-visited the DGPulldown page:

DGPulldown (http://neuron2.net/dgpulldown/dgpulldown.html)

DGPulldown simply adds a pulldown flag to an MPEG-2 stream (it is only useful when encoding MPEG-2 video). This flag tells an NTSC DVD player to add fields to a 24p stream so that it plays at the correct speed on a 29.97 interlaced ("60i") monitor. It can also be used to take 25 fps material and play it on NTSC monitors without doing the usual hard conversion. This is described in this epic thread:

Pulldown of 25 fps to NTSC (http://forum.doom9.org/showthread.php?s=&threadid=88031)

I think that the idea fails for two reasons when applied to the OP's video. First, the ratio is wrong. 24p-->60i pulldown has a nominal ratio of 30/24 = 1.25. The OP needs to go from 16 fps to 25 fps. That ratio is 1.56. Using a 1.25 ratio will only get him to 20 fps, so the video will definitely look very slow.

The bigger issue is that the whole "flag" concept only applies to NTSC, AFIK. I don't think that the DVD standard has a concept of a flag when playing PAL video. I guess that many PAL DVD players also play NTSC discs, and some PAL TV sets can also play NTSC, but even if the OP has that equipment, the video will still play too slowly.

And, as already mentioned, it only works for MPEG-2 video, and only when that is encoded onto a DVD.

[2Bdecided]

IIRC DGPulldown does work for this, and can use any ratio you want. It's a while since I used it, but I'm sure I used it exactly like this.

There's no way I'd use Interframe, or any other motion interpolation, for the only final version of this. It'll look totally wrong, and since the AVIsynth motion interpolations options aren't very good, it'll introduce artefacts. Plus (depending on the ratio) the original frames are partly/mostly gone forever. However, if you want that look, many modern TVs will create it for you in real time, even from pulled-down 16fps sources, and some of them are better at avoiding artefacts than current AVIsynth scripts+functions.

That said, I'd happily create a second copy/version with frame interpolation, and put that on DVD as well. No harm in that. Just preserve the original properly first.

Cheers,
David.

[TheSkiller]

The bigger issue is that the whole "flag" concept only applies to NTSC, AFIK. I don't think that the DVD standard has a concept of a flag when playing PAL video.
You are wrong. Pulldown can be used for PAL DVD output of 25i equally well. All players must support it. Soft-Pulldown isn't limited at all to NTSC output, it's just very rarely used.

There are 2 constraints which always apply:


The base frame rate needs to be lower than the output frame rate (which is either 29.97i or 25i, nothing else)
The base frame cannot be lower than 2/3 of the output frame rate


So you can soft-pulldown 16.666 progressive fps to 25 interlaced fps.

[johnmeyer]

You are wrong. Pulldown can be used for PAL DVD output of 25i equally well. All players must support it. Soft-Pulldown isn't limited at all to NTSC output, it's just very rarely used ... So you can soft-pulldown 16.666 progressive fps to 25 interlaced fps.I just went looking through the DVD specs, and I don't see anything like what you describe.

The information I found is consistent: the MPEG-2 soft pulldown flag for DVD authoring only has two values: 3:2 which adds fields to 24p material so it plays correctly on a 60i NTSC TV set; and 2:2 which adds fields to achieve a 4% speedup to go from 24p to 50i PAL.

I do not see anything, either in the spec, nor in any of my various MPEG-2 encoders, that permits any sort of arbitrary soft pulldown flag which would instruct the playback DVD device to add fields during playback to go from 16p or 18p to either 50i or 60i.

If you can point to something that supports this, I would love to know because this is what I do for a living, and it would be great if I could deliver DVDs that contain 16p or 18p material in native format, and then have the DVD player add the pulldown fields. I'd get massively better encodes, and I could fit a lot more material on a DVD.

Unfortunately, I've never seen this in any software I've ever used.

[TheSkiller]

Maybe you have better luck finding information about this if you're looking into the RFF flags rather than looking for pulldown in general, because that's essentially what's happening: the RFF flags tell a decoder to repeat fields. Those flags are set across the whole stream so that the desired output fps is reached (that's soft-pulldown at it's core). The decoder doesn't need to do anything different except repeating fields as instructed to output standard 25i or 29.97i. All MPEG2 decoders know the RFF flag, it's part of the MPEG spec. This exactly the way standard NTSC film telecine soft-pulldown works. It's not different at all.

Maybe search for threads related to "DGPulldown" here at doom9 for more information.


As to why professional MPEG2 encoders do not have any options for this other than regular NTSC film telecine pulldown... I don't know. Maybe because it's so rarely used by professionals where hard-pulldown (like 16p -> 25i) is most probably applied much earlier in the production chain because common professional storage formats such as DigiBeta do not allow raw 16 fps.


With every MPEG2 encoder to my knowledge you would have to encode a 16 fps source at 25 fps using AssumeFPS(25) and then afterwards use DGPulldown to apply the RFF flags and restore the original 16 fps playback speed.


Some things need to be considered:

The encoded GOPs must be no longer so that after soft-pulldown the longest GOPs are still <=15 frames for PAL and <=18 frames for NTSC. So if you're doing a pulldown of 16.666 fps to 25 fps the encoded GOPs must be limited to a maximum of
15 / (25 / 16.666) = 10 frames for DVD compliance.


Bitrates are given in bits per second. Since we only temporarily speed up the video to 25 fps for encoding we need to calculate all bitrates with a factor of 25 / 16.666 = 1.5 if we're calculating using the real runtime of the video.

[johnmeyer]

Hmmm ... I just read through a lot of that 25-page DGPulldown thread. As you say, it adds "pulldown" internally to the MPEG-2 file, rather than as a flag when the DVD is authored.

I decided to try it out, but could not find any MPEG-2 encoder in my kit that will encode a 16 fps 8mm film to 16 or 16.666 fps.

I'll keep looking for a few more minutes ...

[TheSkiller]

I decided to try it out, but could not find any MPEG-2 encoder in my kit that will encode a 16 fps 8mm film to 16 or 16.666 fps.Like I've said just assume the frame rate to 25 fps and encode it at 25 fps in any MPEG2 encoder.

When applying the RFF flags with DGPulldown you specify the real frame rate which restores the original playback speed.

[manono]

I don't think this works very well for this frame rate.
You couldn't be more wrong. In fact, there is no better way to accomplish what the OP wants, and certainly not interpolation and reinterlacing as he said he plans on doing. In fact, if he applies a custom pulldown set for 16.667->25, he'll apply a 3:3 pulldown and rid himself of the jitter effects of a standard 3:2 pulldown in a standard NTSC DVD.

The others before me have explained it in detail, but for some more clarification:

No, you can't encode for 16.667fps. You encode for 25fps and after applying the pulldown, the length becomes correct. At the same time, adjust the bitrates in the MPEG encoder by a factor of 1.5:1 (25/16.667). For example, if the average bitrate is to be 4000, make it 6000. If the usual max bitrate is 9000, make it 13,5000. It'll all be fine in the end. I've done this many many times myself.

Don't use any Adobe products for authoring as they refuse some DVD-compliant streams. Otherwise I defy you to find any authoring program that won't author the result or player that won't play the result correctly.
If you can point to something that supports this, I would love to know...
Virtually everything supports this as you're producing a 100% DVD complaint stream. It outputs interlaced 25fps as required. You can encode in CCE or HCEnc, among others, and author using Muxman, among others.
...and it would be great if I could deliver DVDs that contain 16p or 18p material in native format
It has to be equal to or greater than 19.98fps for NTSC and 16.667fps for PAL. When working with NTSC silent films under 19.98fps, I interpolate up to 19.98fps and take it from there. Works great.
I'd get massively better encodes, and I could fit a lot more material on a DVD.

Exactly. You're able to encode progressively at a much lower framerate than is usual for material at less than 23.976fps (NTSC). Hard telecine just eats up the bits.
Unfortunately, I've never seen this in any software I've ever used.
DGPulldown.

[johnmeyer]

OK, I now understand what DGPulldown does: it adds pulldown flags to the MPEG-2 encode itself rather than adding a pulldown flag during the DVD authoring stage. This provides a lot more flexibility for encoding native progressive footage from different frame rates (like 16 and 18 fps), as well as doing the 24p-->50i, and 25p-->60i conversions that were the original goal of the DGPulldown project.

Very clever, and I now fully understand why I didn't comprehend the initial claims that there were more pulldown flags than the two that are a hard-wired part of the DVD authoring process.

However ...

One problem in using this approach comes from the following restriction (quoted from the DGPulldown documentation):

"The input frame rate can be freely chosen, but it must be greater than or equal to 2/3 of the output frame rate,and less than or equal to the output frame rate."

Thus, you can take 16 fps material and use this technique to end up with 24 fps (this is exactly 3/2, or 2/3 depending on which way you look at it). However, you cannot go from 16 to 25 fps, and still maintain the correct playback speed. That ratio is greater than the 3/2 allowed, and DGPulldown simply gives you the 3/2 ratio, and nothing more (I just tried it, and that's what happens).

The OP can get pretty close (16.67 fps), however (edit: which is what Manono said earlier).

For me, in NTSC land, there is another, more subtle, issue. NTSC DVDs have to be either 23.976 with the pulldown flag set, or 29.97 interlaced. I don't believe that there is such a thing as a 23.976 DVD without pulldown.

However, the only way to put that on a DVD is with the pulldown flag set.

And that leads to this issue: when the DVD player puts its pulldown on top of the soft pulldown embedded in the MPEG-2 file, it will create a cadence that might not be optimal, and might be different from one player to the next.

To see if this is a major issue I'm going to burn a few test DVDs and see what they look like on my old CRT NTSC monitor.

If I had a progressive DVD player, I am pretty certain that these do permit the 23.976 progressive video to be played natively (they basically ignore the pulldown flag). So, if I had one of those, this scheme would work perfectly.

I definitely learned something today.

[manono]

Thus, you can take 16 fps material and use this technique to end up with 24 fps (this is exactly 3/2, or 2/3 depending on which way you look at it).
No, as 23.976fps isn't DVD-compliant. You apply pulldown to get it to interlaced 29.97fps. As I already explained, for NTSC the lowest framerate on which you can use DGPulldown is 19.98. Anything lower you have to first bring it up to 19.98fps.

[johnmeyer]

No, as 23.976fps isn't DVD-compliant. You apply pulldown to get it to interlaced 29.97fps. As I already explained, for NTSC the lowest framerate on which you can use DGPulldown is 19.98. Anything lower you have to first bring it up to 19.98fps.Yup, I found out that the 23.976 video that results from DGPulldown is not compliant, even though 23.976 is obviously a legal, compliant format that I use all the time. I am not quite sure why that happens, but it does. Perhaps DGPulldown removes the DVD pulldown flag. That would definitely make it non-compliant.

Since starting with 19.98 rather than 16 is going to be quite noticeable, this technique will not work for my application. Even for 18 fps, that would be a 10% increase in speed.

For the OP, starting with 16.66 may be close enough, and therefore acceptable.

Thanks again for the explanations. DGPulldown is still a very cool hack -- another great contribution from "Guest."

[TheSkiller]

And that leads to this issue: when the DVD player puts its pulldown on top of the soft pulldown embedded in the MPEG-2 file, it will create a cadence that might not be optimal, and might be different from one player to the next.There is only one instance of pulldown. A DVD-Player does not have any automatic 23.976 -> 29.97 pulldown. Without RFF pulldown flags insinde the stream you cannot even author a 23.976 stream because the only allowed output frame rates for DVD are 29.97 and 25.



If I had a progressive DVD player, I am pretty certain that these do permit the 23.976 progressive video to be played natively (they basically ignore the pulldown flag)A progressive scan player has to obey the RFF flags as well. They usually have a cadence detection which removes the pulldown fields after decoding and outputs non-interlaced 60 Hz or applies deinterlacing when detected. This is necessary because a stream can in theory happily switch between soft- and hard-pulldown and real 60i (video camera) constantly (uncommon but possible). There's no way of outputting native (pulldown-less) 23.976 fps from a DVD (except on a PC).

[manono]

Since starting with 19.98 rather than 16 is going to be quite noticeable, this technique will not work for my application. Even for 18 fps, that would be a 10% increase in speed.
I never suggested speeding it up (only for Music Fan for whom a ~3% speedup won't be noticed). My suggestion is to interpolate to 19.98fps. Depending on the source, it may or may not work out quite well. The length remains the same; there's no speeding up of the video.

If you don't know the script for interpolating the needed frames, just ask.

[johnmeyer]

I never suggested speeding it up (only for Music Fan for whom a ~3% speedup won't be noticed). My suggestion is to interpolate to 19.98fps. Depending on the source, it may or may not work out quite well. The length remains the same; there's no speeding up of the video.

If you don't know the script for interpolating the needed frames, just ask.I have dozens of scripts for interpolating, using MVTools, SVP, and Interframe, which is sort of a front end to these tools.

The problem I have with interpolating low frame rate material is that the temporal gaps between frames is so large that it is really difficult for the motion estimation to do a good job creating the intermediate frames. As a result, the lower the frame rate, the more obvious the artifacts. The inverse (or is it converse?) of this logic is that if you start with really high framerates, like 60p, you can estimate upwards and get some really amazing slow motions.

I do use interpolation during camera pans because the judder at 16 fps is something terrible to watch. So, my workflow at this point is to apply a "standard" pulldown to 16 fps or 18 fps to get 29.97, and render to an intermediate using a lossless codec. I then also render the same material using interpolation, usually using MVTools2, which for me seems to produce results I like.

I then edit these two similar 29.97 videos like I would a two-camera shoot, cutting between the pulldown version and the interpolated version as needed.

Panning usually interpolates almost perfectly, so I seldom have a problem with artifacts. However, since the difference in cadence between interpolated and pulldown versions is visually quite noticeable, I usually try to cut between them at scene changes, or when the camera gets bumped, or at some other discontinuity that "masks" the change.

[Music Fan]

Thanks all of you, there are amazing informations here !
I'm very astonsihed by the fact that the bitrate can reach 13 Mbps and stay dvd compliant. I guess it means that for the player, the bitrate is detected after applying the pulldown that decreases framerate from 25 to 16.667 which spills the bitrate in a longer duration and thus decreases the bitrate for each second. If yes, it's strange because before applying the pulldown, the player has to decode mpeg-2 stream and at this moment, the bitrate reaches 13 Mbps. Or it doesn't work like that ?

There is something I don't understand about rff flags and encoding in 16.667 fps : at which framerate and speed will the video be sent by the player to the screen ?
Will the player triple the framerate (like I could do with Interframe) ? If yes, I guess there will no be interpolation but just a tripling of each frame, which will not be very fluid.
And does it mean the player decodes at 25 fps and then slow down to 16.667 fps ? I guess no because it would need to keep a lot of frames in memory and the player would be decoding the end of the movie when displaying the 2/3 of the movie, which is impossible. So I guess the player actually never reaches 25 fps in this case during the mpeg-2 decoding process.

The decoder doesn't need to do anything different except repeating fields as instructed to output standard 25i or 29.97i. All MPEG2 decoders know the RFF flag, it's part of the MPEG spec. This exactly the way standard NTSC film telecine soft-pulldown works. It's not different at all.
If there is a simple frame repeating, there will be a big judder. But this seems contradictory with another part of your message ;
With every MPEG2 encoder to my knowledge you would have to encode a 16 fps source at 25 fps using AssumeFPS(25) and then afterwards use DGPulldown to apply the RFF flags and restore the original 16 fps playback speed.
In this case there is no frame repeating, it's just as if the player did an assumefps, which leads to a big duration changing compared to the encoded stream, unlike the soft pulldown used for 24p sources that have to be displayed at 29.97 fps ; it duplicates fields but does not change the total duration.
So I'm a little bit lost, what happens exactly with the solution you recommended me ?
If a kind of assumefps is done, what happens with the sound ?


About the way players handle 23.976 fps with 29.97 pulldown, I had asked years ago to Oppo how they did to allow 24p output for ntsc dvd (when encoded with soft pulldown) : they said the decoder didn't ignore the flag, but after converting in 29.97 fps, an IVTC was done to find again the original 23.976 frames.
This seems complex but is actually simpler for the decoder. They also said that the pulldown flag was technically ignorable, but it would need another decoding architecture, a second clock IIRC.

[manono]

If yes, it's strange because before applying the pulldown, the player has to decode mpeg-2 stream and at this moment, the bitrate reaches 13 Mbps.
It's only 13000 for 25fps. But by applying pulldown you're effectively slowing it back to 16.667fps. The bitrate declines by the same percentage.
at which framerate and speed will the video be sent by the player to the screen ?
It'll play at 16.667fps. I mentioned 3:3 pulldown before. A PAL DVD player outputs 50 fields per second. To make 50 fields per second, each field of your 16.667fps DVD is played 3 times in succession - 3:3. Two are from each frame (they're the same) and the third is added by the pulldown you applied. A progressive scan player sending to a progressive display sends each frame three times and the TV set will show 50 frames per second.
If there is a simple frame repeating, there will be a big judder.
Nope. Here the only jerkiness will be from the original 16.667fps. This particular kind of pulldown adds no judder at all. You're in PAL land and have never had to work with pulldown before the way we NTSC people live with 3:2 pulldown. Just try it out with a sample DVD to convince yourself.
In this case there is no frame repeating, it's just as if the player did an assumefps, which leads to a big duration changing compared to the encoded stream, unlike the soft pulldown used for 24p sources that have to be displayed at 29.97 fps ; it duplicates fields but does not change the total duration.
For NTSC you encode at 23.976fps and add pulldown to output 29.97fps. The length doesn't change. Here you're encoding at 25fps and then slowing it with the pulldown later. This is very different from what happens with standard 3:2 pulldown. 23.976fps is a 'legal' framerate for encoding, 16.667fps isn't.
If a kind of assumefps is done, what happens with the sound ?
If you add audio to fit a 16.667fps source, nothing happens to the audio - it stays in synch.

[Music Fan]

Thanks !

It'll play at 16.667fps. I mentioned 3:3 pulldown before.
Ok, I forgot you wrote it. I knew that Dvd/Divx players could play divx files with strange framerates but I didn't know a dvd player could do 3:3 pulldown with compliant dvd.
Are you 100% certain it will play on all Pal dvd players ?

A PAL DVD player outputs 50 fields per second. To make 50 fields per second, each field of your 16.667fps DVD is played 3 times in succession - 3:3. Two are from each frame (they're the same) and the third is added by the pulldown you applied. A progressive scan player sending to a progressive display sends each frame three times and the TV set will show 50 frames per second.
If I understand well, if sent in interlaced by the dvd player, the video won't be as fluid as if sent in 50p because the player does not triple each frame and interlace this 50p ?

Nope. Here the only jerkiness will be from the original 16.667fps. This particular kind of pulldown adds no judder at all.
Right, I actually meant not fluid but this is not judder.
And you prefer this lack of fluidity than interpolation made with Interframe (or other filter) ?

For NTSC you encode at 23.976fps and add pulldown to output 29.97fps. The length doesn't change. Here you're encoding at 25fps and then slowing it with the pulldown later. This is very different from what happens with standard 3:2 pulldown.
Yes, that's what I understood. Does it mean slowing down could also work for 23.976fps with the same kind of flag than for 16.667fps (but flagged in 29.97 instead of 25) ?
I guess no because dvd players are not supposed to allow 24p output, although some Blu-ray/dvd players can output ntsc movies in 24p but with a double conversion (as I explained above about Oppo).
But this gives me another idea : could your trick work to encode 23.976fps onto Pal dvd (to encode a 23.976fps movie in 720*576 instead of 720*480) with a 25p flag and a rff flag to slow down it to 23.976 ?
Mmmh, actually no, same problem than with ntsc dvd, a dvd player is not supposed to allow 24p output, whatever Pal or Ntsc, right ?
And if it was allowed, the flag wouldn't be needed.

23.976fps is a 'legal' framerate for encoding, 16.667fps isn't.
Don't you mean common instead of legal ? Because if your trick works for 16.667fps, I guess this is not "illegal".

[foxyshadis]

It's field repeating, not frame repeating. For every single decoded frame, three fields are displayed, when you max out the pulldown like that. When displayed, every third frame is "interlaced" (Aa, Ab, Bb, CC, Cd, Dd, etc), but when you're watching on TV, that's as smooth as it's possible to get without blending or interpolating. If your player deinterlaces, you'll get even more extra fake smoothness; if it tries to IVTC, it'll almost certainly fail horribly, but most won't even attempt it with this pattern.

24 fps on 25 fps PAL is generally known as 2:2 pulldown, although it's really 2:2:...:3 (I forget exactly how many 2s). It repeats one field every 12 frames.

No matter how small or large the framerate, the video can still only be 9 Mbps, because DVD is only specified to read data off the disc at 9 Mbps. Framerate has absolutely nothing to do with bitrate, other than if you change the framerate without changing anything else, you change the bitrate. Pulldown changes both the framerate and the frame count, though.

[Music Fan]

It's field repeating, not frame repeating. For every single decoded frame, three fields are displayed, when you max out the pulldown like that. When displayed, every third frame is "interlaced" (Aa, Ab, Bb, CC, Cd, Dd, etc), but when you're watching on TV, that's as smooth as it's possible to get without blending or interpolating.
When watching on CRT only, not on flat screens that de-interlace, right ?
But if one has a flat scren, the best idea is to send the video in 1080p to allow a frame tripling by the player.
Anyway I find this pattern doesn't look fluid : some fields are displayed 2 times and others 1 time.

If your player deinterlaces, you'll get even more extra fake smoothness; if it tries to IVTC, it'll almost certainly fail horribly, but most won't even attempt it with this pattern.
If I understand what manono said, the player will do nor deinterlacing neither IVTC with 16.667fps videos ; if sent in progressive, each frame is tripled, and if sent in interlaced, there is a field repetition (1 or 2 times).

24 fps on 25 fps PAL is generally known as 2:2 pulldown, although it's really 2:2:...:3 (I forget exactly how many 2s). It repeats one field every 12 frames.
Ok but that's very rare, for PAL dvd, movies are usually encoded with the Pal speed-up technique.

No matter how small or large the framerate, the video can still only be 9 Mbps, because DVD is only specified to read data off the disc at 9 Mbps. Framerate has absolutely nothing to do with bitrate, other than if you change the framerate without changing anything else, you change the bitrate. Pulldown changes both the framerate and the frame count, though.
But manono said it worked with 13 Mbps :confused:

[TheSkiller]

Anyway I find this pattern doesn't look fluid : some fields are displayed 2 times and others 1 time.With such low frame rates you will never notice slightly irregular patterns in the pulldown.
Edit: 16.666 fps is not irregular. As explained by foxyshadis every frame is spread across 3 fields. It doesn't get anymore regular than that.


When watching on CRT only, not on flat screens that de-interlace, right ?
But if one has a flat scren, the best idea is to send the video in 1080p to allow a frame tripling by the player.

If I understand what manono said, the player will do nor deinterlacing neither IVTC with 16.667fps videos ; if sent in progressive, each frame is tripled, and if sent in interlaced, there is a field repetition (1 or 2 times).No matter the requested output format for the TV (interlaced or progressive) the player will honor the RFF flags and create 25i as instruced by the flags. For 1080p output this will then run through the player's deinterlacer to create 50p from 25i. That's how it works. Cadence detection, which would avoid deinterlacing, doesn't work with oddball frame rate like 16.666 fps. Cadence detection generally only works with NTSC 3:2 pulldown. Euro-Pulldown (2:2:....:3 as described by foxyshadis) will be deinterlaced as well.

So for progressive output formats the video runs through a player's deinterlacer which is not optimal but if you encoded the video with hard-pulldown instead this would be no different.



But manono said it worked with 13 Mbps :confused:It's Megabits per second at 25 fps. If you play the same stream at 16.666 fps the Bitrate per second declines by the same factor and thus stays within DVD spec.

[Music Fan]

I had understood it, that's what I said earlier. So there was no reason to say that the maximum bitrate is 9 Mbps, it's confusing in this particular case.

No matter the requested output format for the TV (interlaced or progressive) the player will honor the RFF flags and create 25i as instruced by the flags. For 1080p output this will then run through the player's deinterlacer to create 50p from 25i.
Ok, so this kind of encoding (for 16.667fps) is not very interesting for fluidity, the only utility is to have more bitrate by image.
Thus there will be judder added by the player actually, at least when output is interlaced. But even when output is progressive, I'm not sure the result can be similar to a simple frame tripling because of the intermediate 25i step.

Euro-Pulldown (2:2:....:3 as described by foxyshadis) will be deinterlaced as well.
What is the utility of this kind of Euro-Pulldown ? If one frame is duplicated each second to get 25 frames from 23.976 encoding, it will be much less fluid than Pal speed-up encoding. The only advantage is to keep original duration and thus keep original sound without acceleration (even if compensation can be done, but it's not always done).

[TheSkiller]

Ok, so this kind of encoding (for 16.667fps) is not very interesting for fluidity, the only utility is to have more bitrate by image.There is no motion interpolation if that's what you mean (unless the TV by itself does it on top of the pulldown) but fluidity is perfect in regards to the source; in other words it's as fluid as raw 16.666 fps is.

What is the utility of this kind of Euro-Pulldown ?You already mentioned it, the audio does not need to be speed up. This technique can be used if the audio is of greater importance than the video quality, say a music video.

If one frame is duplicated each second to get 25 frames from 23.976 encoding, it will be much less fluid than Pal speed-up encoding.Not 1 frame per second is duplicated but 1 field twice per second. So there are 2 slight hiccups every second. But it's not nearly as bad as duplicating a frame once per second (that's pretty much unwatchable).

[johnmeyer]

A few points of clarification.

1. DVD players play back at 25 fps (PAL) or 29.97 fps (NTSC). Regardless of how the video is encoded inside the MPEG-2 file (e.g., with "soft pulldown," in the case of the DGPulldown trick), when the video is decoded from that file and "sent out the door" from the DVD player to the TV, it will be one of those two frame rates. The one exception is that many modern DVD players have a "progressive output" which lets them ignore the pulldown flag for material encoded as 23.976 fps, so those players can send this frame rate to the TV.

Since I am still learning about this unusual (and non-standard) DGPulldown method, I do not know whether any progressive player can send 16.666 fps (or some other frame rate) directly to the TV set, but I strongly suspect that they cannot. Instead, they send a stream of frames which includes the additional "soft" duplicated fields that are not actually encoded, but instead are created at decode time by the MPEG-2 decoder in the DVD player, which responds to a "flag" in the video stream which tells the player to repeat the previous odd or even field.

2. The bitrate on the DVD cannot reach 13 mbps because the disc and electronics are not spec'd to keep up with that. The repeated fields that get created (on the fly) take essentially no bits to encode (the decoder creates them) and since no bits are extracted from the disc during the time this repeated field is displayed, the total bits per second is reduced from the 13 mbps bitrate.

Will the player triple the framerate (like I could do with Interframe) ?3. Definitely not. The player does duplicate fields, and this does increase the number of frames per second, but it does it by duplicating, not by synthesizing new frames, which is what Interframe does.

As for Interframe, I strongly urge you to create a test DVD, using a re-writeable DVD, after you have created something with Interframe. You may be quite shocked at the severe artifacts you will get when this technology is applied to low frame rate (16 and 18 fps) amateur film. This is even more true if you don't do any of the restoration shown in the long threads in this forum started by VideoFred. For instance, watch what motion estimation does to a big blob of dirt. It is not pretty.

4. There is a lot of apparent confusion in some of the preceding posts about what it actually means to "play back at 16 frames per second." This concept is very simple when dealing with film: there are frames on the strip of film, and if you play 16 of them in one second, you are playing at 16 fps. When you put that film on a sound projector which is hard-wired to play at 24 fps, those same 16 frames play at a faster speed, and motion is sped up.

If you transfer the film to video using a frame accurate transfer, then you end up with a video file that looks exactly like the film. If you play that video file at 16 frames per second, the motion is played at the correct speed. However, if you play it on a TV that is hard-wired to play at 25 or 29.97 frames per second, the motion will be sped up. The way around this is to add additional frames to the video, either by duplicating or interpolating. However -- and this is where I think there is some confusion -- there are still only 16 original frames being played each second; the others are either duplicate fields or synthesized fields and/or frames.

[TheSkiller]

The one exception is that many modern DVD players have a "progressive output" which lets them ignore the pulldown flag for material encoded as 23.976 fps, so those players can send this frame rate to the TV.The pulldown flag must always be obeyed. Cadence detection is what inverses the process and outputs non-interlaced 60 Hz to the TV from a 23.976 video (actually regardless of whether it was encoded with soft-pulldown or hard-pulldown because after decoding to 29.97i this information is lost and not relevant anyway).
The player doesn't really have the option of ignoring the pulldown flags because the flags don't need to follow a fixed pattern (base frame rate may vary) and the stream may be mixed with video content (native 29.97i). If the player just ignored the flags, depending on the video, the results would be unpredictable.

For example, some people converting their NTSC DVDs (especially Anime), not realizing what they do, complain about choppy credits when they "Force Film" in DGIndex instead of leaving it to honoring the pulldown flags. This is exactly what happens if the RFF flags aren't honored.


A DVD, even with a progressive scan player, can only be output to the TV at either 50 Hz or 59.94 Hz. Native 24 Hz via HDMI, like with a Blu-ray, is not possible.

[Music Fan]

The player does duplicate fields, and this does increase the number of frames per second, but it does it by duplicating, not by synthesizing new frames, which is what Interframe does.

There is no motion interpolation if that's what you mean
No, I know that players don't make interpolation, I just meant that playing 16.66 fps in 25 fps can't be fluid because 25 is not a multiple of 16.66.

fluidity is perfect in regards to the source; in other words it's as fluid as raw 16.666 fps is.
How could it be as fluid as raw 16.666 fps ? If the player don't handle all the fields exactly the same way (for example all multiplied by 3, I mean by simple duplicating), it will inevitably introduces judder and the result will be worst than 16.66 fps displayed in 16.66 fps (which is already a little bit jerky due to its low framerate).
The global speed will be the same, but it can't be as fluid.
It's like 23.976 with soft pulldown displayed in 29.97 fps, there is inevitably judder added by the player.

[johnmeyer]

How could it be as fluid as raw 16.666 fps ? If the player don't handle all the fields exactly the same way (for example all multiplied by 3, I mean by simple duplicating), it will inevitably introduces judder and the result will be worst than 16.66 fps displayed in 16.66 fps (which is already a little bit jerky due to its low framerate).
The global speed will be the same, but it can't be as fluidI don't think that is entirely correct. Judder is caused almost entirely by the low frame rate, and not by the added fields.

Suppose I watch a 16 fps movie on a computer screen. Then, suppose I duplicate each field so I now have 32 frames, but I play those at 32 frames per second. Guess what? Those two streams are visually indistinguishable and are absolutely, 100% the same thing!

Now, with more complicated pulldown patterns there is definitely a "start-stop" nature to the pattern where one frame contains a repeated field and the next one does not, so in those cases there is a little bit of additional judder added. However, the main judder problems come from the low frame rate. You can prove this to yourself by watching a low frame-rate video that does not contain any pulldown. I'll give you an example.

Here is one of my film transfers from a 1928 16mm home movie. I timed it to play back at 12 fps, and that is how YouTube displays it. When you watch it, don't look at the kids playing football, but instead watch the buildings in the background as the camera pans back and forth. See the judder? That's caused by the low frame rate, and nothing else. The additional judder caused by 3:2 pulldown is minor by comparison.

1928 Backyard Kids Football (http://www.youtube.com/watch?v=1YekFxBYKNM)

However, irregular pulldown, like the two fields per second required to go from 24 to 25 fps, can be quite distracting.

And, since you seem interested in using Interframe, here is another film from roughly the same era. In this case, I chose to use MVTools2 to interpolate additional frames to go from 16 to 30 fps. I did this because the judder on pans was really difficult to follow:

San Francisco 1930 (http://www.youtube.com/watch?v=2moHDbxUodk)

[TheSkiller]

I just meant that playing 16.66 fps in 25 fps can't be fluid because 25 is not a multiple of 16.66.
How could it be as fluid as raw 16.666 fps ?You need to think in fields rather than frames. ;)

Pulldown flags will spread the 16.666 fps across 50 fields per second (25i, also called 50i but it's the same thing).

Now, 50 / 16.666 = 3 ;)

That's what we mean by "a frame will be spread across 3 fields".

[foxyshadis]

Unless you can set your TV to a multiple of 16 (such as 72 or 128Hz), it will never be perfectly smooth. Even playing your 16 fps video back on a 60Hz monitor will have slight judder, let alone a round trip through DVD with its broadcast-era throwback framerate requirements; it's just never going to be perfect. If you need DVD, then you need to compromise, end of story. Interframe is also a compromise, and you can spend your time on it if you want, but in our opinion it'll be a much worse compromise than pulldown and ultimately a waste of time. Try it on one scene before you commit yourself to reflowing a whole movie.

And I don't know why 13Mbps keeps coming up. If you have 10,000 frames at 16.66 fps encoded to 9Mbps, then the pulled-down 15,000 frames at 25 fps is still 9Mbps.

[TheSkiller]

And I don't know why 13Mbps keeps coming up.It's because when you encode a non-standard frame rate most if not all MPEG2 encoders will complain. Hence we AssumeFPS(25) and pretend it's a 25 fps video for encoding (only for encoding!). Because of that the bitrates we enter for encoding need to be modifyed by the pulldown ratio which in our example of 16.666 fps for PAL pulldown means we raise all bitrates by a factor of 1.5 so that later at 16.666 fps the bitrate is just as intended.

[johnmeyer]

Interframe is also a compromise, and you can spend your time on it if you want, but in our opinion it'll be a much worse compromise than pulldown and ultimately a waste of time. Try it on one scene before you commit yourself to reflowing a whole movie.Ditto.

And I don't know why 13Mbps keeps coming up. If you have 10,000 frames at 16.66 fps encoded to 9Mbps, then the pulled-down 15,000 frames at 25 fps is still 9Mbps.I don't fully understand how DGPulldown works but my understanding is that it doesn't change any of the encoding in the MPEG-2 file, but instead adds flags which tell the MPEG decoder at playback time to add some duplicate fields. These flags don't significantly affect the number of bits in the encoding, but because it now takes longer to play back the video when these duplicate fields are added, the bits per second is lower.

For example, if one second of video contains 6,000,000 bits, if I then duplicate every single field, and don't change anything else, then that video will now take two seconds to play. Because the duplicate fields are created by the decoder, not the encoder, they take no additional bits to encode. Therefore, those same 6,000,000 bits are still all that is used to create this longer video, but those bits are now spread across two seconds. Therefore the bitrate is now 3,000,000 bits per second.

At least that is my understanding from reading various descriptions in this thread (and in the original DGPulldown thread) about how DGPulldown works.

[johnmeyer]

Because of that the bitrates we enter for encoding need to be modifyed by the pulldown ratio which in our example of 16.666 fps for PAL pulldown means we raise all bitrates by a factor of 1.5 so that later at 16.666 fps the bitrate is just as intended.Despite what I just posted above, I don't understand this argument. The bitrate you should use, I would think, should be determined by the quality you want in that 16.666 fps encode, whether or not you add pulldown. This bitrate calculation should be the same as it would be for any video, where you take into account the spatial quality of the original, the frame rate, the resolution, color depth, and nature of the material, and then make a determination of what bitrate is needed.

The fact that you are adding soft telecine flags should not affect your choice of what bitrate to use. It certainly does not need to be higher than it would if you weren't adding these flags.

The key thing that should be noted for the OP, is that encoding without using hard telecine (hard telecine = duplicate fields actually in the video being encoded) makes a HUGE difference in quality, and you can use a much, much lower bitrate and still achieve great quality, compared to the bitrate you have to use to encode hard-telecined material.

I learned this over a decade ago when trying to get great encodes to CD media using the SVCD "standard." I remember spending half a day trying to get one music video to look good at the ultra-low bitrate cap that standard allowed. Then, late in the day, I discovered IVTC buried inside of TMPGEnc: it was a near-religious experience when I encoded and then played the result after all the hard telecine pulldown frames were removed: virtually all the "mosquito noise" disappeared, and the edges and details became clear and crisp.

[manono]

Despite what I just posted above, I don't understand this argument. The bitrate you should use, I would think, should be determined by the quality you want in that 16.666 fps encode, whether or not you add pulldown.
Whether you understand it or not, the argument is correct.

For example, you have an hour long video at 16.667fps you want to encode using an average bitrate of 4000. You can't encode at 16.667fps so you encode at 25fps instead. The video is now 40 minutes long and the average bitrate you use for encoding is boosted by the same factor - to 6,000 (25/16.667=6,000/4,000=1.5). After encoding this 40 minute video you run it through DGPulldown set for 16.667->25. The length goes back to its original hour and that average bitrate is effectively lowered to 4,000 during the pulldown process. What's not to understand? Just try it out and see for yourself. If your normal max bitrate is ... for example ... 9000 and you set it for 13500 for the 25fps encode, by following your logic no authoring program will author it. But since that max bitrate has been lowered back to 9000 after DGPulldown, it'll author with no problem.

In the interests of encoder efficiency, if for no other reason, this is the way to go. I've used DGPulldown many many times for applying non-standard pulldown (silent films mostly) and it works and works very well.

You can lead a horse to water...