Vapoursynth

[videoh]

DG stuff works.

[Boulder]

I'm getting random crashes in vspipe with the test version.

Faulting application name: vspipe.exe, version: 0.0.0.0, time stamp: 0x59f625ab
Faulting module name: DGDecodeNV.dll, version: 2053.0.0.112, time stamp: 0x59f243c4
Exception code: 0xc0000005
Fault offset: 0x000000000002e544
Faulting process id: 0x1bf8
Faulting application start time: 0x01d350eaaa4ce85c
Faulting application path: C:\Program Files\VapourSynth\core64\vspipe.exe
Faulting module path: C:\Program Files\VapourSynth\avs64\DGDecodeNV.dll
Report Id: e91f6cd2-bcdd-11e7-b4dd-00acc7375d92

The crash seems to occur much more frequently if I use my hack-of-a-denoising-function which utilizes mvtools among other smaller things. Often the crash occurs right when starting the encode with x265. Previewing in Vapoursynth Editor works fine all the time.

[Mystery Keeper]

Boulder, you can encode with VapourSynth Editor too. Try and say if you get the same crash. Don't forget to disable the encoder output in encoder arguments.

[Boulder]

It crashes in the same way.

I'll try to narrow down the part of the function which causes the crash, but it may take a while.

EDIT: it was faster than I thought. The "DitherLumaRebuild" function (borrowed in this example script from havsfunc) is what causes the crash. If it's removed, the encoding seems to progress further. The more mvtools stuff there is (i.e. MRecalculate added), the faster the crash. This version crashed just seconds after the encoding started.

import vapoursynth as vs
import resamplehq as rhq

def DitherLumaRebuild(src, s0=2., c=0.0625, chroma=True):
core = vs.get_core()

if not isinstance(src, vs.VideoNode):
raise TypeError('DitherLumaRebuild: This is not a clip')

shift = src.format.bits_per_sample - 8

isGray = src.format.color_family == vs.GRAY

k = (s0 - 1) * c
t = 'x {} - {} / 0 max 1 min'.format(16 << shift, 219 << shift)
c1 = 1 + c
c2 = c1 * c
e = '{k} {c1} {c2} {t} {c} + / - * {t} 1 {k} - * + {i} *'.format(k=k, c1=c1, c2=c2, t=t, c=c, i=256 << shift)
return core.std.Expr([src], [e] if isGray else [e, 'x {neutral} - 128 * 112 / {neutral} +'.format(neutral=128 << shift) if chroma else ''])

core = vs.get_core()
core.avs.LoadPlugin(r'C:\\Program Files\\VapourSynth\\avs64\DGDecodeNV.dll')

clp = core.avs.DGSource(r'Y:\bwtestclip.dgi')

clp = core.fmtc.bitdepth(clp, bits=16)

src = clp
feed = DitherLumaRebuild(src)
prefilt = feed

pelmdg = core.fmtc.resample(clip=src, scale=2, kernel='spline64', center=False)
pelprefilt = core.fmtc.resample(clip=prefilt, scale=2, kernel='spline64', center=False)

superanalyse = core.mv.Super(prefilt, pel=2, chroma=False, rfilter=4, pelclip=pelprefilt)
supermdg = core.mv.Super(src, pel=2, chroma=False, rfilter=4, levels=1, pelclip=pelmdg)

bv1 = core.mv.Analyse(superanalyse, dct=0, blksize=16, overlap=8, search=5, searchparam=4, pelsearch=4, isb=True, chroma=False, delta=1, truemotion=False, _global=True)
fv1 = core.mv.Analyse(superanalyse, dct=0, blksize=16, overlap=8, search=5, searchparam=4, pelsearch=4, isb=False, chroma=False, delta=1, truemotion=False, _global=True)

bv1 = core.mv.Recalculate(superanalyse, bv1, thsad=200, blksize=8, overlap=4, search=3, searchparam=4, chroma=False, truemotion=False)
fv1 = core.mv.Recalculate(superanalyse, fv1, thsad=200, blksize=8, overlap=4, search=3, searchparam=4, chroma=False, truemotion=False)
bv1 = core.mv.Recalculate(superanalyse, bv1, thsad=200, blksize=4, overlap=2, search=3, searchparam=4, chroma=False, truemotion=False)
fv1 = core.mv.Recalculate(superanalyse, fv1, thsad=200, blksize=4, overlap=2, search=3, searchparam=4, chroma=False, truemotion=False)

finalclip = core.mv.Degrain1(src, supermdg, bv1, fv1, thsad=200, thsadc=200, limit=1, limitc=5, plane=0)

finalclip.set_output()

[Mystery Keeper]

It crashes in the same way.

I'll try to narrow down the part of the function which causes the crash, but it may take a while.

EDIT: it was faster than I thought. The "DitherLumaRebuild" function (borrowed in this example script from havsfunc) is what causes the crash. If it's removed, the encoding seems to progress further. The more mvtools stuff there is (i.e. MRecalculate added), the faster the crash. This version crashed just seconds after the encoding started.

import vapoursynth as vs
import resamplehq as rhq

def DitherLumaRebuild(src, s0=2., c=0.0625, chroma=True):
core = vs.get_core()

if not isinstance(src, vs.VideoNode):
raise TypeError('DitherLumaRebuild: This is not a clip')

shift = src.format.bits_per_sample - 8

isGray = src.format.color_family == vs.GRAY

k = (s0 - 1) * c
t = 'x {} - {} / 0 max 1 min'.format(16 << shift, 219 << shift)
c1 = 1 + c
c2 = c1 * c
e = '{k} {c1} {c2} {t} {c} + / - * {t} 1 {k} - * + {i} *'.format(k=k, c1=c1, c2=c2, t=t, c=c, i=256 << shift)
return core.std.Expr([src], [e] if isGray else [e, 'x {neutral} - 128 * 112 / {neutral} +'.format(neutral=128 << shift) if chroma else ''])

core = vs.get_core()
core.avs.LoadPlugin(r'C:\\Program Files\\VapourSynth\\avs64\DGDecodeNV.dll')

clp = core.avs.DGSource(r'Y:\bwtestclip.dgi')

clp = core.fmtc.bitdepth(clp, bits=16)

src = clp
feed = DitherLumaRebuild(src)
prefilt = feed

pelmdg = core.fmtc.resample(clip=src, scale=2, kernel='spline64', center=False)
pelprefilt = core.fmtc.resample(clip=prefilt, scale=2, kernel='spline64', center=False)

superanalyse = core.mv.Super(prefilt, pel=2, chroma=False, rfilter=4, pelclip=pelprefilt)
supermdg = core.mv.Super(src, pel=2, chroma=False, rfilter=4, levels=1, pelclip=pelmdg)

bv1 = core.mv.Analyse(superanalyse, dct=0, blksize=16, overlap=8, search=5, searchparam=4, pelsearch=4, isb=True, chroma=False, delta=1, truemotion=False, _global=True)
fv1 = core.mv.Analyse(superanalyse, dct=0, blksize=16, overlap=8, search=5, searchparam=4, pelsearch=4, isb=False, chroma=False, delta=1, truemotion=False, _global=True)

bv1 = core.mv.Recalculate(superanalyse, bv1, thsad=200, blksize=8, overlap=4, search=3, searchparam=4, chroma=False, truemotion=False)
fv1 = core.mv.Recalculate(superanalyse, fv1, thsad=200, blksize=8, overlap=4, search=3, searchparam=4, chroma=False, truemotion=False)
bv1 = core.mv.Recalculate(superanalyse, bv1, thsad=200, blksize=4, overlap=2, search=3, searchparam=4, chroma=False, truemotion=False)
fv1 = core.mv.Recalculate(superanalyse, fv1, thsad=200, blksize=4, overlap=2, search=3, searchparam=4, chroma=False, truemotion=False)

finalclip = core.mv.Degrain1(src, supermdg, bv1, fv1, thsad=200, thsadc=200, limit=1, limitc=5, plane=0)

finalclip.set_output()It all sounds like a running out of memory issue. Have you got virtual memory disabled?

[Boulder]

It all sounds like a running out of memory issue. Have you got virtual memory disabled?

VM is enabled, 8 GB as a fixed value in addition to 8 GB of RAM. I took a look in Task Manager and vspipe took around 2,5 GB of memory at the beginning of the encode and would gradually release memory.

[videoh]

I duplicated this using HolyWu's script above with a YV12 source and found that after some number of frames this DGSource GetFrame() code hits a bad pointer:

PVideoFrame frame = env->NewVideoFrame(vi);
out->y = frame->GetWritePtr(PLANAR_Y); // pointer OK
out->u = frame->GetWritePtr(PLANAR_U); // pointer BAD
out->v = frame->GetWritePtr(PLANAR_V); // pointer OK

The returned out->u pointer is bad. Sometimes it is the PLANAR_V get call also.

This is done at the very top of the DGSource GetFrame(), so it appears to be an issue with AvsCompat.dll. vs_pipe is not involved.

[videoh]

If I delete the Degrain1() call, it no longer fails.

[Myrsloik]

I tested with a simpler version of Boulder's script below. It does crash with AvsCompat.dll from R40-test1, while AvsCompat.dll from R39 works fine. The crash doesn't always happen at the same frame though. Here is the call stack (https://i.imgur.com/U8bLEcU.png) but I guess it probably doesn't help much.


clip = core.avs.DGSource('foo.dgi')
clip = core.resize.Bicubic(clip, format=vs.YUV420P16)

src = clip
prefilt = core.std.BoxBlur(clip, hradius=1, vradius=1)

pelmdg = core.resize.Spline36(src, src.width * 2, src.height * 2)
pelprefilt = core.resize.Spline36(prefilt, prefilt.width * 2, prefilt.height * 2)

superanalyse = core.mv.Super(prefilt, pelclip=pelprefilt)
supermdg = core.mv.Super(src, levels=1, pelclip=pelmdg)

bv1 = core.mv.Analyse(superanalyse, blksize=16, overlap=8, isb=True)
fv1 = core.mv.Analyse(superanalyse, blksize=16, overlap=8, isb=False)

clip = core.mv.Degrain1(clip, supermdg, bv1, fv1)

clip.set_output()


Does it happen with threads=1?

[Myrsloik]

R40 test2 (https://www.dropbox.com/s/jz7yz6g018advpf/VapourSynth-R40-test2.exe?dl=1)

Should fix the avisynth compatibility issues. This happened BECAUSE AVS+ DECIDED TO MAKE DATA OFFSETS INT INSTEAD OF SIZE_T. Why this was done is a huge mystery, it's also as if it's testing just how many small changes can be made before it chokes on its own ABI and dies. This build should have undone all of this.

Also fixes the flipped rgb in avisource

[pinterf]

Should fix the avisynth compatibility issues. This happened BECAUSE AVS+ DECIDED TO MAKE DATA OFFSETS INT INSTEAD OF SIZE_T. Why this was done is a huge mystery, it's also as if it's testing just how many small changes can be made before it chokes on its own ABI and dies. This build should have undone all of this.
Perhaps it wasn't avs+.
https://forum.doom9.org/showthread.php?p=1712673#post1712673

[Myrsloik]

Perhaps it wasn't avs+.
https://forum.doom9.org/showthread.php?p=1712673#post1712673

I need those size_t changes and so does everyone else who ever wants to use a different memory layout behind the scenes. There are also zero plugins I know of that aren't compatible because of it. Just keep digging your API hole, it isn't my problem anymore.

[TheFluff]

Perhaps it wasn't avs+.
https://forum.doom9.org/showthread.php?p=1712673#post1712673

Yes it's Avs+. We've been over this before, in quite some detail - it's one of the dumber hills ultim&co decided to die on. See here (https://forum.doom9.org/showthread.php?p=1771304#post1771304) and here (https://forum.doom9.org/showthread.php?p=1771312#post1771312) if you want to read someone (me) complaining on the internet, but the tl;dr is that when IanB switched to size_t in the 2.6 API, ultim&co thought "maintaining compatibility"* with like a dozen 64-bit plugin DLL's from 2010 that were at that point only available via web.archive.org was too important to make the same change.

* Note: I'm strongly suspect ultim&co didn't really understand their own ABI, because as Myrsloik says I'm preeeetty sure they could've switched to size_t and those old plugins would've kept working anyway in practice. I think you can still do it now, if you want. It'll technically be an ABI break but I'm pretty sure it'll actually work in all practical cases until people get around to recompiling.

[Boulder]

R40 test2 is working, no more crashes.

[Myrsloik]

R40-RC1 (https://www.dropbox.com/s/o6istvl68pa6ldk/VapourSynth-R40-RC1.exe?dl=1)

Time to finally get a maintenance release out to fix the broken levels for everyone. Report if anything in the change list is more broken than before. Release in two days or so unless major bugs are found.

r40:
improved expr asm slightly
made the framebuffer memory pool size a percentage of the total allowed memory usage instead of a fixed size, this should scale better when processing 8k and larger resolutions
fixed rgb output sometimes being flipped in avisource
added alpha output settings to avisource, the default is no alpha output
fixed gamma being infinite if not set in levels, bug introduced in r39
removed the hack needed to support avisynth mvtools, the native mvtools has been superior for several years now and removing the hack makes avisynth filter creation much faster
added avisynth+ compatibility
only do prefetching in avfs with vs script when linear access is detected, fixes excessive prefetching that could make opening scripts very slow

[lansing]

I couldn't play a avfs mounted 10 bit avi on any media player, while the original 10 bit video works fine.

[Myrsloik]

I couldn't play a avfs mounted 10 bit avi on any media player, while the original 10 bit video works fine.

Which renderer are you using (I sure hope you're using madvr)? what's the output pin format in both cases?

[lansing]

The video format after mount is YUV420P10.

With media player classic, renderer used is Enhanced Video Renderer. I don't know what pin format is. With the avsf one, it reads "P010". With the original file, it reads "NV12".

With VLC player, I get the error message "VLC could not decode the format "P010" (No description for this codec)".

[Myrsloik]

The video format after mount is YUV420P10.

With media player classic, renderer used is Enhanced Video Renderer. I don't know what pin format is. With the avsf one, it reads "P010". With the original file, it reads "NV12".

With VLC player, I get the error message "VLC could not decode the format "P010" (No description for this codec)".

Then the explanation is very simple. Your renderer can't accept it and negotiates another output format it can accept from the decoder (which is basically YV12) and displays that. Since avfs only ever returns one format it's rejected. Install madvr, use mpc and try again for better results.

[lansing]

Yes madvr plays it without problem

[lansing]

I'm trying to create a blankclip with compatbgr32, but blankclip doesn't support the format.

[Myrsloik]

I'm trying to create a blankclip with compatbgr32, but blankclip doesn't support the format.

Create a rgb24 blankclip and then convert it if you really need it

[lansing]

Create a rgb24 blankclip and then cpnvert ot of you really need ot
When I declared a copy clip and format in blankclip, the declared format doesn't overwrite the format of the copy clip like other arguments. It still gave me the error "compat formats not supported".
core.std.BlankClip(compat_clip,length=padding, format=vs.RGB24)

[Myrsloik]

When I declared a copy clip and format in blankclip, the declared format doesn't overwrite the format of the copy clip like other arguments. It still gave me the error "compat formats not supported".
core.std.BlankClip(compat_clip,length=padding, format=vs.RGB24)

Will fix

[Boulder]

How to properly do a thing like Greyscale() in Vapoursynth? I've got a movie which is supposedly black and white, but according to the x265 logs, there is data in the chroma channels.

core.std.ShufflePlanes(clips=inclip, planes=0, colorfamily=vs.GRAY) does create a greyscale clip but in Gray8 format. If I use core.resize.Bicubic(clp, format=vs.YUV420P16) after it to make the video something to feed to x265, the chroma channels have garbage (green) in them.

[mandarinka]

Usually the "black and white" is a transfer from film or photo material. It is not going to be greyscale in the computer (or YUV) sense of the word.

If you strip the chroma, you will loose that "color" tone of the source, and it is likely not-so-insignificant alteration. So I would not do this, unless you are dealing with actual digital cap of a greyscale computer image and you know that for sure.

Basically, think of "sepia" photos. You also ruin those by insisting on saving them in "BW/greyscale" format.

[Myrsloik]

How to properly do a thing like Greyscale() in Vapoursynth? I've got a movie which is supposedly black and white, but according to the x265 logs, there is data in the chroma channels.

core.std.ShufflePlanes(clips=inclip, planes=0, colorfamily=vs.GRAY) does create a greyscale clip but in Gray8 format. If I use core.resize.Bicubic(clp, format=vs.YUV420P16) after it to make the video something to feed to x265, the chroma channels have garbage (green) in them.

Try R40-RC2 (https://www.dropbox.com/s/kf959odlklhlby4/VapourSynth-R40-RC2.exe?dl=1)

It also fixes the blankclip bug reported by lansing

[Boulder]

Usually the "black and white" is a transfer from film or photo material. It is not going to be greyscale in the computer (or YUV) sense of the word.

If you strip the chroma, you will loose that "color" tone of the source, and it is likely not-so-insignificant alteration. So I would not do this, unless you are dealing with actual digital cap of a greyscale computer image and you know that for sure.

Basically, think of "sepia" photos. You also ruin those by insisting on saving them in "BW/greyscale" format.
Hmm..that's an interesting point of view. I was asking this because it is the first time for BW movies that I see anything chroma-related in the P/B frame weighting according to x264/x265 logs. Of course, I'll compare the two outputs if I can see any difference.

Myrsloik: thanks, will test it!

[Boulder]

Try R40-RC2 (https://www.dropbox.com/s/kf959odlklhlby4/VapourSynth-R40-RC2.exe?dl=1)

It also fixes the blankclip bug reported by lansing

And it works, no more garbage there.

[mandarinka]

It can also contain rainbows and such garbage added in transfer/processing too, in such case, I would try to use derainbowers on it, maybe even strong ones (but not ones that wash out colors in large areas, to be safe).

[Boulder]

It can also contain rainbows and such garbage added in transfer/processing too, in such case, I would try to use derainbowers on it, maybe even strong ones (but not ones that wash out colors in large areas, to be safe).

I checked many places by comparing the greyscaled and original output and couldn't see any visual differences. Maybe there's just some bluish hue or something like that which is basically impossible to notice even with a frame by frame comparison. Funny thing is that the greyscale version required a slightly more bitrate when I did a short test encode. The UV channels clearly affected the frame type decision.

[Myrsloik]

R40 released. Blog post as usual (http://www.vapoursynth.com/2017/11/r40-avisynth-compatibility-and-fixes/). Everyone should upgrade since it's a maintenance release.

[hydra3333]

Thank you. In regard to building vapoursynth :-

I think I had been using an incorrect github link for avisynth+ :(

Can you please confirm whether this is the right link ? It seems to have been updated more recently.
https://github.com/pinterf/AviSynthPlus/tree/MT

And this is the right link for zimg I guess.
https://github.com/sekrit-twc/zimg/releases

[Myrsloik]

Thank you. In regard to building vapoursynth :-

I think I had been using an incorrect github link for avisynth+ :(

Can you please confirm whether this is the right link ? It seems to have been updated more recently.
https://github.com/pinterf/AviSynthPlus/tree/MT

And this is the right link for zimg I guess.
https://github.com/sekrit-twc/zimg/releases

Both are right

[DJATOM]

Myrsloik
I tried to find out why TCPServer fails: https://github.com/DJATOM/TCPDeliver/blob/master/src/TCPServer.cpp#L478. I don't know why it crashing on GetFrame call, that code works well on Avisynth.

[pinterf]

Possibly a rare use case in Expr: you cannot use 8-16 bit clips with 32 bit float clips in one expression (working register ordering is the opposite)

[kgrabs]

^ speaking of std.Expr, outputting float from int clips, or vice versa causes some crazy things to happen: http://screenshotcomparison.com/comparison/123935

[Myrsloik]

^ speaking of std.Expr, outputting float from int clips, or vice versa causes some crazy things to happen: http://screenshotcomparison.com/comparison/123935

Already fixed in git. Same issue as pinterf found.

[Myrsloik]

Myrsloik
I tried to find out why TCPServer fails: https://github.com/DJATOM/TCPDeliver/blob/master/src/TCPServer.cpp#L478. I don't know why it crashing on GetFrame call, that code works well on Avisynth.

Nope, can't figure out exactly why. Couldn't even get it to connect and trigger the error oddly enough. Not going to spend more time on this since it's a great perversion even of the avisynth api...

[lansing]

I have a problem applying multiple instances of the virtualdub filter neatvideo in vapoursynth, it was able to load preview but crash on preview close.

core.avs.LoadPlugin(r"C:\Program Files (x86)\AviSynth+\plugins64+\VDubFilter.dll")
core.avs.LoadVirtualdubPlugin(r'neatvideo.vdf', 'nv', 1)

clipa = core.avs.nv_2(clip, setting_a)
clipb = core.avs.nv_2(clip, setting_b)

clip = clipa + clipb
clip.set_output()


However, saving the filter under a different function name will work:
core.avs.LoadPlugin(r"C:\Program Files (x86)\AviSynth+\plugins64+\VDubFilter.dll")
core.avs.LoadVirtualdubPlugin(r'neatvideo.vdf', 'nv', 1)
core.avs.LoadVirtualdubPlugin(r'neatvideo.vdf', 'nv2', 1)

clipa = core.avs.nv_2(clip, setting_a)
clipb = core.avs.nv2_2(clip, setting_b)

clip = clipa + clipb
clip.set_output()


I first thought that it was a problem with neatvideo and avisynth because it was mentioned on the user manual. But after asking in the neatvideo forum and testing it out in avs+, it actually works without any problem. So I think the problem is from vapoursynth.

Here's the crash log from vs editor
Problem signature:
Problem Event Name: BEX64
Application Name: vsedit.exe
Application Version: 18.0.0.0
Application Timestamp: 59f4da49
Fault Module Name: NeatVideo.vdf_unloaded
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 540f49bd
Exception Offset: 000007fed7512d60
Exception Code: c0000005
Exception Data: 0000000000000008
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 1033
Additional Information 1: 0052
Additional Information 2: 0052a83208d9c99bc2a54c9c0c8ea3e8
Additional Information 3: ce3c
Additional Information 4: ce3cde77cba7f1c58c793ecf99d5100f

[Myrsloik]

I have a problem applying multiple instances of the virtualdub filter neatvideo in vapoursynth, it was able to load preview but crash on preview close.

...

Interesting observation. Does it crash on script evaluation, first frame request or later? There's probably some locking/shared resource in the dll that's causing it. I'll try to debug it just to see but these things are hard to figure out without the source.

[lansing]

Interesting observation. Does it crash on script evaluation, first frame request or later? There's probably some locking/shared resource in the dll that's causing it. I'll try to debug it just to see but these things are hard to figure out without the source.

It works fine on preview, I was able to navigate and seek without a problem. It crashes only when I close the preview. I tried opening benchmark while still with the preview window open, the benchmark window works fine until I tried closing it.

I tried the same actions on virtualdub filtermod, no problem on navigate and seeking. I tried running "video analysis pass" and abort it and no crash. The program only crash on close. Here's the crash info.

https://pastebin.com/3LY0zMrA

[Selur]

Small question: Is there a source filter which can handle movs which only link to the tracks?
On ffmpeg I can play such files by adding '-enable_drefs 1', but I don't know of any option in FFmpegSource2, LSMASHVideoSource or LWLibavVideoSource which supports this.
-> is there some to me unknown option or source filter which could be used for this?

Cu Selur

Ps.: Background: A user asked me (see: https://forum.selur.net/showthread.php?tid=162) whether I could add support for this in Hybrid which is why I'm looking into it.

[Myrsloik]

Small question: Is there a source filter which can handle movs which only link to the tracks?
On ffmpeg I can play such files by adding '-enable_drefs 1', but I don't know of any option in FFmpegSource2, LSMASHVideoSource or LWLibavVideoSource which supports this.
-> is there some to me unknown option or source filter which could be used for this?

Cu Selur

Ps.: Background: A user asked me (see: https://forum.selur.net/showthread.php?tid=162) whether I could add support for this in Hybrid which is why I'm looking into it.

Maybe, create an issue with this text and maybe I'll look into it later. No idea how that part of the api works.

[Selur]

Will do. Thanks!

[Myrsloik]

Will do. Thanks!

Do you have some small sample to go with it? I think it's just a simple option to change but need to be able to test it.

[Selur]

There's a download link (google drive) to a test folder with the files in the first post over in my board. -> https://forum.selur.net/showthread.php?tid=162

Cu Selur

[lansing]

Can I output image file name with imwrif base on frame number in the frame property?

[Myrsloik]

Can I output image file name with imwrif base on frame number in the frame property?

If you call imwri insode frameeval ypu should be able to do it.

[lansing]

I have problem with the syntax on appending clips reading from text file. I need to reorder a clip like this:
clip[500:600] + clip[400:450] + clip[601:700]

I have looked in remapframes, but it doesn't have such function.

Right now my text read like this:
500 600
400 450
601 700

And I use a for loop to create the clips, but I always ended having to create a dummy 1 frame accumulator clip so that I can append the clips onto, and then strips that out after the loop.

clip = core.ffms2.source("abc")

accum_clip = clip[1]

with open(file) as f:
line = f.readline()

for line in f:
start, end = (int(x.strip()) for x in line.split())
accum_clip += clip[start:end]

clip = core.std.Trim(accum_clip, 1)


How do I avoid doing that dummy clip?