Log in

View Full Version : From FR 47.952 to 23.976 using Decimate


f@chance
9th October 2005, 01:46
Some AVI footage has an odd frame rate of 47.952 I would like to reduce this to 23.976 and then appy pulldown or go from 47.952 to 29.97.

The pattern of the frames is as follows:
AABBCCDDEEEF...
and then the pattern repeats itself again.

I have used the following entry in the AVS file:

selecteven().Decimate(cycle=12)

It is OK but at certain times it ia a bit jerky. Can anyone please help me in getting the correct entry for reducing the frame rate.

Thanks

actionman133
9th October 2005, 10:55
So, for every 6 frames, the first 4 are duplicated, the fifth is tripled, and the sixth remains single?

If that pattern is constant throughout the whole clip, then try simply adding SelectOdd () - without the 'SelectEven ().Decimate () line. SelectOdd () on the original will choose every second duplicate, the middle of the fifth range, and the sole sixth frame.

If that works out, then you can adjust the script with Merge () to blend the duplicates together and reduce the digital noise....

That should reduce it to 23.976 fps, and you then can use standard telecine to convert it to 29.97 fps.

Let me know how it turns out...

f@chance
9th October 2005, 11:10
So, for every 6 frames, the first 4 are duplicated, the fifth is tripled, and the sixth remains single?

If that pattern is constant throughout the whole clip, then try simply adding SelectOdd () - without the 'SelectEven ().Decimate () line. SelectOdd () on the original will choose every second duplicate, the middle of the fifth range, and the sole sixth frame.

If that works out, then you can adjust the script with Merge () to blend the duplicates together and reduce the digital noise....

That should reduce it to 23.976 fps, and you then can use standard telecine to convert it to 29.97 fps.

Let me know how it turns out...
Thanks a lot that is a brilliant idea, don't know why I didn't try it but would it not select the first & the last from the first & last frame of the triple frame? If it makes any difference I am using the AVS script to frameserve CCE to encode it into a DVD MPEG2 stream. I just ran a 2000 frame test clip with just the select ODD and it works. What would be the AVS line for standard telecine and is Merge() a part of the standard AVISynth commands?

In my case for encoding it to MPEG2 what would be the difference to use pulldown verses telecine?

Sorry for the many questions but this frame rate conversion had me baffeled even after searching the site and thanks for your help, for the posts on telecine and IVTC are filling volumes :)

actionman133
9th October 2005, 12:57
Not to frustrate you by not answering you question or anything, but did using SelectOdd () provide a smooth output? Because, in all honesty it would be pointless to think about telecine and Merge () in this context if SelectOdd () wasn't working...

actionman133
9th October 2005, 13:28
So if using SelectOdd () works, then this script would be useful in using Merge () to blend the duplicated frames together. And Merge () is a standard command in the latest version of AVISynth (my version is 2.56 built on on July 10, and I have it available).

So here is the script:


a = SelectEvery (12, 0)
b = SelectEvery (12, 1)
c = SelectEvery (12, 2)
d = SelectEvery (12, 3)
e = SelectEvery (12, 4)
f = SelectEvery (12, 5)
g = SelectEvery (12, 6)
h = SelectEvery (12, 7)
i = SelectEvery (12, 8)
j = SelectEvery (12, 9)
k = SelectEvery (12, 10)
l = SelectEvery (12, 11)

NewA = Merge (a, b) #Merge the duped A frames
NewB = Merge (c, d) #Merge the duped B frames
NewC = Merge (e, f) #Merge the duped C frames
NewD = Merge (g, h) #Merge the duped D frames

TempE = Merge (i, j) # Merge 1st and 2nd 3 E frames
NewE = Merge (TempE, k, 1/3.0) # Merge the previous E frames with
# 3rd. Result is 33% weight to all 3 dupes

NewF = l # The sole 6th frame

Interleave (NewA, NewB, NewC, NewD, NewE, NewF)


That should give you 23.976 fps video with the duplicated frames blended together. There should be no visible blends of different frames if you scroll through in VDub or whatever program you use.

And to answer your other questions, telecine and pulldown (technically it's '3:2 pulldown', but who cares? :cool: ) are different names for the same process. It isn't a standard command but it is easily achieved with internal commands.

Whether or not you should use telecine depends on your source? Are you outputting for DVD to watch on a TV, or for a video you'll your computer? If it's for DVD your DVD encoder might option progressive encoding. That means it will take your 23.976 fps source and save it as is. Then when it is played back, it will do the telecine in the player (meaning you do nothing :p ).

If it's a cheaper DVD program, it might not offer pulldown/telecine on playback. If that's the case, there is a simple telecine script in AVIsynth's help. It's in the second box on the SelectEvery () page (which is in the 'Editing' section). Just copy and paste that on to the end of the script I provided above.

If it's just for computer, I recommend leaving it alone. Telecine is designed for TV only, and it looks bad on a computer.

PS. I didn't test my script on a video so it may not be perfect. If there seems to be any problems, let me know and I'll run a test. (I'm a little rushed because I SHOULD be studying :D )

Anyway best of luck with the script, hope it works, and let me know how it turns out (don't expect a reply until tomorrow though)...

f@chance
9th October 2005, 13:40
Thanks a million I will try this script later this evening. I do plan to play this back with a stand-alone DVD player over my system. The DVD player is a Sony 930 and it does progressive PAL/NTSC playback. No playback on computer screen.

I do run the latest AVI Synth and for pulldown I use DGPulldown 1.45. The source for this was ABC's HDTV 1280x720p encoded into XVid 960x528.

Thanks alot for your help and studying is one of life's necessary evils, because many of us would either be watching telly or writing code :D Don't worry no rush on this since I have fiddle with this for a week now

Guest
9th October 2005, 16:00
I use DGPulldown 1.45. That's a neat trick, considering that the latest release is 1.0.3.

f@chance
9th October 2005, 20:19
That's a neat trick, considering that the latest release is 1.0.3.
Oh well trying to help you out there, I guess DGIndex is 1.45 and it is a very excellent utility I might add.

actionman133
10th October 2005, 13:54
Thanks a lot that is a brilliant idea, don't know why I didn't try it but would it not select the first & the last from the first & last frame of the triple frame?

Sorry that I didn't answer this before but there is a simple answer to it. Frame numbers start from 0. The first frame is 0, the second is frame 1, etc. SelectEven () and SelectOdd () select the even and odd frame numbers respectively.

So, SelectOdd () picks frame 1, which is the second frame of the video. That means SelectOdd () picks up the 2nd of each of the four duplicates, the middle of the triplets and the sole final frame.

studying is one of life's necessary evils, because many of us would either be watching telly or writing code

lol! I do those *while* I'm studying!! Hell, I was doing all of that last night! It make no difference, man! ;)

MOmonster
11th October 2005, 11:31
The first time I looked at your pattern, I thought it would go further this way:
AA BB CC DD EE EF FG GH HI IK KK...
Or am I wrong. So also selectodd() wonīt help. Selectodd and selecteven will produce a dup all 11 frames. So decimate(11) is the right way after. For blending the duplicates together, blendbob seems to be a good way (if necessary).
If the decimater still doesnīt work good enough, you can also try tdecimate with a higher maxndl (only mode 2).

f@chance
11th October 2005, 13:48
It looks like that later on in the footage the cycle changes to a just plain double frame pattern. This is the most messed up footage I have come across sofar.

I have tried just the selecteven() and then encode it with CCE to MPEG2 and it seems to be as smooth as the original played back on a PC, but I have only tested the first 3 minutes.

I now have encoded the whole 42 minutes with selectodd() also with actionman's function and will now try the decimate(11).

Each encode is 6 hours plus authoring to DVD burning to DVD+RW and playing it over my system and checking for errors. This is spending time that I rather watch the damn thing then fixing it. But what you all don't do for friends that want to borrow it and I am sure after all this work someone will say, I don't know but it played back on my system a bit jerky did it do that on yours too :angry:

actionman133
11th October 2005, 13:56
Hey, fchance, post a sample of your source online if you can. I'll take a look at it and find out exactly what it's like. Admittedly I've never enocuntered a source with such a pattern...

f@chance
12th October 2005, 10:20
Sorry for taking so long but I needed to find a decent public sharing site. Here is the sample of the AVI file (http://box.net/public/next2last/files/968530.html) the first few minutes and the RAR file is password protected since I share this site. The password for extracting is:

doom9

Thanks for your help and see what you make out of it. At about frame 2280 a sequence starts that it jerky.

actionman133
12th October 2005, 12:54
Hey f@chance,

I had a look at the video, and I can only come up with a simple, but not 100% effective solution. There doesn't seem to be an actual pattern to which frames are tripled, or doubled. I'm quite sure that the tripled frames are more common in the car conversation than in the following paramedic scene.

The way I look at it, what you need to do is for every pair of frames, you want the one which is more unique to the one before it.

I tried Decimate (2) on the source, which came out quite well. Some stutters in the conversation in the car before the crash, but the paramedic bit came out quite well. It's not perfect but it is reasonable.

I don't know if you'll be able to do better than that, honestly. I'm not so good when patterns aren't consistent... maybe someone else might be able to help you...

Sorry mate, but good luck with it.

PS. One suggestion though... you should do rough encoding jobs. By one of your earlier posts, its sounds like you encode the whole thing and burn it to DVD. If so, I'm sure you've realised it's quite inefficient (6 hours as you said).

What you should to reduce that is lower the resolution of the clip (480x264 is a good size, for example) and encode a 10 minute section or so on the fastest DivX settings. If you like that, then do a full length encode of the whole video in DivX (still fast settings and small frame size). If *that* turns out good, then commit to the 6 hour job. It will save you a lot of time and frustration...

f@chance
12th October 2005, 13:20
Thanks a lot for your help and the quick reply. I had come to the same conclusion regarding the decimate(2) and I presume that is decimate(cycle=2).

As a matter of fact my very first encode was just that and I looked at it and it was watchable. I have tried two other settings and when burning to DVD+RW the 3 different encodes I will see what I like and if there are any audio sync issues.

You are correct regarding the encode and thanks for the resolution settings. Normally I never run into issues with frames or other hazzles in the video clips. It is either glitches (nothing you can do about that except cut out the frames) or audio sync problems. This is the first time I have had such weird frame rate and picture pattern.

I may also use perhaps another one of the suggestions made by MOmonster.

Thanks again.

MOmonster
13th October 2005, 09:50
This source remind me on a problem in the german Forum. Its a bit different, but there are simple progressiv parts in the source and than fieldshifted parts, because there are two fields doubled every 11 Frames. I work on a solution for it, but wonīt have time before this weekend. Maybe you can use it also for this source (if you use only the fields or I modify the function).

f@chance
13th October 2005, 14:03
This source remind me on a problem in the german Forum. Its a bit different, but there are simple progressiv parts in the source and than fieldshifted parts, because there are two fields doubled every 11 Frames. I work on a solution for it, but wonīt have time before this weekend. Maybe you can use it also for this source (if you use only the fields or I modify the function).
Thanks for the help. I checked several of your posts and have tried some of the suggestions you offered like:
TDecimate(mode=2)
TDecimate(mode=7)
TDecimate(mode=2, maxndl=2)

The TDecimate mode 2 & mode 7 look better then the Decimate(2) or the SelectOdd. For me it is difficult to get a maxndl value that is optimal. I will try a higher one. The size difference in 6000 double frames between non maxndl & maxndl=2 is only a few kBytes. However the jerky scenes sofar have improoved.

Thanks for all the help with this video clip.

MOmonster
14th October 2005, 11:10
There is no difference, if you set maxndl 2 or not. If you donīt set it, tdecimate set it automatically. Only 3 makes sense here. But I only said it for the possibility: selectodd (selecteven) and than decimate(11) or tdecimate with the right framerate. If decimate donīt catch all dups, than tdecimate(maxndl > 11) can help.
This weekend Iīll have a look at your source (here I canīt).
The problem is more to find the parts with these dups and the parts that shows the plain double frame pattern.
If tdecimate(mode=2,rate=23.976) works good enough for you than keep it. Maybe it is worth to try a lower framerate (between 22 and 23.976fps), but this will kill frames in the double frame patterns.
The only nice way is to detect the different parts (by hand or automatical) to work on the separated source.
If the output from tdecimate is acceptable for you there is still the possiblility to overblend the left doubles. This makes the motion a bit smoother, but donīt have the big effect.
Weīll see tomorrow. ;)

f@chance
14th October 2005, 15:46
Thank you very much I will check in egularly to see what verdict you came up with. Thanks for yor efforts.

MOmonster
14th October 2005, 22:31
So I had a look at the source. I was wrong with the pattern. Every triple is followed by a single. There is no real pattern, sometimes there is a triple and sometimes not. But because we have 23.976 different Frames every minute you can just use tdecimate(mode=2,maxndl=3). The result looks ok on my pc. ;)

f@chance
16th October 2005, 20:35
Thanks for your help and I cam across the same conclusion that there is no rhyme or reason to the framerate and patterns.

Thanks again for your help and I will use the TDecimate(mode=2,maxdnl=3)

f@chance
17th October 2005, 23:14
MOmonster,

Just finished encodong and authoring the clip with TDecimate(Mode=2, maxdnl=3) and it looked good. The autoring software DVD Maestro said 29.976 FPS Drop and I was worried that I would run into sync problems but not a bit.

So, thanks a lot again for halping in cleaning up someone else capture that was pittyful.