Trim(), how much exactly?

[asarian]

Wiki says:

"Remember AviSynth starts counting at frame 0."

But then proceeds to say:

Trim(100,0) # delete the first 100 frames...

But wouldn't that be 101 deleted frames then?!

Reason I ask is because of following test:

Trim(70790, -50)

# FreezeFrame(70803, 70812, 70802)
FreezeFrame(13, 21, 12)


To figure out where the glitches are exactly, I first skipped 70790 frames (or 70791? is the point). I then subtracted 70790 from the FreeFrame start, for the test.

So, should I just add 70790 again to the 13 (70803); or, assuming Trim(70790, -50) did trim 70901 frames, start at 70804?

This process will take me ca. 70 hours, so I better get it right. :P)

[wonkey_monkey]

trim(100,0) means the trimmed clip will start at frame 100 (the parameter doesn't mean "delete up to and including frame 100", but "start at frame 100"), skipping frames 0-99 (which is a total of 100 frames).

So frame 13 in your trimmed clip will be frame 70790+13=70803 in your original clip.

showframenumber can be of great help in these circumstances (you could apply before and after the trim to see which numbers correspond).

[asarian]

trim(100,0) means the trimmed clip will start at frame 100 (the parameter doesn't mean "delete up to and including frame 100", but "start at frame 100"), skipping frames 0-99 (which is a total of 100 frames).

So frame 13 in your trimmed clip will be frame 70790+13=70803 in your original clip.

showframenumber can be of great help in these circumstances (you could apply before and after the trim to see which numbers correspond).

Ah yes, thx! I got my logic wires crossed on that, it would seem. :)

FAUX EDIT: Already figured out ShowFrameNumber(), right after I posted this. Turns out ShowFrameNumber() shows the actual frame number (sans the trim), when appended to the FFVideoSource line (which makes sense, of course). This proved to be very useful, as it just showed 70803 in my test clip, so turns out I had no need to calculate, after all.

[asarian]

On the matter of trimming, could Trim() be used to splice two or more sources? (Cut on I-Frames boundaries, of course). That way, instead of doing 1 huge >200 hour encoding session, I might chop it up into several (lossless) parts, and spice em all together later on.

Or does AviSynth only alllow 1 video source?

Thanks.

[videoh]

Avisynth supports multiple source filter invocations. You can use Trim() with the ++ operator to splice clips. Refer to the Avisynth documentation.

[feisty2]

On the matter of trimming, could Trim() be used to splice two or more sources? (Cut on I-Frames boundaries, of course). That way, instead of doing 1 huge >200 hour encoding session, I might chop it up into several (lossless) parts, and spice em all together later on.

Or does AviSynth only alllow 1 video source?

Thanks.

if your clips are in the same format (same resolution, same colorspace, same framerate) you can just use "+" to join them together

a1=clip1
a2=clip2
a3=clip3
....
return a1+a2+a3+....

the upper script will get all the clips together again

[asarian]

if your clips are in the same format (same resolution, same colorspace, same framerate) you can just use "+" to join them together

a1=clip1
a2=clip2
a3=clip3
....
return a1+a2+a3+....

the upper script will get all the clips together again


Now, that is good to know. :) Thx.

In reality, however, I would probably want to encode the parts with a certain overlap (like for things like MCTemporalDenoise(), so as not to see the sudden transition, kinda like how threading works with overlap). And then use Trim() to splice em together.

So, if all parts had like 100 frames (including overlap), like:

return a1.Trim(0, 90)+a2.Trim(10, 90)+a3.Trim(10, 90)...

From what you're saying, it looks like that will be possible. :) Thx again.

[feisty2]

Now, that is good to know. :) Thx.

In reality, however, I would probably want to encode the parts with a certain overlap (like for things like MCTemporalDenoise(), so as not to see the sudden transition, kinda like how threading works with overlap). And then use Trim() to splice em together.

So, if all parts had like 100 frames (including overlap), like:

return a1.Trim(0, 90)+a2.Trim(10, 90)+a3.Trim(10, 90)...

From what you're saying, it looks like that will be possible. :) Thx again.

the trimming should be based on the scene change frames, a scene change frame is where the current motion compensate terminated and a new compensate incepts

edit: if you split your clip at scene change frames, you don't need to overlap at all, and splitting at scene change frames is how mvtools2 works internally as well, there're 2 parameters "thscd1", "thscd2" in mvtools2 which control the detection of scene change stuff

[asarian]

the trimming should be based on the scene change frames, a scene change frame is where the current motion compensate terminated and a new compensate incepts

edit: if you split your clip at scene change frames, you don't need to overlap at all, and splitting at scene change frames is how mvtools2 works internally as well, there're 2 parameters "thscd1", "thscd2" in mvtools2 which control the detection of scene change stuff

Thx. :) That feels like an excellent idea!

[StainlessS]

Perhaps of interest:

Trim Splice from Multiple source clips: http://forum.doom9.org/showthread.php?t=162446

Trim Splice from single source clip: http://forum.doom9.org/showthread.php?p=1683559#post1683559

Both with audio fade at splices (default 1ms) to avoid clicks and cracks in audio.

[asarian]

Perhaps of interest:

Trim Splice from Multiple source clips: http://forum.doom9.org/showthread.php?t=162446

Trim Splice from single source clip: http://forum.doom9.org/showthread.php?p=1683559#post1683559

Both with audio fade at splices (default 1ms) to avoid clicks and cracks in audio.

Thanks! :) Those look great! For now I'm still concentrating on splitting up an x264 stream into several (lossless) parts, on safe key-frames, so as to re-encode them individually. These splicing tools will definitely help re-combining them again. :)