Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
21st February 2012, 00:51 | #2 | Link | |
Registered User
Join Date: Sep 2007
Posts: 5,346
|
Quote:
You cannot do a "linear" fps conversion without dropping or inserting frames, or resampling, because 24 isn't evenly divisible by 60 You could use mvtools to interpolate 60fps => 120 fps, then every frames will be evenly spaced because 120/5 = 24, if that's what you mean by linear. You might use mflowfps for this |
|
21st February 2012, 04:56 | #4 | Link |
partially-informed layman
Join Date: Jan 2002
Location: Bangkok, Thailand
Posts: 314
|
Maybe this?
Code:
super = MSuper(pel=2) backward_vec = MAnalyse(super, isb = true) forward_vec = MAnalyse(super, isb = false) MFlowFps(super, backward_vec, forward_vec, num=24, den=1, blend=false) |
21st February 2012, 09:21 | #5 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
But that's not "simple" either ...
Problem is you can't even do blended 60->24 with ConvertFPS in one go. New rate may not be smaller than 2/3 of original rate. (60 -> 40 -> 26.6 ->...) Bigger ratios can be achieved with "BlendFPS", part of "motion.dll" of mg262. But same as ChangeFPS, both don't have any scenechange detection or handling. Maybe you could arrange with Code:
temporalsoften(1,255,255,20,2) # frame blending, scenechange aware ChangeFPS(24.0) That's quick and easy, however with slightly incorrect weighting. (3-to-1 blending) More "correct" for 60->24 (2.5-to-1 blending) would be Code:
interleave(last,last) temporalsoften(2,255,255,20,2) ChangeFPS(24.0) To improve beyond that, you'd need SCSelect() (removedirt.dll), and a few lines of script fiddling.
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) Last edited by Didée; 21st February 2012 at 11:12. |
21st February 2012, 11:17 | #7 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
Scene change detection is not simple to start with. You can't even make an ultimate definition what is a scenechange and what is not. (Partial crossfades, identical scene but 50% of a frame changes due to an explosion, flashlight, etc.pp.)
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) |
21st February 2012, 12:35 | #8 | Link |
Registered User
Join Date: Nov 2004
Location: Poland
Posts: 2,843
|
I know- but pure scene changes are easy no? It wont work 100% accurate, but I assume 90% can be detected properly and this already make massive difference.
Cinemacraft encoders do very accurate scene change detection |
21st February 2012, 12:55 | #9 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
However. You have a working solution presented above. Sink or swim.
BTW, an encoder has more freedom in its decisions, or: false decisions just cost more bits that must be spend, but are not necessarily visible. Image processing is another ballgame: make scenechange decision more aggressive, the user will whine bohoo when a certain conficuration triggers but the user don't like. Make scenechange decision less aggressive, the user will whine wuhuu when a certain situation will not trigger but the user would like to. Again: frames A-B are basically identical, but frame B has 50% area changed due to flashlight or explosion. Scenechange? Not a scenechange? You can have opinions, but there is no definite answer. Also, there's the arguing: "if the user chooses frame blending for a conversion, then we're not talking "high quality", hence no need to make big efforts".
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) |
21st February 2012, 14:11 | #10 | Link |
Registered User
Join Date: Nov 2004
Location: Poland
Posts: 2,843
|
60p to 24p looks quite fine with simple blending- better than most motion adaptive methods, which introduce much more visible for eye artefacts.
24p is jerky by nature anyway- so blurring due to conversion is actually not that big problem. Not clean scene changes are very visible in some cases. |
21st February 2012, 14:45 | #11 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
Blurring is not a problem indeed (in particular motion blurring...). But frame blending is not blurring. It's simply "ghost images".
Also, there might be a worthwhile difference between the view point of the creator (probably working on a "simple" PC monitor), opposed to the potential end consumer, who might be watching on a modern TV set with full-blown motion-magic-wizardy. A strobing-sharp video can be made look good by such a TV. But if the creator introduced frame blending, the game is lost from the start: if ghost images are in the source, no TV can make it look good again.
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) |
21st February 2012, 15:36 | #12 | Link | |
Registered User
Join Date: Dec 2002
Location: UK
Posts: 1,673
|
Quote:
But don't add ghosting by blending. It's not quite so bad on dumb CRTs, but as Didée says, modern TVs make it look horrible. IMO even normal PC playback makes frame blending look extra horrible - I'm not sure why it looks worse. Maybe it's the non-integer conversion from 24fps to whatever refresh rate the monitor runs at lets some of the ghosted frames stay on screen for even longer than they should. (like pulldown, but not always regular/predictable). Cheers, David. |
|
21st February 2012, 15:53 | #13 | Link | |
Registered User
Join Date: Nov 2004
Location: Poland
Posts: 2,843
|
Quote:
|
|
21st February 2012, 16:02 | #14 | Link | |
Registered User
Join Date: Nov 2004
Location: Poland
Posts: 2,843
|
Quote:
I tried all methods- from simple software to best available motion adaptive ones (including Alchemist which wasn't very good at all). None of them is very good and simple blending (even if it has ghosting) is as good- just problem with scene cuts. It also takes fraction of time compared to other methods. |
|
21st February 2012, 16:34 | #15 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
Well okay. Since you know the holy truth what is best, we don't need to argue. Your best solution is in post#5.
Here's another best solution, using BlendFPS (motion.dll) and SCSelect (RemoveDirt.dll) Code:
video_60p a = ChangeFPS(24) b = BlendFPS(24) # ,aperture=0.8) # ? tweak so that only double-images are produced, but no triple-images ? a.SCSelect(a,a,b,dfactor=4.0) # dfactor = scenechange sensibility
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) |
22nd February 2012, 10:28 | #17 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
Accidentially, I remembered a quote of Tom Barry (trbarry) from many years ago:
"The best way to make a colorspace conversion is to not do it." This applies 1:1 to the term "framerate conversion".
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) |
Thread Tools | Search this Thread |
Display Modes | |
|
|