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)

[DeathTheSheep]

Well, yes, it's possible with a little experience. ;)

Precisely. It's something that can be learned in the space of 15 minutes, and I can't say the same of the other bloatware floating around which you can't edit anyway.

Just remember to offset your selections by 3 frames (depending on # of B-frames used ;)).

whats nice is virtualdub, but this doesnt make .avi and vfw any good
VirtualDub is pretty nice. And it's clearly made it's choice not to go for anything else BUT avi ;)
Also, VirtualDub isn't the only video program I use! Sometimes the video goes through different programs, each with seperate uses but with one thing in common: VFW support (ex: Nero vision for special effects, anyone?)

Like I said, any alternatives that do what VFW can will be listened to ;) But none even come close in many cases.

[DeathTheSheep]

for such cases I use HuffYUV or Lagarith (which are obviously VfW and using AVI).
Lossless tends to make videos balloon out in size, which defeats the purpose of compression for me. I like to combine steps ifn' ya couldn't tell :P (efficiency), so I prefer to get my hands on the source, open it in Vdub/VFW-tool, blast it 'till it it's perfect, then compress via x264 in high quality and distribute it, depending on what it is. Depending on the length, I don't want lots of huge lossless files hanging around my limited HD, especially since I like to come back to the files later for re-editing or further compression.

Even so, should I need to, MP4box allows me to split files and I can always frameserve from AVISynth.
True, but it requires further tools, further time, and is more inefficient than simply keeping it editable in the first place. There's no harm to it, as far as I'm concerned, and the quality isn't sacrificed at all for it.

Using directshow isn't a dead end. Well, that's another debate ;) It certainly adds another element into the equation, though, and I like to keep things as simple as possible while maintaining high quality.

MKV and MP4 have their own tools to analyse streams and give specialised information
Yes, of course, I didn't mean to imply otherwise. ;) But given the choice between the availability specialized information and the availability of the actual video content itself (editing), the answer is fairly obvious in this regard.

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.
Amen to that. Unfortunately, it would require much more developer effort build such tools at this point (and the guides and learning curves and bugs and issues, etc that accompany them) than merely tacking on the features to the VFW.

We only have ourselves to blame. Yes, that is the sad truth. Therefore, I am taking it upon myself to ensure that such mistakes don't happen again—to speak for universalizing the codec world. I merely don't want the codec world to fall into shambles in the mean time. VFW shouldn't be labeled “evil” until viable replacements are widely available, which as of yet, they aren't.

[not direct] Well, why not go for the CLI then? It has a host of benefits even the VFW doesn't have
I see, but you miss my point. The CLI, to many, has become a valuable tool, and is more valuable to them than the confusing morass of frontends I described. But it cannot even come near to replacing VFW as an encoding solution. Using the CLI implies that you already have done all the other strenuous, manual work necessary to get to that point in the first place, whereupon the resulting stream is, again, uneditable.

That aside, a basic AVISynth script ie. " AVISource("video.avi").converttoyv12() " is all you need
Vdub is easier. Right click-open with Vdub. Saves you the typing, and listen to this:
<> How is that script editing a video file? How can it?
<> How is that applying the 2-click de-interlace filters of Vdub, or the resizing, or the resampling, or the previewing, or the special effects, etc?
<> You make the assumption that the user has already:
--finished his video editing,
--encoded it to some huge lossless format,
--created the necessary scripts,
--learned all of the nitty-gritty typed commands (and not to misspell them ;)),
--got all of the paths he needs reduced to DOS code (unless he has taken the liberty of even further inconveniencing himself with lopping all video files and all scripts, exe, etc in the very same messy directory),
--assuming that when he finishes creating the uneditable output, he can then
-- hunt down all the files he had to use during this process, and
--delete all of the intermediary files (the script, the lossless, others maybe), etc.
--And then the user wouldn't have even gotten started on the audio yet, which is another procedure, requiring far more tools and files and time.

How is this more simple than
--opening it with Vdub,
--editing it with user-friendly filters,
--selecting your encoders, and
--saving as an AVI?

That is easily possible with VFW.
I simply don't understand the hassle of your procedure. However, I do understand the rationale behind taking it. You want the quality (as do I!), you want the encoder features (as do I!)! Well, these 2 could have been easily solved with VFW, even as we speak, but somehow anti-VFW sentiment has ground the video codec world to a halt, forcing you to take these alternatives.

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.
...thereby proving my point that VFW eliminates all of this slow and unwieldy effort. Less time + less space + less hassle = VFW.

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.
I guess that's what I'll have to make do with from now on, even though the final output would be uneditable after all? At least until the VFW is updated, that is, eliminating the middle-man and thus the need for all of these lunky go-betweens, and enabling swift editability again, and compatibility with my favorite audio codecs ;)

VfW H.264 in AVI (with the associated hacks) is more likely to suffer problems than H.264 in MP4
All AVI files I've ever made with the x264 VFW played back fine in every player (DirectShow too): Nero Showtime (with Nero filters, I might add), ffdshow, WMP, TCPMP (which isn't DirectShow compatible, and wherein it benchmarks faster than MP4 anyway). MP4 on the other hand has suffered muxing problems, incompatibility with my favorite audio codecs (vorbis, pcm wma, anything .wav), sync problems, splitter problems (and yes, of course you need a special splitter for MP4), etc etc.
In theory, AVI would be more unstable. But that's what this whole anti-AVI thing is based on: theory and speculation. Who cares about the internal code if my video looks and plays great every time (saying the same of the audio stream)?

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.
To me and many other of my opinion, VFW is the only thing that's “right.” It's up to the user to judge whether something is right or wrong for him/her. There can be arguments for or against something, sure, but the codec community has no right to take away people's right to decision. The developers of the codec themselves can, though (and are doing so, from what I gathered from celtic_druid's comments, especially to deprive us of this ability). A limited choice of codecs? Whose fault is that? Not mine. However, I have all of codecs I want (excluding AAC) available from within Vdub's interface, and the interface of any compatible ACM/VFW application under the sun. In fact, ironically, I've only been with the lack of my favorite codecs in MP4--no Vorbis (compatibility issues), no wma, poor ACM support, etc... I've seen and experienced it all. VFW is the solution. Everything I've tried works well with it. MP4 in and of itself requires a “hassle” to play back, too.

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.
Who's fault is that? I'd attribute it to the anti-VFW publicity that's woefully permeating the entire codec community. They are forced, for all practical purposes, into using a radical new system. If you think about the VFW's current lack of features, it might not have been entirely by their choice that they moved to the aforementioned containers. I know of a fansub group who used to use the VFW, but now have moved away from it due to “lack of updates.” However, they still mux their streams into AVI, despite the outcry against it, despite the hassle in having to do so, because since they recommended ffdshow to begin with, no change on the part of the users was required to watch the new file-- they already had the decoder, and there was no container issue. Everyone was happy. Including, I'm not ashamed to admit it, myself ;)

I bet you a large percentage of XviD and x264 VfW users don't even know about the various hacks or limitations
...and therefore aren't limited by them at all. What they experience is an easy and problem-free video encoding scenario. If I hadn't known about the hacks that went into it, I would have thought the system was just about “perfect” the way it was. And, no doubt, others still do, and more power to them.

Just because you gain knowledge of the internals, the seamless VFW experience you had isn't going to somehow miraculously change for the worse. In my opinion, VFW doesn't hurt the file at all—it plays, it plays faster, it plays more codecs, and it plays more reliably. If that's what's now called a “hack,” then I wonder how good “non-hacked” software must be! Oh, that's right—I used the “non-hacked” software and there's been nothing but bugs and problems from day one, nothing but a restriction of freedom, a lessening of convenience, uneditability, wasted time, etc, all of which are vices otherwise unknown to the “hacked” world of VFW. If the nearly seamless VFW experience I had is a hack, I have no reservations whatsoever about lavishing praise upon this so-called “hack,” and using it like there's no tomorrow. Oh, that's right-- everybody's staunchly indoctrinated that VFW is evil ;)

What a mess. In my enlightened opinion, the world was much better off with VFW. But I'm clearly far outnumbered, even though my reasoning speaks for itself.

[CruNcher]

GUI Based NLE + Biff support for .mp4 is allready available only that Vdub doesn't support it doesn't mean it isn't existing :P

[DeathTheSheep]

But this very same lack of standard, universal, application support is one of the main reasons not to go with anything else besides VFW, at least until the widespread implementation of said MP4 technology. However, the current state of affairs is absurd because it is doing this backwards: removing VFW support *before* alternatives become available. Surely you gleaned this from my posts ;) Among enough other reasons to cause death to your average sheep, eh? :D

[ChronoReverse]

Let's put it this way.


If you want to update x264 VFW, you can do it. The developers don't want to do it.


If you want to edit AVC video streams in VFW, in general, you need something far beyond what we have now. With multiple references, you simply need serious effort to get it working. It's in fact possible to make it work in VFW, but the people who actually code don't want to do it. If you want it, learn to do it yourself. This is life; you don't always get what you want.


If you need to do editing, do it in some other format first. Then encode using x264. Simple as that. I would probably do that even if a frame-accurate full-feature VFW h.264 was made if only because of how slow it'd be whenever I try to get at a frame that's not a keyframe.

[Tommy Carrot]

If you want to edit AVC video streams in VFW, in general, you need something far beyond what we have now. With multiple references, you simply need serious effort to get it working.Another good example for a common misbelief here, someone once made this assumption, and people are now just repeating it as a fact without checking the validity. Avi and vfw have ABSOLUTELY no problem with multiple ref frames. The ONLY feature they have "problem" with is the b-frame handling, but then again the same problem existed in xvid too. Strangely it didn't bother anyone there, but suddenly vfw is unusable for h.264 (probably because someone told so).

[ChronoReverse]

No, it does make all the difference. I'm referring to multiple references for b-frames. It worked with DivX and XviD because of some hacks they did (which worked quite well except for the people complaining about the decoder lag).

It doesn't work as well with h.264 style b-frames. Again, it's possible to MAKE it work (like with ASP), but someone has to do it.

That is my point. Ultimately, unless someone wants to and goes about implement something, it's not going to get done. And right now, the people who can, don't want to.

[LoRd_MuldeR]

I really hope somebody will update x264's VFW interface one day. I use it almost every day and for me it works perfect. It's really sad that I can't use the new feature, just because the developpers don't want VFW users to have them. Forcing people to use CLI is pretty much like M$ trying to force people to use WMV. I think everybody should be able to choose himself. And why CLI and VFW shouldn't exist in peaceful coexistence ??? Not developping a great software like x264 VFW any further would be shame !!!

[Nicholi]

Truly the developers are obligated to obey our demands. If they don't...we will be angry and be forced to start more threads about it. They are required to give us what we want, when we want it with no bellyaching about how much extra work it is to do! I am not quite sure where they get off thinking they are allowed to go and make such decisions on their own about these projects. Developers are simply instruments to be controlled by our thoughts, the users. Truly what we want matters most, we do know better afterall.

Fight the man till the end brethren! Let us bring them down. It is not the voices of bond, Richard Berg, RevGen, ChronoCross, Zero1, etc that are stopping our beautiful dreams of a free VfW future come true. It is the twisted, selfish, malicious developers who simply want to make us suffer. We must stop them at all costs. I propose a boycott of all x264 products until the developers yield to our demands which truly is our Manifest Destiny to use VfW forever.

[ChronoReverse]

I really hope somebody will update x264's VFW interface one day. I use it almost every day and for me it works perfect. It's really sad that I can't use the new feature, just because the developpers don't want VFW users to have them. Forcing people to use CLI is pretty much like M$ trying to force people to use WMV. I think everybody should be able to choose himself. And why CLI and VFW shouldn't exist in peaceful coexistence ??? Not developping a great software like x264 VFW any further would be shame !!!

In the end they have no obligation to make things for you. That's the sad truth of it.


@Nicholi

Heh. Sarcasm is best served cold online though.

[Tommy Carrot]

Truly the developers are obligated to obey our demands. If they don't...we will be angry and be forced to start more threads about it. They are required to give us what we want, when we want it with no bellyaching about how much extra work it is to do! I am not quite sure where they get off thinking they are allowed to go and make such decisions on their own about these projects. Developers are simply instruments to be controlled by our thoughts, the users. Truly what we want matters most, we do know better afterall.

Fight the man till the end brethren! Let us bring them down. It is not the voices of bond, Richard Berg, RevGen, ChronoCross, Zero1, etc that are stopping our beautiful dreams of a free VfW future come true. It is the twisted, selfish, malicious developers who simply want to make us suffer. We must stop them at all costs. I propose a boycott of all x264 products until the developers yield to our demands which truly is our Manifest Destiny to use VfW forever.
Your rant is funny, i must admit, but i don't think anybody demanded anything from the developers here. I think this thread was opened as a reaction to the "vfw is evil" bullshit which more often and often appears on this forum.

[Nicholi]

My confusion, I thought this thread actually served some purpose. Not that people were just outbursting that they didn't like what other people were saying.

VfW certainly can't be evil, nor good. It is a tool to be used however you wish. I don't quite think VfW could be used to save children or burn down their houses. However it being a tool then it can be useful or harmful to your task at hand. That settles that eh, VfW can't be evil it's impossible. Now onto the real matter at hand.

Where is all the anger coming from. Whether other people hate your tool or not the x264 developers made their decision. It is akin to a four year old screeching like a tea kettle because he didn't get any chocolate that day. The four year old is powerless in the situation and can't do anything about it especially through screeching like a tea kettle. If you really want x264 VfW to come back you should be thinking of more constructive ways to convince the developers to continue working with it. They have made their decision though and claiming it is a right to have really isn't the way to go in my opinion. Especially since you know very well that they don't want to do it in the first place. You might say "fine" to every single hack because it is for the good of the user, but the developers might just not agree with you. Afterall they will be the ones investing all the extra work into making sure it works and works properly, not you.

[Doom9]

@Nicholi: Your post just brightened up my day ;)

With the x264 GUIs, there's no need to learn AviSynth scripting, filtering is a few clicks away, including preview, commandline knowledge is not necessary, deletion of intermediate file is an option so cleanup is fully automated, and audio is also taken care off.
Add to that that you have to do audio separately in VDub as well (no VBR sir, no AC3 either), that you have to delete your intermediate files manually with no alternative. And your VDub filters are all requiring RGB colorspace.. that's the best way to guarantee slow encoding... RGB processing is extremely outdated.. even when using VDub as encoding software.
That and arrogant statements like
In my enlightened opinion, the world was much better off with VFW and There can be arguments for or against something, sure, but the codec community has no right to take away people's right to decision. fully disqualify as somebody to be taken seriously in this place.

[bond]

The ONLY feature they have "problem" with is the b-frame handling, but then again the same problem existed in xvid too. Strangely it didn't bother anyone there, but suddenly vfw is unusable for h.264 (probably because someone told so).thats actually totally wrong

i have been spreading the word about mp4, pointing out the problems of avi (i have written my avi hackery description thread for asp actually) already when hardly anyone thought about using avc

in fact the time when avi and vfw/acm's downsides began to become clear was already the fall of avi because people wanted to use vorbis: the rise of ogm that time (and later on this triggered the creation of mkv)

face it: avi is old and has problems handling new technologies. what keeps it alive is the existance of virtualdub, nothing less, nothing more (imho)

[LoRd_MuldeR]

face it: avi is old and has problems handling new technologies. what keeps it alive is the existance of virtualdub, nothing less, nothing more (imho)

That only shows how good VirtualDub + VFW Codecs work today. If there are any problems with AVI/VFW concerining x264, they have already been fixed. Only thing that's missing ATM are the new features. So if VFW will disappear one day, that's less because of it's technical limitations but more because the developers don't want to support it. Sad but true...

Question: Who updated the x264 VFW when "Multiple Ref. Frames" were added ???

[bond]

That only shows how good VirtualDub + VFW Codecs work today. If there are any problems with AVI/VFW concerining x264, they have already been fixed.read up about the whole issue, or at least the whole thread, before you make a statement like there are no issues with avi/vfw and x264...

[Inventive Software]

Oh man, some of the crap and useful stuff in here is worthy of a place in the "VFW Hall Of Fame".

Let's be clear on this. We need a tool that has the versatility of VirtualDub, has the support of needed file containers, and has support for not only VFW and DirectShow codecs, but CLI specific things as well.

I'm all for a VirtualDub modification that outputs MP4, uses the x264 CLI, inputs AVS, and encodes AAC. Heck, I may well work on one when I get to uni, as a coding exercise. Just to show it can be done, because it bloody well can.

It's just that no-one wants to.

BTW, I may check-out the x264 source and fiddle with the VFW options a bit, to see what I can get. ;)

[bond]

there are commercial mp4 editor tools, like sony vegas and ulead videostudio, just because noone ever checked them (as noone propably realises that they are existing) doesnt mean they arent there...

[Doom9]

I'm all for a VirtualDub modification that outputs MP4,It needs to open as well ;) Basically, VDubMod + Matroska V2 support + MP4 support. It's certainly doable, but writing your own MP4 parser and writer isn't exactly a piece of cake.

[LoRd_MuldeR]

read up about the whole issue, or at least the whole thread, before you make a statement like there are no issues with avi/vfw and x264...

I never said that there are no issues with avi/vfw and x264. All I said is, that I use VDub + x264 VFW almost every day and I never encountered any problems. So this means there are no problems that effect my work. Or at least the developpers did a great job to keep those problems away from the user. VirtualDub + x264 VFW really works fine and I don't see why the people that like it the way it is should stop using it, except the fact that the new features are not aviable and probably will never be. And that's a pity...

[jackiehcs]

I never said that there are no issues with avi/vfw and x264. All I said is, that I use VDub + x264 VFW almost every day and I never encountered any problems. So this means there are no problems that effect my work. Or at least the developpers did a great job to keep those problems away from the user. VirtualDub + x264 VFW really works fine and I don't see why the people that like it the way it is should stop using it, except the fact that the new features are not aviable and probably will never be. And that's a pity...
If you had no problem with x264 vfw +VDub, that only meant you just did simple works with them.
The developers would never prefer CLI to vfw if they didn't have any experience on the problems and demerits of x264+VDub.
People don't use CLI(and GUI) because they don't know how to scripte avs and decided to use VDub and avi(even all other people use CLI and mkv) for videos for the rest of their lifes.

[LoRd_MuldeR]

If you had no problem with x264 vfw +VDub, that only meant you just did simple works with them.
The developers would never prefer CLI to vfw if they didn't have any experience on the problems and demerits of x264+VDub.

Nope, that's not true. I think I did almost everything that one can do in VDub / x264 VFW, except AviSynth stuff...

[[)370|\|470!2]

People don't use CLI(and GUI) because they don't know how to scripte avs and decided to use VDub and avi(even all other people use CLI and mkv) for videos for the rest of their lifes.

LOL? I'm serving video into vdubmod via avisynth mostly(at least when dealing with dvd).

Really pity that i'm too lazy to recall my coding skills atm, cuz i wasn't working at that
field for quite long time, and moreover kinda busy right now :| But x264 wfv gui definately
deserves some improvements, so if there will be no changes, i'll try to find some time to
look into it. :sly:

[LoRd_MuldeR]

LOL? I'm serving video into vdubmod via avisynth mostly(at least when dealing with dvd).

Really pity that i'm too lazy to recall my coding skills atm, cuz i wasn't working at that
field for quite long time, and moreover kinda busy right now :| But x264 wfv gui definately
deserves some improvements, so if there will be no changes, i'll try to find some time to
look into it. :sly:
:goodpost:

[foxyshadis]

bond, I use an old version of vegas myself for projects, but on the sites of both products you mentioned MP4 import isn't mentioned even in passing, let alone lossless MP4 stream cutting.

[OvejaNegra]

Vdub (mod) is a useful tool and quick, the vfw codecs are usable for any program (i create anime music videos using premiere). But, vfw may have some problems with the new tec, but this can be solved with hacks, but these hacks breaks compatibility whit the mentioned tec. So Hack or not? The developers mus keep compatibility, so the hack is a problem. You must decide your preferences, but the developers can´t please everyone, that´s the main problem with VFW, if you want x264 with full options, someone must do it, and that is not easy. The developers must stay in compat with x264, vfw breaks that. vfw is not bad, is not evil, but has problems with compatibility. DSHOW is not bad, but has some absence of quick / comfortable tools like vdub. MKV (OGM) is not closed (is easy to demux) but there are no tools like Vdub for that. So you must decide what you want and stay with that, say that X or H technology is evil is not right, the problem is that there is no PERFECT/ALL DESIRES/ALL I NEED technology.

At my opinion MKV is very useful, it can accept allmost everything you want (avi+xvid hacked or MPEG4/AVC native) and you can demux it and disassemble it in elemental streams. It can be lossles cuted and splited, the problem are the tools.

Avisytnth is always a life saver and a powerful friend.

Sorry for my english

[DeathTheSheep]

My confusion, I thought this thread actually served some purpose.
It does indeed. This thread has two clear purposes: to raise awareness of the want and need for vfw, and also to explain the reasoning behind this need. Your ideas have only increased its power and effectiveness, and the thread is only growing in potential because of them.

Now, on to buisness. ;)
Add to that that you have to do audio separately in VDub as well (no VBR sir, no AC3 either),
Incorrect. With the addition of an excellent AC-3 ACM decoder and encoder (search for the AC-3 ACM decoder on free-codecs), you can decode and produce high-quality AC-3 audio directly.
VBR? Vorbis ACM handles that well enough for my liking. ABR MP3 is also present in LAME ACM. What more do you need?

[Nicholi]

I think the only awareness level being raised here is the developer's understanding of the ignorance of their users. Somehow I just don't see VfW making "the big comeback" in 2006.

[ChronoReverse]

VBR? Vorbis ACM handles that well enough for my liking. ABR MP3 is also present in LAME ACM. What more do you need?

In that case, what's already working in x264 VFW is more than what you need. After all you're satisfied with "good enough" and "just working".


Ultimately it comes down to you wanting to have the new features without having to pay the price.

[Inventive Software]

I think the only awareness level being raised here is the developer's understanding of the ignorance of their users. Somehow I just don't see VfW making "the big comeback" in 2006.
I do, somehow. VirtualDub's popularity is still quite high, so VFW will still be used quite a lot.

[jackiehcs]

What is the point of using the same thing forever?
For developers, CLI gives advantages to development that allows them to develop faster, more efficient and more space to add new tech. and patchs.
For users, VDub+vfw seems to give more convenience just because they don't like the new interface, don't want to split video/audio with avs, don't mind the problem of compatibility, don't want to try using the CLI but tell developers to fix/hack vfw, etc.
In fact, it's just the problem of what you satisfy.
If you think vfw is already good enough because it did well on DivX/XviD, then keep on using them.
If you think x264 is what you want, you may try CLI.
If you think x264 should be based on vfw and VDub must be used, update the vfw yourself.
Developers may choose the best way they consider to develop their programs, but not the demands of public as they aren't businessmen.

[bob0r]

Now all you PRO-VFW guys need is someone to make it happen for you.
Time to grab some learning books and start converting megui layout to vfw!

To be honest, when i figured out there was x264.exe, i never went back to VFW, but if a full up-to-date vfw for x264 is being developed i dont see why it cant be included, as long as it does not interfere with any x264 features/core/etc...

[bond]

the next downside of avi is that there are no specs how mpeg-4 formats have to be stored in avi
if you look at the whole packed bitstream mess in the hardware player section you realise that a standardised container can help a lot in the interoperability field

[DeathTheSheep]

these hacks breaks compatibility whit the mentioned tec.
Interesting...so why have I only had software compatibility problems with non-VFW material? How come every single program I mentioned above (and some I didn't) play the VFW-created streams with the least issues?
And how come when I remux the VFW-created stream into MP4 or some others, it is just as compatible?
As I've said above, the so-called "non-hacked" files have more issues for me, causing me to waste even more time fixing them. No, this isn't the pile of extra software I'm talking 'bout either (although I hope you can glean they have their fair share), it's the actual "non-hacked" files themselves as well.

The simple answer is, the so-called "hacks" haven't caused any incompatibility problems, seeming only to have solved them in many cases. :)

People don't use CLI(and GUI) because they don't know how to scripte avs and decided to use VDub and avi(even all other people use CLI and mkv) for videos for the rest of their lifes.
That is a blatantly false assumption for many VFW users. Myself, I script on occasion, and have come up with a few rather elaborate ones on occasion. However, looking up and writing bunches of numbers / code defeats the purpose of easy, fast, and interoperable video compression. I only resort to coding when VirtualDub can't easily do it anyway (or if there are no filters available fo the task). Why does anyone script, besides to somehow edit or modify the clip in some way? And then, wouldn't it be easier to visually do the same things with the video right in front of you, all in the click of a mouse, without having to look up parameters and specific frame numbers and arbitrary lines of code? I mean, just look at the example manao provided above, which illustrates my point nicely. Wouldn't you rather pluck out and insert the video segment in an editing program than slaving away with numbers and commands and spelling and syntax when you'll eventually have to look up the needed frames with an editing program anyway??
You see my point. ;)
If you had no problem with x264 vfw +VDub, that only meant you just did simple works with them.
Hmm, are you drawing this conclusion of the general VFW user base? A big merit to VFW is that you can be as simple or as complex as you wish--within the same framework that works best for you. The commandlines and GUIs disallow this, and you are thus reduced to producing works with many layers of software arbitrarily. Here you are bordering on insulting the ability of the VFW user to create complex works or utilize complex operations, which doesn't pass over as an overly noteworthy display of empathy.
writing your own MP4 parser and writer isn't exactly a piece of cake.
Which is why it hasn't been done, there are no current plans for it to my knowledge, and therefore virtually no editor supports MP4 parsing, and perhaps won't for a long time, while we endure the long hard times without being able to use it efficiently. "Ever wonder why people [have the right to] use VFW? I'll tell [have told?] you why." ;)

The developers would never prefer CLI to vfw if they didn't have any experience on the problems and demerits of x264+VDub.
Try not to speak for the developers. We might not understand their reasoning. With that said, I have indeed had more problems with everything else than with x264 VFW.

Also, try not to be of the opinion that VDub support is everything in the equation. Sure, it's a huge plus to the VFW, but certainly not the only merit to VFW by a long shot. I'd still prefer the interoperability and convenience and all-in-one packaging of VFW over CLI in the many, many other programs that support VFW.

Face it, there's no real reason *not* to have VFW besides the relatively obscure technical reasons which don't affect the majority of users anyway.

what's already working in x264 VFW is more than what you need. After all you're satisfied with "good enough" and "just working".
Please don't tell me or anyone else what they need. That completely defeats the purpose of free choice. If someone wants/needs something and makes it known, it's only insulting to the whole community to use strong-arm tactics to force your decisions on us. Instead, you should try to refute my or others' arguments for it, which you haven't been able to do yet IMHO. How on earth does VFW hurt you so much that you argue so passionately against it? Is there any reasoning behind this other than zealotry? Or that you simply don't want us to have it?

If there is anything about the system that is as-of-yet inept, it is due to this irrational haste to move away from ACM/VFW in the first place before any feasible replacements have even been drafted, much less created, standardized, and accepted.
Ultimately it comes down to you wanting to have the new features without having to pay the price.
Price? Perhaps that's exactly what it comes down to; that's my whole argument here! In order to get the features, freedom, and simplicity we crave, we are forced to incur the hefty toll of using less-efficient methods. This is my point exactly; many codec users are now forced to pay a toll in order to use the new features. Doesn't this defeat the purpose of free software? Here, let me change my sig really quickly... ;)

I think the only awareness level being raised here is the developer's understanding of the ignorance of their users.
Ah, so you are calling my [conscious, rational] decisions, and by extension, me "ignorant." I simply don't know what to say to that. These fallacious, strong-arm coercion tactics are detrimental not just to my feelings but also to: the codec, the user, the community, the very essence of free software, etiquette, and common sense.
So, my decision to use a faster, freer, and more efficient means of creating video the way I want to is now directly labeled "ignorant" [by an ever growing number of people!]. See, everyone, the relentless, unbidden discrimination we must suffer at the hands of zealotry. :(
Well, I simply can't fathom you or anyone else coming up with an easier, faster, or less challenging way to solve even the one small but fundamental problem I brought up earlier, that of the "dirty scene editing."
(In sly voice): Ah, but that's right-- maybe "ignorance" really is the issue here, but then, I wonder then who or what is guilty of it, and if there is any justification for that. :sly:

But things are beginning to look up ;)
But x264 wfv gui definately
deserves some improvements, so if there will be no changes, i'll try to find some time to
look into it.
You've made my day ;)
VFW will still be used quite a lot.
True that, true that!

[[)370|\|470!2]

the next downside of avi is that there are no specs how mpeg-4 formats have to be stored in avi
if you look at the whole packed bitstream mess in the hardware player section you realise that a standardised container can help a lot in the interoperability field

Packed bitstream just sux, agree.

But Xvid handles b-frames decoder-side(by loading few frames ahead iirc), flawlessly.
I see no reason why same feature cannot be implemented in CoreAVC or FFMpeg.

[bond]

sheep: can you stop this nonsense now plz, you are quoting wrong things, i definitely didnt write what you are quoting...

Packed bitstream just sux, agree.

But Xvid handles b-frames decoder-side(by loading few frames ahead iirc), flawlessly.
I see no reason why same feature cannot be implemented in CoreAVC OR FFMpeg.divx certification makes sure the player handles 1 b-frame with packed bitstream
altough many players handle xvids way of not using packed bitstream you cant be sure about that everything works fine

[DeathTheSheep]

If you think vfw is already good enough because it did well on DivX/XviD, then keep on using them.
I didn't even bring up such reasoning, nor does it even need to be discussed save for in passing. Although it is indeed a valid point that XviD did perform extremely well in VFW, even with so-called "hacks." Hmm, so well that I almost always see VFW-made XviD streams.
If you think x264 is what you want, you may try CLI.
Many have, including myself. Couldn't you tell? Make sure to read the whole post. This is, in fact, the very reason why we realize the benefits of VFW over it: we've tried both. One cannot in good faith argue the merits of one thing over another until he/she has experienced both to a good degree.

vfw seems to give more convenience just because they don't like the new interface, don't want to split video/audio with avs, don't mind the problem of compatibility, don't want to try using the CLI
Ah, so you didn't bother reading any of my reasoning--you seem to hold on to the stereotype of the "dogmatic change-hater," even though the opposite is clearly true: change has indeed been tried but has failed miserably on all accounts I've mentioned.
Developers may choose the best way they consider to develop their programs, but not the demands of public as they aren't businessmen.
That's why this thread is here, to raise awareness of the current issues and perhaps to spur change. If change is unwanted, it will not come. However, this doesn't bar people from speaking what's on their minds about an issue. Note that many codec developers moving away from VFW are working for corporations who tend to care about customer interests by very definition.
However, free software, being free, doesn't clearly entail "freedom of usability," as many would argue.
What is the point of using the same thing forever?
Wow. Yes, sure, absolutely, without a doubt, I'm making this whole argument because I want to use XviD forever and ever. Come now, why would I want to take a stand, raise awareness, and strive for some kind of change if I wanted to do something old and monotonous over and over again? What is the basis of this statement? :scared:


sheep: can you stop this nonsense now plz, you are quoting wrong things, i definitely didnt write what you are quoting...
Sorry about that quote confusion, bond. Managing all of these quotes can be a bit tedious... it's a price to pay for perseverance ;) Please, anyone, if I've misquoted you, don't hesitate to tell me; it's an accident.

[Doom9]

Well, I simply can't fathom you or anyone else coming up with an easier, faster, or less challenging way to solve even the one small but fundamental problem I brought up earlier, that of the "dirty scene editing."But I did.. the 80/20 rule gets rid of that and a lot of other rare scenarios you can come up with ;)
Well, I simply can't fathom you or anyone else coming up with an easier, faster, or less challenging way to solve even the one small but fundamental problem I brought up earlier, that of the "dirty scene editing."Go cry me a river. The point of free software is that if you don't like what you get, you shut the hell up and either improve it or go someplace else. End of story.
And furthermore, you're getting dangerously close to having a whole rainstorm of rule infractions coming down on your head.. you all but directly accuse the x264 developers of screwing you backwards..

[DeathTheSheep]

I'm sorry if I came across that way. If you got this impression (which I suppose is reasonable, looking back on it), I sincerely apologize.

What I mean to do is merely to raise awareness of the need for VFW and try to push for renewed VFW support. It is something that is rather important to me, and worthy of discussion. I'm merely claiming that the codec world as a whole is moving away from something a bit too early (while other conviniant solutions aren't yet present). You could substitute the name of some other new codecs for 'x264' in many cases above (many definitely not as highly acclaimed or as "good" IMHO ;))

I try to behave in a civilized manner, and I don't want to discriminate against anyone in particular. However, I do like to take a bit of a stance against unwarranted zealotry when it starts to create visible victims (such as myself). I do not mean to insult any individuals themselves.

As for the rarity of my situations, I think your own stance on the matter is mildly one-sided due to the simple fact that they might not have occurred for you. However, if I dare say so myself, there are quite a few video editors out there (percentage compared to straight DVD-compressors?) who certainly would benefit substantially from this technology.

In this, I'm sorry, but I don't believe my stance to be nonsense, and I certainly don't wish to accuse anyone of "screwing me backwards" except perhaps the general direction of the "progression" of the video world as a whole before such change is advisable. Please hold no grudges.

[Sharktooth]

incredible... still speaking of VFW after years...

[DeathTheSheep]

Alas, O Sharktooth, you must read the thread before posting such comments! It's really rather interesting, so you mustn't make it too repetitive. ;)
Numerous times have I already addressed the age issue, which is more of a perception than an actual disadvantage. What's incredible to me is to so suddenly ditch VFW after years when many avid video encoders/editors clearly aren't yet ready for the burden that would entail at this point. At least leave here with the answer to the question "Why do people use VFW?"
If at any point find youself unable or unwilling to, try to open your mind a bit and see it from a different perspective, namely that of those execrated from the benefits of the sudden trends in the encoding world. That's all I ask.

[ChronoCross]

Alas, O Sharktooth, you must read the thread before posting such comments! It's really rather interesting, so you mustn't make it too repetitive. ;)
Numerous times have I already addressed the age issue, which is more of a perception than an actual disadvantage. What's incredible to me is to so suddenly ditch VFW after years when many avid video encoders/editors clearly aren't yet ready for the burden that would entail at this point. At least leave here with the answer to the question "Why do people use VFW?"
If at any point find youself unable or unwilling to, try to open your mind a bit and see it from a different perspective, namely that of those execrated from the benefits of the sudden trends in the encoding world. That's all I ask.

listen vfw is one of them things that has been broken for many years. You shouldn't have to hack a damn codec interface simply to give a sorta compatible solution(packed bitstream is a bad hacked solution). If more people start learning how to make proper encodes then the need for editors will prompt not only companies but open source advocates to create an editor software.

I tried teaching someone the other day how to avoid an entire step in the encoding process. He was using vdub to try and cut an entire thing out of a x264 encode finding it very difficult cause he couldn't load the mp4 into vdub.

Then he told me how he was going to cut it first. output to lossless. then encode it in x264. Now me being the way I am I simply told him to load his source into MeGUI, take down the framesize he wanted to cut out. then simple use trim(). Skipping an entire step. But then he simply just ignored me saying it was too hard. He ended up putting the mp4 to avi then cutting it using direct stream copy....he cut out almost 30 secoonds of the begining. If he had edited it beforehand the rate distribution through x264 would have been better.

I shrugged and moved on with my life. But it's this kind of vfw one way thinking mentality that is stymying the intelligence of people. Learn to "do it once, do it right".

[Zero1]

Heh, I'm beginning to wonder if the purpose is to simply troll, or if you are being genuine. Anyway, on with the reply.

Lossless tends to make videos balloon out in size, which defeats the purpose of compression for me. I like to combine steps ifn' ya couldn't tell :P (efficiency), so I prefer to get my hands on the source, open it in Vdub/VFW-tool, blast it 'till it it's perfect, then compress via x264 in high quality and distribute it, depending on what it is. Depending on the length, I don't want lots of huge lossless files hanging around my limited HD, especially since I like to come back to the files later for re-editing or further compression.
Well the lossless encoding of the filtered source is a tempoary step so that you don't have to run through your source twice with all the filters active when you are encoding with x264. Since it is tempoary and you will delete it once the x264 encode is done, it in no way defeats any purposes of compression, it's not like you have to live with the lossless encode and therefore occupies more disk space. The quality and size of the final output will be the same whether you encode a lossless or not, just you will save yourself time if your script is complex.

You can of course also apply this step to VfW. Just go about your business as usual but instead of setting up jobs for 2 pass XviD or x264 encodes, set the compression to Lagarith and save as AVI (no jobs at this point) and cancel it after a few frames. Now save it as AVI, but add it to the joblist. The second step is to load the "dummy file" you cancelled after a few frames and set up the options just as you would for a 2 pass XviD/x264 encode. You should now have 3 jobs in total. It will save you time on slow scripts since you only run through the source and filter it once, as opposed to multipass where you would be parsing the source and filtering it on the fly, effectively twice. Of course if you are only using a minimal amount of built in Virtualdub plugins, then the filtering of the video won't be all that complex, so a direct two pass will be better for minimalist scripts/filtering.

Regarding size, well it's an easy arguement, but a valid one. Drives are getting larger and compression is getting more efficient. It's near impossible to give you a nominal filesize for a specific duration of what to expect since sources, quality, resolution etc. can vary vastly. In addition to HuffYUV or Lagarith (recommended), you could also use x264 for lossless (not sure if the option is available in VfW), although decoding the lossless H.264 might be CPU intense enough to kill any advantages you would get from compressing your filtered source, so I would recommend HuffYUV or Lagarith. Hmm, well I can give you some figures for some Lagarith encodes I did a while ago. Episode 1 of Gundam X (a 1996 anime, shaky image) ended up about 4GB for 24 minutes, on the other hand a Kamichu (a very clean CG anime with low motion) turned out around 2.5GB for 24 minutes. Lets suppose a movie turns out at 20GB for 90 minutes (that's equivalent to ~5.3GB/24 mins), surely you can spare this amount of disk space temporarily?

As for wanting to come back to files later for re-editing or compression, well if you are just loading the VOBs into Virtualdub, you can just do this again at a later date seeing as Virtualdub is so fast and efficient the way you use it. Re-editing or recompressing compressed sources (for instance MPEG-4 ASP and/or AVC) is not a good idea for some reasons already mentioned before. For starters re-compressing a compressed source when you have the DVD available is lazy and sub-optimal. As for editing, it would ideally be done before compression in something like a non linear editor, for instance Adobe Premiere, or AVISynth. Again, if you care about quality and decide to get the DVD out again to do this re-compressed version, you could edit it at the same time, that way if you are cutting a good bit out of the video you also save encode time.


True, but it requires further tools, further time, and is more inefficient than simply keeping it editable in the first place. There's no harm to it, as far as I'm concerned, and the quality isn't sacrificed at all for it.
Define editable. If by editable you mean taking a video into an NLE such as Premiere or AVISynth, making changes, shifting scenes or pretty much anything that requires frame accuracy, then MPEG-4 Codecs just don't cut it. It's not a case of it being AVI or MP4, VfW or directshow. It's a case of how the video is compressed. You should ideally edit with a codec using only intra frames, such as HuffYUV, Lagarith or MJPEG to mention a few. This means that you can cut at any frame and have a complete frame, rather than cutting a frame that must reference a buch of previous frames. It's faster, safer and potentially more accurate.

If by editable you mean able to shift scenes of a video that has already been encoded, without the need for re-encoding (as I guess you're getting at), then something like MP4Box is perfectly sufficient and doesn't lack the versatility of VirtualDub, that said you will probably want to view the video in Virtualdub to see exactly what times or frames you wish to extract. I can't and won't deny that using a command line for such an operation is usually slower, but since it's a job that takes next to no time anyway, does it really matter if it takes 5 or 10 seconds longer, for the sake of not confining yourself to VfW only? Editing MPEG-4 encoded videos in Virtualdub does not give you any additional functionality since you are really stuck with cutting and joining at I-frames, if anything this method restricts what you want to do.

I'm not intending to troll, I genuinely curious as to what you do that requires you to edit encoded videos on a regular basis in Virtualdub.


Well, that's another debate It certainly adds another element into the equation, though, and I like to keep things as simple as possible while maintaining high quality.
If you really care about quality, then your current routine is limiting you on numerous counts. For starters you are missing the great AVISynth filters that can go a long way in helping to fix or improve a source, add to that the various IVTC filters. Yes, I know Virtualdub has IVTC filters, but you don't have the choice or flexibilty that AVISynth users have. I don't know how I managed before I found AVISynth, it really is essential software for any encoder. Stemming from AVISynth usage and filters a little, is the fact that most (if not all?) of the Virtualdub filters work in RGB, which as Doom9 points out is slow, and it also means unnecessary colour conversions, yet again lowering the quality.


Yes, of course, I didn't mean to imply otherwise. But given the choice between the availability specialized information and the availability of the actual video content itself (editing), the answer is fairly obvious in this regard.
I know it seams like I'm an MP4 zealot but I don't know enough to comment about MKV, otherwise I would. Hmm, choice between specialised information and editing features... Who said you had to choose? MP4Box covers it. It can give you lots of specific information about an MP4 file, allow you to dump certain streams and split by filesize, duration (start and end) or a max duration (start to max duration). It's a very large program, there are probably options that may have been of interest to you that I never checked out.


Amen to that. Unfortunately, it would require much more developer effort build such tools at this point (and the guides and learning curves and bugs and issues, etc that accompany them) than merely tacking on the features to the VFW.
I wouldn't know about that since I don't program, but I'd have thought it would have been easier to implement properly documented standards and features as opposed to hacking something into an old framework such as VfW with it's one frame in, one frame out limitation, working in the dark so to say. I also think that it would require more specific knowledge to be able to hack a workaround for something like the one in one out limit, and how it will affect other programs, or work with programs with internal splitters etc. Besides all that, there are some very competant and dedicated developers around right now, current projects like FFMPEG, FFDShow, AVISynth, XviD, x264, Haali's splitter and any others I missed are proof of that. I'm sure between them they could overcome almost any problem.


Yes, that is the sad truth. Therefore, I am taking it upon myself to ensure that such mistakes don't happen again—to speak for universalizing the codec world. I merely don't want the codec world to fall into shambles in the mean time. VFW shouldn't be labeled “evil” until viable replacements are widely available, which as of yet, they aren't.
I find this to be hypocritical. You claim that you are ensuring that such mistakes don't happen again, but you are clinging on to VfW, pleading for x264 VfW updates and crying out for more hacks to keep the platform alive. This is the root cause of such "mistakes", and is partly the reason why MP4 didn't take off when ASP with B-frames hit the scene (IIRC, SP didn't have B-frames and was pretty much VfW friendly). Note that I didn't entirely blame the VfW supporters, perhaps part of this stemmed from DivX too. Do note that I was a newb back in the DivX 3.11 days, so what I recall might not be correct, but as I remember it, DivX 3.11 was a hack of MSMPEG4 (MPEG-4 SP), then in time came DivX 4 (this was SP too, right?) then DivX 5 and/or XviD (I don't remember the exact chain of events, perhaps someone with a good memory would care to enlighten me?). I guess since DivX 3.11 was VfW, that people expected newer versions to also be VfW despite the newer versions being based on ASP which had additional features (ie B-frames). I guess DivX would have hacked a workaround for B-frames etc so that they could stick with AVI, rather than switch to the then non user friendly MP4.

As for VfW being supposedly evil, I think this is a misunderstanding on your part. You say that a lot of the regular Doom9 goers view VfW as evil, I don't think that is the case. What I do think is the case is that they know there are better methods and view MPEG-4 ASP and AVC in VfW/AVI evil, due to the associated hacks. If you said that you was using VfW for storing Lagarith, HuffYUV or any decent format not requiring hacks, I doubt anyone would bat an eyelid, it's the fact that it's MPEG-4 ASP and AVC in VfW that is the issue here. More so with AVC since with ASP is has become commonly accepted and "the damage has already been done". A lot of people see H.264 as a good oppurtunity to switch to newer formats since it's a different standard, rather than an extension. We see it as a bit of a fresh start and want to do things properly without hacks, be it MP4 or MKV.

So yes, it's not that we categorically hate VfW, it's that we don't like having to use hacks when we don't have to, or producing non standard files. Especially now with HD-DVD coming closer all the time, the liklihood of playing back our (specification compliant) encodes is good.


I see, but you miss my point. The CLI, to many, has become a valuable tool, and is more valuable to them than the confusing morass of frontends I described. But it cannot even come near to replacing VFW as an encoding solution. Using the CLI implies that you already have done all the other strenuous, manual work necessary to get to that point in the first place, whereupon the resulting stream is, again, uneditable.
Sure it replaces the VfW as an encoding solution, that's all it is, a command line encoder. It does exactly what it says on the tin(tm). What you mean is that you cannot cut and paste sections using the command line encoder, and rightly so. An encoder should encode. A video editor should edit. Virtualdub covers both of these roles. As I said before, you should IVTC, decimate and edit prior to encoding, or simply split and concatenate after encoding and muxing. If you are looking for a do it all solution, I believe Doom9's MeGUI does just that, but it seems you are just looking for excuses to fight your corner :)


Vdub is easier. Right click-open with Vdub. Saves you the typing, and listen to this:
<> How is that script editing a video file? How can it?
<> How is that applying the 2-click de-interlace filters of Vdub, or the resizing, or the resampling, or the previewing, or the special effects, etc?
<> You make the assumption that the user has already:
--finished his video editing,
--encoded it to some huge lossless format,
--created the necessary scripts,
--learned all of the nitty-gritty typed commands (and not to misspell them ),
--got all of the paths he needs reduced to DOS code (unless he has taken the liberty of even further inconveniencing himself with lopping all video files and all scripts, exe, etc in the very same messy directory),
--assuming that when he finishes creating the uneditable output, he can then
-- hunt down all the files he had to use during this process, and
--delete all of the intermediary files (the script, the lossless, others maybe), etc.
--And then the user wouldn't have even gotten started on the audio yet, which is another procedure, requiring far more tools and files and time.
The script isn't intended for editing a video file, it's simply for serving an AVI to the x264 CLI, assuming that you have IVTC'ed, decimated, edited and filtered the video, your way (Virtualdub only) or mine (DGIndex, AVISynth, VDub, x264). It's not the journey that matters, it's that you reach your destination (or in this case the 2nd from last stop). If you want to only use Virtualdub and sacrifice quality somewhat, that's your choice, but if you want the full features of x264, you need to use the CLI.

[Zero1]

As for "2-click de-interlace filters", we don't use them. Myself and many others IVTC and decimate in the first AVISynth script, which is the one we load into Virtualdub and dump a lossless file from it, if it's a pretty hefty script. Everything else is done in AVISynth, this allows us to keep our source in YV12 and avoid colour space conversions. As for special effects, depends how special you want, we can do some nice stuff in AVISynth, or otherwise we might need the assistance of Adobe AfterEffects or something of that nature.

Quite correct, I do assume that the user has done all that, or that you have done it your way, either way it doesn't matter, so long as you have a .vdf or a file to serve to x264 via AVISynth. Spelling errors is a bad excuse, all the commands are accessible directly in the CLI, and they aren't long or use complex words either. Usually are able just to use a few letters. As for DOS paths, this is the only inconvienience as far as I'm concerned. What I tend to do is create a 3 letter directory, something like "enc" and just chuck everything I'm using for encoding in there. It's easier to deal with than files located all over the place in different files, I can see what I've got with no searching. If you wrote a batch file inside that directory, that eliminates the need for typing whole paths all the time, just type the file name. And if paths or filenames is such a trial, just type the first few letters and press tab. Completion is a handy thing.

As I said before, if all the files are in the same directory, there is no hunting. Deletion of the files can be lumped into the batch file, same with the audio. Using a command line Vorbis or AAC encoder means you can add this to the batch file, just run the batch and it will crack through the process automatically.


...thereby proving my point that VFW eliminates all of this slow and unwieldy effort. Less time + less space + less hassle = VFW.
I think you missed the point, it doesn't matter whether I'm using VfW or Directshow, it's the fact that trying to edit MPEG-4 with B-frames in a NLE is next to useless since it relies on other frames, but as I said earlier, it seems you mean editing in a different context. If anything, VfW is likely to be worse in this instance what with frame lags. Oh yeah, I think you omitted something, allow me to fix that for you...
Less features + less VBR Audio + less choice of compression + less quality = VFW. :p


I guess that's what I'll have to make do with from now on, even though the final output would be uneditable after all? At least until the VFW is updated, that is, eliminating the middle-man and thus the need for all of these lunky go-betweens, and enabling swift editability again, and compatibility with my favorite audio codecs
Despite the banter in our posts, I'm glad that you consider this rather than just rubbishing it. By the way, you might want to try Matroska if you want true freedom. MP4 is great, but it has a specific usage, think of MP4 kind of like MPG. It's intended to be a widely used standard, rather than a multiformat container.


All AVI files I've ever made with the x264 VFW played back fine in every player (DirectShow too): Nero Showtime (with Nero filters, I might add), ffdshow, WMP, TCPMP (which isn't DirectShow compatible, and wherein it benchmarks faster than MP4 anyway). MP4 on the other hand has suffered muxing problems, incompatibility with my favorite audio codecs (vorbis, pcm wma, anything .wav), sync problems, splitter problems (and yes, of course you need a special splitter for MP4), etc etc.
In theory, AVI would be more unstable. But that's what this whole anti-AVI thing is based on: theory and speculation. Who cares about the internal code if my video looks and plays great every time (saying the same of the audio stream)?
I can't speak 100% for the x264 VfW, but I do know that DivX and/or XviD had hacks both encoder side and decoder side. As a result your video will be playable, but it won't be strictly spec compliant. I guess if you tried to play this on a H.264 player that was only obligated to support the official specs you'd be out of luck, but I guess you'll argue that you don't care about hardware playback, I know a few people that claim they don't. But what about your audience? I read that you distro files. Maybe they wouldn't mind hardware playback as and when it's available (or if you are for example a fansubber, this "goes against" what you work to, as in subs aren't intended to replace DVDs).

I won't deny the muxing problems, shit happens as they say. But what I will say is that it's something that's being developed constantly, and it's opensource. It's something that you should be prepared for and expect somewhat. I can't remember the last time a substantial improvement was made to the AVI parser/muxer. But the fact remains you are comparing a 15 year old format (well less if you perhaps include OpenDML) with muxers/parsers that have been in development in people's free time for maybe a year or two.

You're surprised MP4 has problems with "vorbis, pcm wma, anything .wav"? You shouldn't be, it isn't designed to contain any one of these formats. It predominantly is designed for MPEG-4, for instance MPEG-4 SP, ASP, AVC and LC-AAC and it's various enchancement layers (HE, LTP, Main...etc.), in addition, support for MPEG-4 ALS (lossless audio, seperate from AAC) has been added to the specification. You are supposed to also be able to contain other MPEG versions, for example MP3 Audio, MPEG-2 video etc, check out bond's FAQ for more information.

If you want to use these other formats such as vorbis and pcm, you really got to try out MKV. There's also a GUI for mkvmerge. Just check out this example I made for fun.

http://img206.imageshack.us/img206/7277/mkvhell0iv.th.jpg (http://img206.imageshack.us/my.php?image=mkvhell0iv.jpg)

(Note, the 5.1 FLAC is a bit weird, it encoded and came out much smaller in filesize than expected, so assume it's incomplete or broken ;))

Again, as before. It's not so much anti-AVI, it's more anti-AVI-with-hacks. But there is an element of people wanting containers that handle more formats, more features and lower overheads (heh).


To me and many other of my opinion, VFW is the only thing that's “right.” It's up to the user to judge whether something is right or wrong for him/her. There can be arguments for or against something, sure, but the codec community has no right to take away people's right to decision.
Sure, I can appreciate that, but at the same time the "codec community" or more specifically the developers,have no obligations whatsoever to make a hacky VfW encoder. We should just appreciate the work they have done already and be greatful for their time. I think there is too much being taken for granted and people have come to expect, neigh, near on demand things now.


A limited choice of codecs? Whose fault is that? Not mine. However, I have all of codecs I want (excluding AAC) available from within Vdub's interface, and the interface of any compatible ACM/VFW application under the sun.
Yes, it is your fault, if you moved with the times say to MKV or MP4 you would have a MUCH larger choice. As much as you can hack and comprimise, I believe there are some things you can't really change, those are things like VBR audio in AVI. I believe this is due to a limitation in the AVI format (specifically the information written in the header). It works for playback, and I think some people have reported desync on skipping. Then you have your editing. You can't cut and paste sections with VBR audio, it becomes out of sync. By the way, the world doesn't revolve around Virtualdub, it is possible to put AAC in AVI (but I won't tell how, because if you want to produce H.264 + AAC encodes, you might as well use MP4 while you are at it and produce a spec compliant file that no one will ever have problems with, or at least use MKV which people are more familliar with.


In fact, ironically, I've only been with the lack of my favorite codecs in MP4--no Vorbis (compatibility issues), no wma, poor ACM support, etc... I've seen and experienced it all. VFW is the solution. Everything I've tried works well with it. MP4 in and of itself requires a “hassle” to play back, too.
As I have mentioned before (again with the mentioned befores...) AVI is a multiformat container, MP4 is NOT a multiformat container. MP4 is designed to contain most if not all MPEG streams, but focusing more on the new MPEG-4 stuff (since MPG and VOB handle older MPEG streams). If you want true freedom, MKV is the answer. It supports a bunch of VfW AND Directshow codecs, though if using H.264 in MKV, it is highly recommended you use it's native mode as opposed to VfW.


Who's fault is that? I'd attribute it to the anti-VFW publicity that's woefully permeating the entire codec community. They are forced, for all practical purposes, into using a radical new system. If you think about the VFW's current lack of features, it might not have been entirely by their choice that they moved to the aforementioned containers.
No, it's because some encoders have some background knowledge about video in general, some about windows and some about video coding and between them are smart enough to deduct that hacking formats into old containers is not smart, not at least when viable alternatives exist.

I wasn't forced. If I want, I can mux the latest encode I do with x264 CLI to AVI, and throw an AAC stream in there, maybe even some softsubs. But I thought to myself, "Why should I do things in a hackish way, when I can put these into MP4, and it be perfectly spec compliant?". I'm not saying MP4 is right for everyone, far from it. It's not very flexible unless you want to use MPEG codecs, in which case I suggest MKV. But for those of us wanting to use new methods of compression, AVI has finally outlived its use. For old methods there is no problem, no question. It's just when everything now requires hacking in, it's time to try something else.

What do you do when your feet outgrow your shoes? You buy new ones, or do you wear them until the death, which results in bad feet? It might be an odd analogy, but it's not a totally bad one. ASP and H.264 have "outgrown" (now make use of features not supported) AVI and require a "bigger" (more able) container.


...and therefore aren't limited by them at all. What they experience is an easy and problem-free video encoding scenario. If I hadn't known about the hacks that went into it, I would have thought the system was just about “perfect” the way it was. And, no doubt, others still do, and more power to them.
This creates problems though. Because they don't appreciate that problems exist, they whine and complain that the x264 VfW is hardly updated, they think it's working and stable, why no releases? When in actual fact you eventually end up killing a format. This might sound drastic, but look at the effect DivX and XviD have had on ASP. Hell, I'll even bet that there are people that think AVI is it's native container and not even know that it should have been contained in MP4 all along.

Maybe if ASP had been contained in MP4 all this time, MPEG-4 DVD players (ASP at least, with MP4 support) would be widely available, and that would be an extra chance of HD-DVD supporting the .MP4 format by default. Well I consider it a very high chance, say for user authored discs, even if pre-recorded use some weird DRM'ed transport stream. Partially thanks to Nero and KiSS, since Nero will want to promote their recode software which has been outputting .MP4 all this time.

On a lighter note, we have this quote hung up in our sales office where I work, I think it is very much related ;)

“I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant." - Robert McCloskey

By the way, feel free to use hacky VfW, just don't plague us with your "dirty" files :p ;)


If you need to do editing, do it in some other format first. Then encode using x264. Simple as that. I would probably do that even if a frame-accurate full-feature VFW h.264 was made if only because of how slow it'd be whenever I try to get at a frame that's not a keyframe.
My sentiments exactly.


And why CLI and VFW shouldn't exist in peaceful coexistence ??? Not developping a great software like x264 VFW any further would be shame !!!
They should do, and can do. But VfW needs to exist for it's old formats, not for new formats to be hacked into it. It's unfortunate but true. As soon as someone makes a Virtualdub(mod) clone but outputs spec compliant MP4 or MKV, things will quickly shift I think.


@Nicholi
Fantastic, I haven't laughed that much in a while :D


face it: avi is old and has problems handling new technologies. what keeps it alive is the existance of virtualdub, nothing less, nothing more (imho)
I agree. The way DeathTheSheep always returns to Virtualdub as source of arguement is proof. I actually think it's kind of rewarding to say that I don't use Virtualdub for encoding, since many people used to rely on it, in fact the only thing I use Virtualdubmod for is for previewing when I am filtering.


Oh man, some of the crap and useful stuff in here is worthy of a place in the "VFW Hall Of Fame".
Lol, yeah. This is already high on my list of "legendary threads"


It needs to open as well Basically, VDubMod + Matroska V2 support + MP4 support. It's certainly doable, but writing your own MP4 parser and writer isn't exactly a piece of cake.
That's true, but I guess with the help of jeanlf, haali (and is it mosu for Matroska?, pardon my ignorance) it would be more feasible, wouldn't it?


Interesting...so why have I only had software compatibility problems with non-VFW material? How come every single program I mentioned above (and some I didn't) play the VFW-created streams with the least issues?
Because the software is still in development you might say. VFW isn't perfect, I don't know if you were around during the switch from DivX 3.11 to XviD (IIRC, remember I wasn't involved in encoding back then), but it caused some real shit in the fansubbing scene at least playback wise. People crying all over the place that their AVI files won't play, or that they got weird artifacts.


Go cry me a river. The point of free software is that if you don't like what you get, you shut the hell up and either improve it or go someplace else. End of story.
ROFL, Doom9 is so blunt and to the point, I love it. I wish I could be more frank.


I try to behave in a civilized manner, and I don't want to discriminate against anyone in particular. However, I do like to take a bit of a stance against unwarranted zealotry when it starts to create visible victims (such as myself). I do not mean to insult any individuals themselves.
Uh, I hate to say it but a lot of the time you are digging holes for yourself, especially when you present such a one sided story of VfW vs Directshow, it will only invite reactions and trolling.

[Tom Ellard]

incredible... still speaking of VFW after years...

As a side issue to this whole debate - a partner of mine is attempting to preserve some very important video for the next couple of hundred years. Given how fast technology comes and goes we don't think that DVD is a great idea, nor is any current codec. We are working on the idea of uncompressed RGB video for windows stored on hard drives, and he's designing a piece of hardware that will read it and some instructions on how to build it written on acid free paper. Even YUV is a worry as we've seen too many different codecs for that :) and this thing has to work in a world where computers might not be anything like ours.

Anyway, back to the discussion ...

[dragongodz]

will this thread never end ? the total disrespect from both sides is amazing.

ok there is a sticky already explaining why the VFW gui has not been updated.
http://forum.doom9.org/showthread.php?t=105899

that should be all that needs be said about not requesting it to be.
of course if a person has problems then advise them that this is a known potentiality and advise them how they may avoid it. but please dont tell them they MUST change to CLI or GUI for CLI as being the only way since it is not.

the derision towards people that do want to use VFW and AVI is just as unneeded and ignorant. some of the B.S. said like people are afraid to change to newer stuff or if they use VFW in AVI and dont have any sync problems they must be only doing something simple or whatever etc etc etc. i can use x264 in avi and have no sync problems because i know what i am doing. as i side note i dont do dvd to avi with bloody frameserving to virtualdub either, will people get their heads out of the sand, vdub is NOT the only VFW program out there.

also IMHO people who constantly pollute threads by saying "VFW is evil", "H264 in AVI is evil" etc should get a life. i dont tell you what method you must use so please dont waste space with such pointless posts trying to tell me i am doing something wrong. maybe create a sticky giving the reasoned downsides to useing H264 in AVI and VFW and just point to that and then let people decide for themselves.