serving compressed audio frames in avs...

Well when you do src = avisource(...) src1 = src.trim(0,xxx) src2 = src.trim(xxx,yyy) src3 = src.trim(yyy,0) return src1+src3 Avs will return uncompressed audio (needing a reencode) which is bad when you could just direct stream copy the audio frame.... So what about a flag on audio stream saying to keep audio in a compressed form (or by default if no audio filter applied?) then we could use vdub/ndub/vdubmod in audio direct stream copy, and avoid a recompression... esby PS: edited: corrected title of the topic, since it's dealing with compressed audio frame & not non compressed ones.

I have been pleading for this for a while.

I've had this on my mind for some time. To be honest I couldn't say at this point what architectural changes would need to be made to allow compressed A/V, since to be useful it would have to allow some filters like Trim to operate on it. I'll have to study the VDub code and see what it does.

AviSynth only deals with decompressed sources - adding compressed "passthrough" doesn't make sense in AviSynth, and would break everything in AviSynth. Use vdub for these tasks.

@Shodan - It's not always that simple. Sometimes you are dealing with 'odd' formats, sometimes you are having (for whatever reason) difficulty extracting the original audio. Audio isn't always available in an easily accessible file. This doesn't mean you CAN'T get to it, but it would save *several* unnecessary steps if a passthru option was available. If (for the moment) that means Trim or certain other filters cannot be used in passthru mode, then so be it.

Well, i (re?)started this debate, this post is a bit long, but i hope it will help in a way or in another. It's mainly a single reflexion and some ideas. For me, directStreamcopy is a vdub property coming from the avi structure. If aviSynth is what it's stands for, it should be possible to create this property in avs too. but Let's continue by an example: When you rip a dvd to an avi file you do: (in a very rusty way) dvd ==> avisynth ==> encoder application. where you have yv12 colorspace in entrance, and yv12 in output if you are using xvid... Now, let's take another example: avi to avi. (eg:fansubbing case) avi ==> avisynth ==> encoder application. of course if your decoder decode via yv12 and your encoder use yv12, the fastest way is to try to keep yv12 in the filtering process. Now suppose we don't want to reencode the avi but just change the flux in it, trimming & retrimming according to the avi restriction. Actually we can't do it. since avisynth decodes the video by 'default'. In this case the fastest way should be to keep 'compressed frames' and trim with the structure. Now another case, more realist, because nobody uses or probably plans to use avs in this way. The audio case: For each video frame corresponds a certain ammount of audio frames. Usually, you don't want to reencode the audio, unless you can't keep the format.(ac3 --> mp3 etc.) But in some other cases, you might want to keep it, (ac3 --> ac3 ; mp3 --> mp3) And there, if we go via the avs way actually, we are : 1- forced to killaudio() gently and mix it later. 2- decoding in avs & reencoding it in the fly in the encoder. Now let's consider, we have to trim out the commercials of the video so we'll end with the case : src1 = src.trim(xxx,yyy) src2 = src.trim(yyy+1,zzz) # just for conveniance src3 = src.trim(zzz,www+1) (... repeat theses steps till we have no commercial to cut) return src1+src3+src5+...+src19 #excessive case Now if we want the audio correcly synched, it will be a pain to trim the raw in vdub like we did in avs, just to extract a synchronized audio... And if we reencode via avs we'll loose quality. So the motivation is the same than with using yv12 plane, to gain time, adding to this it reduces the chance of errors caused by the human intervention. That's all for the 'justify it' part. Now to be technical. we have colorspace for video stream in avs. What about a colorspace named 'Oz' ( where impossible become possible), being a (virtual?) compressed colorspace. in 2.5, that will make Oz, yv12, yuy2, rgb you can go: Oz-- -->(another colorspace) via a decoder. you can go(in theory) (another colorspace)-- -->Oz via the codec in compression mode. Now let's talk about the restriction, since Oz is a special colorSpace, Only filters not affecting or not using the uncompressed data are authorized. Meaning : crop(),resize(), tweak(), etc. are not possible. But functions such as trim() are possibles, if they respect the avi specifications, thoses being mainly: do not start trimming on a non keyframe, do not concat differents streams using different codec... in avs scripting, that would mean src = avisource(...,decode=false) src1 = src.trim(...) src2 = src.trim(...) src = src1+src2 src = src.decode() # only if you want to use filters #maybe a convertToColorSpace() could just do the trick in term of syntax return src Now for the real case, the audio: Since no colorspace exists, a flag & an audio fourCC can do the trick. If you want to apply audio filter, you must be sure they fit the req(audiospace?), and if they are not able to operate in compressed space & given f4cc, they should throw warning (like what happend when you try to use yv12 filter in rgb...) Of course you should be able force the audiodecode(), which would enable the use of audio filters. But if you don't decode, the encoder will get compressed frames and fourCC from avs. Hopefully for the audio, the spec for trimming are less strict, (at least for mp3 and frames based audio codec vdub uses for audio) So regarding what i said, i'm not sure this would break avs, maybe it just hard to implement correctly, and it's not a priority indeed. But if that was to be implemented, it will reduces the ammount of work & time needed when you need to trim several times in an encode. (dvd or fansub) esby

I partially changed my mind. It is vital that Trim work properly even with a passthru option. To me this would be #2 on my priority list. #1 is having a fixed DirectShowSource (/w audio, seeking, FPS detection, correct framecount) which is being attempted. Thanks Shodan! :) EDIT: Did you delete that thread? I swear you created a thread about an experimental DirectShowSource you were working on. Tell me I'm not crazy. With both of these abilities, we should be able to work around any audio troubles much easier than present.