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

[Music Fan]

And what about the maximal bitrate usable for 23.976 films with soft pulldown for ntsc dvd displayed in 29.97 fps ? I guess it's 10 Mbps max because the speed does not change, unlike 16.66 fps encoded in 25 fps @ 13 Mbps then slowed down by DGPulldown which decreases detected bitrate by the player, right ?

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!
Of course, because it's a perfect multiple.

The additional judder caused by 3:2 pulldown is minor by comparison.
Ok, I can admit this. And as foxyshadis said, a compromise has to accepted when making dvd with this kind of sources.

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)
Nice videos. Did you crop edges to remove artefacts due to interpolation ?
Is MVTools2 better than Interframe ?

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".
Ok, but how can it be as fluid as original material if outputted in 25i ?
What's the fields order, admitting 1t = top field of 1st frame, 1b = bottom field of 1st frame, ... ?
Does it look like this (16 frames above, 25 below at the same speed) ?
---1--------2--------3--------4--------5--------6--------7--------8--------9----...
1t,1b,1t-2b,2t,2b-3t,3b,3t-4b,4t,4b-5t,5b,5t-6b,6t,6b-7t,7b,7t-8b,8t,8b-9t,9b,9t-...
--1--,--2--,--3--,--4--,--5--,--6--,--7--,--8--,--9--,--10-,--11-,--12-,-13--,...
I guess that whatever the pattern and the framerate, there is always a top field of one of the original frames followed by a bottom field of one of the original frames to create the new frames, because there is never field inversion, right ?
If my pattern is correct, we see clearly that 1t is used 2 times while 1b is used one time and that 2b is played before 2t. Same problem for some other fields, which prevents to keep the same fluidity than the original framerate.
And if this pattern is correct, how is it handled by the player when output is set to 1080p ? How will it create 50p from this 25i pattern ?

[TheSkiller]

And what about the maximal bitrate usable for 23.976 films with soft pulldown for ntsc dvd displayed in 29.97 fps ? I guess it's 10 Mbps max because the speed does not changeCorrect (actually it's 9.8 MBit/s including audio if present).



What's the fields order, admitting 1t = top field of 1st frame, 1b = bottom field of 1st frame, ... ?Field order can be either top or bottom; it is defined by the TFF flag in the stream (you can set or unset this in DGPulldown as well). But which field order is generated by the pulldown flags doesn't make any significant difference, it would just take the opposite fields from the encoded frames (so "1t,1b,1t" would become "1b,1t,1b").


Does it look like this (16 frames above, 25 below at the same speed) ?Yes, that's exactly what it looks like (top field first scenario). You can see that the first field for every interlaced output frame (meaning after pulldown) is always a top field, hence it's a top field first sequence.


there is always a top field of one of the original frames followed by a bottom field of one of the original frames to create the new framesIn case of bottom field first pulldown (TFF flag not ticked), the bottom field of one of the original frames would be followed by the same frame's top field, so it would be inverted.


If my pattern is correct, we see clearly that 1t is used 2 times while 1b is used one time and that 2b is played before 2t.Correct. This is not a problem however because 1t, 1b and again 1t are all coming from the same source frame which is progressive and hence all those 3 fields represent the same point in time that the original frame did (same for 2b,2t,2b and so on). Looking at a top field twice and only once at a bottom field doesn't harm fluidity if all 3 fields represent the same point in time. They do differ spatially (top/bottom field lines) but not in time. So you see the top field lines 2 times and the bottom field ones only once (and vice versa) but they are all coming from the same source frame and the same sampled point in time.




And if this pattern is correct, how is it handled by the player when output is set to 1080p ? How will it create 50p from this 25i pattern ?It's simply getting bob-deinterlaced by the player (or by the TV if the output of the player was an interlaced format such as 576i), meaning every field will be turned into a frame by interpolation and motion estimation. It's being treated like every other 25i video.

[johnmeyer]

Whether you understand it or not, the argument is correct ... 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? ... You can lead a horse to water...If you look at my previous post, you will see that I described exactly that same thing as you just posted (partially quoted at the beginning of this post).

That part I understand.

What I was not "getting" was that you have to do the original encode at 25 fps and then run that through DGPulldown to add the additional fields, but keep the playback header at 25 fps. My mistake was that I thought you encoded at 16.666 and then added the pulldown flags to get to 25 fps, thus increasing both the number of fields and the framerate. In that frame of reference, my statements were correct. However, that's not how DGPulldown works.

I stand corrected.

[johnmeyer]

Did you crop edges to remove artifacts due to interpolation ?No. There are definitely LOTS of artifacts. Just look at the short sequence near the beginning of the clip where the cars are going down the hill on the Pacific Highway. You'll see morph artifacts as the cars enter and leave the frame, or when they pass behind the pedestrians in the foreground.

Is MVTools2 better than Interframe ?If you look under the covers, they are pretty much the same thing.

Interframe is a script by Subjunk which uses SVSmoothFPS to do the actual frame or field interpolation. And, it turns out that SVSmoothFPS is derived from MVTools2. In particular, if you look at at the

SVPflow Wiki (http://www.svp-team.com/wiki/Plugins:_SVPflow)

you'll find this sentence "Motion vectors search plugin (svpflow1.dll) is a deeply refactored and modified version of MVTools2 Avisynth plugin".

My understanding is that this plugin was created in order to dramatically speed up the processing by using your computer's GPU. This was done so that the processing could be done in real time for home theater applications.

The reason I use MVTools2 is that while both it and the Interframe/SVPflow combination use the same underlying estimation engine, I was able to better control the parameters which affect morphing artifacts when I used MVTools2 directly. I posted my experience over in one of the two VideoFred 8mm film restoration threads.

[manono]

It's simply getting bob-deinterlaced by the player (or by the TV if the output of the player was an interlaced format such as 576i), meaning every field will be turned into a frame by interpolation and motion estimation. It's being treated like every other 25i video.

There's a major exception here as compared to most PAL movies on DVD that are encoded as interlaced. This one is encoded as progressive. Even the cheapest flag-reading 20 Euro DVD player will see the progressive frame flag and after that it's incapable of deinterlacing it. That's one of the problems of flag-reading players - that sometimes interlaced material is encoded as progressive and the interlacing will slip through because it's not 'seen' as being interlaced. The better cadence-reading players can spot the interlacing and deinterlace it if necessary.

In the case of a progressive scan player outputting to a progressive display, that original outputted field is 'intercepted' and joined with its partner field and then output as a full frame, 3x3x3x3 in the case of the 3:3 pulldown we have here:

The progressive output of a DVD player should assemble 2 fields from each film frame and create a complete progressive frame that looks just like the original film frame. ... This form of display gives us a moving image very close to the original film.

http://www.hometheaterhifi.com/volume_7_4/dvd-benchmark-part-5-progressive-10-2000.html

It's in 'Reinterleaving 24fps Film'. It also talks about 'judder' because it's discussing 3:2 pulldown. With 3:3 pulldown there's no pulldown-induced judder. 2:2 pulldown is also discussed and it's more similar to the 3:3 pulldown we have with Music Fan's video.

The point I'm making is that nothing gets deinterlaced or bobbed. The frames are recreated from their component fields and sent to the TV set as stored on the DVD (except here each frame is sent three times for a 50Hz display).

[Music Fan]

That's good news, I guess this 3:3 pulldown is only possible with 16.66 fps (I mean on PAL dvd) and is thus very rarely used.
But some players are maybe better than others with that kind of encodings, and a simple bobbing (as suggested TheSkiller) is perhaps done sometimes which probably leads to less defined images (on certain frames, those created from 2 different frames like the 2nd in the pattern I described above, 1t-2b).

There are definitely LOTS of artifacts. Just look at the short sequence near the beginning of the clip where the cars are going down the hill on the Pacific Highway. You'll see morph artifacts as the cars enter and leave the frame, or when they pass behind the pedestrians in the foreground.
I find these artifacts are quite discrete.

In case of bottom field first pulldown (TFF flag not ticked), the bottom field of one of the original frames would be followed by the same frame's top field, so it would be inverted.
Ok, but I wanted to be sure that a top field will always stay a top field and cannot become a bottom field during the interlacing process done by the player with the instructions of the flag (and vice versa for a bottom field).

This is not a problem however because 1t, 1b and again 1t are all coming from the same source frame which is progressive and hence all those 3 fields represent the same point in time that the original frame did (same for 2b,2t,2b and so on). Looking at a top field twice and only once at a bottom field doesn't harm fluidity if all 3 fields represent the same point in time. They do differ spatially (top/bottom field lines) but not in time.
Ok, I understand better now, so there will be no judder but the video will be less defined on certain frames.

Are there mpeg-2 encoders able to create these RFF flags or DGpulldown is the only one to make it ?
If DGpulldown has to be used, is there anything special to do in the encoder ?
Do all encoders accept to encode @ 13 Mbps in 25 fps ? Because they are not supposed to know that DGpulldown will be used after to decrease framerate and thus bitrate.

[manono]

Are there mpeg-2 encoders able to create these RFF flags or DGpulldown is the only one to make it ?
MPEG-2 encoders can add 3:2 pulldown. Any other kind has to be done via DGPulldown.
If DGpulldown has to be used, is there anything special to do in the encoder ?
You might have to disable any sort of a DVD template that might be in use.
Do all encoders accept to encode @ 13 Mbps in 25 fps ?
They should, after making sure the DVD template is disabled.

[Music Fan]

Thanks ;)

[Music Fan]

I nearly forgot something ; the size of GOP is important too and can't exceed 10 frames for 16.66 fps, as explained TheSkiller a few days ago ;
http://forum.doom9.org/showthread.php?p=1693010#post1693010

I'd like to be sure to understand correctly the term "3:3 pulldown" ; does it concern this kind of encoding (16.66 fps in Pal and 19.98 in Ntsc with rff flags), whatever the way it is outputted by the player or only when it is outputted in progressive mode (to get each frame entirely 3 times) ?

About DGpulldown, in the custom line, do I have to write 25 on the left and 16.667 on the right ? Or the reverse ?

[manono]

I'd like to be sure to understand correctly the term "3:3 pulldown"

It means each field is played three times. For the more common 3:2 (or 2:3) pulldown for NTSC films on DVD the fields are played in a 323232 pattern, hence the judder.
About DGpulldown, in the custom line, do I have to write 25 on the left and 16.667 on the right ? Or the reverse ?
The reverse.

[Music Fan]

Ok, I will try this.

It means each field is played three times.
So it means it can be done only if the player if set to progressive output (and if the player does a smart de-interlacing [from the 25i created by the flag] to display 3 times each original frame), because in 25i with this flag there are 3 fields created from each frame (1 field displayed 2 times, the other 1 time), which is different than playing each field 3 times.

[manono]

If the TV is progressive (1080p or whatever) then the output has to be made progressive by either the player or the TV. I think most people have progressive scan players these days. You set it to output for a 1080p display and the frames will be output three at a time. It's mostly old 'square' CRT TVs that need to have fields sent to them.
...(and if the player does a smart de-interlacing [from the 25i created by the flag]...
As I mentioned, there's shouldn't be any deinterlacing going on, smart or otherwise. The two correct fields per frame are woven together.

You could have tried this days ago to see if you like the results. And one criterion for good results is the quality of the encoded frames as compared to your interpolate and reinterlace idea earlier. If you do it both ways for the same size (a full DVDR, for example) there should be quite a difference in the average 'Q' between the two methods, not to mention the artifacts created by interpolation.

[Music Fan]

As I mentioned, there's shouldn't be any deinterlacing going on, smart or otherwise. The two correct fields per frame are woven together.
Yes, that's what I meant, but that's the ideal method, and I'm not sure all players make this from the 25i pattern I described a few days ago.

Therefore, are you ok with me about the 3:3 pulldown, it only concerns progressive output, not interlaced ?

You could have tried this days ago to see if you like the results. And one criterion for good results is the quality of the encoded frames as compared to your interpolate and reinterlace idea earlier.
I will try this soon.

[manono]

Yes, that's what I meant, but that's the ideal method, and I'm not sure all players make this from the 25i pattern I described a few days ago.
That interpolate and reinterlace method requires you to encode as interlaced.

3:3 or any other kind of pulldown requires the video be encoded as progressive.

[Music Fan]

Yes I know, I was talking about 16.667 fps with the flag added by DGpulldown that lets the player play it @ 25fps without speed change.

But you didn't answer clearly my question yet :o
I guess you meant : yes, 3:3 pulldown only concerns progressive output with this kind of encoding because interlaced output can't play 3 times each field as shows this schema ;
---1--------2--------3--------4--------5--------6--------7--------8--------9----...
1t,1b,1t-2b,2t,2b-3t,3b,3t-4b,4t,4b-5t,5b,5t-6b,6t,6b-7t,7b,7t-8b,8t,8b-9t,9b,9t-...
--1--,--2--,--3--,--4--,--5--,--6--,--7--,--8--,--9--,--10-,--11-,--12-,-13--,...

[Music Fan]

The DGpulldown trick works on my 3 players (Oppo, Sony and Pioneer) that play the video at the good speed :)
They are all set on 1080p but the Sony has problems to de-interlace it correctly, this was especially visible on the timecode I added to verify if the speed was good, the numbers were not sharp and seemed to shake.
This reinforces my belief that some players can't make 3:3 pulldown with this kind of encoding because of the 25i step created by the player because of the flag.

Here is my method for the timecode ;
assumefps(16.667)#because the video will be considered as 16.667 fps by DGPulldown and the player
ShowTime()
assumefps(25/1)#because the mpeg-2 encoder needs 25 fps

[Music Fan]

Hi,
I come back because I realize that I don't understand very well this explanation ;
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.
How do you count 30 frames ?

[johnmeyer]

I come back because I realize that I don't understand very well this explanation: How do you count 30 frames ?Create an AVISynth script that contains nothing more than a line to load the video file (e.g., AVISource), and a second line which separates the video into fields, i.e., "separatefields()".

Open this script in VirtualDub, or editor of your choice. As you press the "frame advance" key (the right arrow in VirtualDub), you will now be advancing by one field, and not one frame. Because your original video is telecined (i.e., pulldown fields have been added) you will see nothing more than a slight up & down motion between some fields. When this happens, it means that the fields come from the same frame of film. Do not increment your frame count when you only see up/down motion.

With your pulldown pattern, you sometimes get two fields, sometimes three fields, and sometimes four fields all from the same frame. Only increment the frame count when you see actual motion from one field to the next, indicating that you are now viewing another frame of film. When there is little motion, this can sometimes be difficult to see, but with film, there is usually a little dirt or dust spot that you can use to tell that the film has advanced to the next frame. Also, the telecine pattern tends to repeat, so after a few frames, you can anticipate when the next field is going to be from a different frame of film.

[Music Fan]

Thanks, that's what I did but I still don't understand how you chose 30 frames or how you determined the length of the cycle, it seems arbitrary, especially because it's not linked to the framerate (25 for the avi, 16 for the original 8mm movie).
Before separatefields() there are 215 frames and after separatefields() there are 430 frames (or fields in this case).
Do you count blended fields (14, 17, 20, maybe 23 ...) on which we can see a little motion compared to previous field ?

In the 60 first fields (I could stop later but I'm not gonna count until 430), I count 27 different fields.
But one can also say that during the 25 first fields, there are 11 different fields or that during the 40 first fields, there are 17 different fields (admitting I count correctly).
Therefore the cycle values could be different, for example cycle=40,cycleR=7, right ? If yes, I guess the longer the cycle is, the more precise the result is.
If I understand well your method of calculation, and if applied to my count, 17 different fields mean 34 useful fields on 40, which means that 6 must be discarded, and cycleR is found by adding 1 to the number of fields that must be discarded, right ?

[johnmeyer]

Thanks, that's what I did but I still don't understand how you chose 30 frames or how you determined the length of the cycle, it seems arbitrary, especially because it's not linked to the framerate (25 for the avi, 16 for the original 8mm movie).There is nothing arbitrary or approximate about the technique. You simply count how many unique fields (two unique fields per frame of film) you have in your clip, and then look at how many total fields you have, which you get by looking at the frame counter when viewing the last frame in the clip and multiplying that number by two. The difference is the number of fields you have to decimate.

Always think about fields, not frames. Also, always look at fields, not frames when analyzing your video. Looking at frames of interlaced or telecined video always confuses people and leads them into doing the wrong thing. This happen for two reasons: because they think something is broken when they see herring bone video due to the temporal offset between fields (nothing is wrong); and because they think something needs to be deinterlaced when in fact it needs to be IVTC'd.

Also, do not pay any attention to the playback speed of the clip. That will get you confused. The playback speed of the video you get from the film-to-video transfer operation doesn't matter at all. The actual number of frame remains the same whether the film/video is played at 10 fps, 16 fps, or 18, 24, 23.976, 25, or 29.97 fps. You can set the playback speed later, as the very last statement in your script, using an AssumeFPS() statement. Set the playback speed to match what you think was the original shooting speed of the film. And, remember that silent amateur film was not always taken at some standard speed. Prior to the mid 1930s, there were still hand-cranked cameras, and the shooting speeds was completely arbitrary. Even when spring wound cameras were used, the mechanisms were not well calibrated, and you could get some very unpredictable speeds. Finally, even into the 1960s, many cameras had a "film saving mode" that let them shoot at a much slower speed than 16 or 18 fps, which by that time were the usual speeds for 8mm and Super 8 film.

[TheSkiller]

Sony has problems to de-interlace it correctly, this was especially visible on the timecode I added to verify if the speed was good, the numbers were not sharp and seemed to shake.The Sony was deinterlacing the 25i pulldown video like it does with native 25i video. This is not really an error, the player is just doing what it's told. The Oppo and Pioneer seem to handle this differently internally, possibly matching the fields rather than blind deinterlacing.

[Music Fan]

Yes, and this "blind deinterlacing" isn't appropriate and is not watchable, that's what I meant by "problems to de-interlace it correctly". And I had also said it differently ;
some players can't make 3:3 pulldown with this kind of encoding because of the 25i step created by the player because of the flag

@ johnmeyer : thanks but I had understood most of these things, you don't really answer my last questions.:o
Sorry to insist but I need to understand why you say there are 30 frames while there are 215 in the video I posted (and 147 with your script that discards 68 frames).
Let's imagine the video contains 10000 frames (20000 fields), I guess you are not gonna count all of them, you just stop after a few tens because it's enough to identify the problem and find the good cycle values.
Therefore, after how many frames (or fields in this case) do you determine you have seen enough to choose cycle values ? Do you see a repetitive pattern that let you think that the cycle values will be relevant for the whole video ?

[johnmeyer]

Most patterns can be identified as soon as the pattern repeats. I usually continue until I see the same pattern repeat 2-3 times.

[Music Fan]

Ok, so this pattern was probably not easy to detect because of its length (86 fields), you had to count at least to ~170 to detect this pattern twice.
As it is nearly impossible to remind, one need to write it and then see if a pattern seems to repeat itself, for example : 3 - 4 - 1 - 2 - 4 - 1 - 1 | 3 - 4 - 1 - 2 - 4 - 1 - 1 | 3 - 4 - 1 - 2 - 4 - 1 - 1 ... which means the first field is repeated 3 times, the next 4 times ...
In this example, each pattern consists of 16 fields : 7 different, 14 useful (2 fields for a frame), and thus 2 have to be discarded this way : cycle=16,cycleR=3, right ?

[Bernardd]

Hello,

My proposal to de interlace zoocut.avi is to use TFM function and Dedup (with two pass).
After Dedup first pass process, when Dedup args "show" is true and args "dec" is false, we can see a pattern.


AVISource("E:\Normal\Downloads\zoocut.avi")

LoadPlugin("C:\.............\TIVTCv105\TIVTC\TIVTC.dll")

# match_on_odd
TFM(order=-1, field=1, mode=0, PP=0, ovr="", input="", output="", outputC="", debug=false, display=false, slow=1,\
mChroma=true, cNum=15, cthresh=9, MI=80, chroma=false, blockx=16, blocky=16, y0=0, y1=0, mthresh=5, d2v="", ovrDefault=0,\
flags=4, scthresh=12.0, ubsco=true, micout=0, micmatching=1, trimIn="", hint=false, metric=0, opt=4)
#match_on_even
TFM(order=-1, field=-1, mode=4, PP=0, ovr = "", input="", output="", outputC="", debug=false, display=false, slow=1,\
mChroma=true, cNum=15, cthresh=9, MI=80, chroma=false, blockx=16, blocky=16, y0=0, y1=0, mthresh=5, d2v="", ovrDefault=0,\
flags=4, scthresh=12.0, ubsco=true, micout=0, micmatching=1, trimIn="", hint=false, metric=0, opt=4)

LoadPlugin("C:\..................\dedup-0.17\dedup\DeDup.dll")
#~ DupMC(log="D:\Travail sur Videos\Dedup 3.txt")
DeDup(threshold=0.3, threshold2=0.5, range2 = 0, trigger2 = 5.0, maxcopies=2, maxdrops=2, \
log="C:\...............\Dedup.txt", show =false,dec = true)


Do you think this script is able to solve de interlace 8mm clip ?
Thanks

[2Bdecided]

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).In the very few times I've seen this used professionally, it's been one frame repeat per second, never two separate field repeats. Using the field repeats, you end up with half the movie being out of phase (each single video frame consisting of a mix of two different film frames, one in each field), and some broadcasters don't like that. We're not in NTSC land you know ;) - we don't find such things "normal"! Some TVs don't really like it, and a few really don't like it.


Yes, and this "blind deinterlacing" isn't appropriate and is not watchable, that's what I meant by "problems to de-interlace it correctly".It'll probably do exactly the same thing with hard telecine, and the quality will be lower. You could try it, but chances are nothing will help this player.

I can imagine a different dumb-ish player outputting 50p is going to give you four clean identical frames, a two bob-deinterlaced frames, four clean identical frames, a two bob-deinterlaced frames, ...

Most modern TVs are going to process it yet again, so you can't be sure you're seeing what your player is sending. While it's the overall effect you probably care about, you don't want to find that what you've chosen to do is revealed as being horrible when you buy a new TV ;)

I've already said what I'd do (bottom of page one).

Cheers,
David.

[manono]

we don't find such things "normal"!
Which doesn't mean it's not 'better' or that it doesn't play more smoothly. For what it's worth, while I've seen some instances of frames being repeated to go from 24 to 25fps (and many many more examples of such conversions being field-blended, where the 'standard' is speeding it up to achieve 25fps), I have seen one example of 'hard-telecined' field repeats in a retail DVD when converting 24 to 25fps for PAL. And, yes, it looked odd with the interlacing every half second and lasting half a second.
You could try it, but chances are nothing will help this player.
I agree. I wouldn't use the example of a single player not playing DVD-compliant material correctly as a reason not to do it that way, especially not for 3:3 pulldown which should play smooth as silk (ignoring the inherent jerkiness of a 16fps source) without being deinterlaced. His Oppo plays it right, and it's the gold standard by which other players should be judged.

[Music Fan]

Hi,
more than year later, I re-read this topic and realize I don't understand very well this ;
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.
Your script was there ;
http://forum.doom9.org/showthread.php?p=1692790#post1692790
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 )
As 26 fields on 86 must be discarded, why did you put 27 and not 26 for cycleR ?

[johnmeyer]

Hi,
more than year later, I re-read this topic and realize I don't understand very well this ;

Your script was there ;
http://forum.doom9.org/showthread.php?p=1692790#post1692790
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 )
As 26 fields on 86 must be discarded, why did you put 27 and not 26 for cycleR ?I can't even remember what I had for breakfast, and yet you expect me to remember how many fields I counted in a video clip two years ago?

Therefore I cannot answer your questions with any specifics. However, in general, you count the fields until you see the pattern repeat. That is Cycle. You then record how many duplicate fields you must decimate. That is CycleR. However, you need to be careful not to count the start or end field twice. This is similar to the issue every programmer faces on whether to start a count with 0 or with 1. It is very possible that I did this or, perhaps, you are doing this and therefore one of us is off by one.

So, I can't tell you whether I got it right or not, because it is way too long ago, and I'm sure not going to go back and re-count 80+ fields.

[Music Fan]

Ok, but I don't ask you to remember anything, you can simply re-read this sentence your wrote ;
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.
That's why I wonder why you put 27 and not 26 for cycleR.

[johnmeyer]

You are asking me to correct a two-year-old typo??

My original quote should have read 27 fields must be discarded.

Remember, this has nothing to do with 30 fps. The fps for amateur film can be anything: it is not confined to NTSC or PAL standards.

[Music Fan]

You are asking me to correct a two-year-old typo?
No, I just try to understand if there was an error or if I didn't understand any subtlety to be sure to understand the method.

My original quote should have read 27 fields must be discarded.
Ok, that's what I wanted to know.


edit : actually I still don't understand :o because if 60 fields are needed (for 30 frames), 26 is the good value for CycleR.
Thus your error was maybe in the script (should be 26 instead of 27) and not in your explanation that had followed.

You gave 2 explanations that seem incompatible ;
"cycle=86,cycleR=27" means that out of every 86 fields, 27 fields are removed. This means that 59 are left.
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.
59 or 60 ?

edit 2 : I tried with 26 instead of 27, this is not good ; the frame 41 is the same than 40, thus your script was ok. Therefore, there is a problem with your second explanation.

[johnmeyer]

Thank you for correcting me.

[Music Fan]

You're welcome.
I tried your method (separatefields) and observed a repetitive pattern all 26 fields : 4 are single blended frames (unneeded), others are 9 groups of 2 or 3 fields, which means there should be 18 fields (for 9 frames) on 26 fields, thus 8 on 26 must be discarded.
So I replaced cycle=86,cycleR=27 by cycle=26,cycleR=8 and it works well too :)