AviSynth/FFMpeg memory leak

[Paser]

I seem to be having a problem where AviSynth will absolutly hemorrhage memory. First off, let me explain a bit about what I'm doing:

I'm using nVidia ShadowPlay to record game footage. I'm using FFMpegSource (version 2.19) to load that footage into AviSynth (version 2.60, also occurs with 2.58 though) and edit it. Here's an example of one of my scripts for a video:

# double airshot
master = ShadowPlaySource("tf2_0.mp4")
output = Trim(master, 910, 1084)

# lol shovel
master = ShadowPlaySource("tf2_1.mp4")
output = output ++ Trim(master, 805, 1767)

# yey critz
master = ShadowPlaySource("tf2_2.mp4")
output = output ++ Trim(master, 1653, 1758)

# scout aint gettin away
master = ShadowPlaySource("tf2_3.mp4")
output = output ++ Trim(master, 1578, 1754)

# quickfix op
master = ShadowPlaySource("tf2_4.mp4")
output = output ++ Trim(master, 1209, 1513)

# lol autobalance
master = ShadowPlaySource("tf2_6.mp4")
output = output ++ Trim(master, 1550, 1773)

# bird sniper :3
master = ShadowPlaySource("tf2_8.mp4", 60)
output = output ++ Trim(ChangeFPS(master, 30), 768, 877)
output = output ++ master.AssumeFPS(15, sync_audio = true).ChangeFPS(30).Trim(3169, 3288).ResampleAudio(master.AudioRate())

# scout snip
master = ShadowPlaySource("tf2_11.mp4")
output = output ++ Trim(master, 1644, 1742)

# u fell into da trap solly
master = ShadowPlaySource("tf2_13.mp4")
output = output ++ Trim(master, 1068, 1762)

# game sense brah
master = ShadowPlaySource("tf2_14.mp4")
output = output ++ Trim(master, 436, 574)

# crossbow airshot
master = ShadowPlaySource("tf2_16.mp4")
output = output ++ Trim(master, 1612, 1787)

# wat headshot
master = ShadowPlaySource("tf2_18.mp4")
output = output ++ Trim(master, 1667, 1764)

return output

My own function ShadowPlaySource:

function ShadowPlaySource(string localSource, int "fps")
{
fps = default(fps, 30)

# return FFMpegSource2(localSource, cachefile = "FFMpegCache/"+localSource+".ffindex", atrack = -1, fpsnum = fps)

return FFMpegSource2(localSource, cache = false, atrack = -1, fpsnum = fps)
}

A script such as this will use as much as 600 MB when first playing through, but after skipping to a different part of the file in VirtualDub, AviSynth will double the memory used, up to 1.2 GB. Skipping again results in an attempt to allocate 1.7+ GB of memory, during which VirtualDub crashes.

This isn't a bug with VirtualDub because the same problem happens when playing the avs script in Windows Media Player.

Is there something I can do to fix this memory leak from my scripts? Or do I need to look for the problem in FFMpegSource?

Here's an example that reproduces the problem for me: RepeatedVideo.avs in http://ibemad.dyndns.org:8080/files/avisynth/avisynth_memory_leak.7z

[raffriff42]

Don't know about Shadowplay, but I tried your script with some MP4/H264/AAC source files and did not have any trouble.
System memory usage before loading was 500MB, after loading 850MB; seeking had little effect on memory.

[Paser]

I'll upload a video in a bit to show how to reproduce this problem.

These "random questions" require some amount of research and are incredibly annoying. Also annoying was the fact I had to wait 5 days before I could post this...

[Paser]

Here we are:

http://www.youtube.com/watch?v=Px6IcpIosXQ&feature=youtu.be

You can see at about 1:23 where I skip backwards, and memory usage skyrockets, followed by a crash.

[raffriff42]

I see my memory usage rise slowly just as you do, but after skipping backwards my usage remains stable.

ShadowPlay's video output is brand new and untried - it could have some weird interaction with FFMS2.

1. Does the problem occur with a simpler script?
2. How about with another type of source video?
3. What about with DirectShowSource?
4. Can you post a MediaInfo report on a typical ShadowPlay video?

[qyot27]

Knowing the particular versions of AviSynth and FFMS2 being used would help.

Does it still happen if you remux to MKV with mkvmerge? If the issue is with how ShadowPlay writes its files, then that could help to verify it.

[Paser]

I see my memory usage rise slowly just as you do, but after skipping backwards my usage remains stable.

ShadowPlay's video output is brand new and untried - it could have some weird interaction with FFMS2.

1. Does the problem occur with a simpler script?
2. How about with another type of source video?
3. What about with DirectShowSource?
4. Can you post a MediaInfo report on a typical ShadowPlay video?

1. The problem is lessened the fewer clips are used. However, it still occurs and just requires more seeking to be done before it runs out of memory.
2. See my response to qyot27 below.
3. DirectShowSource isn't able to open these files. (Note that I can play back these files perfectly in Windows Media Player, so never quite understood what was up with that)
4. Sure:
General
Complete name : D:\dxtory\shadowplay\Team Fortress 2\exploding_demoman.mp4
Format : MPEG-4
Format profile : Base Media / Version 2
Codec ID : mp42
File size : 334 MiB
Duration : 53s 364ms
Overall bit rate : 52.6 Mbps

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L5.0
Format settings, CABAC : Yes
Format settings, ReFrames : 1 frame
Format settings, GOP : M=1, N=30
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 53s 364ms
Source duration : 53s 365ms
Bit rate : 52.5 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Frame rate : 60.000 fps
Minimum frame rate : 57.197 fps
Maximum frame rate : 63.025 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.422
Stream size : 334 MiB (100%)
Source stream size : 334 MiB (100%)
mdhd_Duration : 53364

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 53s 364ms
Source duration : 53s 288ms
Bit rate mode : Constant
Bit rate : 100 Kbps
Nominal bit rate : 192 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 652 KiB (0%)
Source stream size : 652 KiB (0%)
mdhd_Duration : 53290

Knowing the particular versions of AviSynth and FFMS2 being used would help.

Does it still happen if you remux to MKV with mkvmerge? If the issue is with how ShadowPlay writes its files, then that could help to verify it.

Sorry, forgot about that little tidbit of important info. I'm using AviSynth 2.60, but this problem also occurs with 2.58. I'm using the latest version of FFMS2, which is 2.19. I've updated the first post as well.

If I use MKVMerge to combine the files into one MKV, then play that back with FFMS, the problem still occurs when seeking backwards.

[wonkey_monkey]

This won't really help as it's only an anecdote, but I've recently been playing with some AVS files that now crash on opening unless I strip out some of the many ffmpegsource2s and replace them with blankclips. They never used to do this, but unfortunately I have no idea which version of ffmpegsource I was using before (neither AviSynth 2.58 or 2.60 solve the problem).

David

[qyot27]

What happens when running the script in mpv (http://mpv.io/) (builds here (http://mpv.srsfckn.biz/))?

mpv "script.avs"
Use the arrow keys to seek back and forth.


Other things to try would be using a git build of FFMS2 (like the C-plugin builds I periodically upload: latest (http://forum.doom9.org/showthread.php?p=1658765#post1658765)), or using AviSynth+ (http://www.avs-plus.net/) (although it may make more of a difference once MT gets merged into the master branch, due to the associated cache changes).

[Paser]

What happens when running the script in mpv (http://mpv.io/) (builds here (http://mpv.srsfckn.biz/))?

mpv "script.avs"
Use the arrow keys to seek back and forth.


Other things to try would be using a git build of FFMS2 (like the C-plugin builds I periodically upload: latest (http://forum.doom9.org/showthread.php?p=1658765#post1658765)), or using AviSynth+ (http://www.avs-plus.net/) (although it may make more of a difference once MT gets merged into the master branch, due to the associated cache changes).

When I try to use mpv, I get the following result:

http://puu.sh/6GCNJ.png

Using AviSynth 2.60 with your build of FFMS still has the same result (large memory leak followed by crash).

As a test, I re-encoded all my clips with Lagarith (still using ShadowPlaySource to open). Still a massive memory leak followed by a crash, so it appears the issue is not the format of the ShadowPlay files. If I open these files with AviSource, the same memory leak occurs o.O So apparently the issue is not with FFMS but rather with AviSynth.

The same issue occurs with AviSynth+, so neither of these suggestions fix this bug :/

[qyot27]

Was that with the latest build of mpv? If there was an error in the script (which is what throws that error here), then it should report what was wrong through the log message:
F:\mpv-i686-latest>mpv ..\test.avs
Playing: ..\test.avs
[ffmpeg/demuxer] avisynth: AVISource autodetect: couldn't open file 'daybreak2.avi'
[ffmpeg/demuxer] Error code: 2
[ffmpeg/demuxer] (..\test.avs, line 1)
[lavf] LAVF_header: avformat_open_input() failed
Failed to recognize file format.


Exiting... (No files played)

[raffriff42]

I'm sure this has nothing to do with the problem, but just to make sure, you might want to temporarily uninstall Dxtory:

https://www.dropbox.com/s/9617434x2ok5kug/vdub-dxtory-warning.jpg?raw=1
(from the linked video)

[Paser]

Was that with the latest build of mpv? If there was an error in the script (which is what throws that error here), then it should report what was wrong through the log message:
F:\mpv-i686-latest>mpv ..\test.avs
Playing: ..\test.avs
[ffmpeg/demuxer] avisynth: AVISource autodetect: couldn't open file 'daybreak2.avi'
[ffmpeg/demuxer] Error code: 2
[ffmpeg/demuxer] (..\test.avs, line 1)
[lavf] LAVF_header: avformat_open_input() failed
Failed to recognize file format.


Exiting... (No files played)

It's not an error in the script, because the same script can be played back in any other video player without modification. However, it appears that mpv includes some sort of built-in, poorly implemented version of AviSynth, since it throws errors about not being able to find functions like FFMpegSource2 and ShadowPlaySource, despite the fact that they are defined in avsi files in my AviSynth plugin directory. After shuffling some files around and manually including those avsi files in the script, I get this error:

http://puu.sh/6HBbM.png

Perhaps a 32/64bit binary incompatibility?

I'm sure this has nothing to do with the problem, but just to make sure, you might want to temporarily uninstall Dxtory:

https://dl.dropboxusercontent.com/u/108089426/Screenshots/vdub-dxtory-warning.jpg
(from the linked video)

Uninstalled Dxtory, didn't help :P That message only shows up when I have "Directly decode Y Pb Pr sources" in VirtualDub unchecked (which also has no effect, by the way).

[qyot27]

It's not an error in the script, because the same script can be played back in any other video player without modification. However, it appears that mpv includes some sort of built-in, poorly implemented version of AviSynth, since it throws errors about not being able to find functions like FFMpegSource2 and ShadowPlaySource, despite the fact that they are defined in avsi files in my AviSynth plugin directory. After shuffling some files around and manually including those avsi files in the script, I get this error:

http://puu.sh/6HBbM.png

Perhaps a 32/64bit binary incompatibility?
It's not built-in or poorly implemented, it accesses the system's version of avisynth.dll directly. With the 32/64 bits situation, everything (mpv, AviSynth, and plugins - and if using AVISource or DirectShowSource, the installed codecs) needs to be in one bittage (this generally means they all need to be 32-bit; the OS being 64-bit shouldn't have an effect). One possibility could be that there's a registry conflict somewhere that's mucking things up.

[Paser]

It's not built-in or poorly implemented, it accesses the system's version of avisynth.dll directly. With the 32/64 bits situation, everything (mpv, AviSynth, and plugins - and if using AVISource or DirectShowSource, the installed codecs) needs to be in one bittage (this generally means they all need to be 32-bit; the OS being 64-bit shouldn't have an effect). One possibility could be that there's a registry conflict somewhere that's mucking things up.

...okay then. I'll try on another computer that I haven't installed AviSynth on before to test.

[Paser]

Sorry about the slow reply. I've finally gotten around to testing it on another computer, and the same issue occurs. It doesn't crash because I used the 64-bit version of AviSynth+, FFMS, and VirtualDub, but memory usage quickly exceeded 2 GB (and was still rising) at the point where I stopped it.

[Paser]

Anyone? Here's a download (albeit quite a slow one) of a set of files that reproduces the problem for me. http://ibemad.dyndns.org:8080/files/avisynth/avisynth_memory_leak.7z. Open up "avs/RepeatedVideo.avs" and wait till it's about halfway through, then seek backwards to say 25% of the way through, you should see memory usage spike.

[Paser]

All right, it's been more than a day now. Bump.

[qyot27]

Can you get it to crash on 64-bit? Don't quit when it exceeds 2GB, if it's going to crash let it crash (and take note of when - if it happens, I'll bet it'll be when it runs out of physical and virtual memory). Because it's well-known that 32-bit stuff has a 2GB hard limit on Windows - so a program crashing when it hits that boundary because it needs more than 2GB of memory is not inconceivable (and there's the whole /LARGEADDRESSAWARE and /3GB things that can kinda sorta work around it). Removing the 2GB (or 3GB, or 4GB) limit is part of what makes 64-bit useful in the first place, so if the crash only happened because of the OS/32-bit getting in the way, then it's very possible it wouldn't occur on 64-bit regardless of exceeding 2GB.

Also, it would probably be useful to actually ask about the topic in the AviSynth+ thread (as well as testing against the newest build posted there, r1689) so that you can get input from the devs that actually know about AviSynth's caching/memory use behavior and whether this qualifies as a true memory leak or if they think it's a case of simply trying to open too many clips at once.

[raffriff42]

You are calling 18 FFMpegSource's and 18 AviSource's, that's no good.
https://www.dropbox.com/s/ugo5kqyl60p3tld/AviSynthFFMpeg%20memory%20leak%20fix1.png?raw=1

revised RepeatedVideo.avs:SetMemoryMax(128)
/*
AlignedSplice(
\ AviSource("bad_heavy.avs"),
\ AviSource("bad_heavy.avs"),
\ AviSource("bad_heavy.avs"),
\ AviSource("bad_heavy.avs"),
\ AviSource("bad_heavy.avs"),
\ AviSource("bad_heavy.avs"),
\ AviSource("bad_heavy.avs"),
\ AviSource("bad_heavy.avs"),
\ AviSource("bad_heavy.avs"),
\ AviSource("bad_heavy.avs"),
\ AviSource("bad_heavy.avs"),
\ AviSource("bad_heavy.avs"),
\ AviSource("bad_heavy.avs"),
\ AviSource("bad_heavy.avs"),
\ AviSource("bad_heavy.avs"),
\ AviSource("bad_heavy.avs"),
\ AviSource("bad_heavy.avs"),
\ AviSource("bad_heavy.avs"))
*/
B=AviSource("bad_heavy.avs")
return B++B++B++B++B++B++B++B++B++B++B++B++B++B++B++B++B++B

[Paser]

Can you get it to crash on 64-bit? Don't quit when it exceeds 2GB, if it's going to crash let it crash (and take note of when - if it happens, I'll bet it'll be when it runs out of physical and virtual memory). Because it's well-known that 32-bit stuff has a 2GB hard limit on Windows - so a program crashing when it hits that boundary because it needs more than 2GB of memory is not inconceivable (and there's the whole /LARGEADDRESSAWARE and /3GB things that can kinda sorta work around it). Removing the 2GB (or 3GB, or 4GB) limit is part of what makes 64-bit useful in the first place, so if the crash only happened because of the OS/32-bit getting in the way, then it's very possible it wouldn't occur on 64-bit regardless of exceeding 2GB.

Also, it would probably be useful to actually ask about the topic in the AviSynth+ thread (as well as testing against the newest build posted there, r1689) so that you can get input from the devs that actually know about AviSynth's caching/memory use behavior and whether this qualifies as a true memory leak or if they think it's a case of simply trying to open too many clips at once.

So that's the solution then? :/ Just use 64-bit binaries, and don't use seeking at all? Okay then :/

You are calling 18 FFMpegSource's and 18 AviSource's, that's no good.
https://dl.dropboxusercontent.com/u/108089426/Screenshots/AviSynthFFMpeg%20memory%20leak%20fix1.png

revised RepeatedVideo.avs:SetMemoryMax(128)
/*
AlignedSplice(
\ AviSource("bad_heavy.avs"),
\ AviSource("bad_heavy.avs"),
\ AviSource("bad_heavy.avs"),
\ AviSource("bad_heavy.avs"),
\ AviSource("bad_heavy.avs"),
\ AviSource("bad_heavy.avs"),
\ AviSource("bad_heavy.avs"),
\ AviSource("bad_heavy.avs"),
\ AviSource("bad_heavy.avs"),
\ AviSource("bad_heavy.avs"),
\ AviSource("bad_heavy.avs"),
\ AviSource("bad_heavy.avs"),
\ AviSource("bad_heavy.avs"),
\ AviSource("bad_heavy.avs"),
\ AviSource("bad_heavy.avs"),
\ AviSource("bad_heavy.avs"),
\ AviSource("bad_heavy.avs"),
\ AviSource("bad_heavy.avs"))
*/
B=AviSource("bad_heavy.avs")
return B++B++B++B++B++B++B++B++B++B++B++B++B++B++B++B++B++B

The repeated video was simply an example of how the memory usage skyrockets with multiple clips. In a real use case, every one of those clips is different.

I guess I was using AviSynth incorrectly then... apparently I need to invest in some real video editing software instead since it appears AviSynth was never intended to stitch a bunch of clips together. That's sad though, because Adobe Premiere doesn't support variable frame rate video and it doesn't appear that Adobe has any interest in ever adding support for it. Sony Vegas on the other hand does support variable frame rate, but is *much* slower than AviSynth (read: takes 2-3 times as long for the same operation of stitching clips together).

[Reino]

I guess I was using AviSynth incorrectly then... apparently I need to invest in some real video editing software instead since it appears AviSynth was never intended to stitch a bunch of clips together.Rubbish! You should never use AVISource() to open other scripts! Use Import() instead, if you really want to use different scripts. But there really is no need for that:

SetMemoryMax(128)

ffms2=FFmpegSource2("bad_heavy.mp4", atrack=-1).Trim(1483, 1765)

Loop(ffms2,18)

================================================

AVSMeter 1.7.6 (AVS 2.6, x86) by Groucho2004
AviSynth 2.60, build:Jan 14 2013 [16:50:35]

Number of frames: 5094
Length (hhh:mm:ss.ms): 000:01:24.897
Frame width: 1920
Frame height: 1080
Framerate: 60.002 (60062/1001)
Interlaced: No
Colorspace: YV12

Frames processed: 5094 (0 - 5093)
FPS (min | max | average): 34.54 | 168.3 | 95.64
CPU usage (average): 90%
Thread count: 15
Physical Memory usage (peak): 231 MB
Virtual Memory usage (peak): 238 MB
Time (elapsed): 000:00:53.261

SetMemoryMax(128)

lsmash=AudioDub(LWLibavVideoSource("bad_heavy.mp4"),LWLibavAudioSource("bad_heavy.mp4")).Trim(1483, 1765)

Loop(lsmash,18)

================================================

AVSMeter 1.7.6 (AVS 2.6, x86) by Groucho2004
AviSynth 2.60, build:Jan 14 2013 [16:50:35]

Number of frames: 5094
Length (hhh:mm:ss.ms): 000:01:24.896
Frame width: 1920
Frame height: 1080
Framerate: 60.002 (240250/4004)
Interlaced: No
Colorspace: YV12

Frames processed: 5094 (0 - 5093)
FPS (min | max | average): 39.06 | 198.2 | 110.7
CPU usage (average): 95%
Thread count: 15
Physical Memory usage (peak): 230 MB
Virtual Memory usage (peak): 237 MB
Time (elapsed): 000:00:46.030
Memory usage no where near the 2GB you mentioned. No problem at all. You could even try L-SMASH, because it looks to be a bit faster than FFMS2.

[raffriff42]

Previously discussed here: Decompressor error after too many calls to AVISource? (http://forum.doom9.org/showthread.php?t=131687)
... it was suggested that DirectShowSource may not have this problem. Several other workarounds are suggested.

Me, I would prefer to merge these source videos into one or more lossless intermediate files. Once that's done, editing is much easier.

Since you have some effort invested in your script, maybe cut it into manageable segments, load one at a time and create a lossless intermediate for each, then continue editing from there.

[Paser]

Rubbish! You should never use AVISource() to open other scripts! Use Import() instead, if you really want to use different scripts. But there really is no need for that:


Loop(ffms2,18)



Once again, let me restate that I was not looping the same video repeatedly. Here's an example of an average script:


AlignedSplice(AviSource("aimbot_mode.avs"), AviSource("airshot.avs"), AviSource("airshot_2.avs"), AviSource("bad_heavy.avs"), AviSource("drive_by_sniping.avs"), AviSource("dumb_scout.avs"), AviSource("exploding_demoman.avs"), AviSource("invisible_headshot.avs"), AviSource("lol_caber.avs"), AviSource("lolno_scapegoat.avs"), AviSource("nice_shot_pyro.avs"), AviSource("raep_face_spy.avs"), AviSource("rocket_jumper_plz.avs"), AviSource("sticky_jumper_plz.avs"), AviSource("tele_camp.avs"), AviSource("tele_camp_2.avs"), AviSource("the_flying_sniper.avs"), AviSource("medic_market_garden.avs"), AviSource("i_love_valve_servers.avs"), AviSource("SPINTU.avs"))

Edit: Thanks for the heads up about LSMASH, it's much faster loading videos than FFMS due to no caching being required. However it still has the memory leak. Even with just the following script, I can get it to reach about 1.2 GB of memory usage :/


output = LShadowPlaySource("hi_spy.mp4").Trim(3118, 3329)

output = output ++ LShadowPlaySource("how_to_aimbot.mp4").Trim(3120, 3466)

return output

[Reino]

Why do you insist on using AviSource and this "LShadowPlaySource"?

output = AudioDub(LWLibavVideoSource("bad_heavy.mp4"),LWLibavAudioSource("bad_heavy.mp4")).Trim(0,359)
output = output ++ AudioDub(LWLibavVideoSource("bad_heavy.mp4"),LWLibavAudioSource("bad_heavy.mp4")).Trim(360,719)
output = output ++ AudioDub(LWLibavVideoSource("bad_heavy.mp4"),LWLibavAudioSource("bad_heavy.mp4")).Trim(720,1079)
output = output ++ AudioDub(LWLibavVideoSource("bad_heavy.mp4"),LWLibavAudioSource("bad_heavy.mp4")).Trim(1080,1439)
output = output ++ AudioDub(LWLibavVideoSource("bad_heavy.mp4"),LWLibavAudioSource("bad_heavy.mp4")).Trim(1440,1799)
output = output ++ AudioDub(LWLibavVideoSource("bad_heavy.mp4"),LWLibavAudioSource("bad_heavy.mp4")).Trim(1800,2159)
output = output ++ AudioDub(LWLibavVideoSource("bad_heavy.mp4"),LWLibavAudioSource("bad_heavy.mp4")).Trim(2160,2519)
output = output ++ AudioDub(LWLibavVideoSource("bad_heavy.mp4"),LWLibavAudioSource("bad_heavy.mp4")).Trim(2520,2879)
output = output ++ AudioDub(LWLibavVideoSource("bad_heavy.mp4"),LWLibavAudioSource("bad_heavy.mp4")).Trim(2880,3239)
output = output ++ AudioDub(LWLibavVideoSource("bad_heavy.mp4"),LWLibavAudioSource("bad_heavy.mp4")).Trim(3240,0)
return output
================================================

AVSMeter 1.7.6 (AVS 2.6, x86) by Groucho2004
AviSynth 2.60, build:Jan 14 2013 [16:50:35]

Number of frames: 3591
Length (hhh:mm:ss.ms): 000:00:59.848
Frame width: 1920
Frame height: 1080
Framerate: 60.002 (240250/4004)
Interlaced: No
Colorspace: YV12

Frames processed: 3591 (0 - 3590)
FPS (min | max | average): 74.41 | 516.4 | 135.4
CPU usage (average): 85%
Thread count: 51
Physical Memory usage (peak): 921 MB
Virtual Memory usage (peak): 927 MB
Time (elapsed): 000:00:26.521
This can be done more efficiently:
a=AudioDub(LWLibavVideoSource("bad_heavy.mp4"),LWLibavAudioSource("bad_heavy.mp4")).Trim(0,359)
b=AudioDub(LWLibavVideoSource("bad_heavy.mp4"),LWLibavAudioSource("bad_heavy.mp4")).Trim(360,719)
c=AudioDub(LWLibavVideoSource("bad_heavy.mp4"),LWLibavAudioSource("bad_heavy.mp4")).Trim(720,1079)
d=AudioDub(LWLibavVideoSource("bad_heavy.mp4"),LWLibavAudioSource("bad_heavy.mp4")).Trim(1080,1439)
e=AudioDub(LWLibavVideoSource("bad_heavy.mp4"),LWLibavAudioSource("bad_heavy.mp4")).Trim(1440,1799)
f=AudioDub(LWLibavVideoSource("bad_heavy.mp4"),LWLibavAudioSource("bad_heavy.mp4")).Trim(1800,2159)
g=AudioDub(LWLibavVideoSource("bad_heavy.mp4"),LWLibavAudioSource("bad_heavy.mp4")).Trim(2160,2519)
h=AudioDub(LWLibavVideoSource("bad_heavy.mp4"),LWLibavAudioSource("bad_heavy.mp4")).Trim(2520,2879)
i=AudioDub(LWLibavVideoSource("bad_heavy.mp4"),LWLibavAudioSource("bad_heavy.mp4")).Trim(2880,3239)
j=AudioDub(LWLibavVideoSource("bad_heavy.mp4"),LWLibavAudioSource("bad_heavy.mp4")).Trim(3240,0)
AlignedSplice(a,b,c,d,e,f,g,h,i,j)
================================================

AVSMeter 1.7.6 (AVS 2.6, x86) by Groucho2004
AviSynth 2.60, build:Jan 14 2013 [16:50:35]

Number of frames: 3591
Length (hhh:mm:ss.ms): 000:00:59.848
Frame width: 1920
Frame height: 1080
Framerate: 60.002 (240250/4004)
Interlaced: No
Colorspace: YV12

Frames processed: 3591 (0 - 3590)
FPS (min | max | average): 83.00 | 505.0 | 143.8
CPU usage (average): 93%
Thread count: 51
Physical Memory usage (peak): 820 MB
Virtual Memory usage (peak): 826 MB
Time (elapsed): 000:00:24.966Other than that, I can't help you.

[Paser]

Why do you insist on using AviSource and this "LShadowPlaySource"?

Because it's easier to type


LShadowPlaySource("bad_heavy.mp4")


than it is to type


AudioDub(LSMASHVideoSource("bad_heavy.mp4"), LSMASHAudioSource("bad_heavy.mp4"))


?