Re: [MEncoder-users] Newbie struggling with pullup
On Wed, Feb 27, 2008 at 10:13:59PM -0600, Laine Lee wrote:
On 2/27/08 8:04 PM, "Rich Felker" <dalias@aerifal.cx> wrote:
No, 1280x720 @ 60 fps is progressive content with duplicated frames, rather than (field-based) telecine. You can either use the decimate filter with the right settings (and the right -ofps) to remove the duplicate frames, or use the tinterlace=4 filter prior to pullup to convert to normal telecine which pullup can handle. The latter approach is probably better.
Thanks. I had already stumbled onto that tinterlace=4 before pullup but am still trying to refine it. Actually, the following filter chain resulted in the fewest reports of skipped or duplicated frames.
tinterlace=2,pullup=8:8:8:8:-1:1,softskip,hqdn3d=2:1:2,pp=fd,scale=720:480,h arddup
But in 30000/1001 output, I always see a pattern of 5 frames with the 4th and 5th being similar (duplicate). Would decimate have a better chance of giving me output with only unique frames?
The output is not supposed to be 30000/1001 but 24000/1001, so what you're seeing is perfectly natural. Just fix the ofps. And please keep replies on-list, ALWAYS. Rich
On 2/27/08 10:22 PM, "Rich Felker" <dalias@aerifal.cx> wrote:
The output is not supposed to be 30000/1001 but 24000/1001, so what you're seeing is perfectly natural. Just fix the ofps.
Thank you!. I am quite please to see that the latest version of mencoder once again allows me to select that output frame rate in combination with other arguments I've grown fond of. It didn't for quite a while for "-lavcopts vcodec=mpeg2video", I think. I have high hopes for decimate, because for passages where I've been able to target the right frames with it, the results have been near perfect. It's a bit more difficult to set the decimate arguments than I expected, however, because although I can easily make the distinction between frames I want to drop and those I want to keep when viewing frame by frame, my arguments for decimate seem to result in some very similar frames being kept. It seems that in my case the first argument should always be 2, because I always want to drop two of the three frames of the 3:2 pattern. Would you please provide an example of decimate arguments that would only allow very similar frames to be dropped along with a suggestion about which values to adjust so that increasingly dissimilar frames may be dropped also?
And please keep replies on-list, ALWAYS.
Sorry, that was an accident. I'm aware that my attempt to correct the error didn't yield ideal results. Thanks again. -- Laine
On Thu, 2008-02-28 at 08:12 -0600, Laine Lee wrote:
I think. I have high hopes for decimate, because for passages where I've been able to target the right frames with it, the results have been near perfect. It's a bit more difficult to set the decimate arguments than I expected, however, because although I can easily make the distinction between frames I want to drop and those I want to keep when viewing frame by frame, my arguments for decimate seem to result in some very similar frames being kept.
If none of the good suggestions work out for you, there's still one more method I've found that works with 720p material, especially stuff that has crazy 2:2:3:3 combinations or is causing distracting interlaced frames to slip through. I've found that for some reason "detc=2" (with softskip) sometimes does a great job of locking onto the pattern of duplicates. It doesn't actually remove the duplicated frames so you'll see "skipping frame" messages continuously during the encode but these are the frames that should be skipped. You can pipe stderr to /dev/null if the messages are bothersome. I've even used this on material that had drop outs and other corruption that broke every other method I use and somehow old detc was able to get back on the pattern in less than a second. Of course I don't know why this works because detc wasn't designed for this purpose so I can only shrug and tell you to try it if nothing else works.
On 2/28/08 10:51 PM, "Scott Larson" <scowl@pacifier.com> wrote:
If none of the good suggestions work out for you, there's still one more method I've found that works with 720p material, especially stuff that has crazy 2:2:3:3 combinations or is causing distracting interlaced frames to slip through. I've found that for some reason "detc=2" (with softskip) sometimes does a great job of locking onto the pattern of duplicates. It doesn't actually remove the duplicated frames so you'll see "skipping frame" messages continuously during the encode but these are the frames that should be skipped. You can pipe stderr to /dev/null if the messages are bothersome.
I've even used this on material that had drop outs and other corruption that broke every other method I use and somehow old detc was able to get back on the pattern in less than a second. Of course I don't know why this works because detc wasn't designed for this purpose so I can only shrug and tell you to try it if nothing else works.
Thanks. I've gotten mixed results when I've used your suggestion to convert short clips that I've extracted from my larger video files. I've been extracting clips with the dd command. Is that adequate, or should I be using something else, such as mpgtx? Thanks again. -- Laine Lee
On Friday 29 February 2008 16:21, Laine Lee wrote:
On 2/28/08 10:51 PM, "Scott Larson" <scowl@pacifier.com> wrote:
If none of the good suggestions work out for you, there's still one more method I've found that works with 720p material, especially stuff that has crazy 2:2:3:3 combinations or is causing distracting interlaced frames to slip through. I've found that for some reason "detc=2" (with softskip) sometimes does a great job of locking onto the pattern of duplicates. It doesn't actually remove the duplicated frames so you'll see "skipping frame" messages continuously during the encode but these are the frames that should be skipped. You can pipe stderr to /dev/null if the messages are bothersome.
I've even used this on material that had drop outs and other corruption that broke every other method I use and somehow old detc was able to get back on the pattern in less than a second. Of course I don't know why this works because detc wasn't designed for this purpose so I can only shrug and tell you to try it if nothing else works.
Thanks. I've gotten mixed results when I've used your suggestion to convert short clips that I've extracted from my larger video files. I've been extracting clips with the dd command. Is that adequate, or should I be using something else, such as mpgtx? Thanks again.
try with -vf tinterlace=4,filmdint=fast=0,yadif,softskip,harddup -- Regards
On 2/29/08 10:35 AM, "Grozdan Nikolov (openSUSE Linux)" <microchip@telenet.be> wrote:
try with -vf tinterlace=4,filmdint=fast=0,yadif,softskip,harddup
Thanks. Is that with -ofps 24000/1001? -- Laine
On Friday 29 February 2008 17:55, Laine Lee wrote:
On 2/29/08 10:35 AM, "Grozdan Nikolov (openSUSE Linux)"
<microchip@telenet.be> wrote:
try with -vf tinterlace=4,filmdint=fast=0,yadif,softskip,harddup
Thanks. Is that with -ofps 24000/1001?
yes with -ofps 24000/1001 you may see some frame drops and skipped frames though -- Regards
On Friday 29 February 2008 17:55, Laine Lee wrote:
On 2/29/08 10:35 AM, "Grozdan Nikolov (openSUSE Linux)"
<microchip@telenet.be> wrote:
try with -vf tinterlace=4,filmdint=fast=0,yadif,softskip,harddup
Thanks. Is that with -ofps 24000/1001?
Alternatively you can use -vf framestep=2,filmdint=fast=0,softskip,harddup -fps 60000/1001 -ofps 24000/1001 this gives the best results on your sample here -- Regards
On 2/29/08 11:07 AM, "Grozdan Nikolov (openSUSE Linux)" <microchip@telenet.be> wrote:
Alternatively you can use
-vf framestep=2,filmdint=fast=0,softskip,harddup -fps 60000/1001 -ofps 24000/1001
this gives the best results on your sample here
When this reply arrived, I was in the middle of composing a reply explaining that I wanted to try to continue to refine my decimate arguments because decimate had given me better results than any other combinations I had tried, including the one you had just sent. These results appear to completely eliminate the duplicate frame problem. In a few places it appears that a very few desired frames were eliminated along with undesired ones, but overall I agree that the results are the best so far. I'll let you know if I find anything better. Thanks! -- Laine
On Friday 29 February 2008 20:43, Laine Lee wrote:
On 2/29/08 11:07 AM, "Grozdan Nikolov (openSUSE Linux)"
<microchip@telenet.be> wrote:
Alternatively you can use
-vf framestep=2,filmdint=fast=0,softskip,harddup -fps 60000/1001 -ofps 24000/1001
this gives the best results on your sample here
When this reply arrived, I was in the middle of composing a reply explaining that I wanted to try to continue to refine my decimate arguments because decimate had given me better results than any other combinations I had tried, including the one you had just sent.
can you send your decimate parameters? I want to try them out
These results appear to completely eliminate the duplicate frame problem. In a few places it appears that a very few desired frames were eliminated along with undesired ones, but overall I agree that the results are the best so far. I'll let you know if I find anything better. Thanks!
-- Regards
On 3/1/08 5:44 AM, "Grozdan Nikolov (openSUSE Linux)" <microchip@telenet.be> wrote:
On Friday 29 February 2008 20:43, Laine Lee wrote:
On 2/29/08 11:07 AM, "Grozdan Nikolov (openSUSE Linux)"
<microchip@telenet.be> wrote:
Alternatively you can use
-vf framestep=2,filmdint=fast=0,softskip,harddup -fps 60000/1001 -ofps 24000/1001
this gives the best results on your sample here
When this reply arrived, I was in the middle of composing a reply explaining that I wanted to try to continue to refine my decimate arguments because decimate had given me better results than any other combinations I had tried, including the one you had just sent.
can you send your decimate parameters? I want to try them out
These results appear to completely eliminate the duplicate frame problem. In a few places it appears that a very few desired frames were eliminated along with undesired ones, but overall I agree that the results are the best so far. I'll let you know if I find anything better. Thanks!
Here's a sample command. I want to be sure you understand that "-vf framestep=2,filmdint=fast=0,softskip,harddup" did work better than my decimate. Anyway, I'm trying to drop any frame that is even remotely similar to its neighbor with these decimate parameters, and I still don't seem to be getting that result. Picture quality is excellent, though. mencoder -oac copy -ovc lavc -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9000:vbitrate=7600:vrc_eq=te x^qComp:keyint=18:trell:mbd=2:precmp=2:subcmp=3:cmp=3:dia=-10:predia=-10:cbp :vqmin=1:lmin=1:dc=10:vstrict=0:aspect=16/9 -vf decimate=3:3072:1:3072,hqdn3d=2:1:2,scale=720:480,harddup -of mpeg -mpegopts format=dvd:tsaf -fps 60000/1001 -ofps 24000/1001 -o out.mpg in.mpg -- Laine
On Sunday 02 March 2008 08:27, Laine Lee wrote:
On 3/1/08 5:44 AM, "Grozdan Nikolov (openSUSE Linux)" <microchip@telenet.be>
wrote:
On Friday 29 February 2008 20:43, Laine Lee wrote:
On 2/29/08 11:07 AM, "Grozdan Nikolov (openSUSE Linux)"
<microchip@telenet.be> wrote:
Alternatively you can use
-vf framestep=2,filmdint=fast=0,softskip,harddup -fps 60000/1001 -ofps 24000/1001
this gives the best results on your sample here
When this reply arrived, I was in the middle of composing a reply explaining that I wanted to try to continue to refine my decimate arguments because decimate had given me better results than any other combinations I had tried, including the one you had just sent.
can you send your decimate parameters? I want to try them out
These results appear to completely eliminate the duplicate frame problem. In a few places it appears that a very few desired frames were eliminated along with undesired ones, but overall I agree that the results are the best so far. I'll let you know if I find anything better. Thanks!
Here's a sample command. I want to be sure you understand that "-vf framestep=2,filmdint=fast=0,softskip,harddup" did work better than my decimate. Anyway, I'm trying to drop any frame that is even remotely similar to its neighbor with these decimate parameters, and I still don't seem to be getting that result. Picture quality is excellent, though.
there is another alternative you can try out, which is -vf filmdint=fast=0/io=60:24,softskip,harddup -fps 60000/1001 -ofps 24000/1001
mencoder -oac copy -ovc lavc -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9000:vbitrate=7600:vrc_eq=t e x^qComp:keyint=18:trell:mbd=2:precmp=2:subcmp=3:cmp=3:dia=-10:predia=-10:cb p
:vqmin=1:lmin=1:dc=10:vstrict=0:aspect=16/9 -vf
decimate=3:3072:1:3072,hqdn3d=2:1:2,scale=720:480,harddup -of mpeg -mpegopts format=dvd:tsaf -fps 60000/1001 -ofps 24000/1001 -o out.mpg in.mpg
-- Regards
On 3/2/08 9:53 AM, "Grozdan Nikolov (openSUSE Linux)" <microchip@telenet.be> wrote:
there is another alternative you can try out, which is
-vf filmdint=fast=0/io=60:24,softskip,harddup -fps 60000/1001 -ofps 24000/1001
It appears that "-vf framestep=2,filmdint=fast=0,softskip,harddup" gives me the best results. The decimate arguments for my most successful filter chain using decimate were "decimate=3:3072:.2:4096". Mencoder version for both is SVN r26146. -- Laine Lee
"Laine Lee" <llee@lonestar.utsa.edu> wrote:
Here's a sample command. I want to be sure you understand that "-vf framestep=2,filmdint=fast=0,softskip,harddup" did work better than my decimate. Anyway, I'm trying to drop any frame that is even remotely similar to its neighbor with these decimate parameters, and I still don't seem to be getting that result. Picture quality is excellent, though.
The real test for these kinds of filters is to run them on material that has very little change from frame to frame. Try them on a dimly lit scene with little action and camera motion. You may find that the filter will start eliminating the wrong frames because they all qualify as duplicates, while frames that should be duplicates (following the 3:2 pattern) actually have more change between them and won't be eliminated. It can be frustrating because your filter may run perfectly on material that doesn't hit these two cases, but then fails later when it comes across them.
On Monday 03 March 2008 18:34, Scott W. Larson wrote:
"Laine Lee" <llee@lonestar.utsa.edu> wrote:
Here's a sample command. I want to be sure you understand that "-vf framestep=2,filmdint=fast=0,softskip,harddup" did work better than my decimate. Anyway, I'm trying to drop any frame that is even remotely similar to its neighbor with these decimate parameters, and I still don't seem to be getting that result. Picture quality is excellent, though.
The real test for these kinds of filters is to run them on material that has very little change from frame to frame.
already done that and picture looks perfectly fine here
Try them on a dimly lit scene with little action and camera motion. You may find that the filter will start eliminating the wrong frames because they all qualify as duplicates, while frames that should be duplicates (following the 3:2 pattern) actually have more change between them and won't be eliminated.
It can be frustrating because your filter may run perfectly on material that doesn't hit these two cases, but then fails later when it comes across them.
_______________________________________________ MEncoder-users mailing list MEncoder-users@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/mencoder-users
-- Regards
"Grozdan Nikolov (openSUSE Linux)" <microchip@telenet.be> wrote:
On Monday 03 March 2008 18:34, Scott W. Larson wrote:
The real test for these kinds of filters is to run them on material that has very little change from frame to frame.
already done that and picture looks perfectly fine here
The question is will it always work fine on all material. These filters can sometimes by chance sync with the 3:2 pattern and pull the correct frames only to fail later when something like an edit throws them off. The framestep=2 decreases the chances of them getting thrown off the pattern but it may also be hiding that the filter isn't really syncing with the pattern in a predictable way. I've declared victory several times over the years with this problem. I've had filters convert hours of 720p to 24 fps only to fail on some other special case I'd never seen before. I had one filter work perfectly until a station dropped their bitrate which smeared the duplicated frames even more. I had to start from scratch again.
On Monday 03 March 2008 20:17, Scott W. Larson wrote:
"Grozdan Nikolov (openSUSE Linux)" <microchip@telenet.be> wrote:
On Monday 03 March 2008 18:34, Scott W. Larson wrote:
The real test for these kinds of filters is to run them on material that has very little change from frame to frame.
already done that and picture looks perfectly fine here
The question is will it always work fine on all material. These filters can sometimes by chance sync with the 3:2 pattern and pull the correct frames only to fail later when something like an edit throws them off. The framestep=2 decreases the chances of them getting thrown off the pattern but it may also be hiding that the filter isn't really syncing with the pattern in a predictable way.
in a sense you are correct, however I had a 60p clip here where I tried for months to make it 24p with no real success until I tried -vf filmdint=fast=0/io=60:24 -fps 60000/1001 -ofps 24000/1001 it went through like a knife goes through butter and delivered excellent results. I was so happy that I "broke" this particular clip that I could have gone out and screamed on the streets lol Also keep in mind that no filter(chain) is perfect. Maybe we need a filter which looks forwars and detects changes and adjusts its process according to the changes. Off topic: I'd also like to see more motion compensated filters in MEncoder, maybe a motion compensated temporal denoiser? :)
I've declared victory several times over the years with this problem. I've had filters convert hours of 720p to 24 fps only to fail on some other special case I'd never seen before. I had one filter work perfectly until a station dropped their bitrate which smeared the duplicated frames even more. I had to start from scratch again.
_______________________________________________ MEncoder-users mailing list MEncoder-users@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/mencoder-users
-- Regards
On Fri, 2008-02-29 at 18:07 +0100, Grozdan Nikolov (openSUSE Linux) wrote:
Alternatively you can use
-vf framestep=2,filmdint=fast=0,softskip,harddup -fps 60000/1001 -ofps 24000/1001
this gives the best results on your sample here
I've thrown the most problematic 720p clips I've collected over the years at this filter chain and I haven't been able to make it fail yet. It's very fast too. Thanks!
On 3/1/08 1:22 AM, "Scott Larson" <scowl@pacifier.com> wrote:
On Fri, 2008-02-29 at 18:07 +0100, Grozdan Nikolov (openSUSE Linux) wrote:
Alternatively you can use
-vf framestep=2,filmdint=fast=0,softskip,harddup -fps 60000/1001 -ofps 24000/1001
this gives the best results on your sample here
I've thrown the most problematic 720p clips I've collected over the years at this filter chain and I haven't been able to make it fail yet. It's very fast too. Thanks!
Because about a month has gone by, I wasn't sure whether to submit this as a reply to this thread or not, but I decided in favor of it. I was able to use the above filter chain for clips with great success, but found that when applied to longer captures, it resulted in several apparently randomly occurring passages during which the output contained 3 unique frames out of every 4, as well as what seemed to be a gap in the motion between the pair of unique frames and the pair of duplicates in that group, as though a previous frame had been skipped. It seemed logical to me that this would be the result if the order of pullup had been "flipped" regarding the 3:2 arrangement. Anyway, because none of my attempts to use "decimate" yielded results as desirable as those achieved using this filter chain in the passages where it worked properly, I kept coming back to it again and again. Because I tried so many modifications for the command line, I consider it almost by accident that I seem to have finally found a single additional option that completely remedied the problem of incorrectly skipped and duplicated frames described above. The solution was simply to include "-noskip". Here's a complete 2-pass command example for converting one of my 720p source files to a high quality format which can be authored to standard or dual-layer DVD with dvdauthor. Please send any corrections if you spot something wrong or obviously unneeded. mencoder -oac copy -ovc lavc -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9000:vbitrate=7600:me_range= 8:ilme:vme=5:vqcomp=1:vrc_eq=tex^qComp:keyint=18:trell:mbd=2:precmp=2:subcmp =3:cmp=3:dia=-10:predia=-10:cbp:vqmin=1:lmin=1:dc=10:vstrict=0:aspect=16/9:v pass=1:turbo -vf framestep=2,filmdint=fast=0,softskip,harddup,scale=720:480 -noskip -of mpeg -mpegopts format=dvd:tsaf:telecine -fps 60000/1001 -ofps 24000/1001 -o /dev/null /Users/me/inputfile.mpg && mencoder -oac copy -ovc lavc -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9000:vbitrate=7600:me_range= 8:ilme:vme=5:vqcomp=1:vrc_eq=tex^qComp:keyint=18:trell:mbd=2:precmp=2:subcmp =3:cmp=3:dia=-10:predia=-10:cbp:vqmin=1:lmin=1:dc=10:vstrict=0:aspect=16/9:v pass=2 -vf framestep=2,filmdint=fast=0,softskip,harddup,scale=720:480 -noskip -of mpeg -mpegopts format=dvd:tsaf:telecine -fps 60000/1001 -ofps 24000/1001 -o /Users/me/outputfile.mpg /Users/me/inputfile.mpg Anyway, I'm quite excited to have found the solution. Next I'll be looking into dividing the DVD content into chapters, so please tell me if you have any suggestions. Thanks. -- Laine Lee
participants (5)
-
Grozdan Nikolov (openSUSE Linux) -
Laine Lee -
Rich Felker -
Scott Larson -
Scott W. Larson