Log in

View Full Version : 720p 60 fps to 24 fps decimation?


karl_lillevold
9th February 2004, 22:58
I just ran into a new type of source material, to be encoded for demo purposes. It is 1280x720p at 60 fps, where the pattern is as follows: 3 repeated frames, 2 rep, 3 rep, 2 rep etc. It is all progressive, so all I need to do is decimate in the right pattern. However, I know no filters that can do this. It is easy enough to write one, but alas, too little time. Any ideas for existing filters?

sh0dan
9th February 2004, 23:06
I'm not in my homefield here, but SelectEvery(5,0,3) sounds like it might do the job.

You should end up with a 12fps movie them. Sounds like it might be a native 24fps movie with every second frame animated.

Dali Lama
9th February 2004, 23:09
Hi Karl,

Have you tried to perform multiple decimates?:

Decimate(2)
edit: -> Decimate(5)

Or perhaps the separate filter MultiDecimate from Donald Graft? I havn't used that one to comment on though.

Good Luck,

Dali

karl_lillevold
9th February 2004, 23:34
SelectEvery(5,0,3) does exactly what is needed. The 60 fps source is converted to 24 fps. Thanks!

karl_lillevold
10th February 2004, 03:32
If only.... turns out the source did not maintain an accurate pattern. It changes every 20-30 seconds, causing the SelectEvery to get out of whack. I am looking into MultiDecimate now, but it has trouble during static scenes, and I worry about audio sync problems.

sh0dan
10th February 2004, 09:29
Ok - another try:


Decimate(5)
Decimate(4)
Decimate(3)


... again - just guessing here. ;)

This will produce 24fps material, so using your dropdupe filter in RV might be a good idea.

AS
10th February 2004, 11:31
60 -> 24

#telecide(order = fieldorder,post=1. vthresh=255) # optional, but decimate works better when hinted by telecide. Make sure you get the correct field order
decimate(cycle=2) # 60->30
decimate(cycle=5) # 30->24

sh0dan
10th February 2004, 11:39
@AS: If the material is progressive, what how can Telecide help? (Setting field order for progressive material seems like a contradiction in itself).

My reason for not using Decimate(2) was that is is the same as doing SelectEven. It will not be able to do a good selection of which frame to decimate (as it always has to delete one of two frames, without looking outside the cycle).

karl_lillevold
10th February 2004, 19:40
Thanks, the problem is everywhere the pattern breaks, and fixed pattern decimation does not work. I do not know why the pattern is not 100% accurate. Perhaps as a result of the film scanning process and that 24 fps -> 59.96 needs adjusting every so often, as opposed to 24 -> 60, where 3-2-3-2 should have worked.

I got a tip from neuron2's Video Processing forum, which suggested smartdecimate(24,120). I had to add option tel=1.0 to prevent it from 'bob'-ing frames during static scenes where it has trouble detecting the pattern. So smartdecimate(24,120,tel=1.0) works well.

Multidecimate resulted in small hickups every so often, and audio sync skewed (framerate becamse 24.5 fps instead of 23.976 fps as well)

I could have encoded 60 fps directly and used my DropDupe filter, this is true, but I wanted to see if I could find a way to convert the source first, never having run into it before. We are likely to have to deal with it again later. I would have probably needed to tune DropDupe for this particular source as well, and also, I needed to encode multiple times at multiple resolutions, and then conversion beforehand results in faster encodes.

scharfis_brain
10th February 2004, 19:46
What happens, If you're first reinterlacing the source to 60i and then doing an IVTC?

like this


separatefields

selectevery(4,0,3) #or (4,1,2) #don't know now
weave()

smartdecimate(24,60,tel=1.0) #or telecide(post=0).decimate(5)

karl_lillevold
10th February 2004, 21:19
SmartDecimate(24,120,tel=1.0) actually works well. I found one hickup in the result though, where it looks like your latest suggestion handles it, but have not looked at the whole file with it yet. Thanks!

[just to make sure: the source is completely progressive, no telecine or combing, just repeated progressive frames]

karl_lillevold
21st March 2008, 19:09
I have another 59.97 fps HD video with repeated frames, that I need to convert to 23.976 reliably. I admit I have not been keeping track of recent developments, and I could not find other threads than my own when searching.

Does anyone have any recent suggestions on this topic?

Karl.

karl_lillevold
21st March 2008, 19:35
It seems SmartDecimate will not work in recent Avisynth versions, but I believe Donald Grafts's MultiDecimate will do the trick.

I tested it with "Remove duplicates: Cycle-based: Naive", removing 36 out of every 60 frames, and my test video looked fine. Now on to processing all 30 GB, which will take a while.

tuprware
31st March 2008, 23:28
It seems SmartDecimate will not work in recent Avisynth versions, but I believe Donald Grafts's MultiDecimate will do the trick.

I tested it with "Remove duplicates: Cycle-based: Naive", removing 36 out of every 60 frames, and my test video looked fine. Now on to processing all 30 GB, which will take a while.

Did this work for you? I'm trying to convert JVC 24p to 23.976 with not great success.

NerdWithNoLife
1st April 2008, 00:33
I've done it this way:SelectEven().Decimate(5)
I think Decimate(2) followed by Decimate(5) is excessive because select even should effectively do the same thing, but it doesn't need to know how similar the frames are - Decimate(5) will take care of that.

rebkell
1st April 2008, 00:58
TDecimate(CycleR=3) will remove the 3 frames with the least change in them, it works great on all the 720P Fox and ABC broadcasts for me, if it's a straight 3:2 cadence, it works great and is very fast. You can add display=true if you want to step through and see exactly what frames are being decimated.

McCauley
1st April 2008, 15:25
Hi,

i'm currently confronted with the same problem. This is what i did:
dup(threshold=1.7, copy=true, blend=true)
fdecimate()
If you don't have a very clean source, you can change the threshold parameter to something like 2.5 (or leave it at the default of 3).
The dup() call reduces noise a bit while (almost) not touching the details, or sometimes it improves the details, because the blended picture is the average from a good and worse frame, so fdecimate() cant pick the worse frame while skipping the good one.

Regards
McCauley