View Full Version : Trim on Load for Avisource
a451guy451
13th November 2009, 22:01
I'm curious if there is a way to have avisource load a trim (instead of the whole file) without having to scan the whole source. In my head, this looks something like this:
avisource("C:\source.avi",TrimIn=12,TrimOut=50)
Not really sure if that's even possible (or if it exists already since I've been scouring the forums/google), but you never know. If nobody knows, I'm considering posting as a request on the developer forum...
Reason I'm looking into this, is to help ease my network storage for a transcode farm. I've got a watch folder with nodes, and am simultaneously dropping lots of AVS files that apply trims from a single avi source. Problem is, since each AVS scans the avi in full just to grab a trim of a few frames, it's straining my crummy network storage to the point that all my transcodes fail.
Any help is apreciated! (even if just to say that this is impossible).
Gavino
13th November 2009, 22:22
Since Avisynth loads frames only on request, what you ask for is unnecessary.
AviSource("source.avi")
Trim(12, 50)
will only process frames 12 to 50 anyway.
Of course, depending on the codec used in the avi file, it may well be necessary to scan through frames 0 to 11 to find frame 12. But your proposal would not alter that (unavoidable) aspect.
a451guy451
13th November 2009, 22:32
Well that helps, because it means I probably have some other problem with my network storage then. What if I was using directshowsource with wmvs (which I know is a terrible idea to begin with)?
TheRyuu
13th November 2009, 22:48
Well that helps, because it means I probably have some other problem with my network storage then. What if I was using directshowsource with wmvs (which I know is a terrible idea to begin with)?
DSS is not frame accurate so I would not recommend that.
FFMS2 is frame accurate and should be used instead.
(And should that fail, DSS2 as a fallback).
a451guy451
13th November 2009, 23:29
I actually have a trick that gives frame accuracy on most WMVs (at least in terms of doing consistent trims):
directshowsource("C:\source.wmv",convertfps=true,fps=###)
sumawo13
14th November 2009, 21:14
I actually have a trick that gives frame accuracy on most WMVs (at least in terms of doing consistent trims):
directshowsource("C:\source.wmv",convertfps=true,fps=###)
AFAIK that has nothing to do with frame accurate seeking. I would recommend trying what TheRyuu suggested.
a451guy451
15th November 2009, 20:30
Well, I've done several hundred of them like this and they've all been frame accurate. But that's not really the main issue anyways. Was just curious about the trims on load and why I'm tapping out my transcode farm when I hit the same source too many times. It appears to me that avisynth is scanning the entire source file even when it's just trimming a few frames. I'm not super network savvy though, so I might not be barking up the right tree anyways.
Gavino
15th November 2009, 21:40
It appears to me that avisynth is scanning the entire source file even when it's just trimming a few frames.
It shouldn't do.
But as I said, depending on the source characteristics, the source filter or codec may have to scan at least up to the start of the trim, if it cannot directly seek to the appropriate position.
wonkey_monkey
15th November 2009, 22:46
Problem is, since each AVS scans the avi in full just to grab a trim of a few frames, it's straining my crummy network storage to the point that all my transcodes fail.
I'm not entirely sure how you're implementing this, but I've had experience of farming out AVS jobs in sections with trim(). Despite managing 15fps with mcbob (which ran at <1fps on a single machine), I begin to see diminishing returns when I added new machines. All those machines seeking large amounts of data simultaneously from different points in the file... not good. And then when each participating machine finished at about the same time and started copying back it's file to a network location... also not good.
AviSynth should only have to look at the index at the end of the file (up to a few hundred k), then it should be able to decode from the correct frame (or nearest keyframe).
David
a451guy451
15th November 2009, 23:32
Alright. Thanks for that bit about the index. I've been fiddling with it for a while now, and I'm starting to think that there's just too much lag created by all my nodes hitting the same file on my network storage (which, since it's sorta ductaped together, doesn't have a huge amount of I/O power). I think I just need to scale back and figure out what the proper balance is. Thanks for the input all.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.