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

[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.