Re: [MEncoder-users] inverse telecine with 60 fps progressive video
But doesn't interlacing pairs of frames together effectively eliminate every other frame anyway? Won't tinterlace combine two different frames at the end of the three-frame sequence making an ugly frame? I don't see how merging frames together into distorted frames will help the inverse telecine filter know what to do but I'll see if it helps.
On Thu, Apr 07, 2005 at 10:55:27PM -0800, Scott W. Larson wrote:
But doesn't interlacing pairs of frames together effectively eliminate every other frame anyway? Won't tinterlace combine two different frames at the end of the three-frame sequence making an ugly frame? I don't see how merging frames together into distorted frames will help the inverse telecine filter know what to do but I'll see if it helps.
No, it doesn't just drop every other frame, interlacing the frames means just that, it takes every 2 frames and turns them into 1 frame by interlacing them together to a double hieght frame. The source is like this: 1 1 2 2 3 3 3 4 4 5 5 5 6 6 after tinterlace, you get this: 1 2 3 3/4 4/5 5 6 (double hieght) and after pullup, you get: 1 2 3 4 5 (still double hieght) If you were to just drop every second frame, you'd still get a lot of duplicates (1 every 5 frames). And because the phase changes, you can't just drop the duplicates easily. When you interlace, the pullup filter does the rest. - ods15
On Thu, Apr 07, 2005 at 10:55:27PM -0800, Scott W. Larson wrote:
But doesn't interlacing pairs of frames together effectively eliminate every other frame anyway?
No, most definitely not. You have the exact same amount of data as you started with, just organized differently. In particular it's organized the way it needs to be for any of the inverse telecine filters to work.
Won't tinterlace combine two different frames at the end of the three-frame sequence making an ugly frame?
Yes, that's the whole point. But it's not an "ugly frame", it's a pair of fields. Inverse telecine operates on fields.
I don't see how merging frames together into distorted frames will help the inverse telecine filter know what to do but I'll see if it helps.
Not understanding how doing the right thing works isn't an excuse for doing the wrong thing. :) Rich
Not understanding how doing the right thing works isn't an excuse for doing the wrong thing. :)
Except the "right" thing didn't quite work. It did produce the most interesting pattern so far. After the edit, I got a pattern of seven good frames with each eighth frame duplicating the seventh. Unless there are any more ideas about filters, I'll just adjust the troublesome EDL pts's by hand until they pass a pattern that the pullup filter can handle. Remember that pullup handles *most* of the edits perfectly so I know pullup and filmdint can handle most 60 fps telecine patterns. It may just be a matter of adding another case to their code to handle this particular pattern. I will also extract a 60 fps clip of the edit that causes the failure and post it so others can see what I've been seeing every day for a couple weeks.
On Fri, Apr 08, 2005 at 09:28:50AM -0700, Scott W. Larson wrote:
Not understanding how doing the right thing works isn't an excuse for doing the wrong thing. :)
Except the "right" thing didn't quite work. It did produce the most interesting pattern so far. After the edit, I got a pattern of seven good frames with each eighth frame duplicating the seventh.
Perhaps the video actually has this many extra frames, to increase the length by 1/7? Without seeing a sample I have no idea..
Unless there are any more ideas about filters, I'll just adjust the troublesome EDL pts's by hand until they pass a pattern that the pullup filter can handle. Remember that pullup handles *most* of the edits perfectly so I know pullup and filmdint can handle most 60 fps telecine patterns. It may just be a matter of adding another case to their code to handle this particular pattern.
This is blatently false. pullup DOES NOT HANDLE 60P TELECINE WHATSOEVER!! It will output the exact same sequence of frames you input to it, if they're progressive. What's happening is that _mencoder_ is skipping frames to drop down to only 24 frames per second. If the phase of mencoder's skipping is lined up with the telecine pattern, you'll get the exact right sequence. Otherwise the results will be very bad and choppy. But NO INVERSE TELECINE IS HAPPENING. -vf pullup,softskip on 60p content will give (aside from minor errors here and there) identical output to using no -vf at all. Filmdint on the other hand will do some skipping on its own to make the output 24 fps. However, I don't think it will try to match up which frames are duplicates in any sane manner.
I will also extract a 60 fps clip of the edit that causes the failure and post it so others can see what I've been seeing every day for a couple weeks.
The only cause is that it's out of phase with mencoder's skipping. There's nothing strange/bad about it. Rich
Perhaps the video actually has this many extra frames, to increase the length by 1/7? Without seeing a sample I have no idea..
I think this is unlikely but I'll step through this part of the video tonight and see if the 2:3 pattern is consistant through it. I definitely don't see any choppiness in the original.
What's happening is that _mencoder_ is skipping frames to drop down to only 24 frames per second. If the phase of mencoder's skipping is lined up with the telecine pattern, you'll get the exact right sequence.
And I should be able to prove this is what's happening by running mencoder with no filters at all with fps set to 59.97 and ofps set to 23.967. The abundance of duplicate progressive frames is what's probably increasing the chances of making the frames line up. If that's the case then adjusting the EDL edit times will be my best option to make this work.
Filmdint on the other hand will do some skipping on its own to make the output 24 fps. However, I don't think it will try to match up which frames are duplicates in any sane manner.
The man page says filmdint was "designed to handle any pulldown pattern". I guess I shouldn't interpret that claim that too literally.
The only cause is that it's out of phase with mencoder's skipping. There's nothing strange/bad about it.
Well, it would be great if there were a filter that could lock onto the 2:3 progressive pattern. I wonder if decimate could just remove all the duplicate frames leaving 24 fps output. The man page claims that pullup can handle 30 fps progressive material. Would I be taking this claim too literally to think I can simply drop every other 60 fps frame and expect it to inverse telecine the result correctly?
On Fri, Apr 08, 2005 at 01:38:03PM -0700, Scott W. Larson wrote:
Perhaps the video actually has this many extra frames, to increase the length by 1/7? Without seeing a sample I have no idea..
I think this is unlikely but I'll step through this part of the video tonight and see if the 2:3 pattern is consistant through it. I definitely don't see any choppiness in the original.
Even a 2:3 pattern is extremely choppy..
What's happening is that _mencoder_ is skipping frames to drop down to only 24 frames per second. If the phase of mencoder's skipping is lined up with the telecine pattern, you'll get the exact right sequence.
And I should be able to prove this is what's happening by running mencoder with no filters at all with fps set to 59.97 and ofps set to 23.967. The
Never set -fps manually; mencoder knows the input fps. Also, the numbers are 60000/1001 and 24000/1001, NOT 59.97 and 23.967.
Filmdint on the other hand will do some skipping on its own to make the output 24 fps. However, I don't think it will try to match up which frames are duplicates in any sane manner.
The man page says filmdint was "designed to handle any pulldown pattern". I guess I shouldn't interpret that claim that too literally.
This "progresive telecine" nonsense of HDTV did not exist when that was written, or none of us had ever heard of it. Anyway, what you have is not pulldown, imo. My definition of pulldown: any process for converting a sequence of progressive frames to a sequence of fields. Notice the word fields. If the output is still progressive, I call it framerate conversion by frame duplication, not pulldown. But this is getting into silly semantics.
Well, it would be great if there were a filter that could lock onto the 2:3 progressive pattern. I wonder if decimate could just remove all the duplicate frames leaving 24 fps output.
Possibly, with the right settings. You need to adjust the thresholds so it doesn't drop too much or too little.
The man page claims that pullup can handle 30 fps progressive material. Would I be taking this claim too literally to think I can simply drop every other 60 fps frame and expect it to inverse telecine the result correctly?
No. What that means is that it will pass progressive content through UNCHANGED. This is not what you want. The duplicate frames will still be there. Rich
D Richard Felker III wrote:
Even a 2:3 pattern is extremely choppy..
The 2:3 pattern makes 24 fps material look perfect at 60 frames per second. I've never seen film look this smooth outside of a movie theater.
Never set -fps manually; mencoder knows the input fps.
At least it wasn't hurting anything.
Also, the numbers are 60000/1001 and 24000/1001, NOT 59.97 and 23.967.
Of course I meant to type 23.976. This value is suggested three times in the mencoder documentation. The documentation doesn't suggest 24000/1001 anywhere. It doesn't even mention that -ofps accepts this fractional notation.
Notice the word fields. If the output is still progressive, I call it framerate conversion by frame duplication, not pulldown. But this is getting into silly semantics.
Companies that transfer film to 720p still call them "telecine pulldown conversions" and treat them no differently from their other services that produce interlaced conversions. One popular 60 progressive fps HD camera says it uses a "telecine 2:3 pulldown" process to optionally convert its output to 24 fps. The term pulldown doesn't necessarily imply interlaced video any more now that progressive video formats (480p and 720p) are becoming more popular to convert to.
Well, it would be great if there were a filter that could lock onto the 2:3 progressive pattern. I wonder if decimate could just remove all the duplicate frames leaving 24 fps output.
Possibly, with the right settings. You need to adjust the thresholds so it doesn't drop too much or too little.
I'm half way through a conversion using decimate with no tuning. Everything I've reviewed so far looks absolutely perfect! No choppiness, no duplicates, exactly what I wanted. Thanks for steering me away from trying to use pulldown filters. It would have taken me months to figure out they weren't really doing anything. I also put tinterlace=1 in front of decimate to throw away half the frames. It's faster since decimate has less work to do.
On Fri, Apr 08, 2005 at 11:16:06PM -0700, Scott W. Larson wrote:
D Richard Felker III wrote:
Even a 2:3 pattern is extremely choppy..
The 2:3 pattern makes 24 fps material look perfect at 60 frames per second. I've never seen film look this smooth outside of a movie theater.
Then you have very bad eyes. :) Everyone complains about how choppy telecine looks.... particularly during pans and vertical-scrolling credits.
Never set -fps manually; mencoder knows the input fps.
At least it wasn't hurting anything.
It was because you were using the wrong numbers.
Also, the numbers are 60000/1001 and 24000/1001, NOT 59.97 and 23.967.
Of course I meant to type 23.976. This value is suggested three times in
It's still wrong. I didn't even notice your typo, I was talking about the incorrect rounding.
the mencoder documentation. The documentation doesn't suggest 24000/1001 anywhere. It doesn't even mention that -ofps accepts this fractional notation.
It does now (cvs). You're using an old version. BTW all floating-point options in mplayer/mencoder accept fractional notation. It's a common part of the config parser module. :)
Possibly, with the right settings. You need to adjust the thresholds so it doesn't drop too much or too little.
I'm half way through a conversion using decimate with no tuning.
Excellent. Glad to know it's useful for someone. I just wrote it for testing very-low-bitrate encodes where I wanted to drop as many frames as possible, and didn't figure it would ever really be useful to someone else.
Everything I've reviewed so far looks absolutely perfect! No choppiness, no duplicates, exactly what I wanted. Thanks for steering me away from trying to use pulldown filters. It would have taken me months to figure out they weren't really doing anything.
I also put tinterlace=1 in front of decimate to throw away half the frames. It's faster since decimate has less work to do.
:) Rich
participants (3)
-
D Richard Felker III -
Oded Shimon -
Scott W. Larson