24p->25p woes - "Euro Pulldown"?

[Lyris]

Right now I have a 24p-based music video that has to go out to PAL DVD. This is really problematic piece of video, because the entire thing is full of tiny details (guitar strings, etc.) which cause interpolation issues with all of the motion compensated frame rate conversion tools I've tried, and really nasty interlace flicker with field-blending standards converters (and it'd be a damn shame to just blur the video to conceal this).

Wikipedia mentions another method for converting 24fps to 25fps:
This pulldown method[4] is sometimes used in order to convert 24 frames/s material to 25 frames/s. Usually, this involves a film to PAL transfer without the aforementioned 4% speedup. For film at 24 frames/s, there are 24 frames of film for every 25 frames of PAL video. In order to accommodate this mismatch in frame rate, 24 frames of film have to be distributed over 50 PAL fields. This can be accomplished by inserting a pulldown field every 12 frames, thus effectively spreading 12 frames of film over 25 fields (or “12.5 frames”) of PAL video. The method used is 2:2:2:2:2:2:2:2:2:2:2:3 (Euro) pulldown (see below).

This method was born out of a frustration with the faster, higher pitched soundtracks that traditionally accompanied films transferred for PAL and SECAM audiences. A few motion pictures are beginning to be telecined this way[citation needed]. It is particularly suited for films where the soundtrack is of special importance.

Can AviSynth produce such a conversion? I imagine it involves some use of the "SelectEvery" function, but I'm not aware of exactly how I'd go about doing this. Can anyone help?

[manono]

Just use DGPulldown on it, with the 'Custom' box checked and 24->25 filled in.

http://neuron2.net/dgpulldown/dgpulldown.html

[Lyris]

Thanks for the link Manono. This is going out to a replicated, pressed DVD. This isn't going to break DVD-Video spec compliance, is it?

[Revgen]

Use assumefps(25.000,sync_audio=true)

Frames are just sped up, not interpolated. Sound is adjusted to sync with the new framerate.

[Gavino]

Use assumefps(25.000,sync_audio=true)

Frames are just sped up, not interpolated. Sound is adjusted to sync with the new framerate.
If you use this approach, you will also need to resample the audio back to a standard rate for DVD, since assumfps does the time adjustment by simply changing the playback sampling rate.

But speeding the video up might be a bad idea here, since this is a music video. As Lyris said, the 'euro pulldown' "is particularly suited for films where the soundtrack is of special importance".

[Lyris]

Compatibility is the #1 priority here. My authoring tools are pretty strict with what they accept, but I'm still not willing to lose sleep over it. If manipulating the stream in such a way could cause player hiccups, then is there no way to perform the Pulldown in AviSynth to generate an interlaced stream which I can then encode, rather than achieving the same result with Repeat Field Flags? That way I could be assured what I was doing was in-spec...

[Gavino]

If you want a pure Avisynth solution, it would be something like:
SeparateFields()
SelectEvery(48, 0,1, 2,3, 4,5, 6,7, 8,9, 10,11, 12,13, 14,15, 16,17, 18,19, 20,21, 22,23, \
22,25, 24,27, 26,29, 28,31, 30,33, 32,35, 34,37, 36,39, 38,41, 40,43, 42,45, 44,47, 46,47)
Weave()

[Lyris]

Thanks Gavino, I'll give that a whirl. In any case though, it just occurred to me that any playback device is going to have to deinterlace in Video mode (since I don't think any solution out there would recognise this pulldown pattern!) which is going to cause aliasing anyway. I think I'm just gonna go for duplicating every 24th frame with "ChangeFPS(25)" - hardly perfect, but it's a slow-paced video so it shouldn't be too jarring.

Frickin' 50hz...

[wonkey_monkey]

After manono suggested using DGPulldown, I did a bit of "research" (thank you Google), but I couldn't find anything absolutely definitive. I found at least one site claiming that the chips in DVD players simply honour any combination of pulldown flags, so if they can pulldown 23.976, they should also be able to pulldown 24 to 25, as long as the flags are right. But as I said, I couldn't find an absolutely definitive "yes it will always work" answer.

David

[Lyris]

Frame repetition it is then. Thanks for your help, everyone.

[Didée]

Frame repetition it is then. Thanks for your help, everyone.
It's your decision. But consider ...

Soft pulldown means 99% of viewers will have a smooth viewing experience. 1% of viewers may experience some sort of problems (and probably are already used to have them, due to their hardware).

Frame repetition means 100% of viewers will have a stuttery viewing experience.

Satisfy the vast majority of customers, or punish all customers because a minority has funky/cheapo hardware?

I'm not recommending anything, but you see in which direction my argumentation is heading. The strictly "least common denominator" is always that: the poorest solution.
(And no matter what you do ... there will always be some customers that can't play your disk correctly, for reasons nobody has thought of.)

[Lyris]

Didee: In principle, I agree with you (well, apart from one thing: I think field-blended interpolation would be the poorest solution).
I'm going to give DGPulldown a look and test the hell out of the disc.

One of the other reasons I'd rather just repeat frames is so that progressive scan equipment's Film Mode Detection can operate and give full vertical resolution. If the DGPulldown method requires a Progressive device to deinterlace in Video mode, then it wouldn't be so great. True, repeating frames will cause stutter, but to me that seems better than flickering in fine details... anyone else's thoughts?

Stephen: it's good to know that discs have gone into replication using this technique. Is it safe to assume they used DGPulldown to achieve that? I don't think any other tools offer this option...

[Mug Funky]

soft pulldown doesn't break compatibility. i've used it quite a few times.

i'll disclaim that by saying i've used it on replicated discs and it hasn't proven a problem. i haven't observed an increase in returned discs beyond the "background level" of discs that are returned to the store because the customer is too daft to wipe their own fingerprints off a perfectly functional disc.

you'll have far more problems with the physical process of replication than with soft pulldown.

that said, a lot of users simply may not notice a problem, or not bother to return a disc if they notice one. it's a tricky area. i was lucky enough to work at a very enlightened authoring house back in the day which had returned discs sent to the office for inspection, and also had online forums where technical questions from customers were addressed directly with the authoring team. during my 2 years, no problems with pulldown came up (many other issues did mind you... only one of these was avisynth related, and i was very embarrassed by my poor choice of the dedot filter on hard pulldowned material).

so... if your authoring software is correct, it will accept the stream you give it, and the replicator will have no issue if the disc compiles nicely.

just be wary of maximum bit-rates, as these will need to be changed.

good luck!

btw, in avisynth, assuming progressive input:

changefps(50)
assumetff()
separatefields().selectevery(4,0,3)
weave()

for upper-field first output

[IanB]

A cunning approach might be to repeat the natural duplicates in lower motion parts of the clip.

Neuron2's Dup filter normally used for making approximate duplicates exact duplicates also can log the metrics to a file. i.e. (Debug=True, Log="log.txt")

A little calcu-processing to find the natural duplicates and insert extra frames there. Probably need some rules like duplicates no closer than 10 frames and no further then 120 frames. As AV sync errors of 200ms are just detectable you could hold upto a 4 or 5 frame deficit for a short while, perhaps including some scene change detection to allow for dumping all the deficit there and maybe even go 1 frame into credit.

For 2.5.8 DuplicateFrame() takes multiple frame numbers to duplicate so you could add say 50 at a time. And Stickboy has a good selection of frame remapping tools.

Just an idle thought.

[Lyris]

What about changing every 25th frame to an average (either blended or motion compensated) of frames 24 and 26? That is, fill in the gap to make the judder a little less noticeable. That way, I could just hand-check each of the synthetic frames for artefacts (it's a 6-minute music video). Can anyone think of a way of doing that with AviSynth? My coding skills aren't quite up to that.

[Mug Funky]

unless you change every frame but the 24th, there'll be noticable motion stammering whichever way you look at it. at least if it's soft pulldown it can be removed, and will give you a handy bitrate advantage.

it'll only really be noticable on smooth pans. if it's a music video it'll probably have tons of fast cuts, and flashing lights, and handheld camerawork. you wont see it on that unless you're unlucky enough to have a dup on a flash, or have very very good eyes.

[Lyris]

Fortunately it doesn't, because I shot it :)
It's an acoustic music video, so it's very slow-paced, no whip-pan camera moves, etc., and all done on a tripod.

[wonkey_monkey]

Could you post a short sample? I'm curious to see if anything can be done with it. Given that it's a slow smooth shoot, it's a shame you've had trouble making a nice mo-comp'd version.

David

[Lyris]

Sure thing. I'll post a short sample of the most nightmarish shot, which shows a tripod pan of a guy playing guitar.
There is actually a similar test clip to this one on the Silicon Optix HQV test disc. Says it all. The funniest thing is, I shot the whole thing knowing full well what the delivery frame rate was going to be; I guess I'm just a glutton for punishment.

When you see the amount of detail in here, I think you'll understand why I really want to encode and playback as 100% Progressive whenever possible.

http://lyris-lite.net/temp/guitarpan.avi (~40mb, Lagarith YUY2) - link active 10 mins after post time

I would have made the disc NTSC, but the 'main event' on it is native 25fps. What a shame you can't mix 50/60hz on DVD (while staying in spec, that is) like you can on BD.

[jpsdr]

For what i know, 'standard' PAL telecine only consist on speedup from 24fps to 25fps. This way, you avoid the off seing... don't know the correct english word... 'glitch' on traveling, introduced by other method. This way give advantage to video over light sound speedup. The other way described in first post, give advantage to sound over video, you'll have a 'glitch' every 0,5s.
The other option is simply to make a Blu-Ray at 24fps. Note, only 720p and 1080p are allowed at 24fps for Blu-Ray, so you may have to upscale your video if it's not at this framerate.

[manono]

This isn't going to break DVD-Video spec compliance, is it?
No.
When you see the amount of detail in here, I think you'll understand why I really want to encode and playback as 100% Progressive whenever possible.
Then I don't see how you have any other choice but to apply pulldown to the progressive 23.976fps video. I don't consider repeating a frame every second or creating a blended frame every second as choices. All the interlaced encoding options will result in the video being deinterlaced along with the resulting quality degradation in most PAL DVD players feeding into progressive displays, as well as the slight stutters twice a second.
The other way described in first post, give advantage to sound over video, you'll have a 'glitch' every 0,5s.
If you're talking about my reply recommending DGPulldown, that's exactly what it aims to avoid.

I got the sample and made a 23.976fps MPV using CCE, followed by applying DGPulldown set for 23.976->25, followed by authoring it for DVD using Muxman, followed by playing it. I tested in both software (PowerDVD) and in my standalone (an Oppo feeding into a Sony LCD HDTV). In both instances it played smoothly with no glitches or repeated frames. I'm in NTSC land and can't vouch for all combinations of players and TVs under all circumstances in PAL countries, but for me it played as I expected it would.

[wonkey_monkey]

Is there a way to make mvtools compensate only for global motion? That at least would fix the stuttering caused by changefps (and to a lesser extent by pulldown flags).

David

[2Bdecided]

It's your decision. But consider ...

Soft pulldown means 99% of viewers will have a smooth viewing experience. 1% of viewers may experience some sort of problems (and probably are already used to have them, due to their hardware).I'm confused about this statement Didée.

As far as I'm aware, the vast majority of DVDs are watched on TVs. On these TVs, a disc with soft pulldown (field repeats) is going to stutter, exactly like the hard pulldown example.

Are you saying there's technology in standard DVD players and TVs to detect this rare kind of pulldown, and switch to 24p on-the-fly?

I know some TVs find 24p-in-60i, remove pulldown, and display it at 72fps - but I haven't seen any TV do pulldown detection of 24p-in-50i to give 48fps or similar. (25p-in-50i is far far more common, and handled by most modern TVs).

Cheers,
David.

[2Bdecided]

Is there a way to make mvtools compensate only for global motion? That at least would fix the stuttering caused by changefps (and to a lesser extent by pulldown flags).DePan can do that. It goes horribly wrong with some footage!

I think I'd do two versions...
1. mo-comped conversion to 25p
2. field-repeat conversion to 25p (with the repeated fields being blends of adjacent ones?)
...and use 1 except where it was nasty, where I'd cut to 2 until the problem went away.

Might be a terrible idea - certainly painful - but if you want to try to get the best for a few minutes of music video it might be worth it.

Would be nice to find the problems automatically and automatically switch between the two!

Cheers,
David.

[Didée]

I'm confused about this statement Didée.
Well okay, my wording was a bit simplistic. I was simply referring to the difference between field repetition (soft/hard pulldown), and full-frame repetition. Of course pulldown will result in slight stuttering, but it's not that bad, it is acceptable. In contrast, the stuttering from full frame repetition is really bad. There were occasions where I stopped viewing such sources I had run over, because I simply could not stand that stuttering: it truly gave me headaches.
Also, note that I still am using CRT tubes, for both PC monitor and TV set. Consequently, I've not that awfully much experience with the behaviours of modern fully-progressive display devices. I'd suppose that even a simple pulldown will look more stuttery on these, compaired to old schoold interlaced TVs.

[StainlessS]

Just a daft suggestion,
Instead of blending to produce a 25th frame, howabout selecting 2 adjacent frames
from every 24 and 'tween' these using MVTools to produce a complete new frame
temporally between the two selected frames, and then add this new
manufactured frame into the sequence.

[Lyris]

Then I don't see how you have any other choice but to apply pulldown to the progressive 23.976fps video. I don't consider repeating a frame every second or creating a blended frame every second as choices. All the interlaced encoding options will result in the video being deinterlaced along with the resulting quality degradation in most PAL DVD players feeding into progressive displays, as well as the slight stutters twice a second.

Encoding as Progressive (with each 25th frame repeated) will allow capable progressive scan DVD players, video processors, HDTVs (etc) to detect the 2-2 cadence with their Film Cadence Detection and stay locked onto it, giving full vertical resolution without jaggies throughout. Anything else is going to require deinterlacing in Video mode (jaggies ahoy).

Thanks for the clarification on compliance, BTW - very good to know.

I think I'd do two versions...
1. mo-comped conversion to 25p
2. field-repeat conversion to 25p (with the repeated fields being blends of adjacent ones?)
...and use 1 except where it was nasty, where I'd cut to 2 until the problem went away.
I'll give this a shot, only instead of #2, I'll do simple frame blending on difficult parts (to stay Progressive).

[StainlessS]

AVISource("D:\avs\testvid.avi").AssumeFPS(24.0) # Any clean test vid
Conv_24_to_25()
return last

Function Conv_24_to_25(clip Last)
{
A=Selectevery(Last,24,0)
B=Selectevery(Last,24,1)
C=Selectevery(Last,24,2)
D=Selectevery(Last,24,3)
E=Selectevery(Last,24,4)
F=Selectevery(Last,24,5)
G=Selectevery(Last,24,6)
H=Selectevery(Last,24,7)
I=Selectevery(Last,24,8)
J=Selectevery(Last,24,9)
K=Selectevery(Last,24,10)
L=Selectevery(Last,24,11)
M=Selectevery(Last,24,12)
N=Selectevery(Last,24,13)
O=Selectevery(Last,24,14)
P=Selectevery(Last,24,15)
Q=Selectevery(Last,24,16)
R=Selectevery(Last,24,17)
S=Selectevery(Last,24,18)
T=Selectevery(Last,24,19)
U=Selectevery(Last,24,20)
V=Selectevery(Last,24,21)
W=Selectevery(Last,24,22)
X=Selectevery(Last,24,23)

Z=Selectevery(24,0,1)
# assume progressive FILM 24 fps source
backward_vec = MVAnalyse(Z,isb = true, truemotion=true, pel=2, idx=1)
# we use explicit idx for more fast processing
forward_vec = MVAnalyse(Z,isb = false, truemotion=true, pel=2, idx=1)
MVFlowFps(Z,backward_vec, forward_vec, num=4, den=1, ml=100, idx=1)
Z=SelectEvery(4,1)
# Return Z # Uncomment to see Synthesized Frames oNLY
Interleave(A,Z,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U,V,W,X)
}

Try above, seems to work ok although looks a bit overcomplicated.

[manono]

Encoding as Progressive (with each 25th frame repeated) will allow capable progressive scan DVD players, video processors, HDTVs (etc) to detect the 2-2 cadence with their Film Cadence Detection and stay locked onto it, giving full vertical resolution without jaggies throughout.
So will encoding as progressive 23.976fps with pulldown.
Anything else is going to require deinterlacing in Video mode (jaggies ahoy).
No. Encoding as interlaced with the duplicate fields already in the video will cause a player to deinterlace (most of them anyway). But even the lousiest flag-reading player will spot the progressive encoding for what it is and ignore the pulldown. I'm assuming a progressive scan player outputting to a progressive display. For an all-interlaced setup there won't be any difference.

I added in a ChangeFPS(25) to the AviSynth script and encoded it as progressive. It looked just the same on my setup as did the one encoded as progressive 23.976fps with DGPulldown applied afterwards. To my surprise, I didn't even find the one stutter every second all that annoying. But I'm in NTSC land and am used to that sort of thing.

About all you can do is to try out the different methods and select the one you like best. But don't rule out progressive 23.976fps with pulldown because of some mistaken impression that it'll force a player into video mode and deinterlace it.

[Lyris]

Aha, that explains our differences in opinion, I think :) My own setup has a dedicated video processor which is fed by a DVD player outputting at 480i/576i over HDMI (the processor does all the cadence detection and deinterlacing). Obviously, it can't communicate with the MPEG decoder and has no access to flags. That would explain the different results.

[Mug Funky]

if it's tripod, acoustic, single camera, then just mvtool or motionprotectedfps the lot to whatever framerate you want. the only artefacts will be on moving hands, and they'll be too slight to notice on realtime playback.

that's what i'd do anyway, if pulldown was out of the question (btw pulldown will be unnoticable is the camera doesn't move)

[manono]

Obviously, it can't communicate with the MPEG decoder and has no access to flags. That would explain the different results.
The Oppos use cadence detection also. I was using flag readers as an example, and the vast majority of the standalone DVD players and most of the software DVD players out there are flag readers. Like I said, the one encoded as progressive 25fps looked the same as the one encoded as 23.976fps with pulldown. So you've tried a number of ways already and noticed obvious differences? Being in NTSC land I can't definitively say how even the ones I encoded for DVD will appear on PAL players outputting to PAL TV sets. But if you have a high-end setup, you'd best test on a number of different systems, including the low-end ones, before deciding how best to handle this.

By the way, I admire your attempts to find the best possible solution - keeping the audio at the correct speed and pitch and figuring the best way to convert the video to PAL specs, at the same time keeping it at the original length. So many DVD production companies would just run it thropugh a cheap standards conversion box and blend the heck out of it, thus forever ruining the video.

[Lyris]

If you're viewing the results on a 60hz monitor, I imagine that will be masking the differences between methods. (Which Oppo, BTW? I have an Oppo DV-980H here which was given to me free since I helped Oppo's European division and Mediatek get 2-2 detection working on it).

Since I still have access to the original music video edit, it may be worth me converting the individual clips to 25fps mocomp and then re-rendering, so all of the difficult fades are re-generated in native 25p by the NLE. That would at least make things a little easier...

[wonkey_monkey]

Here's my effort (requires depan (http://avisynth.org.ru/depan/depan.html)):

i=avisource("guitarpan.avi").crop(8,0,-8,0) # to give depan something to mirror at the edges

data=depanestimate(i)
a=depan(i,data,offset=-0.5,mirror=15)
b=depan(i,data,offset=+0.5,mirror=15).trim(1,0)

mix=overlay(a,b,opacity=0.5)

interleave(i,mix)
selectevery(48,0,2,4,6,8, 9, 10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46) # updated!
# the "9" above is arbitrary - you could choose any odd number as long as it goes in the right place

addborders(8,0,8,0)
assumefps(25)


The big "selectevery" essentially returns the original clip, with an extra frame inserted for every original 24. The extra frame consists of a blend of the frames on either side, motion compensated to each other. This reduces the judder of changefps. The caveat is that this is not a 23.976->25 conversion, but a 24->25 conversion, and you would need to resample the audio (or otherwise compensate for the 1 frame every 40 seconds drift).

I'll keep thinking on how to do a fully global-motion compensated version, which I still think might give you the nicest result. To do a truly 23.976->25 conversion might need a selectevery with 1000 parameters, though!

David

[StainlessS]

@ DavidHorman

Lovely job, works great but on longer clip will produce a few to little frames.
Think perhaps it should read:-
selectevery(48,0,2,4,6,8, 9, 10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46)

ie selecting 24 even frames and 1 odd frame ie 25 out of 48 rather than 26 out of 50. :)

[Lyris]

David: that did the trick, thanks a ton! There were three frames where it produced an unwanted result, I simply deleted these frames "DeleteFrame(xxxx)" and then duplicated a convenient nearby frame "DuplicateFrame(xxxx)" (eg the end of a previous scene) to keep sync as much as possible.

As for having to timestretch the audio, my ear can't personally hear a difference (the running time is changed by 1 second for a 6 minute video). The real test will be whether or not the musician objects :)

[Alex_ander]

I'll keep thinking on how to do a fully global-motion compensated version, which I still think might give you the nicest result. To do a truly 23.976->25 conversion might need a selectevery with 1000 parameters, though!
David

Unfortunately, the sample of that particular footage gives artifacts with mvtools(2) due to fast finger motion across the strings (too low correlation between the frames).
As for hard pulldown, there's no necessity to select in such a complicated way. The 24 to 25 script was invented for speed only and in case 23.976 to 25 (to keep the length), it's just enough to use these lines:

ChangeFPS(50)
AssumeTFF()#the order planned for encoding
SeparateFields()
SelectEvery(4,0,3)
Weave()

or:
ChangeFPS(50)
DoubleWeave()
SelectEvery(4,1)#field order opposite to input

It gives the same playback type as with DGPulldown suggested by manono. The difference is that here you must encode it interlaced and it will also take extra bitrate per frame. The DGPulldown version must work with any standard mpeg2 decoder since it follows current flags (top/bottom_field_first and repeat_first_field) for each encoded frame (doesn't use some "type of pulldown" pointed somewhere). The output to TV is interlaced. The problem is with progressive only displays which force deinterlacing. On interlaced displays it looks quite smooth (I still use such an old TV). Another problem might appear with some authoring applications like DVDLab (it tries to index frames and analyses encoding type by header at this).

[wonkey_monkey]

@ DavidHorman

Lovely job, works great but on longer clip will produce a few to little frames.
Think perhaps it should read:-
selectevery(48,0,2,4,6,8, 9, 10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46)

ie selecting 24 even frames and 1 odd frame ie 25 out of 48 rather than 26 out of 50. :)

Oops, I think you're right! I'll update my post; hopefully Lyris caught your post as well.

I'm guessing the video would be about 9 frames out over 6 minutes. You could fix this by duplicating a few more similar frames, evenly spaced throughout.

David

[wonkey_monkey]

Here's my (probably final) effort:

i=avisource("guitarpan.avi").crop(8,0,-8,0) # to give depan something to mirror at edges

data=depanestimate(i)

p=1
a=depan(i,data,offset=-(1-p*0.04),mirror=15)
b=depan(i,data,offset=+p*0.04,mirror=15).trim(1,0)
mix1=overlay(a,b,opacity=1-p*0.04)

p=2
a=depan(i,data,offset=-(1-p*0.04),mirror=15)
b=depan(i,data,offset=+p*0.04,mirror=15).trim(1,0)
mix2=overlay(a,b,opacity=1-p*0.04)

p=3
a=depan(i,data,offset=-(1-p*0.04),mirror=15)
b=depan(i,data,offset=+p*0.04,mirror=15).trim(1,0)
mix3=overlay(a,b,opacity=1-p*0.04)

p=4
a=depan(i,data,offset=-(1-p*0.04),mirror=15)
b=depan(i,data,offset=+p*0.04,mirror=15).trim(1,0)
mix4=overlay(a,b,opacity=1-p*0.04)

p=5
a=depan(i,data,offset=-(1-p*0.04),mirror=15)
b=depan(i,data,offset=+p*0.04,mirror=15).trim(1,0)
mix5=overlay(a,b,opacity=1-p*0.04)

p=6
a=depan(i,data,offset=-(1-p*0.04),mirror=15)
b=depan(i,data,offset=+p*0.04,mirror=15).trim(1,0)
mix6=overlay(a,b,opacity=1-p*0.04)

p=7
a=depan(i,data,offset=-(1-p*0.04),mirror=15)
b=depan(i,data,offset=+p*0.04,mirror=15).trim(1,0)
mix7=overlay(a,b,opacity=1-p*0.04)

p=8
a=depan(i,data,offset=-(1-p*0.04),mirror=15)
b=depan(i,data,offset=+p*0.04,mirror=15).trim(1,0)
mix8=overlay(a,b,opacity=1-p*0.04)

p=9
a=depan(i,data,offset=-(1-p*0.04),mirror=15)
b=depan(i,data,offset=+p*0.04,mirror=15).trim(1,0)
mix9=overlay(a,b,opacity=1-p*0.04)

p=10
a=depan(i,data,offset=-(1-p*0.04),mirror=15)
b=depan(i,data,offset=+p*0.04,mirror=15).trim(1,0)
mix10=overlay(a,b,opacity=1-p*0.04)

p=11
a=depan(i,data,offset=-(1-p*0.04),mirror=15)
b=depan(i,data,offset=+p*0.04,mirror=15).trim(1,0)
mix11=overlay(a,b,opacity=1-p*0.04)

p=12
a=depan(i,data,offset=-(1-p*0.04),mirror=15)
b=depan(i,data,offset=+p*0.04,mirror=15).trim(1,0)
mix12=overlay(a,b,opacity=1-p*0.04)

p=13
a=depan(i,data,offset=-(1-p*0.04),mirror=15)
b=depan(i,data,offset=+p*0.04,mirror=15).trim(1,0)
mix13=overlay(a,b,opacity=1-p*0.04)

p=14
a=depan(i,data,offset=-(1-p*0.04),mirror=15)
b=depan(i,data,offset=+p*0.04,mirror=15).trim(1,0)
mix14=overlay(a,b,opacity=1-p*0.04)

p=15
a=depan(i,data,offset=-(1-p*0.04),mirror=15)
b=depan(i,data,offset=+p*0.04,mirror=15).trim(1,0)
mix15=overlay(a,b,opacity=1-p*0.04)

p=16
a=depan(i,data,offset=-(1-p*0.04),mirror=15)
b=depan(i,data,offset=+p*0.04,mirror=15).trim(1,0)
mix16=overlay(a,b,opacity=1-p*0.04)

p=17
a=depan(i,data,offset=-(1-p*0.04),mirror=15)
b=depan(i,data,offset=+p*0.04,mirror=15).trim(1,0)
mix17=overlay(a,b,opacity=1-p*0.04)

p=18
a=depan(i,data,offset=-(1-p*0.04),mirror=15)
b=depan(i,data,offset=+p*0.04,mirror=15).trim(1,0)
mix18=overlay(a,b,opacity=1-p*0.04)

p=19
a=depan(i,data,offset=-(1-p*0.04),mirror=15)
b=depan(i,data,offset=+p*0.04,mirror=15).trim(1,0)
mix19=overlay(a,b,opacity=1-p*0.04)

p=20
a=depan(i,data,offset=-(1-p*0.04),mirror=15)
b=depan(i,data,offset=+p*0.04,mirror=15).trim(1,0)
mix20=overlay(a,b,opacity=1-p*0.04)

p=21
a=depan(i,data,offset=-(1-p*0.04),mirror=15)
b=depan(i,data,offset=+p*0.04,mirror=15).trim(1,0)
mix21=overlay(a,b,opacity=1-p*0.04)

p=22
a=depan(i,data,offset=-(1-p*0.04),mirror=15)
b=depan(i,data,offset=+p*0.04,mirror=15).trim(1,0)
mix22=overlay(a,b,opacity=1-p*0.04)

p=23
a=depan(i,data,offset=-(1-p*0.04),mirror=15)
b=depan(i,data,offset=+p*0.04,mirror=15).trim(1,0)
mix23=overlay(a,b,opacity=1-p*0.04)

p=24
a=depan(i,data,offset=-(1-p*0.04),mirror=15)
b=depan(i,data,offset=+p*0.04,mirror=15).trim(1,0)
mix24=overlay(a,b,opacity=1-p*0.04)

interleave(i,mix1,mix2,mix3,mix4,mix5,mix6,mix7,mix8,mix9,mix10,mix11,mix12,\
mix13,mix14,mix15,mix16,mix17,mix18,mix19,mix20,mix21,mix22,mix23,mix24)
selectevery(24,0) # comment this out for 25x slowmo! # selectevery(25,0) would return the original clip

addborders(8,0,8,0)
assumefps(25)

Again, it's 24->25, and it spazzes out when the strumming hand becomes the main area of the clip. You might be able to tweak depanestimate (e.g. dymax=25 for this sample) for each shot but it's probably not worth the hassle. I just like "solving" things :)

David

[2Bdecided]

Since I still have access to the original music video edit, it may be worth me converting the individual clips to 25fps mocomp and then re-rendering, so all of the difficult fades are re-generated in native 25p by the NLE. That would at least make things a little easier...Ah, you didn't mention that before.

With "typical" music video (which this isn't), you have lots of cuts - usually more than 1 a second.

This means you can simply run the 24fps footage at 25fps - and edit it to match the original audio track.

Since each clip is on-screen so briefly, it never gets chance to go visibly out-of-sync.

Problem solved!

But if you have longer clips in the video with visible elements that are co-timed with the music, it won't work at all. It'll drift out of sync by one frame per second, which is easily visible after, er, a second!

Cheers,
David.

[Emulgator]

Lyris:
I have an Oppo DV-980H here which was given to me free since I helped Oppo's European division and Mediatek get 2-2 detection working on it).

As long as the people who could know more are still around here
(Lyris, manono and hopefully many others...):

In DVD-Video there is a provision for a "Film" flag, DVD-legal exclusively on PAL DVD-Video.

I am not too sure what it actually controls.
(May it be 2:2 pulldown, may it be playback of 25p as 25i, vice versa...?).

Could you enlighten me a bit? DVDlab does not mention it. Encore, DVD-A: no mentioning.

PGCEdit allows control, but rolZ did not explain further as I remember.
A search was not too satisfying and forgive me for not opening a new
thread.

[Lyris]

As far as I know, there's a couple of clues that a PAL DVD can give to the player to say "I'm progressive, go into Film deinterlacing mode".

There's this one which is what I think you're talking about, but I've heard so little about it that I don't know how it will behave "out in the field": http://forum.doom9.org/showthread.php?t=151402

And also the "Progressive" attribute that some MPEG2 encoders write into the Sequence Display Extension part of the video stream (although if I recall correctly, my weapon of choice, Cinema Craft SP2, doesn't include this part at all).

And then there's just encoding Progressive frames inside the stream, which very few PAL Film DVDs seem to do (lazy encoding or "pro" encoders that don't allow for this to be set?)

Whatever these functions were intended for, most of the players I've seen tend not to be swayed by flags too much, and just run everything through the player's own cadence detection. In other words, they second-guess everything, which makes sense since these flags are rarely set correctly.

[Alex_ander]

PGCEdit allows control, but rolZ did not explain further as I remember.

The film/camera setting had been included in DVDRemake before it appeared in new versions of PGCEdit (after some discussion in another section) and it also had been included in ifo tables published by mpucoder.
http://www.mpucoder.com/DVD/ifo.html

Most likely that setting is intended to instruct a DVD player at letterboxing anamorphic 16:9 for a 4:3 display. In case video is progressive it is safe to modify image height without deinterlacing (which usually degrades quality). In case of NTSC it can't be used since the output of MPEG2 decoder is interlaced even in case of soft pulldown (it's the task of that decoder to follow pulldown flags). That is why it is only defined for PAL sped-up from film. I didn't see that setting in authoring applications however, and can't remember it used in any DVD I opened in DVDRemake. But it can be easily set in both DVDRemake and PGCEdit (with hope some DVD players make use of it).

[StainlessS]

Function FPS_23_to_25(clip Last) {
# Generic Progressive 23.976 FPS to 25 FPS
# NEED TO CROP BORDERS FOR DEPAN MIRROR AND REPLACE AFTER CALL
Return FPS_23_to_24().FPS_24_to_25
}

Function FPS_24_to_25(clip Last) {
# Modified from Original By DavidHorman
# NEED TO CROP BORDERS FOR DEPAN MIRROR AND REPLACE AFTER CALL
data=depanestimate(Last)
MixA=depan(Last,data,offset = -0.5, mirror = 15)
MixB=depan(Last,data,offset = +0.5, mirror = 15).trim(1,0)
Mix=Overlay(MixA,MixB,opacity=0.5)
Interleave(Last,mix)
Selectevery(48,0,2,4,6,8,10,12,14,16,18, 19 ,20,22,24,26,28,30,32,34,36,38,40,42,44,46)
return Last.AssumeFPS(25.0)
}

Function FPS_23_to_24(clip Last) {
# Generic Progressive 23.976 FPS to 24 FPS
# Inserts synthesized frame, every 999 source frames starting @ dest 499,
# ie Floor((999/2)+0.5) = 499.5+0.5 = 500, 500th frame is 499 (1st frame 0)
# , eg New Destination Synthesized frames @ 499, 1499, 2499 etc
# NEED TO CROP BORDERS FOR DEPAN MIRROR AND REPLACE AFTER CALL
Return __FPS_23_to_24__().AssumeFPS(24.0)
}

GScript(""" # GScript, Language extension, If, While etc (c) Gavino
Function __FPS_23_to_24__(clip Last)
{
# Lo Level (Should Not Be directly called)
Cnt=FrameCount()
if(Cnt >= 500) {
In = Last
Last=In.Trim(0,498) # 499 Frames, incl 1st of Blend Pair
Mix = __FPS_23_to_24_Blend__(In.Trim(498,499)) # Blend Pair frame
Last = Last + Mix + In.Trim(499,-1) # Add Synthesized frame & 2nd of Blend pair
if(Cnt>500) {
if(Cnt<=999) {
Last = Last + In.Trim(500,0) # No More to do
} else {
Last = Last + In.Trim(500,998) + __FPS_23_to_24__(In.Trim(999,0))
}
}
}
Return Last
}
""") # End GScript, Language extension, If, While etc (c) Gavino


Function __FPS_23_to_24_Blend__(Clip Last) {
# Lo Level (Should Not Be directly called)
# Blend 1st 2 frames together returning single frame clip
# Could alter to suite as required
# Modified from Original By DavidHorman
data=depanestimate(Last)
MixA=depan(Last,data,offset = -0.5, mirror = 15)
MixB=depan(Last,data,offset = +0.5, mirror = 15).trim(1,-1)
return Trim(Overlay(MixA,MixB,opacity=0.5),0,-1)
}

AVISource("D:\avs\GuitarPan.avi")
Crop(8,0,-8,-0)
FPS_23_to_25()
AddBorders(8,0,8,0)
return last



This is a little generic Progressive FPS conversion stuff for:-
23.976 to 24 FPS
24 to 25 FPS
23.976 to 25 FPS

Requires GScript (c) Gavino
(Great stuff Gavino, 1st time used it)

:)

EDITED As per post #49.

[StainlessS]

@ DavidHorman

Sorry to correct you again, in your "Probably Final Effort" you used addborders(8,0,-8,0).
The Negative RHS border gives a weird and I am sure unanticipated result.

Also, see code in previous post, I used your original posted code.

:)

[wonkey_monkey]

@ DavidHorman

Sorry to correct you again, in your "Probably Final Effort" you used addborders(8,0,-8,0).

:)

Never be sorry about correcting me! I've edited the original post.

David

[Emulgator]

Thank you, Lyris and Alex_ander!

This link to the other post in dvdafteredit forum helped

(by bigotti 5):
1. Camera mode - a temporal shift of 1/50sec between the odd and even fields
Film mode (only valid for PAL DVD) - no temporal shift (each field of a frame is recorded at the same time), progressiv scan

I have to restore some film footage (which was brought on 25i) back to 25p.
I get very useful results using avisynth and TGMC, MCSpuds and the like.

Now after encoding such 25p footage for DVD (so no matter if encoded as genuine 25p or as 25i containing 2 fields from the same frame);
after authoring I may set this flag to Film mode and may hope that some DVD player will do the right thing while handling this.

[type1encryption]

I'm not into professional DVD mastering, but I once ran into the same situation as you and decided (after some experiments) to speed up the a/v.


those 2.5 % or w/e weren't as noticable as mediocre or even accaptable stuttering/artifacts (mocompensation with mvtools).

[Gavino]

I know this is an old thread, but I got a PM from a user who reported that StainlessS's script above in post #44 fails with the error:
Script error: there is no function named "__FPS_23_to_24__"

He reported it to me as it seemed to be connected with GScript, and he was able to fix it by moving the function header outside the GScript call, changing
GScript("""
Function __FPS_23_to_24__(clip Last)
{
...
}
""") # End GScript
to this:
Function __FPS_23_to_24__(clip Last)
{
GScript("""
...
""") # End GScript
}
This puzzled me since GScript is designed to support entire function definitions as well as simple code fragments.


However, the script above fails because GScript is never called at all, as the call is after the end of the script ('return last').
The solution is to move the script lines so that they come [i]after the call to GScript (for example at the end of the file).

GScript("""
Function __FPS_23_to_24__(clip Last)
{
...
}
""") # End GScript

AVISource("D:\avs\GuitarPan.avi")
Crop(8,0,-8,-0)
FPS_23_to_25()
AddBorders(8,0,8,0)
return last
The other function definitions (outside GScript) can come anywhere as they are seen directly by the standard Avisynth parser.

[StainlessS]

The difference is probably imperceptible unless the function is called very many times - that could apply here since StainlessS's function is recursive, so that's perhaps why he put the whole thing inside GScript.]


The reason for moving the 'Gscript' outside was due to this post:

Thanks, StainlessS. Interesting example.

Although it doesn't actually seem to be a problem, you could eliminate the recursive call to GScript itself by defining the entire function within GScript, ie
GScript("""
Function __FPS_23_to_24__(clip Last)
{
...
}
""")

Of course, the function itself would still be recursive.
I wondered if that recursion could be easily removed by using a 'while' loop, but I think your algorithm is easier to express recursively, as you have done.

http://forum.doom9.org/showpost.php?p=1354783&postcount=23

I think I must have just edited the post and not actually tried out the altered script, I shall edit as suggested.