No more vfw x264 builds?

[Sharktooth]

personally, i use both new and old.

if i encode a move or something, then i'd use megui. but if its an episodic thing, then i'd use vdub - only because, afaik,there is no 'simple' way of splitting the video afterwards.

i know mkvmerge can split video, but last time i used it you could only type in a timestamp. without being able to open the vid in vdub then its very awkward to do this.

IMO, mp4 etc is the future, but the tools for those of us who dont write code etc, isnt anywhere near as good for editing/splitting etc as they are for vfw and it looks like it will be years before we have those tools.

until that happens, i will use both. its not because i want to stick with vfw, its because not using vfw severly limits my options.
It already happened. Get avidemux.

[Sharktooth]

Ah, the diversity and freedom of choice suffers another blow for the good of...uh, whatever the good in suddenly canning VfW happens to be (above posts hinted at...something or another, I believe). :P

Well, VfW is old, and I guess it is too easy for the average user, eh... Can't let 'em have it too easy; heavy-duty learning must be done! :P

I mean, it's not like my entire 13-page guide with explanations and illustrations has in one day been rendered completely and utterly useless...

And it's not like 50% of x264 users will be left in the cold, forced to switch to a whole new GUI, container, and jargon to receive any further updates to this one codec, and seperately install GUI software to use this one codec, and install .NET framework 2 for this one codec (GUI), and other of such nasty things, eh?

This whole thing reminds me (unpleasantly) of having to learn and upgrade to a whole new OS (XP) or processor just to use a new version of a software (Windows encoder), when compatibility with the older ones could easily have been retained... Didn't you say something like that before, bond? :)

So here is my (constructive) suggestion: just keep the vfw code intact. The VfW is complete enough for the average user, is it not? Why force drastic and unnecessary change when leaving it the way it is takes virtually no effort?

Thanks for hearing me out.
Oh... that's a catastrophic report. But since x264 VFW was no longer mantained new features will not be implemented. You can still use an old version... im sure they're still around they work... oh and magically your guide is still good for those...
Also read what Virus said... all the VFW code is still on the SVN... you just have to know how to get it. A coder or a builder will surely know how to do.
All this "oh my god! it's gone... oh my god! bring it back! oh my..." it's a NONSENSE. Stop whining and get a life.

[DeathTheSheep]

Well, sometimes a report is necessary.
I'm afraid all the speed boosts and quality enhancements which are not encapsulated within the "options" will be missed out on. For instance, the drastic speed boost of exhaustive motion estimation would have been... "missed," you could say, if the VfW wasn't silently updated along with the CLI, with no added effort or cost to anyone (except the compiler, who would be doing 50% of x264 users a huge favor, really :)).

But on a completely different not, I'm afraid I don't see the "magic" to which you are referring ;).

[Sharktooth]

You know, VFW code is only a "wrapper"... you dont need to update it to get the latest shiny new internal x264 optimizations ... just compile libx264 and then compile the VFW frontend.
There is no difference if the VFW code is not in the current SVN... you can always get it.
For instance, i could build x264VFW rev600 (when it will be available) even if the VFW folder is no longer in the current SVN revision...
Now follow my suggestion and stop bitching and refrain to make childish comments (like this: http://forum.doom9.org/showthread.php?t=98247&page=7). It could only make it worse...

[DeathTheSheep]

i could build x264VFW rev600 (when it will be available) even if the VFW folder is no longer in the current SVN revision...
Really?! That would be nice of you, Sharktooth. 1 VFW build every 20 revisions would be great, actually... Maybe you could treat it as a sort of "consolation prize" to the people who lost out when they went with VfW? :)

Just a suggestion.

[Sharktooth]

It was an example. Everyone can do it but no one wants to...
So, start thinking doing it by yourself...

[DeathTheSheep]

Maybe it's just a matter of them (us) not knowing how, fearing the compilation of a codec to be a complicated process, and depending on the kindess and generosity of others who know the way around?
I suppose if someone handed me a short guide of "how to whip up a VFW-only" version, I'd give it a healthy shot and everyone would be happy again! :D

But even then, honestly, your optimizations are so dang good I can't hope to compete, ya know :D

[Sharktooth]

Well, i no longer optimize "to the bone" since some revisions coz some flags were causing problems.
However here's my configure and make commandlines:
./configure --enable-avis-input --enable-mp4-output --enable-pthread --extra-cflags="-I../gpac/include -march=pentium2 -mmmx -O3 -finline-functions -funroll-loops -ffast-math -fomit-frame-pointer" --extra-ldflags="-L../gpac/bin/gcc"
make fprofiled VIDS="../foreman_352x288.yuv ../coastguard_352x288.yuv"
nothing special, as you can see.
if you want VFW just add: --enable-vfw in the configure line but since the configure script was edited to remove VFW you need to get the VFW code from the SVN as well as the reversing the configure script prior to the VFW support removal then you can go...
Pretty easy, just make a script for that and you just have to type its name on the MSYS console command prompt...

... but im still sure ppl wont do it by themself...

[DDogg]

Might be a goofy question - I get the fact that it is time to move off Vfw, but is it theoretically possible for a VDub plugin, new internal code, something, etc., to allow Vdub to interface to a state of the art X264 of some type.

To put that differently, do we permanently lose the ability to use VDub with a non Vfw x264, or is it doable by somebody if they ever wanted to do it.

[Zero1]

Encoding isn't easy. No one said it would be easy. Of course for myself and fellow Doom9 members, encoding is probably second nature, so it's hard to remember what it's like being a beginner. Try to look from the outside in, back in the days when you encoded a video but it was blurry because you didn't know about IVTC and such.

Some people view Doom9 as a forum, elitist; and it's members elitist also. That may be true for some people, but I think that's an unfair comment. I think a more accurate word would be enthusiast. We are enthusiasts about quality, video compression and encoding in general, and as such we tend not to like regression and hacks/workarounds so that new standards and encoders may be used with old containers. In short it's counter productive.

The VfW-ites may view what pengvado has done as harsh, but I think it's one of his better decisions. He and his fellow developers are very proud of this work, it's efficiency and ability to give any commercial encoder (or professional, for that matter) a run for it's money. I can appreciate if he wants to dump VfW and keep it as professional and spec compliant as possible.

Now I say looking from the outside in; I can appreciate that not everyone can understand or learn encoding; some people simply can't take to something like that; that is why user friendly software like Nero Recode exists. You can still create high quality, spec compliant MP4 files with an easy GUI using Nero.

I think one of the main points, and something we tend not to think about, is the huge knock on effect these "hacks" can have. I mean look at MPEG-4 ASP; it's specified and supposed to be contained in MP4, but due to people being so attached to AVI and DivX wanting to create user friendly encoders, workarounds were created and AVI hung on for a few more years. Had we been using MP4 for ASP back then, no doubt MP4 tools and support would be much better than it is now (even though it is very good already). I also think that we would have some decent standalone devices, if things were done to spec.

As such, the format was neglected for a number of years in favour of creating workarounds for AVI; which is of course counter productive.

Yes, some of you have mentioned freedom of speech/choice etc. Well it's the devs freedom of choice to withdraw VfW support. That's how it goes in opensource, you take what is offered and be thankful for the time and effort put into the project; if you don't like it, offer to help, make suggestions where appropriate or learn to code yourself.

[Sharktooth]

Might be a goofy question - I get the fact that it is time to move off Vfw, but is it theoretically possible for a VDub plugin, new internal code, something, etc., to allow Vdub to interface to a state of the art X264 of some type.

To put that differently, do we permanently lose the ability to use VDub with a non Vfw x264, or is it doable by somebody if they ever wanted to do it.
Yes, you can load vdub plugin into avisynth.
However you can frameserve vdub output to x264CLI.
For both the "know how"s :search: ;)

[DDogg]

Yes, you can load vdub plugin into avisynth.
However you can frameserve vdub output to x264CLI.
For both the "know how"s :search: ;)Yep, I'll use search to find all my own posts and guides on those subjects - You know what I was talking about, wiseguy :)

[Sharktooth]

Sadly Vdub relies on VFW, completely...
You cant use directly a non VFW codec into Vdub.
However Avidemux is becoming a good alternative to Vdub.

[Romario]

Yes, Avidemux is good, but it's still not good enough.

Can anybody tells me how to use x264cli in terms of direct encoding via my TV card? Precisely?

[DDogg]

Sadly Vdub relies on VFW, completely...
You cant use directly a non VFW codec into Vdub.
However Avidemux is becoming a good alternative to Vdub.
Just trying to be part of a solution - Maybe if put our heads together we think of positive things to help people make the transition to cli. For example, cut-lists are a biggy to many VDub users and I know somewhere on this forum is a tool (by BB maybe?) to convert the VDub VCF project file into a set of trim statements for avisynth. Maybe putting together a small transitional guide with these type of things would be a positive outcome of this slight controversy. Perhaps this already exists and I have missed it. If so, give me a pointer please.

Here is the converter: http://forum.doom9.org/showthread.php?t=30587&page=2 I guess VDubMod 1.5.4.1 does not have the save edit list checkbox that VDub has, but 1.5.10.2 does

[Sharktooth]

Yes, Avidemux is good, but it's still not good enough.

Can anybody tells me how to use x264cli in terms of direct encoding via my TV card? Precisely?
No, for that you can continue using the actual x264VFW builds but frankly i would capture with a light lossless codec then re-encode lately with better settings...

[Romario]

Ok, Shark, thanks. Do you have any other idea.

For example, can you make an directshow x264 encoder. .

[Sharktooth]

Yes one. Ask milan to reintegrate x264 encoder into ffdshow while we wait for a proper capturing support in avidemux (or in other softwares).
DirectShow? it has its own drawbacks too...

[foxyshadis]

x264 was taken out of ffdshow because it was so old and had to be kludged in to make it work. We actually took it out because x264vfw was still there and doing a better job, maybe it'll have to go back in (hopefully more sanely, no modifying libx264 this time).

To clear up an earlier misconception, avidemux cannot split, save, open, or in any other way work with mkv files. If it was done in mp4, then it could be split up.

Avidemux's problems to me are mostly aesthetic; it has a generic linuxy/windows 3.1 feel to it, no matter what window manager you use. It's too big and busy (whereas virtualdub is too empty), and violates too many UI principles. If they could somehow convince phaeron to help, they'd be in business.

[DDogg]

Sharktooth, Ilike you said, MeGUI will open a VDub frameserved VDR file which is wrapped in an avisynth script using avisource. RGB24 of course, but I guess it is better than a sharp stick in the eye and it does work pretty well.

[d'Oursse]

Sadly Vdub relies on VFW, completely...
You cant use directly a non VFW codec into Vdub.
However Avidemux is becoming a good alternative to Vdub.

i've written a small interface to x264 in gtk. It's in svn. Someone was able to make it work with virtual dub and sent me his code.

I don't have a lot of free time, so there are not a lot of updates. But I want to maintain it. At least, it provides a gui interface on linux (I use it for avs3)

[DarkZell666]

After reading all this, I figured out it's a short-term loss for a long-term benefit ... (if new tools come out to replace the old ones ! easier said than done !)

Dinosaurs eventually disappeared so why not VFW ? ^^
It's all in the name anyway : video for windowsaurs =)

[Sharktooth]

Sharktooth, Ilike you said, MeGUI will open a VDub frameserved VDR file which is wrapped in an avisynth script using avisource. RGB24 of course, but I guess it is better than a sharp stick in the eye and it does work pretty well.
Yeah sure, but i think it's a bit complicated for the newbie.
Would you like to write a guide for it? I'm sure it will be added to the MeGUI wiki.

[DDogg]

Yeah sure, but i think it's a bit complicated for the newbie.
Would you like to write a guide for it? I'm sure it will be added to the MeGUI wiki. Sure, I already have most of the bits and pieces laying about the forum, just not tuned to MeGUI input. I don't know Wiki from Whacky so I'll just post it here someplace.

A base framework for someone to add and mod with more details. Not much to this:

1> Go to your Vdub, or VdubMod directory and run AuxSetup.exe. Choose "Install handler"
2> Setup Vdub or VDubMod as you always do except you will not need any compression. Just use video defaults.
3> File > Start Frame Server
4> Press "start" leaving name as is
5> A save dialog will come up. Name can be anything.VDR, but I prefer "Signpost.VDR" - Make a habit of saving it in the same place like C:\My_VDR_Files or such.
6> Verify all is working by opening another instance of VDub and dragging or opening "Signpost.VDR". You should see video.
7> Create a simple Avisynth script using - Avisource ("c:\My_VDR_Files\Signpost.vdr").converttoyv12() - Save this script as Signpost.avs and make sure if using notepad there is no .txt added on to it
8> Verify Signpost.avs plays in VDub, WMP, MPC
9> Open this script as your source with MeGUI
10> Proceed as normal
11> After finishing, It was always recommended to run auxsetup again and select uninstall handler
12> Send lots of notes to Sharktooth asking for MeGUI to natively open a VDR file (would need yv12 conversion in code of course)

Notes:
1> Somebody smarter than me will have to address the colorspace issue. Should the original script contain colormatrix? Dunno.
2> Once you set this up the first time and have created the initial Signpost.avs it is always reusable so long as you use Signpost.VDR as your frameserve filename and always save it to the same path.

[Sharktooth]

ok, thank you. Ill make sure it gets into the wiki ;)

[bananacreamandpeca]

its all so confusing, different builds, wich one was originally last non-tempered with, whats baseline, wich build wich company wich beta or alfa wich compile and wich source, whats vfw.

omg. im getting a headache

[Sirber]

http://encyclopedia.tfd.com/Video+for+Windows
http://encyclopedia.tfd.com/H264
http://encyclopedia.tfd.com/Source+Code
http://encyclopedia.tfd.com/Compiler

have fun!

[Sharktooth]

its all so confusing, different builds, wich one was originally last non-tempered with, whats baseline, wich build wich company wich beta or alfa wich compile and wich source, whats vfw.

omg. im getting a headache
Try with this: http://en.wikipedia.org/wiki/Suicide
sorry... i couldnt resist... :D

Jokes apart...
Well, guides are there for a reason... and this forum is a big source of knowledge.
All you need is time...

[Sirber]

Well, guides are there for a reason... and this forum is a big source of knowledge.
All you need is time...Time is money, which you can send to my paypal account :D

[bananacreamandpeca]

Try with this: http://en.wikipedia.org/wiki/Suicide
sorry... i couldnt resist... :D

Jokes apart...
Well, guides are there for a reason... and this forum is a big source of knowledge.
All you need is time...

Are you dutch???

[Sirber]

he's Italian

but let's not get personal ;)

[bananacreamandpeca]

Time is money, which you can send to my paypal account :D

Besides time theres a lot of patience needed.
And with all these threads and cross information and nerdy suff like all these abbreviaions.
Can you blame me for getting a headache just by the thought having to go through all that?
Im still going to do it ;)

Found an interesting source for video newbies yesterday:
http://www.animemusicvideos.org/guides/avtech/

pretty clear and very understandable.

[Sirber]

Well, I could teach you.

but it will cost ya.

that's right... all the tea :D

[DeathTheSheep]

Time is money, which you can send to my paypal account :D

Which one to send? Time or money? Because I can do time :D

[Sirber]

Which one to send? Time or money? Because I can do time :DWell, paypal currently doesn't support the currency "time", so if you could convert before using it, it would be great!

[buzzqw]

@d'Oursse
can you put in your sign the link to your (or where to download) gtk build ?

thanks

BHH

[DeathTheSheep]

Sharktooth: Your PM box is full :(

[ChronoCross]

Sharktooth: Your PM box is full :(

just the way he likes it if I remember correctly lol

[DeathTheSheep]

lol :D I guess it does save time to have it always full ;)

[check]

I mean, it's not like my entire 13-page guide with explanations and illustrations has in one day been rendered completely and utterly useless...

It hasn't. The options of the vfw are simply a subset of the options in the full CLI encoder. For example, see this that I wrote up: http://mewiki.project357.com/Video_configuration_dialog/X264_Configuration
Even thought one was written for vfw and one for CLI, there is a significant overlap.

Your recommendations are still useful for those using the CLI encoder, the only thing you need to change is updating images and adding options that didn't appear in the vfw interface.

[Sharktooth]

lol :D I guess it does save time to have it always full ;)
yeah... i should keep my mailbox full too...

[ChronoCross]

everyone should read this (New rules for vfw discussions):

http://forum.doom9.org/announcement.php?f=77

[DDogg]

everyone should read this (New rules for vfw discussions):

http://forum.doom9.org/announcement.php?f=77
Suggest #4 be reworded for clarity.

[Romario]

delete this please

[SeeMoreDigital]

How about: -

4) When someone asks for help with encoding using x264 VfW, do not belittle them with replies such as "why are you still using VfW" or "you should not be using VfW". Your replies should be positively structured to help the poster in his efforts. If not you will be striked for violation of rules 11 and 16. Which means you are just one strike away from being banned!

[DeathTheSheep]

SMD: I like that! I think it sounds good n' fair!

[Doom9]

@SeeMoreDigital: Rules and regulations have a tendency to be worded more formally, as well as more broadly. You won't find any forinstances in a lawbook either. That is because if you try to be specific, you always end up missing things and have to keep on correcting.
@Romario: It's a free world, nobody points a gun to your head and forces you to come here.

[Adub]

Well said doom9. Isn't it about time to close this thread?

[SeeMoreDigital]

@SeeMoreDigital: Rules and regulations have a tendency to be worded more formally, as well as more broadly. You won't find any forinstances in a lawbook either. That is because if you try to be specific, you always end up missing things and have to keep on correcting. Indeed...

However, some of what Bond has written doesn't seem to flow quite right. Most probably because English is not his primary language....

I'm not criticising, just trying to lend a helping hand.


Kind Regards

[DeathTheSheep]

When I first read rule 4, I got the following out of it (until re-reading it a few times):

"If someone is asking for help for encoding with x264 vfw, noone should answer.
Only try to convince the user to not use x264 vfw. The answers should always help the user with his efforts."

In fact, that's almost exactly what is already written, but with added punctuation. Perhaps this is the opposite of what was intended? I'm unsure.

But I think the new system is quite acceptable and I give it my [preliminary] support.
:cool:

[edit] I B COOL new thing B Better :P