Why do people use VFW? I'll tell you why.

[DeathTheSheep]

Since you seem to want to use VfW.. may I ask why? I'm just curious.
People often gravitate towards VFW, and many hard-core doom9ers seem to be confused about this, or simply do not understand the rationale behind the usage of VFW over many of the other newer encoding methods sprouting up.
Perhaps someone needs to shed some light on the matter as I (and many of my peers) see it.

Why do people go VFW? I'll tell you why.

To many people, VFW gives them freedom.
Many people wish to live in a world where they can edit and tweak and refine and modify and change and compare all of their videos using a single tool. Today, there are innumerable programs that support all of this, the most famous of which is our beloved VirtualDub though there are many other encoding/editing/modifying/playing tools which support or rely on VFW as well (videocleaner, VirtualDub, AVISynth, mpegable, NERO even ;) etc.), whereas the only darn way to get a good x264 encode these days is to go hunting for programs and frontends (either that or use the frustrating CLI with specific kinds of input). This is a problem. People don't want to have get to know tons of radically differnet encoding programs, each of which requires a new learning curve. They want to use what they wish, how they wish to use it. With VFW, this was and is possible-- it is possible to use any given VFW codec in any given program that supports VFW. This is completely impossible with the current 3rd-party, frontend-based x264 encoders we have today; every frontend supports only itself, and there can be no linkage between these tools and any other program unless a specific arrangement is made for both. In essence, there simply isn't a system as free and easy as VFW. So, the question is: "Why can't the new stuff do this? Why can't I edit my files, or edit/modify/encode how I want with the software I want?" An answer is not forthcoming. Is it so unrealistic to hold new technology to the same standards of convenience and freedom? Or must people be shackled?

Popular VFW codecs like XviD and early x264 give you absolute freedom as a video encoder, and are available within nearly every video editing/encoding/etc application, a widespread and universal availability that is often due solely to the fact that each is a VFW solution, which is supported nearly everywhere.

To them, VFW gives them convenience.
They'd rather just use the VFW with *ANY* video program they deign to choose and have their happy little VFW along for the ride wherever they go. Additionally, they have to install but *one* piece of software, the VFW, which isn't technically a "program" in and of itself and therefore not subjected to the constant programming issues that go into tools such as MeGUI (oops, today it doesn't load right. Oops, today it needs a new framework. Oops, today it displays this error message about "job not found." Oops, I'll need to update my profiles again because the new program doesn't support it, etc).
The numerous x264 frontends, which the encoding world is now forced to resort to, consist of innumerable separate, 3rd-party GUI frontends, all of which undergo changes at a breakneck pace, completely undermining any attempts to make encoding guides as each frontend makes 10 changes a week. Sometimes these changes (complete, useless layout shifts, etc) so radically change things around that large rewrites are sometimes necessary—for the software, for the guides, and for the user's encoding routine. Some tools cease being updated, some simply accumulate bugs, some are too bloated, many experience said rewrites on a daily basis. This is the biggest merit of using VFW instead -- one universal, non-3rd party solution that works with anything, is always improved, and provides the most freedom they as video encoders deserve. XviD, for instance, is used almost entirely in its VFW form, which has remained relatively error-free, crash-free, free of usability issues, free of radical changes, and free of all other woes of 3rd party software which make the entire video encoding experience of many video enthusiasts suffer dramatically. Refrain: Is it so unrealistic to hold new technology to the same standards of convenience and freedom? Or must people be shackled?

To them, it saves time.
Time spent learning MeGUI's innumerable layouts, time spent hunting down programs that frontend it properly, time piecing through old crappy GUIs to find one that works, then to start the process over.
Time spent worrying about program-level bugs. The VFW, from its creation, has never once crashed on me, whereas MeGUI does so every other build, it seems.
Time spent learning AVISynth
Time spent compressing from the editing program, only to do it again in order to get it in AVC
Time spent muxing raw streams into AVI with very user-unfriendly tools which take forever to mux, often producing shabby results.
Time cleaning up all of the intermediary files necessary to get one music video into AVC.
Time waiting for the new features of each 3-rd party application to come out.
Time waiting for the bugfixes which invariably plague these frontends to be resolved.
Time spent downloading new frameworks for such software pieces.
Time spent relearning the frontend every other week due to rampant changes and rewrites.
Time spent pouring through the befuddling morass of constantly changing commands and encoding tools, many unique to each frontend and unavailable in others.
This list can go on indefinately. It's often hard to count the hours of peoples' lives wasted at the hands of frontends and GUIs every time they want to edit or compress video, which they can't do without using a limited set of 3rd-party programs.
This isn't how it was with VFW.
Refrain: Is it so unrealistic to hold new technology to the same standards of convenience and freedom? Or must people be shackled?

To many people, VFW is the solution they all need. Fine, one that requires "hackology," fine, one that requires 2-3 dropped frames in the beginning of the file, fine one which is relentlessly ridiculed by the entire DVD-encoding community. But despite all of this opposition, VFW is one solution that time and time and time again, has proven to work when other tools fail, proven to run fine when others crash and burn. Time and time again, it is one that never fails to mux and play via any AVC-supporting player, unlike the mkv troubles that so plagued (plague – present tense, even?) MeGUI and other tools. Time and time again, one which proves its merit tenfold in encoding convenience, usability, playability, bug-free-ness, usability, editability...the list goes on.
The only all-in-one solution, true, but it's managed to beat out nearly all the rest in at least all of the points above, at least at some point or another.

When all is said and done, who WOULD choose anything besides VFW? Is it really worth the hassle of non-VFW encoding over simply remembering that the stream is 3 frames behind? Or that there's a bit of overhead in AVI (which is easily solved by exporting to OGM via a 10-second, 3-click procedure in VDUBMOD, which gives you the *least* overhead of any container--perhaps barring MP4, thereby giving you the very best of both worlds)?

No, until someone comes out with a 'VFW2,' there's no hope in getting people away, nor any good reason to. Look how many people selected "VFW" in the recent poll, even though personally, I was quaking like a sheep scared to death. Even through fear of container discrimination ;), even though the folks registered on this forum are generally more anti-VFW than most I've seen, even though plenty more than "10%" of the folks I know (and nearly all who make music vids) use VFW and wouldn't think of changing it in the near future, these brave folks still stuck up for their opinion and voted VFW, which is more than I did.

[Richard Berg]

No, until someone comes out with a 'VFW2,'
It's called DirectShow. Welcome to 1998 (older, if you count DirectX ActiveMovie).

[iceloki]

Ofcoz you can still use x264 vfw interface as well. But cli is still useful for me.
"Freedom", I think cli is really freedom, even better than vfw, almost we can do anything with cli, cli can work dependently, I can even use cli on linux/unix without vfw support. That's really 'freedom' i think. ;)
"Convenience", I don't think you can use vfw well without in-deep understanding to the options, which is the same as cli parameters. In fact, you can use default parameters at first, i don't think it make any different with the default vfw options. And another good benefit is that we can use cli from almost anywhere else such as script, batch files or shells or some other programs (just like MeGUI did).
"Time", I agree that the first time using cli is much difficult, but when u learn the parameters well, you will find it really efficient. Now I usually use a script to backup dozens of my movies without any depends on other programs. Which really save too much of my time.
And the other benefit of using cli is that we can exchange our encoding parameters in a much standard way, u know, to describe the config in vfw is really boring.
And I don't think it a problem to make a choice between vfw and cli, in fact, the x264 cli use a vfw front-end to get video from avs/avi. I think anyone can make a choice himself...

[DeathTheSheep]

It's called DirectShow. Welcome to 1998.
Oh yeah, what was I thinking. There are just butloads of programs that boast of DirectShow encoding :D

Seriously though, in terms of its current state of encoding usability, coupled with the fact that there are very few encoders for it, DirectShow is quite lacking. I have great difficulty even with switching containers in DirectShow, much less using a DirectShow movie editor, if one exists. For decoding, DS takes the cake, but otherwise, for an encoding solution, it hasn't yet started to be viable, nor does it seem like there are prospects of this happening.
I agree, it does indeed have potential, but such potential is as of yet unrealized, and I'm unsure as to the results of such a transformation of the standard encoding system. With the proper tools, however, it might evolve into something of substantial merit.

However, the very fact of its existence since 1998 has proved at least one sad truth to me: that such a technology isn't sought after in the encoding world. I only know of a few DirectShow encoders, all other modern codecs having chosen to move towards self-sufficient encoding modules rather than embracing universal standards (such as DirectShow).

Additionally, modern codecs such as x264 and VP7 have shown much greater interest in VFW then they have DirectShow, which I believe to be a radically different technology than its "unfashionable" predecessor. Perhaps if the current VFW system was modified slightly so as to natively support B-frames and newer containers (an abolition of the one-frame-in, one-frame-out system, essentially), there are more promising prospects of progress as opposed to the adoption of DS, which very few codecs have even taken note of over the years (encoder-side).

[Revgen]

This whole VFW vs. CLI debate reminds me of people who debate widescreen vs. fullscreen. People are either naturally intrigued or afraid of what they don't understand.

Some people prefer to see and experience the movie the way the director intended it to be. Others just don't like those "ugly black bars" at the bottom and top of the TV. This is because these people would rather see a compromised version of a film rather than change the way they experience a movie on their television.

CLI allows programmmers to write their code and present their vision without having to deal with the confines of a VFW platform. VFW provides conveniance and easy access for those who want to stick with what they understand rather than face the uncertainty of having to change.

[DeathTheSheep]

almost we can do anything with cli, cli can work dependently
A CLI encoder can only be integrated harmoniously within another program if that program is specifically modified to accomidate that particular CLI. This also introduces problems with upgrading--you cannot upgrade an integrated component unless the CLI exe is separate, in which case upgrading is pointless if there are new features introduced--you'll need to update the entire host software, an upgrade which is released later, increasing the waiting time.

No, a CLI's only practical use is independency, which is, like I've said, a hassle unless you are encoding one straight file and tend to make no modifications or changes, nor will you be able to in the future. A CLI is only preferable for Linux systems which don't support VFW.
But then again, how many codecs aren't windows-only? A percent, I'm sure, but certainly not all of them. What percentage of people run heavy video editing programs on Linux, or even run Linux at all? A percent, but not a large one ;).
I don't think you can use vfw well without in-deep understanding to the options
Hmm...DivX's VFW is pretty darn user-friendly, I should say. ;) Default options are the same, and its easier to push checkboxes than remember ugly tags especially if you select a lot features, especially when you mess up the spelling in the tags (which, from my experiance, is frequent).
we can use cli from almost anywhere else such as script, batch files or shells or some other programs (just like MeGUI did).
Funny how typing up automatic scripts doesn't quite edit your videos for ya :D
Also funny how much many people prefer using a user-friendly job management system *cough-VirtualDub-cough* over typing up and renaming textfiles, especially when they want to do a complicated task and might mess up one little typed word ;)
And like I said, you can't use a CLI from any other programs except those that are custom-tailored to that particular CLI, barring any updates the CLI might experiance or the fact that you now have to worry about the bugginess of the "other programs" as well.
the first time using cli is much difficult, but when u learn the parameters well, you will find it really efficient.
It's not learning the CLI itself, its the extraneous steps involved in the encoding process as a whole. Re-read "Time..." entries 4-6, where I outline some problems that occur with editing, appending, and compressing any non-preformed video file ;)
I usually use a script to backup dozens of my movies without any depends on other programs. Which really save too much of my time.
If the entire, processed, finished, edited, fine-tuned video file is on your system, in the correct format, and correctly referenced in your AVISynth file, then you might be able to get away with a script -> CLI -> LockedOutput.raw, which you'd then need to mux into AVI anyway for further editing. It saves time only in very particular cases, and only then if you don't know how to get VirtualDub to do almost the same :)
we can exchange our encoding parameters in a much standard way
Would that really be more standard than following a good x264 guide or choosing self-explanatory settings in the VFW? If someone said to enable rate distortion for B frames, you'd have to look up the proper commandline tags and adjust them accordingly, presuming you'd used them right in the first place. The VFW would have a simple checkbox under "B-frames." Sharing parameters without explaining them isn't beneficial to the user anyway, who could easily garner similar results from a preset or some such thing.

in fact, the x264 cli use a vfw front-end to get video from avs/avi.
It's a choice between other unstable, restrictive, isolated little 3rd-party frontends vs. one standardized, universal frontend (VFW) that's compatible with every VFW program I can think of. Also, a VFW is typically updated at the same time the codec is updated (except in x264's case now, unfortunately). I've made my choice ;)

[DeathTheSheep]

This whole VFW vs. CLI debate--
ARrrr, stop right there, mate. The CLI and VFW are different tools. Every encoder should have a CLI--it's the backbone of the operation. I'm not saying otherwise.

To use the darn thing, though, is another matter. I know very few people actually use the CLI itself to encode anway, but prefer frontends. I'm merely saying that VFW should be the frontend of choice for all the reasons I've mentioned above.

[This whole shebang here y'all] reminds me of people who debate widescreen vs. fullscreen.
:eek: That's...a very... interesting but fully non-representative comparison, my friend. This has nothing whatsoever to do with visual preference. It's about ease of use, conveniance, editability, etc of the VFW over other frontends...

We're not speaking of anything related to the old:
"I no like encoding wit dose DANG scary new thingees even tho they're betta' just cuz I is uzed to my old way and that's how it's gunna be. Cased clozd man. "
Just to get the message accross to those who are taking this wrongly, I only use the outdated VFW for editing. It's now feature-ly inept for other applications. I was forced long ago to abandon it for the other frontend "solutions" (such as MeGUI and RealAnime), and I have a sizeable amount of experience with both. Now, in fact, I daresay I have more experiance slaving away with MeGUI than I do with the VFW, which I believe is truly a sad situation for the encoding world in general.

People are either naturally intrigued or afraid of what they don't understand.
Wait a minute here--I sense an accusation here, and one I ain't all too fond of. Understanding? So that's what it is? :sly: Hey...wait, lemme say it better: Did you actually read a word of what I wrote up there or did you simply assume this was a mindless rambling of someone who is merely "reluctant to change"?
Allright. Tell me a way to move this one dirty scene in my movie to the end (as a "deleted scene"), then save as a compressed AVC file ready for any possible editing later. With VDub: open movie. Select dirty scene and hit cut, then move the slider to the end and hit paste. Choose codec from the list, save as .avi. Voila.
Wow, so it must be even easier with these new tools (these strange tools I don't understand ;))! I wonder how easy it is to do so much as a simple copy-paste with these state-of-the-art tools, if only I'd get to know them.

Your argument has merit, but unfortunately, it doesn't apply at all in this situation. With VFW, there will be no intermediaries, no scripting, no locked containers, no hassle, no wasted time, no beating around with parameters or obscure AVISynth commands, just simple cut and past. (Tell me how that's possible with non-VFW material :sly: ) And yet some people say this is all about "not wanting to upgrade my mindset with the new technology." lol

[celtic_druid]

I really don't get this. As far as I know no one said that you can't use x264 via VfW.

Ok, I stopped uploading VfW builds some time ago, other than as part of FairUse Wizard.
Ok, no one has released a public patch updating x264 VfW in awhile.
Ok, people might make fun of you for wanting to use VfW.

Still nothing stopping anyone using it. There are still publicly available binaries and the source is open, so those who want can update it.

[DeathTheSheep]

no one has released a public patch updating x264 VfW in awhile.
That's kinda teh reason there, in a nutshell ;)
Still nothing stopping anyone using it.
...Yeah, but what about the cool new feeeeatures??
people might make fun of you for wanting to use VfW.

:scared: :( I feel execrated from the video encoding society :scared:
the source is open... update it.
Ah, you hit it right on the nose there-- it looks a bit beyond my league...ya.

But this thread's more about "why" and the justification than "please, please, pleeeeeeeease somebody do it" -- that's been asked too many times before and I'm all cried out :(

[Richard Berg]

There are just butloads of programs that boast of DirectShow encoding...much less using a DirectShow movie editor, if one exists
You must be talking about the OSS world only, because all of the major commercial apps use DirectShow. There's nothing wrong with OSS -- I use & develop it all the time -- but it's not the only software model, and in this area it's lagging the industry, not the other way around.

The absence of OSS Directshow filters is mostly a historical accident. Encoders stay CLI because most of the dev effort comes from Linux, which doesn't really have a competing API; processing filters have been able to avoid DS only because most "rip tools" use Avisynth (which, once established, kept its lead due to its much simpler plugin interface); none of these advantages applied to decoders, and so 99% of Windows users decode through DS. This has made for an interesting & vibrant community, but you can't really argue that it's better this way. For instance, if Avisynth hadn't become popular just at the right time and OSS filter developers had started coding for DS instead, then you'd be able to use Dust and FFT3DFilter and Decomb directly from within Premiere, Avid, Vegas...or Graphedit...or Avisynth.

[ChronoCross]

the problem with vfw is the generally accepted fact that the newer formats get hacked to pieces by avi. There is no point in using vfw if it's just going to cause problems with actual features. As has been pointed out in at least 5 audio out of sync threads.

As for ease of use. There are 3 programs that I can think of that do it just as easy(load file, choose settings, hit encode). Not that difficult.

As for editing functionality it's vfw that has caused this problem. Since everyone wants to still use vfw even with it's downfalls the need for developers to make enhanced tools to do editing in mp4 isn't in high demand right now. Once it is then you'll be able to have more programs that do it.

As for saving time I think it's exactly this idea that has made for 100's of "help me omfg I didn't read the manual" type issues that could be solved by a simple search. If people would learn to do it well rather than fast the encoding community would in general be even stronger.

vfw is outdated and causes too many issues.

Edit: I wanted to add an additional idea to this. Has anyone ever thought of avisynth based editor? As far as I know all the functionality of editing in vdub can be accomplished using avisynth. I think that would be pretty sweet.

[Revgen]

:eek: That's...a very... interesting but fully non-representative comparison, my friend. This has nothing whatsoever to do with visual preference. It's about ease of use, conveniance, editability, etc of the VFW over other frontends...

I'm not talking about visual preference, I'm talking about how people think.


We're not speaking of anything related to the old:
"I no like encoding wit dose DANG scary new thingees even tho they're betta' just cuz I is uzed to my old way and that's how it's gunna be. Cased clozd man. "
Just to get the message accross to those who are taking this wrongly, I only use the outdated VFW for editing. It's now feature-ly inept for other applications. I was forced long ago to abandon it for the other frontend "solutions" (such as MeGUI and RealAnime), and I have a sizeable amount of experience with both. Now, in fact, I daresay I have more experiance slaving away with MeGUI than I do with the VFW, which I believe is truly a sad situation for the encoding world in general.


I'm glad you see it this way. Some people don't.


Wait a minute here--I sense an accusation here, and one I ain't all too fond of. Understanding? So that's what it is? :sly: Hey...wait, lemme say it better: Did you actually read a word of what I wrote up there or did you simply assume this was a mindless rambling of someone who is merely "reluctant to change"?

No accusation intended. These are simply my thoughts of people I've had personal experience with who are reluctant to change despite the advantages. If I wanted to accuse you personally, I can PM you;) .


Allright. Tell me a way to move this one dirty scene in my movie to the end (as a "deleted scene"), then save as a compressed AVC file ready for any possible editing later. With VDub: open movie. Select dirty scene and hit cut, then move the slider to the end and hit paste. Choose codec from the list, save as .avi. Voila.

You can use MeGUI and Vdub together with Vdub's frameserving feature. See my post in Doom9's sticky.


Wow, so it must be even easier with these new tools (these strange tools I don't understand ;))! I wonder how easy it is to do so much as a simple copy-paste with these state-of-the-art tools, if only I'd get to know them.

You have a point there. It is a little more of a hassle, but for me it's worth doing to use the advanced features of the x264.exe and MeGUI. It may not be worth it for others.


Your argument has merit, but unfortunately, it doesn't apply at all in this situation. With VFW, there will be no intermediaries, no scripting, no locked containers, no hassle, no wasted time, no beating around with parameters or obscure AVISynth commands...

Is

avisource("mydrive:\myvdubframeservefile.vdr")
ConvertToYV12()

an obscure AVISynth command?

I can only imagine how you could feel looking at Didee's scripts.:D

I understand what you're saying, but I reiterate that I personally don't find it too big of a hassle considering the quality that I recieve in return for using x264.exe and MeGUI. That may not be the case for other people.

The reason why the devs don't update x264vfw is because x264 is still in active development and VFW with all of it's constraints (especially when it comes to B-frames) is PITA to develop for. I'm pretty sure that when x264 reaches a point where the project starts to mature that a fully working vfw version will be made.

[Manao]

which is easily solved by exporting to OGM via a 10-second, 3-click procedure in VDUBMOD, which gives you the *least* overhead of any container--perhaps barring MP4, thereby giving you the very best of both worlds)?You certainly meant the worst of both worlds, isn't it ?modern codecs such as x264 and VP7 have shown much greater interest in VFW then they have DirectShowHuh ? why do you complain then ? No, really, I think you must have meant "only x264 and VP7 cares about VfW", which is quite closer to the truth : DivX goes away from it ( DrDivX ), XviD too ( enc_raw's developpement is resumed ), all AVC codecs except x264 and vss don't do vfw, real doesn't either, so doesn't QT.Perhaps if the current VFW system was modified slightly so as to natively support B-frames and newer containers (an abolition of the one-frame-in, one-frame-out system, essentially)Ah, but no. The only reason vfw is used is because it allows easy editability. That editability comes to the price of the design of the framework : one frame in, one frame out, and constant framerate. Remove one of them and you lose the only vfw assets ( i'm talking about the framework itself ). And what makes you think that a vfw2 would be adopted by all the softwares you want to use ? ( and without making them buggy for a while during the conversion )


For all the other complaints, it really comes down to 'i want a stable version of an encoding software' and 'i want to be able to use x264 with the program I want'. The first one is hardly related to vfw. Go bug GUI's developpers on their respective threads to ask them to make 'milestone' releases, and instability will be gone.

The second one is quite more to the point. Indeed, vfw allows a good deal of interoperability, and is in fact the only interoperable environment known to the OSS world ( as Richard stated, DirectShow is only used by professionnal - but widely used by them -, and the other alternatives that comes to my mind - QuickTime and GStreamer - are either a pain or a bit too unstable still to be usable )

Now, that interoperability comes with a price : you don't use the codec as it should be. Quite frankly, I wouldn't mind using a vfw version of x264 where bframes and mref are disabled. That way, I'd produced files that are valid - in a way - in the avi framework. But I guess you wouldn't like being deprive of two of the great assets of x264, would you ?

Edit :
The reason why the devs don't update x264vfw is because x264 is still in active development and VFW with all of it's constraints (especially when it comes to B-frames) is PITA to develop for. I'm pretty sure that when x264 reaches a point where the project starts to mature that a fully working vfw version will be made.Somehow, I doubt that. It's quite easy to maintain the GUI, but nobody's doing it, because nobody uses it. The issue is that devs are people eager to learn new things, such as new GUIs or CLI tools, and that devs are reluctant to do bad things, such as putting mrefed, bframed video into a container not designed to contain it, especially when other containers ( namely mp4 and mkv ) are much more suited to the task. And even if one unselfish dev would want to update the vfw GUI, he would still hesitate, because he would know it would only bring evil into the world - because people would unknowingly do bad things with it.

[MeteorRain]

DeathTheSheep:
Why we don't use VfW is that, it is too old. You can't make that old interface to fully fit the new codec. We have to change, find a new home for h.264. And CLI is a good choice. It's convenient to developer -- they don't need to write lots of code to fit that old interface nor to do a lot of hack like DivX in putting menu or something into AVI.

[twist3d]

deathtosheep: my morning babble ->
if you really appreciate x264 and use it daily to encode your videos, studying cli for that extra 15min (that took to write your post for vfw) or using megui with those excellent sharktooth's x264 profiles isn't that difficult. Many programs work through cli, ie. lame, ogg vorbis - don't really know if younger generation really understands commandprompt, many of us old-timers have dos-commands in our backbones ;D. But my main point is: If you appreciate the x264 coders and want really those "cool new feeeeatures" it isn't really that hard to learn something new than to promote and use 10-year old technology. Just my 2c.

[celtic_druid]

It isn't hard for simple updates like adding trellis, b-rdo, etc. Have a look at one of the older patches.

Just stuff like:
- { "mixedref", &reg.b_mixedref, 0 }
+ { "mixedref", &reg.b_mixedref, 0 },
+ { "trellis", &reg.i_trellis, 0 }
and
+ case IDC_TRELLIS:
+ config->i_trellis = SendDlgItemMessage(hTabs[3], IDC_TRELLIS, CB_GETCURSEL, 0, 0);
+ break;

It wouldn't take long. Problem is that it just encourages people to use VfW for encoding. Better use of time/effort would be to create a dshow wrapper for libx264.

[Doom9]

I know all the reasons too well.. but at some point I asked myself: how much of the advantages are mostly imaginary? What good is editability if the only thing I'm ever going to do is split the movie into CD sized pieces? It's not like I'm going to do further processing.. after all.. under fair use provisions I'm supposed to have the original so I can make another copy from that if needs be. So when it comes to splitting by a certain size, I really don't need VDub for that (and let's not forget that VDub is no good to most people for that.. they use Nandub or VDubMod because plain VDub doesn't support VBR audio nor go to a certain split size). For me, the advantage of editability is thus mostly imaginary.. I really can live just fine with the alternatives as I eventually found out when I looked beyond my noise.

As far as convenience goes, you're getting way ahead of yourself. So you have the same encoding tool. And then? And then? And theeeeen ? (perhaps you remember the movie). How the heck do you get your DVD into VDub? AviSynth of course. How do you create your AviSynth script? Via Notepad, or GKnot of course.. so there's another tool right there. How do you get your dgindex project? With dgindex of course.. another program. Then you need to encode audio.. so BeLight it is.. then mux audio and video.. VDub it is. Or, you use one of those despisable frontends that you seem to not like at all. GKnot is such a frontend too.. except for the codec configuration dialog, it's all its own app as well. So is AutoGK (it doesn't even let you access the codec's internals). So in the end, if you want some degree of automatization, you have no choice but to use some frontend, and they all have different GUIs and learning curves.

When it comes to AviSynth.. ever tried dragging and dropping a file into MeGUI? It basically does all the work for you. And you don't have to learn the GUI. Say you want video encoding only, you drag and drop your video file.. if it's not an avs, your avs will be created with a few clicks (offering way more features than comparable tools.. automatic interlace detection anyone?), then you select one profile, and you're already set. You never even have to enter the codec configuration dialog. And as far as the queuing system goes.. if you know VDub, you know MeGUI because they work exactly the same.. they even look the same.

I'm sure staxrip and realanime offer similar advantages over using VDub manually.

Tell me a way to move this one dirty scene in my movie to the end (as a "deleted scene"), then save as a compressed AVC file ready for any possible editing later.First off.. how often does that happen? Never and then some? Ever heard of the 80/20 rule? Then, for later editing.. with a 300 frame IDR frame intervall.. heck yeah.. better do your editing once before encoding.. it never has, VfW or not, been a good idea to edit MPEG-4 files after the fact (encoding).

It's a choice between other unstable, restrictive, isolated little 3rd-party frontendsAs developer of one of these tools, I take offense . Plain video encoding hardly ever breaks and most issues reported with MeGUI are not the application's fault or some obscure use case. Just because you see many reports doesn't make them all our problem.. if encoding fails due to an improper source.. not my problem, if encoding fails due to an old build not compatible with the commandline, not my problem, if somebody muxes the content with another muxer and forgets to set the proper framerate so the audio is out of synch, not my problem, and I could go on rambling for an entire day. And it's not like the x264 vfw never crashed.. you're just conveniently leaving that out.

Refrain: Is it so unrealistic to hold new technology to the same standards of convenience and freedom? Or must people be shackled? Considering the automatization I get from MeGUI as opposed to doing things manually in VDub, I'll gladly give up that imaginary freedom. I used to create scripts in GKnot and encode them manually in VDub (partly because codecs were VfW, partly because of its job management). Now that I have MeGUI.. I have little use for those other tools.

They want to use what they wish, how they wish to use it.Then they have three choices: 1) find a program that does that, 2) write a program that does that, or 3) pay somebody to write a program that does that.

[Doom9]

by the way, I almost forgot to discredit your editing example: Audio is going to be a headache. You are limited to old/dead VDub derivates unless your audio is CBR MP3 with a WAV header (which app writes that by default?), or a plain WAV file (= large intermediate files), or it's part of an input script (oh no, AviSynth again). And, say we use AC3, AC3 frames have a certain size.. you can't just cut where you want but it has to be at an AC3 frame size.. so if those errors accumulate, your audio will go out of synch. So basically your audio has to be PCM for optimal results.

[stax76]

3rd-party GUI frontends, all of which undergo changes at a breakneck pace, completely undermining any attempts to make encoding guides as each frontend makes 10 changes a week.


I'm pretty much done with StaxRip, it appears to be matured enough, docs are pure but it's not too hard and I'm not good in doing docs. I'm already thinking about a new project, working on StaxRip I've learned a lot about .NET, I want to do something with C++ now and learn a lot about C++. Your post don't sound like you've ever tried StaxRip btw. because I think it addresses some of the mentioned problems.

[bkman]

This is no different than the Windows VS. Linux debate. One likes theirs because they don't have to go out of their way to understand how to use it, and the other side already has and can't imagine giving up the extra flexibility and power.

'Nuff said, really.

[foxyshadis]

I do agree that Virtualdub's wide acceptance has retarded the creation of more advanced editing tools, since it's generally good enough and codecs have conformed to its standard for so long. It doesn't offer any of the features of mpeg editors, such as single-gop or partial-god re-encoding, knowledge of references, functional vbr audio cutting, but to people who just need something to back a DVD up it's good enough, and in fact still is until newer audio formats (and dual) enters the picture.

On the other hand it has something DShow doesn't guarantee and rarely seems to have: perfect seekability. Cutting a video up and re-muxing or re-encoding in a directshow environment is impossible because you could end up 5 frames off from where you thought you were. Not that b-frame delay works usefully in vfw, but most other formats (as well as packed bitstream) do work pretty well for editing.

I'll be the first to agree that vfw is long past its expiration date and smelling rank. But there's nothing to replace it yet that can cut out a scene because you dislike it, or save a hilarious 30 seconds to send to a friend. Nothing to directly edit most codecs without manually writing a script (vdubmod's ability to create a directshowsource script was a huge timesaver I'm sad to see never implemented in mainline; I love megui being able to do that). The containers to work seamlessly with vfr, modern audio, and wild new codecs are here, but not the tools to quickly and simply dissect them.

And in 10-15 years I'm sure it'll be outdated as well, less if it's not designed as openly as vfw.

I'll also agree that a forum dedicated to DVD and capture backup is not going to be interested in this, because your aim is to get it into that final container and leave it alone, which is totally understandable. But I'd like to be able to back up my lastexile box set and still be able to use it for other purposes, eg, AMV/commercials.

[DaveEL]

How about a vfw codec which does the following.

Every frame in it writes out a frame to vfw with dummy data in (more on that later). But the real x264 bitstream is written out to a proper mp4 file specified in the codec config dialog. This way you can output MP4 from any vfw app. Ok this now give us a problem with audio an ACM codec with the same function should solve that problem as long as the two can communicate with each other the output can be place in a single muxed file. This is ok for output but doesn't really deal with avi input at all. For that i suggest that the dummy data which is output to the avi is in fact a filename of the location of the real output. When the codec is asked to decompress the data it in fact opens the filename in the bitstream and decopresses the real data. OK we will need a utility to change the filename in the avi when we move it around but that should be a nice simple utility to write and use anyway.

DaveEL

[Sirber]

How about a vfw codec which does the following.

Every frame in it writes out a frame to vfw with dummy data in (more on that later). But the real x264 bitstream is written out to a proper mp4 file specified in the codec config dialog. This way you can output MP4 from any vfw app. Ok this now give us a problem with audio an ACM codec with the same function should solve that problem as long as the two can communicate with each other the output can be place in a single muxed file. This is ok for output but doesn't really deal with avi input at all. For that i suggest that the dummy data which is output to the avi is in fact a filename of the location of the real output. When the codec is asked to decompress the data it in fact opens the filename in the bitstream and decopresses the real data. OK we will need a utility to change the filename in the avi when we move it around but that should be a nice simple utility to write and use anyway.

DaveELfiles can be hand renamed ;)

[Inventive Software]

I'd still like to see a VFW app that outputs to MP4, natively. VirtualDubMod anyone?

[DaveEL]

Exactly why i said we need a utility to update the fake avi output. Ok this is not a perfect solution but it does seem to go a long way to proucing output that is without the VFW/VCM/ACM limitations but still available through applications supporting the VFW api.

[DaveEL]

I'd still like to see a VFW app that outputs to MP4, natively. VirtualDubMod anyone?

Thats the whole point VFW cannot support MP4 its a limitation of the VFW api.

DaveEL

[Kurtnoise]

@DaveEL :: http://uci.sourceforge.net/

[Inventive Software]

OK, wasn't aware of that.

[DaveEL]

@DaveEL :: http://uci.sourceforge.net/

That doesn't solve the problem at all. I looked into what it did some time back while i am sure its made progress its still a different API that everyone will have to write apps to support.

DaveEL

[DaveEL]

In fact looking at the page it doesn't look like any progress has been made in the since 2002

[Inventive Software]

It's unlikely to be adopted anytime soon.

We need something that Microsoft will get behind, but isn't DirectShow. That way it will take off better.

[Doom9]

Cutting a video up and re-muxing or re-encoding in a directshow environment is impossible because you could end up 5 frames off from where you thought you were.This is the parser's fault though.. a good parser is frame accurate.

I'd still like to see a VFW app that outputs to MP4, natively. That's only half the story. Obviously you'd also like to be able to use an AAC audio encoder, mux audio with video, open MP4 files and edit them... just admit it. I know that's what I'd like. It isn't about the architecture, it's having a tool that offers the editability features VirtualDub has.. it is its strongest selling point and no other application using any architecture has come close to achieving this..

[Inventive Software]

Perhaps that what you want with MeGUI? It could become what VirtualDub is to VFW what MeGUI is (sort of) to CLI codecs.

[jackiehcs]

avs scripting does all the things that VD can do.
CLI+avs gives you the most convenience if you've learned about avs scripting by just reading several doc.
CLI+avs won't waste your time, and GUI gives you even more convenience after it has became stable.
People who is using GUI, which is still in develop, and saying that vfw is the best, is the most hard-core...

[DaveEL]

That's only half the story. Obviously you'd also like to be able to use an AAC audio encoder, mux audio with video, open MP4 files and edit them... just admit it. I know that's what I'd like. It isn't about the architecture, it's having a tool that offers the editability features VirtualDub has.. it is its strongest selling point and no other application using any architecture has come close to achieving this..

The problem is an application that can do that still does not offer the compatibilityi can't use output from hundreds of other programs unless you implement a VFW compatibility import and loading the output in other applications is a total no go.

Also one of the reasons vdub can support the lossless linear editing eaisly is the simple VCM rules. Once you starting talking about more complicated strutures then simply I and P frames it becomes a lot more difficult. This is a limitation also of the false VCM codec idea i posted above. you could do lossless editing on the avi as it would not effect the original file at all but to "apply the changes" to the real video data would be a lot more difficult. You would either have to
a) reencode the whole thing again
b) write a utility that applied lossless edited to the muxed file later.
Unfortunatly if following the VCM rules you can't really edit any file with B-Frames in it.eg the frame sequence

IBBPI
12345

take the frame 3 and 4 away as normal VCM style codec would you will find that you can't decode frame 2 anyway. This is the reason i suggested to the matroska guys a while back that had non-displayed frames possible in the container so you would remove frame 3 and while writing frame 4 back to the bitstream so you can decode frame 2 it would never be displayed. If later you removed frame 2 as well the hidden frame 4 would be dropped as it was no longer needed.

An alternative would be a "low" loss edit which would apply any updates possible losslessly and reencoded only those frames it has to.

DaveEL

[Doom9]

Perhaps that what you want with MeGUI?Not really, but with the addition of avisynth based audio encoding, input editing will become possible.. e.g. you can then frame accurately cut away those nagging ads from TV captures without running the risk of desynch. We'll see how much demand there is for editing beyond that point. But mind you that this is input editing, and it's limited to what the input provides (many DS parsers do not provide frame accurate nagivation)

This is the reason i suggested to the matroska guys a while back that had non-displayed frames possible in the container so you would remove frame 3 and while writing frame 4 back to the bitstream so you can decode frame 2 it would never be displayed. If later you removed frame 2 as well the hidden frame 4 would be dropped as it was no longer needed.Eww.. if you want frame accurate cutting, unless you have a codec that's using only I-frames, you always either have to settle to cut at a GOP boundary, or re-encode the GOP you're going to "cut into"..

[foxyshadis]

That's why MPEG editors feature single-gop reencoding. You could probably even hack that into a mod of virtualdub, but it'd be a heckuva hack. (I'm surprised mkv doesn't support extraneous frames, given it was designed with MPEG-4 lessons so fresh. Not always the best solution but it works. Does MP4?)

[DaveEL]

Eww.. if you want frame accurate cutting, unless you have a codec that's using only I-frames, you always either have to settle to cut at a GOP boundary, or re-encode the GOP you're going to "cut into"..

But this allows you to make multiple intermediate files as you go along editing and then do the GOP reencoding when finished rather then reencoding every time you save. Then again you can just save a cut list each time until your finished i suppose.

DaveEL

[bond]

ffdshow is already able to write native theora into .ogg from inside the vfw encoder (by outputting a fake .avi via vfw at the same time)

btw the only reason why people still use vfw is the existance of virtualdub
still this doesnt mean that encoding in megui (or other guis) is any harder or worse...

[Zero1]

Many people wish to live in a world where they can edit and tweak and refine and modify and change and compare all of their videos using a single tool.
I can appreciate that since I do a lot of encoding and non linear editing, flexibility is of the utmost importance, but for such cases I use HuffYUV or Lagarith (which are obviously VfW and using AVI). If I intend to put out something for distro, it will usually be using XviD or x264 and the likelyhood that I will need to edit these files is very low. Even so, should I need to, MP4box allows me to split files and I can always frameserve from AVISynth. Using directshow isn't a dead end.

As for your comment on comparing files etc containers such as MKV and MP4 have their own tools to analyse streams and give specialised information, rather than perhaps generic information. There's nothing stopping someone adding full MP4/MKV support to a tool like Gspot though, it's a great program.

Anyway, if people made the switch to MP4 a few years ago, like it should have been, as opposed to XviD becoming predominantly VfW, general MP4 support and tools would be much better than they are now. Fortunately Jeanlf and co. are doing a great job. MKV is doing amazing, so many features. Perhaps even directshow encoding would be more widely accepted. We only have ourselves to blame.

whereas the only darn way to get a good x264 encode these days is to go hunting for programs and frontends (either that or use the frustrating CLI with specific kinds of input).
Whilst CLI's invariably are different in the switches, uses etc, they usually work in a similar way, and have built in documentation which you can usually get by typing something like --help or -h. This will usually list all the switches and syntax, I can see how it can be confusing for a newbie, I've been there, done that. Trust me I used to hate CLI's and be exactly in your position wanting VfW to last forever, but I got frustrated with being stuck with MP3 audio (without any major hacks) and a "crippled" (read not updated as much as the CLI) x264 VfW. On top of that I thought to myself, "I want to use AAC, which is better than MP3, and I also want to use H.264. I can do this with hacks, but why bother when MP4 allows what I want and is not a hack?" All it requires is the installation of Haali's splitter over any codecs I would have instructed people to install if I went the way of AVI.

Because I would have trouble with CLI's I would look out for any examples and modify them to suit my needs, add and remove switches as I need. I still don't know x264 perfectly off by heart, but by this repetition of editing and viewing my batch files, I have remembered a good amount of switches I commonly use. I practically never type a command in full, I always use a batch and edit it, except for MP4box where the switches for a basic mux are very short. If I'm adding names to tracks and such, then I will lump it into a batch. Now that I have gotten used to it, using CLI's is no harder than AVISynth scripts.


The numerous x264 frontends, which the encoding world is now forced to resort to, consist of innumerable separate, 3rd-party GUI frontends, all of which undergo changes at a breakneck pace, completely undermining any attempts to make encoding guides as each frontend makes 10 changes a week. Sometimes these changes (complete, useless layout shifts, etc) so radically change things around that large rewrites are sometimes necessary—for the software, for the guides, and for the user's encoding routine.
Heh, come on. It's not all bad :p As far as guides are concerned, I started writing a guide for an AMV website for encoding with the x264 CLI, which includes a basic explanation of the switches, explanation of batch files, how to build a command line and common batch file commands (for instance IF EXIST, IF NOT EXIST). It's quite a long guide and is incomplete (and I need to check some things to make sure I'm not misinforming people), but it's my belief that I've explained it sufficiently for a regular person familliar with XviD to be able to read through and produce an encode using the CLI. It's not hard, but I can appreciate how some people feel about command lines, which is what prompted me to write it. I agree with you about the GUI's. Life would have been a lot easier for me to write a guide on MeGUI or something, but as you mentioned, it's subject to change. I've been using x264 since something like revision 200 and not a great deal has changed, mostly just the addition of switches, in which case it's easy to add to the guide.


Time spent learning MeGUI's innumerable layouts.............
.............Time spent pouring through the befuddling morass of constantly changing commands and encoding tools, many unique to each frontend and unavailable in others.
Hmm, a good guide (hopefully mine will be considered good when it's done) will be able to show a user how to use the CLI, this eliminates the first problem from that list.
As for time learning AVISynth, it's my opinion that it's more or less part and parcel with encoding, but I guess there are people that refuse to or don't know how to use this either. That aside, a basic AVISynth script ie. " AVISource("video.avi").converttoyv12() " is all you need I don't consider that much of a hardship, and is already covered in my guide (specifically using AVISynth to frameserve to x264 CLI).
As for "Time spent compressing from the editing program, only to do it again in order to get it in AVC" it's usually beneficial to do this. For example you have made a music video in Adobe Premiere, or some nice effects in After Effects. What most editors do is dump a lossless file and encode to whatever using Virtualdub later. Since most people (I hope) use 2 pass this is faster since you aren't rendering the file twice, you render it once and just compress a lossless file later. Even though such programs are VfW, they don't offer you the flexibility of Virtualdub, so there's that aspect to it also. Similarly, if you meant compressing a lossless in Virtualdub to frameserve to x264, well that's ok for similar reasons. Say if you have a complex AVISynth script, it would be better to dump it to a lossless file, and compress the lossless file in x264, otherwise doing a 2 pass encode with a filtered source is going to take forever.
Cleaning up. You could build this part into the batch file, just tell it to "del *.264 del *.aac del *.stats" etc. Downloading frameworks and relearning frontends is a non issue using the x264 CLI, and as stated before, the x264 switches usually remain the same. It's very consistant.

It really can be as easy or as hard as you want to make it. I cannot disagree though, that for sheer convienience Virtualdub is undisputable.


Time and time again, it is one that never fails to mux and play via any AVC-supporting player, unlike the mkv troubles that so plagued (plague – present tense, even?)
Woah, hold on there. VfW H.264 in AVI (with the associated hacks) is more likely to suffer problems than H.264 in MP4 (especially in future hardware players). As for MKV, I can't comment because I don't use the format enough, but again I'll say if MKV doesn't work for you, that MKV or AVI aren't the only viable choices. Try MP4, rather that than hacky AVI's, or did the associated problems come from people putting H.264 into MKV using the VfW compatability mode? I don't know. If they did they have no-one to blame :p


When all is said and done, who WOULD choose anything besides VFW? Is it really worth the hassle of non-VFW encoding over simply remembering that the stream is 3 frames behind? Or that there's a bit of overhead in AVI (which is easily solved by exporting to OGM via a 10-second, 3-click procedure in VDUBMOD, which gives you the *least* overhead of any container--perhaps barring MP4, thereby giving you the very best of both worlds)?
Yes it is worth it. If a job's worth doing, do it right. When there are alternate methods, I don't see why I should put up with frame lags, hacks, excessive file overhead, or limited choice of codecs. As for OGM, it's not intended as a multiformat container IIRC, so that's another bunch of potential problems. Leave it to Vorbis and Theora, or whatever it was designed to handle. Also, MKV v2 has lower overhead than everything, including MP4. Collectively, it's worthwhile to switch to Directshow.


Even through fear of container discrimination , even though the folks registered on this forum are generally more anti-VFW than most I've seen, even though plenty more than "10%" of the folks I know (and nearly all who make music vids) use VFW and wouldn't think of changing it in the near future, these brave folks still stuck up for their opinion and voted VFW, which is more than I did.
Maybe the people you know are the same type of people I know (AMV editors?). The majority of viewers are happy to stick with VfW because it's easy, it requires minimal "hassle" to play back. However, a lot of the video editors I know are perfectionists, and are very much willing to move to H.264 and MP4 and/or MKV in the search for higher quality. I think I've given around 6 people a crash course in x264 CLI and they took to it very well and are now releasing H.264 encodes in MP4. In fact it is a few of the guys in the #amv channel that requested it, which is why I started the guide.

Opinions are generally mixed. Fansubbing is making and increasingly bigger jump to H.264, the people moving straight from XviD in AVI tend to go the way of H.264 in MP4, maybe some groups still use AVI, but it's generally accepted that H.264 should be contained in MKV or MP4. The DVD ripping guys stay loyal to MKV, you also get some fansubbers using MKV, usually the audiophiles who have been using it for the ability to place Vorbis in it.

The fans, or the leechers aren't so happy about the change, yes it means smaller files with equal quality, but they don't look at the big picture distro wise. The common comment we get is "we don't care if a file is 60MB larger, just stay with XviD". The other comments pertain to installation of decoders and splitters, fortunately FFDShow and Haali's splitters keep hassle to a minimum.


However, the very fact of its existence since 1998 has proved at least one sad truth to me: that such a technology isn't sought after in the encoding world. I only know of a few DirectShow encoders, all other modern codecs having chosen to move towards self-sufficient encoding modules rather than embracing universal standards (such as DirectShow).
Well, this is partly down to the reason that people are content to use VfW, as you are. If people were unhappy about VfW, say for instance encoding x264 was not possible in VfW, people would switch. I bet you a large percentage of XviD and x264 VfW users don't even know about the various hacks or limitations, and therefore don't know it isn't strictly a good idea. As long as tools exist people will stick with them. It's like all this fuss over LCD and plasma screens. I recently spent a decent amount on a 21" flat screen CRT. Can't beat them... Progress? Hah! :p


Also funny how much many people prefer using a user-friendly job management system *cough-VirtualDub-cough* over typing up and renaming textfiles, especially when they want to do a complicated task and might mess up one little typed word
I disagree, managing jobs via batch files is just as easy, if not easier. It saves me time too. It's a lot easier to copy and paste a line, make a slight change to the file name than it is to go through GUI menus, reloading the video etc.

[Zero1]

One recent example was a real lifesaver. I muxed 26 episodes, each with 2 external files (78 files) to 26 MKV files. All I did was copy paste this command line:

"mkvmerge" -o "C:\mux\Episode 01.mkv" --language 0:eng --track-name 0:Subtitle -s 0 -D -A "C:\mux\Episode 01.idx" --language 0:jpn --track-name 0:Video --language 1:jpn --track-name 1:Audio -a 1 -d 0 -S "C:\mux\Episode 01.avi" --track-order 1:0,1:1,0:0
and alter the numbers accordingly. Must have taken about a minute to do. Would have taken ages to do in a GUI, setting it up each time. Also lowers the chance of human error since all operations are the same (unless you mess up the first one!). The other advantage, is that before transmuxing, the avi, idx, and sub files totalled 7.92 GB (8,508,969,437 bytes), and muxed to MKV is 7.87 GB (8,459,358,990 bytes). Smaller in filesize, and less clutter. Nice.


Allright. Tell me a way to move this one dirty scene in my movie to the end (as a "deleted scene"), then save as a compressed AVC file ready for any possible editing later. With VDub: open movie. Select dirty scene and hit cut, then move the slider to the end and hit paste. Choose codec from the list, save as .avi. Voila.
That's the way! Now instead of outputting to XviD, output to Lagarith or something (or even VDub's frameserver thing) and create an AVS script to serve the output to the x264 CLI.


...Yeah, but what about the cool new feeeeatures??
We need some incentive to push directshow, right?


As for editing functionality it's vfw that has caused this problem. Since everyone wants to still use vfw even with it's downfalls the need for developers to make enhanced tools to do editing in mp4 isn't in high demand right now. Once it is then you'll be able to have more programs that do it.
Bingo. You should be able to do some good things in MP4box though, with -cat and -splitx (and variations).

If you appreciate the x264 coders and want really those "cool new feeeeatures" it isn't really that hard to learn something new than to promote and use 10-year old technology. Just my 2c.
Agreed, but it's even older than that! IIRC it debuted in 1991 with Windows 3.1 (or it might have been 3.11 for workgroups, I think it was one of them). So 15 years old. I think the only software excusable for being that old and still used is notepad (which is even older I think) :p


or partial-god re-encoding
Even the big guy upstairs encodes! ;)


I'll be the first to agree that vfw is long past its expiration date and smelling rank. But there's nothing to replace it yet that can cut out a scene because you dislike it, or save a hilarious 30 seconds to send to a friend. Nothing to directly edit most codecs without manually writing a script (vdubmod's ability to create a directshowsource script was a huge timesaver I'm sad to see never implemented in mainline; I love megui being able to do that). The containers to work seamlessly with vfr, modern audio, and wild new codecs are here, but not the tools to quickly and simply dissect them.
Yeah, the big one with VfW is that most people already have some form of AVI splitter/parser, and a lot of people have DivX and/or XviD and if not they are small enough to send and effortless to install. For quick and dirty encodes or whatever, it rules.


But I'd like to be able to back up my lastexile box set and still be able to use it for other purposes, eg, AMV/commercials.
Yep, I guess this is the so called flexibility. As you mentioned directshowsource for video editing is next to useless, so under normal circumstances I'd rip the DVD again and use it as my source or transcode it to a lossless format. I find that what I consider to be a normal backup for anime would be useless for editing anyway, what with B-frames, but maybe using AVIsource would be ok, albeit slow.



Perhaps I've missed something, or an application already exists (I suspect MeGUI does something like this, but being a CLI user I don't know). You would have a Virtualdub "shell". A plain GUI, not related or "plugged into" VCM or ACM at all. You would have a settings menu where you could choose the path to the CLI's and you would still have the same menu structure as in Vdub. You could load a video like can be done in Vdubmod where it automatically creates and AVS script.

If you go to Video > Compression, it gives you a list of CLI's that are linked via the settings menu, you would choose and configure x264, but be presented with something that looks like the VfW codec's interface. Setting the options on this fake VfW interface would put the switches into the CLI.

The same would happen with audio, say for instance if you linked FAAC, you would go about setting it up in a similar way to the x264 VfW (since FAAC has quite a few options). As for muxing, you would have File > Save as MKV/MP4. If you chose MP4 you would be taken to a config box, something like export options where you would specify any additional information. Maybe framerates if they couldn't be autodetected, or simply track names or additional params.

It's probably a silly and/or flawed idea, it's just something that entered my mind. But it would be a way to get those attached to virtualdub producing dshow encodes, because I believe part of the reluctance to switch is the comfort factor they have with virtualdub, as opposed to the stark environment and text only CLI.

(Apologies for double post, ran out of characters :( )

[DeathTheSheep]

No accusation intended. If I wanted to accuse you personally, I can PM you ;).
Hehe, sorry 'bout that, you got PM (j/k :D).
You certainly meant the worst of both worlds, isn't it ?
HEY!! That was mean :( It's sometimes hard for me to tell sarcasm on boards, and that was just...callous, man. Yeah, that's teh word. Callous...hmm...
That way, I'd produced files that are valid - in a way - in the avi framework.What?! As long as it works (something other solutions can't claim to do lots of the time), and works well (something other solutions can't claim to do lots of the time), and works quickly (something other solutions can't claim to do lots of the time), it's perfectly "valid" for me or any other user. Because the internal technical specifications are different, VFW can only be labeled "invalid” from an internal, technical standpoint only.

It's quite easy to maintain the GUI, but nobody's doing it---
My sentiments precisely.
because nobody uses it.
Wow. Just wow. bkman, did ya hear that? Yer Windows vs. Linux comparison shot down before you even posted it.
But c'mon, be a little bit more serious. The poll on this great DVD forum indicated a near 10% usage of VFW, and that's very generous given that most people who come here are those interested in the newer GUIs anyway, and those that vote are themselves trying to promote them. I was scared to vote VFW and so I didn't, and can only imagine the number of people who share my fear, or who simply don't care to go out of their way to make a statement. But the time has arrived to do so at last, has it not? In face of the danger of what is taking place now, I fear for the codec world. In this slow strangling of the user's freedom of choice, DVD rips won't suffer tremendously, but much else invariably will unless something is done.

And even if one unselfish dev would want to update the vfw GUI--So these poor hard-working devs are "selfish," are they? Hmm, an interesting point, but that's taking things a little bit farther than I would.

--he would still hesitate, because he would know it would only bring [size=5]evil into the world - because people would unknowingly do bad things with it.[/quote]
Wow. Just wow. Here ye, here ye, the shackling, uncompromising words of 90% of the anti-VFW following. "Evil?" This is indoctrination and is thus going against very basis of a free society wherein people can make their own informed decisions. "Evil...people would unknowingly do bad things with it" What is this?
If your idea of "bad" is convenience, reliability, and freedom, then you are adopting the same rhetoric folks are accusing MS of doing, a feat which is humorous to say the least. So you're argument is that the people doing what is best for them is really "very bad" for obscure technical reasons, and that they should give up what works wonders for them because of some equally debatable "anti-VFW" doctrine? I might go as far as to wonder if you are of this opinion because you are affiliated with an anti-VFW company yourself?
You can't make that old interface to fully fit the new codec. We have to change, find a new home for h.264.
As the kind folks below have pointed out, many features can be added without much hassle at all. You may have developed the very idea the anti-VFW community is spreading, the fallacious notion that x264 in vfw is "impossible." You were misinformed then, I'm afraid.
Why we don't use VfW is that, it is too old.
So you are letting a factor that has nothing at all to do with the matter influence your decision. Frankly, even if it was 50 years old, I would harbor no reservations to use an older "something that is better" over a brand-new "something that is worse." I'd pick an old Kenmore washer over a new quickey-wash washer any day.
No, vfw isn't "too old" to work with AVC. I'm almost sure that if it weren't for all the growing "VFW is evil" indoctrination cropping up unbidden, the VFW would have been kept up-to-date even today.

using megui with those excellent sharktooth's x264 profiles isn't that difficult.
For all the scenarios I described (which often occur on a daily basis for me and others I know), it is utterly difficult and time-consuming to do as you suggest. For any sort of video editing, in particular.
Problem is that [the VFW] just encourages people to use VfW for encoding.
Problem? No, my friend, 'tis a solution to much greater problems. The wanton brutality of the growing anti-VFW sentiment has convinced (or scared) a startlingly large amount of people to slave away at a task for hours instead of being able to do it in mere minutes with a simple VFW. Need examples? I gave many... read them again if you must ;)

What good is editability if the only thing I'm ever going to do is split the movie into CD sized pieces? It's not like I'm going to do further processing.
To you, relatively none. To many, it's life and death for their videos (and in some relatively obscure cases, their businesses, careers, etc).
So you have the same encoding tool. And then? And then? And theeeeen ?
Pick video file, edit it, select audio and video compressor, save as AVI.
How the heck do you get your DVD into VDub? AviSynth of course. How do you create your AviSynth script? Via Notepad, or GKnot of course.. so there's another tool right there. How do you get your dgindex project? With dgindex of course.. another program. Then you need to encode audio.. so BeLight it is.. then mux audio and video.. VDub it is. Or, you use one of those despisable frontends that you seem to not like at all. GKnot is such a frontend too.. except for the codec configuration dialog, it's all its own app as well. So is AutoGK (it doesn't even let you access the codec's internals). So in the end, if you want some degree of automatization, you have no choice but to use some frontend, and they all have different GUIs and learning curves. and you can't just cut where you want but it has to be at an AC3 frame size.[requiring more steps, right]
Wow. ;)
1. Rip vob (w/o splitting)
2. Open vob with vdubmod/VdubMPEG2.
3. select audio (Ever heard of LAME/Vorbis ACM? I don't keep the audio as AC3 anyway—too darn big) and video compressors
4. Save as AVI or OGM (or better yet: as a job, so you can do multiple in an automated sequence).

This method works with a majority of my DVDs, but for ones in which VDub exhibits bad parsing I type one line into a text file (notepad is hardly a 3rd party application since anyone has it regardless and by goodness doesn't require a learning curve ;)): directShowsource(“vid.vob”), and then tack on the '.avs' extension. Maybe if I wanted to be really fancy I'd write another line: ensurevbrmp3sync(). Delicious amount of labor that requires, especially since I reuse the same text file.

By golly, look at how the encoding world has become. Your very post is testament to that, doom9! GordionKnot?? AutoGK?? BeLight?? DGIndex?? Super AVISynth scripting?? Tons of steps?? Muxing-demuxing-remuxing??
You see, this is what the world now expects because people can't get their act together and universalize things. And now VFW and ACM, the final remnants of open, universal simplicity and usability, are under fire by the very people who support “open software!”


This is no different than the Windows VS. Linux debate. One likes theirs because they don't have to go out of their way to understand how to use it
Enough of this, please. If more careful attention had gone into actually looking at my post, you'd understand, but it is clear you do not. Windows vs Linux implies that I'm against open software. This is the very opposite in reality, I'm afraid. It implies that my entire points are merely reluctance to switch to something that is *more* flexible, *more* powerful, which is exactly what I'm talking about here—the simple fact that this is a misconception, and that VFW is much more than it is made out to be by the anti-VFW fanatics 'round here ;)
and the other side already has and can't imagine giving up the extra flexibility and power.
My challenge still stands. With your more powerful, more flexible software, can you tell me a more flexible, easier solution the scenario I described above? Let me reiterate. “Tell me a way [with these more flexible and powerful tools] to move this one dirty scene in my movie to the end (as a "deleted scene"), then save as a compressed AVC file ready for any possible editing later. [Give up?] With VDub: open movie. Select dirty scene and hit cut, then move the slider to the end and hit paste. Choose codec from the list, save as .avi.”
I put hard work into this post, and you trivialize it like this without even looking at it. I'm afraid that's considered inconsiderate, my friend.

To me, VFW is the very definition of a codec. When I think of codec, I think of a small, interoperable part, a tool that does it's job and compresses video where and how the user wants it to. Now, it's grown into a huge conglomerate monster; a whole program suite and expertise is now required to perform a copy-paste, it's not at all interoperable with standards (and I thought we were an open-standard community?), and it locks the file for editing. Yes, “locks.” Open software that denies the user's freedom to keep a file “open.” Locks vs. openness—the very crux of “open software” is becoming increasingly obscure. Nowadays, without VFW, a codec has truly become a greedy conglomerate monster.

Check this out guys, some pro-VFW doctrine:

Thou art our true Savior, O VFW!


"Cannot thou rebuild our world
And make it as it was! be-cause,
We deserve not on us burden hurled,
An usurpation of ancient laws.

Reasons doth stretch long and curled,
But chained to maws of clanking jaws.
Canst flags of freedom be unfurled
'Twixt such ravage of savage claws?!

For when all shall fall toil,
Our dreams a lost cause,
Leave us not bathed in soil;
--Thier schemes we shall foil!
Thou art our true savior, O! VFW!
For thee we shall strive without pause."

See how preposterous this is? Imagine if I went clogging every conceivable thread with this kind of crap, trolling and spamming my doctrine as I please.
It would be ridiculous, wouldn't it? But look at how many people get away with the exact same trolling and spamming of "VFW IS EVIL!! NEVER USE IT!! IT DOESN'T WORK" etc, etc.... And not just from one person, no! There's an anti-VFW cult following around here, and it's time I made a stand on behalf of the innocent, helpless sheep who would otherwise undergo the death of the easy, wondrous codec world they've come to know and love.

[DeathTheSheep]

PS:
Wow zero1.... impressive. Seems like I'll get a good discussion out of this after all ;)

[Manao]

Ok, I seem once again to have made myself a bit misunderstood.
You certainly meant the worst of both worlds, isn't it ?HEY!! That was mean It's sometimes hard for me to tell sarcasm on boards, and that was just...callous, man. Yeah, that's teh word. Callous...hmm...Ask anyone around. All will tell you what a plague ogm is. It's basically unseekable ( ie, it needs _huge_ and _ugly_ hacks to be half seekable - no player does it properly ), and it's not more adequate to avc than avi is. It's hardly even meant to contain theora... The only reason for its existance was that when it appeared, it was the sole container able to contain vorbis. Luckily, mkv soon arrived ( NOT mkv created by VDubMod, i'm speaking of the good mkvs created by mkvmerge ).

It's quite easy to maintain the GUI, but nobody's doing it---My sentiments precisely.because nobody uses it.I meant no devs, it was a poorly constructed sentence...

And even if one unselfish dev would want to update the vfw GUI--So these poor hard-working devs are "selfish," are they? Hmm, an interesting point, but that's taking things a little bit farther than I would.Devs developps only what interests them, in their free times.

So you're argument is that the people doing what is best for them is really "very bad" for obscure technical reasonsIt's not what is best for them. They limit themselves into a framework that prevent them from using proper audio codec ( namely aac, vorbis ), and the full potential of the avc standard ( variable framerate, bframes, multiref ). Hacks exist to overcome these three issues. VFR is handle by blowing up the framerate to 120 fps then introducing dummy frames. Hardly user friendly if you ask me, and doesn't work except in vdub. BFrames are handled in a way leading to video / audio desync, and mref is simply ignored ( which means the video won't be editable later )

BTW, you'll be happy I guess to learn that thunderbird automatically detected your post as a spam :p

[Tommy Carrot]

But look at how many people get away with the exact same trolling and spamming of "VFW IS EVIL!! NEVER USE IT!! IT DOESN'T WORK" etc, etc.... And not just from one person, no! There's an anti-VFW cult following around here, and it's time I made a stand on behalf of the innocent, helpless sheep who would otherwise undergo the death of the easy, wondrous codec world they've come to know and love.
:goodpost:
Good to see that someone finally took the side of the poor oppressed VFW users. :D Yeah, the "VFW must DIE" zealots can be quite irritating, it's obvious that in most cases they don't even know that actually what's wrong with VFW (nothing they should be concerned about), they are just parroting what they've heard from other people. VFW might be hackish, VFW might be ugly, but it still works, and it is irreplaceable for certain purposes. I know, editability is not important for the majority - like the dvd rippers - here, but there is a small minority (including me) where it has capital importance. MKV and MP4 are practically locked containers, so they are completely useless for our needs. Until this situation changes, avi and vfw has no alternative for those people who need editability.

[Manao]

Btw, :

Let me reiterate. “Tell me a way [with these more flexible and powerful tools] to move this one dirty scene in my movie to the end (as a "deleted scene"), then save as a compressed AVC file ready for any possible editing later. [Give up?] With VDub: open movie. Select dirty scene and hit cut, then move the slider to the end and hit paste. Choose codec from the list, save as .avi.”Avisynth : source = mpeg2source("my_video.d2v")

return source.trim(0, begin_dirty_scene - 1) + source.trim(end_dirty_scene,0 ) + source.trim(begin_dirty_scene, end_dirty_scene-1)Hardly more complicated than what you did.

And, of course, you claim that what you describe can be done with any vfw software. Well, in fact, only vdubmod/mpeg2 can load an mpeg2 into the vfw framework, since mpeg2 doesn't fit in that framework. And it forces you to reencode - which isn't what I call editability. So in the end, it ends up with you wanting desperatly to use vdub to do - as you said - open video / save as avi. Well, why not do that with MeGui, StaxRip, RealAnime, or whatever else ?

[bond]

:goodpost:
Good to see that someone finally took the side of the poor oppressed VFW users. :D Yeah, the "VFW must DIE" zealots can be quite irritating, it's obvious that in most cases they don't even know that actually what's wrong with VFW (nothing they should be concerned about), they are just parroting what they've heard from other people. VFW might be hackish, VFW might be ugly, but it still works, and it is irreplaceable for certain purposes. I know, editability is not important for the majority - like the dvd rippers - here, but there is a small minority (including me) where it has capital importance. MKV and MP4 are practically locked containers, so they are completely useless for our needs. Until this situation changes, avi and vfw has no alternative for those people who need editability.editability???
as if cutting avi files with b-frames is in any way nicely possible...

[Tommy Carrot]

editability???
as if cutting avi files with b-frames is in any way nicely possible...
Well, yes, it's possible with a little experience. ;)

[DeathTheSheep]

source = mpeg2source("my_video.d2v")

return source.trim(0, begin_dirty_scene - 1) + source.trim(end_dirty_scene,0 ) + source.trim(begin_dirty_scene, end_dirty_scene-1)

What's this mumbo-jumbo? How am I supposed to know exactly what frame this scene starts and ends? Ah that's right, I must first open it with virtualdub and find out what frames you're talking about, write the numbers down, plug them into the script, and then what? Feed it to another seperate program to encode and lock it for me ;) Just the looking up numbers part in Virtualdub practically defeats the purpose of the whole script thing anyway--with the video already open, just choose your compressers and from the list and watch it compress ;) gotta love the preview feature.
I mean, how am I supposed to know this command? And type it in without error? And all the "-1" "-1" stuff, how's the average user supposed to know you're talking about here? Why must I be aquainted with a scripting language and its commands and syntax when I can just do it in VDub with far less work? And in light of it all,
Hardly more complicated than what you did. :eek: Uh-huh, riiight, your way's juuuuuust as easy ;)

Good to see that someone finally took the side of the poor oppressed VFW users.
Yeah! Someone dares to speak out against the oppression! :) See, we're out there!
....[everything else I said]...
YES, exactly. Couldn't have said it better myself :D

[bond]

Well, yes, it's possible with a little experience. ;)still, .avi is far from a what a nice container should be if you use it with b-frames, you can go on ignoring the downsides of the container in this case but this will not make them go away...

whats nice is virtualdub, but this doesnt make .avi and vfw any good (imho people usually mix these two things (the prog and the tech) up)