VideoHelp Forum
+ Reply to Thread
Results 1 to 21 of 21
Thread
  1. Let's say it fluctuates between a duplicate every 5th and 6th frame. How would I properly decimate this?

    The pattern is:

    FFFFFD
    FFFFFFD
    FFFFFD
    FFFFFFD

    F is frame, D is duplicate frame.
    Quote Quote  
  2. TDecimate(Mode=0,Cycle=13,CycleR=2)
    Quote Quote  
  3. If the pattern repeats perfectly (not likely):

    SelectEvery(13, 0, 1, 2, 3, 4, 6, 7, 8, 9, 10, 11)
    Quote Quote  
  4. Originally Posted by manono View Post
    TDecimate(Mode=0,Cycle=13,CycleR=2)
    This looks like it would delete 2 frames after every 13th iteration. Not what I asked for. I wanna delete the 6th frame then 7th then 6th after that then 7th etc.

    jagabo, no the pattern doesnt repeat perfectly.
    Quote Quote  
  5. Member budwzr's Avatar
    Join Date
    Apr 2007
    Location
    City Of Angels
    Search Comp PM
    Why can't you use IVTC?
    Quote Quote  
  6. Originally Posted by budwzr View Post
    Why can't you use IVTC?
    Because I'm not converting NTSC to PAL?
    Quote Quote  
  7. Member budwzr's Avatar
    Join Date
    Apr 2007
    Location
    City Of Angels
    Search Comp PM
    Originally Posted by Mephesto View Post
    Originally Posted by budwzr View Post
    Why can't you use IVTC?
    Because I'm not converting NTSC to PAL?
    But the long interval between frames suggests a minor change, like 50 to 60, no? Just trying to help figure the algorithm. So you can predict and make a script. I admit I'm not nearly as knowledgeable as Jagabo, aqnd probably whoever else posted.

    But I do like to troubleshoot things. Hahaha

    I know they have different logics to conform different fps. Maybe I'll learn something too.
    Last edited by budwzr; 25th Jul 2012 at 17:55.
    Quote Quote  
  8. Originally Posted by Mephesto View Post
    Originally Posted by manono View Post
    TDecimate(Mode=0,Cycle=13,CycleR=2)
    This looks like it would delete 2 frames after every 13th iteration. Not what I asked for. I wanna delete the 6th frame then 7th then 6th after that then 7th etc.
    This does exactly what you want. It doesn't necessarily do it in that order. It decimates 2 duplicates out of every group of 13


    To be clear , you should use more precise notation. I'm assuming this is what you really mean?

    ABCDEE
    FGHIJKK
    LMNOPP
    QRSTUVV
    Quote Quote  
  9. Originally Posted by poisondeathray View Post
    Originally Posted by Mephesto View Post
    Originally Posted by manono View Post
    TDecimate(Mode=0,Cycle=13,CycleR=2)
    This looks like it would delete 2 frames after every 13th iteration. Not what I asked for. I wanna delete the 6th frame then 7th then 6th after that then 7th etc.
    This does exactly what you want. It doesn't necessarily do it in that order. It decimates 2 duplicates out of every group of 13
    But not necessarily one frame out of 6 then one frame out of 7. Most of the time it won't matter though.
    Quote Quote  
  10. This does exactly what you want. It doesn't necessarily do it in that order. It decimates 2 duplicates out of every group of 13
    I don't have two duplicates at every 13th frame, I said I have two PATTERNS of duplicates.

    To be clear , you should use more precise notation. I'm assuming this is what you really mean?

    ABCDEE
    FGHIJKK
    LMNOPP
    QRSTUVV
    That's right. Btw I love how this font perfectly aligned all of those so it looks like theres only one duplication pattern. I love Fixedsys.
    Quote Quote  
  11. But you said the pattern doesn't repeat perfectly, and isn't perfectly aligned - otherwise you could use SelectEvery as above

    Did you try those Tdecimate settings ? It's adaptive, so even if you have 2 patterns and there is a slight cadence swap it will still work (it will look for the duplicates wherever they might be within that cycle, not blindly take every 6th or 7th frame) - whereas SelectEvery will make a mistake if it's not aligned perfectly (you need perfect match for the pattern)

    I don't have two duplicates at every 13th frame, I said I have two PATTERNS of duplicates.
    It's not AT every 13th frame, it's search radius is within every 13 frames. The duplicates might be placed anywhere, and it will select them anywhere within that cycle (ie. it's adaptive)
    Last edited by poisondeathray; 25th Jul 2012 at 21:10.
    Quote Quote  
  12. Originally Posted by poisondeathray View Post
    Did you try those Tdecimate settings ? It's adaptive, so even if you have 2 patterns and there is a slight cadence swap it will still work (it will look for the duplicates wherever they might be within that cycle, not blindly take every 6th or 7th frame) - whereas SelectEvery will make a mistake if it's not aligned perfectly (you need perfect match for the pattern)
    I'll try it right now. Why was 13 specifically selected though? Would there be too much danger in changing it to 14 or 12?

    Originally Posted by poisondeathray View Post
    It's not AT every 13th frame, it's search radius is within every 13 frames. The duplicates might be placed anywhere, and it will select them anywhere within that cycle (ie. it's adaptive)
    Yeah, that's why I'm using TDecimate. But my understanding was that the number of frames to decimate was absolute while the range was variable, I didn't know both were variable.
    Quote Quote  
  13. Originally Posted by Mephesto View Post
    Why was 13 specifically selected though? Would there be too much danger in changing it to 14 or 12?
    13 was selected because that is the additive sum of your 6 and 7 pattern (6+7=13)

    Yes there is danger of selecting different number because the cycles won't line up (you'll eventually miss a duplicate, or more than it would normally miss) . 13 is "ideal" given the information you've provided

    CycleR / Cycle

    This means 2/13 (or 2 frames out of the cycle of 13 are selected)
    Quote Quote  
  14. Originally Posted by poisondeathray View Post
    Originally Posted by Mephesto View Post
    Why was 13 specifically selected though? Would there be too much danger in changing it to 14 or 12?
    13 was selected because that is the additive sum of your 6 and 7 pattern (6+7=13)

    Yes there is danger of selecting different number because the cycles won't line up (you'll eventually miss a duplicate, or more than it would normally miss) . 13 is "ideal" given the information you've provided

    CycleR / Cycle

    This means 2/13 (or 2 frames out of the cycle of 13 are selected)
    Should it not be 11 (5+6)? I never thought about the importance of whether to delete the first or last duplicate frame.
    Quote Quote  
  15. Originally Posted by Mephesto View Post

    Should it not be 11 (5+6)? I never thought about the importance of whether to delete the first or last duplicate frame.

    No, because it won't "see" the outside duplicate

    Take this example:

    ABCDEE
    FGHIJKK


    The KK will be missed in that cycle if you chose 11

    The "adaptive" part means it doesn't matter if you started on an "A" frame or a "D" frame etc.... because if that pattern is fairly consistent, then every 13 frames will have 2 duplicates
    Quote Quote  
  16. Originally Posted by poisondeathray View Post
    Originally Posted by Mephesto View Post

    Should it not be 11 (5+6)? I never thought about the importance of whether to delete the first or last duplicate frame.

    No, because it won't "see" the outside duplicate

    Take this example:

    ABCDEE
    FGHIJKK


    The KK will be missed in that cycle if you chose 11

    The "adaptive" part means it doesn't matter if you started on an "A" frame or a "D" frame etc.... because if that pattern is fairly consistent, then every 13 frames will have 2 duplicates
    Ah, I see. Btw, is there any way to keep track of the original frames in the decimated video? If I use Showframenumber BEFORE decimation then I'm worried about the yellow numbers confusing the TDecimate algorithm. Wish there was a way for Showframenumber to not actually be part of the video.
    Quote Quote  
  17. Originally Posted by Mephesto View Post
    Ah, I see. Btw, is there any way to keep track of the original frames in the decimated video? If I use Showframenumber BEFORE decimation then I'm worried about the yellow numbers confusing the TDecimate algorithm. Wish there was a way for Showframenumber to not actually be part of the video.
    To learn what decisions it's making you can use the debugmode, either display=true to show it overlaid or debug=true to output using OutputDebugString() . Read the instructions for more information (the "inframe" is the original framenumber, starting at zero like avisynth normally does) . Using this you can tweak the dozen other settings to get more customized results as well
    Quote Quote  
  18. Since you see pattern changes, I suspect it's not truly 2 of every 13 frames that needs to be removed (and also because 11/13 doesn't correspond to any of the standard frame rate conversion). You may want to look at a longer section to determine what the real frame rate is (something close to 11/13 of the source frame rate) then use "mode=2, rate=x", where x is whatever that frame rate turns out to be.
    Quote Quote  
  19. Originally Posted by jagabo View Post
    Since you see pattern changes, I suspect it's not truly 2 of every 13 frames that needs to be removed (and also because 11/13 doesn't correspond to any of the standard frame rate conversion).
    I thought the same, but this guy is an ornery cuss so I gave him what he asked for. And he still had the nerve to argue before even trying it. Or even before reading the doc which is quite clear about Mode 0 and what Cycle and CycleR mean. I have, for example, seen plenty of PAL to NTSC conversions where the repeat pattern is 7 6 5 7 6 5, or some variation of that which averages out to one dupe frame out of every six.

    And then rather than us trying to guess what he really has, better might be to provide a small sample from the source.

    Originally Posted by mephisto
    Should it not be 11 (5+6)? I never thought about the importance of whether to delete the first or last duplicate frame.
    Gimme a break.
    Quote Quote  
  20. Originally Posted by manono View Post
    And he still had the nerve to argue before even trying it. Or even before reading the doc
    As is usually the case with Mephesto.
    Quote Quote  
  21. Perfect, this worked. Your guess is as good as mine why the source is so weird. If you knew what I worked with and all the bizarre rare videos that mental fucks on eBay are looking for it might make more sense.

    manono and jagabo, both of you can bite me. You might surpass me in technical knowledge but you've achieved them at the expense of intellectual aptitude. I own up when I'm wrong, have many times and do it immediately without any bullshit. I've seen neither of you do so once. You are more apt at lecturing than learning, a trait more common with the uneducated.

    Remember our discussion about the benefit of deleting duplicate frames? Funny how poisondeathray and neither of you responded to the evidence I posted in a new thread. Tells a lot about your character and how little you are willing to put to educate yourself.

    I'm not interested in being right, I'm interested in being correct, and I live on $3 a day. You can do way better, holms.

    And he still had the nerve to argue before even trying it. Or even before reading the doc which is quite clear about Mode 0 and what Cycle and CycleR mean.
    Or I could've been using TDecimate for enough years to not recall every function of every setting. In fact, this is the first time I've used any other value in the number of frames remove besides 1, and the first video I dealt with that had two patterns of duplicate frames.
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!