Which tool do you use to encode x264?

[stax76]

I thought it would be interesting to know how people encode x264.

[Sirber]

Yep.

we'll see about:Originally Posted by Doom9
megui is being used by 95+% of all users for x264 encoding

[Razorblade2000]

Yep.

we'll see about:


6 Voters

you = your software
stax = his software

--> 4 "free" voters

MeGui + MeGui264 = 4 Voters

--> 100% of the "free" voters use MeGui :P

[Doom9]

megui is being used by 95+% of all users for x264 encodingare you guys (all non native speakers by the way, me included) misreading my sentence.. I'm not saying that 95% of all the people using x264 use MeGUI as a GUI for x264.. but 95% of the people that do use MeGUI, do so for x264 encoding, not for xvid encoding, fmp4 encoding or snow encoding, muxing-only, audio-only, etc.

[Revgen]

are you guys (all non native speakers by the way, me included) misreading my sentence.. I'm not saying that 95% of all the people using x264 use MeGUI as a GUI for x264.. but 95% of the people that do use MeGUI, do so for x264 encoding, not for xvid encoding, fmp4 encoding or snow encoding, muxing-only, audio-only, etc.

Ahh...So you intentionaly tried to confuse us.:D

[stax76]

are you guys (all non native speakers by the way, me included) misreading my sentence..

Good you mention it because I did indeed misread it ;)

[krmathis]

Other -> QuickTime Player

[buzzqw]

i voted for other...

i use my gui

BHH

[Sirber]

Good you mention it because I did indeed misread it ;)
I like it more thid way :)

[thetrueavatar]

Till now I have used satsuki all2x264 but since satsuki won't developp it anymore I will probably use megui x264.

[DarkNite]

I wish I could vote twice because I use both win32 and *nix systems. I ended up voting for the win32 tool (MeGUI x264) because I use that more often than batch/script now.

The full MeGUI is great for all the ASP projects though. Now I just have to try out StaxRip before I can say I've put all these apps through the ringer.

[unmei]

i have a couple of .bat with my most used switches, if i want other switches i call the exe only, which i assume is what you meant by "command shell" even tho calling a bat is actually also command shell.

[Sirber]

@unmei

The thing you use is "batch, script", .bat means .batch ;)

[DeathTheSheep]

Man I wish I could vote for two.
GO REALANIME!! GO VFW!!!

VFW 4 EVAR!!!!! :P

[uray]

I'm using :

avisynth (AVSEdit) -> x264cli

it's more than enough...

[deets]

im a big fan of megui, i used it purely for my x264 stuff (pretty much all my dvd's are being converted for the psp). the bitrate calc, d2v creator and the avs creator mean it pretty much does all i need.

[lexor]

I'm using :

avisynth (AVSEdit) -> x264cli

it's more than enough...
more than enough? just out of curiosity, what would you remove, avisynth or x246cli? :sly:

[Zero1]

To hell with VfW and AVI :devil:

Command line & batch is the only way to fly. Though I have to say I too have a common batch and I just edit it should I need to or a new feature become available.

[unmei]

@sirber, that's what i voted.
My point was just, whether i open the CLI to type in something like "x264.exe -blah -blah" or "x264fast blah blah" doesnt make much of a difference.
Well, except that i generally use less parameters with the batches than with the exe (that's what they are for after all :)).

[Sirber]

Both MeGUI should have been as one, since it's the same soft.

[SeeMoreDigital]

It's MPEG Mediator for me ;)


Cheers

[*.mp4 guy]

Both MeGUI should have been as one, since it's the same soft.
Not really, I've used both and I greatly prefer MeGui X264.

[berrinam]

Not really, I've used both and I greatly prefer MeGui X264.
I'm not complaining or anything, I'm just intrigued. Why do you prefer MeGUI x264 when MeGUI full offers exactly the same and more if you want it?

[DarkNite]

I can't speak for anyone else, but it is rather convenient since it's included in the x264 full package (so you usually get the applicable updates for both in one simple download with installer), and contains almost everything you need if you only use MeGUI for x264 encoding.

It's also really convenient when you want to quickly set up a slave for encoding the video jobs while you typeset or edit, or slap out spreadsheets on another box. Not that I'd ever put work computers to use for anything that wasn't ultimately aiding the shareholders... Employee morale is important to productivity, right? ;)

[Doom9]

Both MeGUI should have been as one, since it's the same soft.As part of the MeGUI team, I find it rather important that this distinction was made.. it helps up with an eventual decision to dump or not the conditional compilation.

What I'd like to know (and I'm sure stax and Sirber as well), is why there are 9.5% using VfW and why people make their own scripts which is more effort than using a GUI with profiles.

[Wilbert]

What I'd like to know (and I'm sure stax and Sirber as well), is why there are 9.5% using VfW
I'm one of those :) I guess not everyone is bothered to install .NET (yes i know the CLI version doesn't need that, but i avoid CLI versions when possible).

and why people make their own scripts which is more effort than using a GUI with profiles.
Ehm ... Not everyone uses it for encoding his clean dvd's.

[Doom9]

Not everyone uses it for encoding his clean dvd's.So? There's an avisynth script creator and you can have profiles that you can fill with exotic filters that would make me run away screaming..

[Sirber]

I'm one of those :) I guess not everyone is bothered to install .NETRealAnime is in Delphi 7, so no .NET to install or any other framework :D

[nm]

What I'd like to know (and I'm sure stax and Sirber as well), is why there are 9.5% using VfW and why people make their own scripts which is more effort than using a GUI with profiles.
This is why I make my own (bash and Perl) scripts:

1) It is hard to get most of these GUIs running on other operating systems than Windows.

2) Scripts can be easily used through SSH remote connections and they can be left running in the background when there is no connection.

3) Not everyone uses x264 to encode DVD sources. TV recording (timeshifting) and for example 24h video surveillance both require more automatic encoding which can be done either by including x264 support directly in the video capture program, or by simple scripting to enhance existing programs.

[CruNcher]

yep i also prefer commandline encodeing and batch/bash especialy remotely

[Doom9]

2) Scripts can be easily used through SSH remote connections and they can be left running in the background when there is no connection.Well.. there's x11 tunneling over SSH and RDP for Windows ;)

[Sirber]

What I'd like to know (and I'm sure stax and Sirber as well), is why there are 9.5% using VfW and why people make their own scripts which is more effort than using a GUI with profiles.That's a good question indeed. Maybe coz VFW is editable in VDub...

[smok3]

i use batch script(s) for providing my editing stuff to the people (you know like work in progress stuff), it is avi->mp4 centric, and it is a one click encoding (just a button in total commander.)

however if i wanna be fancy i have set different encoding methods for both audio and video and you can call the script with a command line like:

x264_ c:\file.avi d:\template.avs itunes slow

(which is: use avisynth template called template.avs, use itunes for sound, use slow preset for x264)

also the script will automagically hint the mp4 file, upload it to my ftp server and return the url, so that url gets mailed asap. - basically it is about the specific need....

edit: oh, i do use megui actually, mostly to rip shartooths presets.

[nm]

Well.. there's x11 tunneling over SSH and RDP for Windows ;)
Both require an order of magnitude more bandwidth and persistency is difficult to achieve at least with X11 tunneling (if the connection is closed, the app goes down). Actually I use VNC myself to always have a persistent remote desktop running. However, I mostly use it to have some terminal windows running, so it would be better to have a script or a simple program that uses SSH+screen to easily connect to multiple remote shells at once.

But don't listen to me, I use X (which is my only desktop) just to have multiple terminal windows on the same screen, run a browser, an IM client and the occasional MPlayer instance ;)

[dimzon]

As part of the MeGUI team, I find it rather important that this distinction was made.. it helps up with an eventual decision to dump or not the conditional compilation.
http://forum.doom9.org/showthread.php?t=105776

[Richard Berg]

and why people make their own scripts which is more effort than using a GUI with profiles.
I've been using UltraEdit + VDub to write scripts for like 5 years. Many GUIs have been written, but none of them seemed good enough to invest the necessary time to get comfortable/fast with them, so I didn't. Now that I'm kinda involved with MeGUI maybe I'll change workflow.

I'm certain VFW has only stayed alive because of VDub.

[Revgen]

That's a good question indeed. Maybe coz VFW is editable in VDub...

MeGUI CLI encodes can be edited in Vdub using VDub's frameserving function.

"your .avs" or "your.avi" file --> Open in Vdub and edit and frameserve to "your.vdr" file--> open "your.vdr" file in avisynth using avisource("mydrive:\your.vdr")--> open this .avs file in MeGUI, RealAnime, StaxRip, etc and encode. It's a little more of a hassle, but at least you get the better quality that the CLI version provides.

[Doom9]

I used to use GKnot for bitrate calculation and avs generation and manually encoded in VDub.. but that was before I started adding all those tools to MeGUI.. I haven't installed GKnot anymore with the latest PC resetup back in June.. I've never had the need anymore.

[raymod2]

What I'd like to know ... why people make their own scripts which is more effort than using a GUI with profiles.

How is click here, click there, pull down this menu, select this tab, press this radio button, click OK, click File->Save, click Yes, click OK.... easier than execute encode.bat?

[berrinam]

Ok: batch file operation:
1. Open command prompt.
2. Navigate to your directory.
3. Type encode your_avs_script.avs

MeGUI approach.
1. Open a window with your_avs_script.avs
2. Drag it onto MeGUI.
3. Press Queue. (With Autostart Queue turned on, that's enough)

[Richard Berg]

"your .avs" or "your.avi" file --> Open in Vdub and edit and frameserve to "your.vdr" file--> open "your.vdr" file in avisynth using avisource("mydrive:\your.vdr")--> open this .avs file in MeGUI, RealAnime, StaxRip, etc and encode. It's a little more of a hassle, but at least you get the better quality that the CLI version provides.
That's the hard (and very slow) way. Better: export your VDub cutlist, use one of the vcf->avs tools, then paste the Trims into your script.

[bob0r]

batch, script, cap.bat:


start /low /b /w x264 --progress --pass 1 --bframes 3 --me dia --ref 1 --subme 1 --analyse none --output NUL cap.avs
start /low /b /w x264 --progress --pass 2 --bitrate 528 --bframes 3 --b-pyramid --b-rdo --weightb --ref 8 --trellis 1 --bime --subme 6 --8x8dct --analyse all --output x264.mp4 cap.avs

::start /low /b /w MP4Box -add video.264 x264.mp4
start /low /b /w MP4Box -sbr -add audio.aac x264.mp4


Basically i try just to test all options and see if it works.

[stax76]

That's the hard (and very slow) way. Better: export your VDub cutlist, use one of the vcf->avs tools, then paste the Trims into your script.

May using AVSEdit to create the trims be a easier approach?

[hitbit]

I voted "other". I use mencoder, with CLI or with a custom GUI written by me, mainly because it supports ripping straight from DVD.

[Richard Berg]

May using AVSEdit to create the trims be a easier approach?
Quite possibly :) I've never gotten around to trying the new Avisynth GUIs.

[lrms]

I also use mencoder (usually with batch files), so I voted other.

[virus]

What I'd like to know (and I'm sure stax and Sirber as well), is why there are 9.5% using VfW and why people make their own scripts which is more effort than using a GUI with profiles.
I voted "scripts". Here's why:
1) more flexibility, especially for testing - automatic generation of graphs and reports, with the ability to easily define test sequences from my own material and reuse them as I wish, without any limitations.
2) forces me to learn and gain a better understanding of what's under the hood.
3) easier and faster updates/bugfixing, just when I need them, since I'm the one writing the code.
4) funnier, I like practicing shell scripting. Lot of power in a few keystrokes.
5) generally poor or nonexistant support for Linux.
6) I refuse to support/use any technology related to .NET and other M$ crap. I don't feel like spending my free time making the guy in Redmond more rich than he actually is, nor I want to support their "let's use a monopoly to enforce another monopoly" tactics anymore.
7) I don't like authors that enter practically all threads with the usual "why don't you use my GUI, it does X, Y and Z, instead of your stupid scripts/vfw/whatever" (maybe not with this exact wording, but the meaning is pretty clear). I found this redundant, disrespectful and plain annoying. Certainly I'm not going to use those tools unless I'm absolutely forced to. Which I am not.

[Dayvon]

What I'd like to know (and I'm sure stax and Sirber as well), is why there are 9.5% using VfW and why people make their own scripts which is more effort than using a GUI with profiles.

I used to use GKnot for bitrate calculation and avs generation and manually encoded in VDub.. but that was before I started adding all those tools to MeGUI.. I haven't installed GKnot anymore with the latest PC resetup back in June.. I've never had the need anymore.

I have a fairly simple explanation for that. I feel like I'm just an average encoding boy. I like to use the MPEG-4 for space constraints, but I like high quality video files on my hard drive. So I visit doom9.org every now and then, update my stuff every now and then and I'm happy as a lark.

So, when you post a codec comparision, I tend to follow your lead and use what's the best codec right now. Well, an x264 link isn't even on the downloads page. Neither is MeGUI, YAMB, Mp4Box, mencoder. And these are the BASIC tools needed to use CLI (which I still don't even know what that is exactly). The only reference to x264 is in the guides section, which shows how to use it with Gordian Knot or VirtualDub. So I started using that, but I had to poke around the forums to figure out how I could start using AAC and the .MP4 container. And then I hit this wall of "down with VfW!!!" when I don't even know what that is!! So I had to login to the forums (for the first time) and start getting down and dirty to get up to speed.

So the simple explanation is that alot of peeps do what they can follow a guide for. I like to reference guides and then do what I want. I'm sure that if the guides and download links were updated that would help alot of people get on board. I like MeGUI alot after finally getting it to work (with your help :) ) but it took ALOT of effort for me to get here. And I know its taking you guys tons of effort to make this stuff, and I'm very grateful, but you've got to know that alot of people need that "take me by the hand" stuff. If you want VfW to die, we need to help these people out.

Needless to say, I voted MeGUI, because I want to switch to the .MP4 container sooner than later, and MeGUI seems pretty freakin' sweet. DGIndex + MeGUI looks like the magic two for reasonably simple encoding. Then again, you still need Mp4Box, BeSweet, and AVSynth, so I guess it's not that simple...

[Sirber]

5) generally poor or nonexistant support for Linux.I've been told RealAnime 4.0 runs fine on wine ;)
6) I refuse to support/use any technology related to .NET and other M$ crap. I don't feel like spending my free time making the guy in Redmond more rich than he actually is, nor I want to support their "let's use a monopoly to enforce another monopoly" tactics anymore.That's why I use Delphi VCL. No framework, no dependency, only a bigger EXE :)

[berrinam]

@Davyon: :goodpost: Of course, the real problem is that this forum is focussing on the absolute latest versions of these programs, whereas the main Doom9 webpage is a bit behind, and has the tried and true encoding methods. Especially MeGUI, having moved recently to SourceForge, has undergone heavy development, and with all the planned changes, writing a guide could well waste a lot of time if it changes structure sometime soon. Also, more effort is going into development than into documentation (why should the coders be responsible for documentation anyway? It doesn't take any coding knowledge to write a guide).

[Dayvon]

@Davyon: :goodpost: Of course, the real problem is that this forum is focussing on the absolute latest versions of these programs, whereas the main Doom9 webpage is a bit behind, and has the tried and true encoding methods. Especially MeGUI, having moved recently to SourceForge, has undergone heavy development, and with all the planned changes, writing a guide could well waste a lot of time if it changes structure sometime soon. Also, more effort is going into development than into documentation (why should the coders be responsible for documentation anyway? It doesn't take any coding knowledge to write a guide).

Totally understand and agree. Its weird because this forum was like a completely different world for me. I mean VfW, CLI, mencoder, and countless other terms just had no meaning whatsoever because there is no definitions or other guide-like things on doom9.org. I don't know if Doom9 is the only guy who does that stuff, but I know that it needs to be done if the rest of the masses are gonna jump on this wagon. I imagine that half the reason the updates have not been done is cause there seems to be updates every 2 days to x264 or MeGUI, which does negate the effort that would be put into a new guide. But having nothing is not a good option either.

BTW that's probably also why you guys are getting more Noob traffic here in the forums. They want to move up, but don't know how the heck to do so. You can prolly count me in that bunch! ;)

[Doom9]

Well.. if anybody wants to volunteer to write a guide... I know I should, but I rather write code.. it's more of a challenge and more satisfying to get something done.. writing a guide is just "I'm glad it's done" kinda stuff.

As already pointed out, hosting x264 on my site makes no sense.. too many updates. The link to the latest mp4box compiles is in the MP4 guide, and YAMB is hosted. Mencoder is simply too big (and it comes bundled with a player for masochists)

5) generally poor or nonexistant support for Linux.You can say that for all multimedia software. Linux' main problem is that it has no multimedia framework built-in. Which means, all video tools have to reinvent the wheel or copy from each other, which isn't exactly productive.
6) I refuse to support/use any technology related to .NET and other M$ crap. I don't feel like spending my free time making the guy in Redmond more rich than he actually is, nor I want to support their "let's use a monopoly to enforce another monopoly" tactics anymore..NET is an ECMA standard (a signed off one.. not like some of the "yeah, we submitted it to the ECMA so consider it a standard), so is C# and there is at least one useful alternative implementation. As long as you do not use ASP.NET or ADO.NET, you're really using a standard and the code will compile and run on any other complete platform implementation.
If DGDecode, AVIFile and .NET run on WINE, then I'm pretty sure MeGUI would run as well. It really only uses standard compliant code but it has a DGDecode and AVIFile dependency.. those are not really avoidable.. there's no alternative that doesn't involve lots of extra work.

3) easier and faster updates/bugfixing, just when I need them, since I'm the one writing the code.Well, to our defense, those tools are all open source.. if you want something fixed, you can do it on your own.. and it should give you that warm fuzzy feeling since it's free software;)

[nm]

You can say that for all multimedia software. Linux' main problem is that it has no multimedia framework built-in. Which means, all video tools have to reinvent the wheel or copy from each other, which isn't exactly productive.
Of course Linux doesn't have a multimedia framework built-in. It doesn't even have a graphical desktop built-in. But if you need a framework, GStreamer (http://gstreamer.freedesktop.org/) is nowadays available on every major distribution. It is actually a bit ironic that you are complaining about Linux multimedia support when you have based an encoder GUI on Mencoder ;)

.NET is an ECMA standard (a signed off one.. not like some of the "yeah, we submitted it to the ECMA so consider it a standard), so is C# and there is at least one useful alternative implementation. As long as you do not use ASP.NET or ADO.NET, you're really using a standard and the code will compile and run on any other complete platform implementation.
As long as the code doesn't call any native win32 libraries. Many programs require parts of them to be optimized for speed, and some need to use hardware directly through drivers when there is no standardized .NET interface available. Java has the same problem, but it is worse for .NET because Microsoft's "reference" implementation is only available on one platform. Most developers won't care about portability as long as the code runs on different flavors of Windows.

[Doom9]

Of course Linux doesn't have a multimedia framework built-in. It doesn't even have a graphical desktop built-in. But if you need a framework, GStreamer is nowadays available on every major distribution.But that's just the thing... it needs to be packed. You can't say "if it runs Linux I can use it because it's there".. it's, check for it, and send the user through dependency hell if it's not there. That's the main reason that even when given the choice, I'd chose Windows as a development platform. Windows API are slow changing and anything that's in it, you can assume most people have. And if not, you package the runtime and know everybody will be able to install it.. that definitely doesn't work for Linux.. I'd dare say an ever changing API is a developer's biggest nightmare.

It is actually a bit ironic that you are complaining about Linux multimedia support when you have based an encoder GUI on MencoderThat was out of necessity.. the Me in the name has already lost much of its significance since most people use x264.exe with the GUI. If I can find a suitable raw -> avi muxer, x264 encoding will no longer be available via mencoder, and the same goes for xvid encoding as soon as encraw is good enough.
As long as the code doesn't call any native win32 libraries. That's interop and naturally any reference to native code makes the whole thing no longer platform agnostic.. but that's not part of .NET.. it's a Microsoft addition.

[nm]

But that's just the thing... it needs to be packed. You can't say "if it runs Linux I can use it because it's there".. it's, check for it, and send the user through dependency hell if it's not there. That's the main reason that even when given the choice, I'd chose Windows as a development platform. Windows API are slow changing and anything that's in it, you can assume most people have. And if not, you package the runtime and know everybody will be able to install it.. that definitely doesn't work for Linux.. I'd dare say an ever changing API is a developer's biggest nightmare.
Now this is a completely different argument and the "dependency hell" part is taken care of by modern package management (à la Debian). Granted, there are generally no stable API's , but I'd say that is the case with all software libraries that are under development. That is the reason why some commercial software is built to run on specific versions of certain distributions.

Open source software on the other hand can be just left loose on the net and if it is good enough, other people and distributions will pack it up for you. They take care of the dependencies to suit the distro no matter what API's the code is based on (you know, there can be multiple versions of the same libraries installed on the system). Then the user can just browse through a software repository, click on your program and it gets installed. You don't really need to worry about packaging to get people to use your software. If the software is interesting or useful, there are also people who will do the work for you.

It is actually a bit ironic that you are complaining about Linux multimedia support when you have based an encoder GUI on Mencoder.That was out of necessity..
Exactly.

That's interop and naturally any reference to native code makes the whole thing no longer platform agnostic.. but that's not part of .NET.. it's a Microsoft addition.
I'd say the whole .NET is a Microsoft addition.

[Doom9]

Now this is a completely different argument and the "dependency hell" part is taken care of by modern package management (à la Debian).You'll find articles on ./ that outline this clearly isn't the case.. it works mostly.. but not always and there are still instances where the whole package management fails utterly and completely. You might remember the article.. it was somebody suggesting an extreme overhaul to make Linux fit for the desktop... quite an interesting read and some of the proposed things are quite radical.

I'd say the whole .NET is a Microsoft addition.Then what is Mono? Just because it has Microsoft on the packaging shouldn't automatically make it bad.

That is the reason why some commercial software is built to run on specific versions of certain distributions.Just as an example of a commercial software... I wrote a remote support solution at work.. it serves about 100 people in two countries running machines ranging from NT, over W2K to WinXP.. it's the exact same code for a decade worth of operating systems. And the whole thing is written in .NET with no interop whatsoever (well, there's one ActiveX from Microsoft but that's it). You can bash Microsoft and .NET all you want, show me a Linux soft where one binary serves 10 years worth of Linux versions ;)

[nm]

You'll find articles on ./ that outline this clearly isn't the case.. it works mostly.. but not always and there are still instances where the whole package management fails utterly and completely. You might remember the article.. it was somebody suggesting an extreme overhaul to make Linux fit for the desktop... quite an interesting read and some of the proposed things are quite radical.
I know the slashdot articles, and from years of personal experience, I also know that they are usually BS. People who write them want to have Windows or OS X -like package management where the programs are separated from each other and software repositories aren't required. I have come from that world a long time ago, and I haven't looked back after running apt-get upgrade (or was it emerge world) for the first time. I used RPM-based packaging before that and it used to have difficult dependency problems, but those days are past already.

Autopackage might one day provide OS X style packaging for those who need it. I do agree that it is nice for small-scale development and custom software.

Finally, as a counter argument, there is no usable packaging at all on Windows. Now how do I upgrade all the programs on my system? One by one, and even then I need to go to a website to download the newest versions. Now that is what I call complete failure of package management :)

Then what is Mono? Just because it has Microsoft on the packaging shouldn't automatically make it bad.
I already said why .NET might not work in practice and that wasn't because of the name, but because of the software developers' laziness and lacking requirements for portability.
Mono is an incomplete implementation that most Linux developers are hesitant to use because of the (invisible) strings attached. I'm not saying Mono is a bad idea or that it shouldn't be used, but that is still the common attitude. And if developers on Linux won't really support it, why would the Windows folks. As I said, they only need to care about Windows compatibility, so they can use whatever legacy code they need to get things done easily.

Just as an example of a commercial software... I wrote a remote support solution at work.. it serves about 100 people in two countries running machines ranging from NT, over W2K to WinXP.. it's the exact same code for a decade worth of operating systems. And the whole thing is written in .NET with no interop whatsoever (well, there's one ActiveX from Microsoft but that's it). You can bash Microsoft and .NET all you want, show me a Linux soft where one binary serves 10 years worth of Linux versions ;)
Yes, Windows has very stable API's to provide good binary backward compatibility, although your example doesn't really show that (I can easily have a Java app that runs on 10 years worth of Linux versions). But why would I need binary compatibility when I have the source code! And where have I bashed Microsoft? It was you who "attacked" Linux and I am just defending it ;)

[Morte66]

RealAnime is in Delphi 7, so no .NET to install or any other framework :D

Hey cool... I'm currently having a problem with MSVCR80.DLL in .Net (eDonkey is only stable with the beta, MeGUI/StaxRip use a method that's only in the release version).

[Doom9]

I also know that they are usually BS.The one I'm refering to shows a complete and utter failure of apt-get.. if that's BS, well.. you can write the rest of that sentence.

Finally, as a counter argument, there is no usable packaging at all on Windows.Actually.. it has no package management whatsoever. But the extensive APIs that are already onboard migitate that somewhat. And if you upgrade libX via apt-get you risk compatibility with app y and the likes. The compartmentalization of Linux software might work for developers (since they know what they're doing), but even they'd often be better off having a known software standard that you can count on, so you either make sure your app runs against that, or you ship your own libraries.

The mess that is software installation on Windows is largely the fault of developers. Commonly used installers offer more than enough means to properly check for dependencies before the software is installed, offer rollback, and during an uninstall, there's no reason to prevent you from getting rid of everything created by your own software.

But why would I need binary compatibility when I have the source code!Because asking the user to compile is a dangerous thing to do (actually.. I feel like writing stuff here that causes a flamewar). No user should ever be expected to run more than a setup program.. so either setup.exe or ./setup.bin. And no, a bash script that launches ./configure, and make isn't the same thing.. it requires that the user would have compiler and all the libraries.. (and a compiler most definitely has nothing to do on a desktop platform..(unless we're talking about a machine of a developer) it makes it easy for developers but that's no excuse).

And what do you do if an app isn't known to the package management? You need somebody to integrate it.. so for each version of each app and library, somebody has to lay a hand on.. that's a huge amount of time just because there's no common stable APIs on the platform.

Last but not least, not every distro has the same package manager.. tons use rpm, and it's not like Debian is manageable for a normal user.

[stax76]

Creating a poll with .NET and Linux tools, I should have seen it coming :)

[nm]

Hey cool... I'm currently having a problem with MSVCR80.DLL in .Net (eDonkey is only stable with the beta, MeGUI/StaxRip use a method that's only in the release version).
@ Doom9
Oh yeah, talking about developing against changing APIs and the euforia of Windows package management :sly:

[Doom9]

I'm currently having a problem with MSVCR80.DLL in .NetUhh.. you need such DLLs for native apps, not managed ones. If you create an MFC app in VS2k5 you'd need to make sure this DLL is available on a target system.

[Morte66]

Uhh.. you need such DLLs for native apps, not managed ones. If you create an MFC app in VS2k5 you'd need to make sure this DLL is available on a target system.

I'm afraid I don't know what that means, or whether I can do anything about it. :( Nor, I think, do 99% of users. [Or a pretty high percentage of programmers -- I recently scored 100% on a Sybase test that included questions meant to stop anyone scoring 100%, but I don't know a MFC app from a hole in the ground.]

[For the record, I realise that eDonkey is at fault here, not Windows or MeGUI or StaxRip. But I get clobbered by the dependencies all the same. And maybe I could lash somthing up with multiple copies of MSVCR80.DLL and MSCOREIE.DLL that calls it, and maybe that would work or maybe it would just reveal further issues, but it's simpler to use GordianKnot.]

[I like square brackets.]

[nm]

The one I'm refering to shows a complete and utter failure of apt-get..
I don't remember that one. Would be nice if you could dig up a link.

Actually.. it has no package management whatsoever.
That's what I said.
But the extensive APIs that are already onboard migitate that somewhat.
Yes, good APIs are useful, but they don't replace packaging at all. They don't solve software updates, which is the part of package management that is actually useful to the end-user. Package management handles that AND the API problems get straightened out behind the scenes (from the user perspective).

And if you upgrade libX via apt-get you risk compatibility with app y and the likes.
That is misinformation. I have never managed to break anything like this without forcing updates against dependencies (and that would be difficult to do). Apt is designed to avoid these kind of dependency problems. Have you actually used Debian stable or Ubuntu?

The compartmentalization of Linux software might work for developers (since they know what they're doing), but even they'd often be better off having a known software standard that you can count on, so you either make sure your app runs against that, or you ship your own libraries.
It works perfectly well for users who don't go installing software "the Windows way". There are stable standards for developers who need them. As you know, Java, Mono and some scripting languages can be used to write even complex desktop software that works wherever the platform is installed.


The mess that is software installation on Windows is largely the fault of developers. Commonly used installers offer more than enough means to properly check for dependencies before the software is installed, offer rollback, and during an uninstall, there's no reason to prevent you from getting rid of everything created by your own software.
Installers alone won't solve updates and the unnecessary bloat that comes from shipping shared libraries with every program and then mixing them to DLL hell.

Because asking the user to compile is a dangerous thing to do (actually.. I feel like writing stuff here that causes a flamewar). No user should ever be expected to run more than a setup program..
My throw about having the source was sarcasm and I agree completely about users compiling code. However, this is not a problem that (granny-level) users commonly face with Linux. At least not when they use package management properly. We were talking about old programs. Now, if there is source available, someone (a distro developer probably) can compile it to run on a more recent system. This is only done if the code is valuable and there is need to use it; that is, it hasn't been replaced by a newer version or another similar program. So getting old software running is not a problem when there is need (unlike with binary-only stuff that is beyond hope when binary compatibility is lost). If the user absolutely needs a certain version of a deprecated app, then tough luck, he must either find someone to compile it for him or do it himself. This is the case where binary compatibility wins. But how often do you need age-old versions of software? Hasn't happened to me except once with a closed-source DOS database program that we needed to run on Linux, and that was easy with Dosemu.

And by the way, an installer can compile things automagically so that it is an entirely smooth operation. NVidia does this with their Linux driver, and when the compiler dependencies are handled by apt, there are really no problems at all. Using a C compiler like this in Linux is not harder than using java to execute bytecode.

And what do you do if an app isn't known to the package management? You need somebody to integrate it.. so for each version of each app and library, somebody has to lay a hand on.. that's a huge amount of time just because there's no common stable APIs on the platform.
Perhaps, but building new versions of packages is mostly automated and there are people who like doing it. Then there are source-based packaging systems like Portage in Gentoo Linux and ports in the BSDs, where the building step is left to the user machine. Maintaining packages in that landscape is much easier and installing is almost as nice as in Debian.

Last but not least, not every distro has the same package manager.. tons use rpm, and it's not like Debian is manageable for a normal user.
Just talking about package management here? Are you kidding? Synaptic (and Ubuntu if you are talking about other administration tools and system installation) is the answer here.


Ok, we are so far away from the topic that it can't even be seen from here, so I'll try to hold my horses now. Although this is an interesting debate, nothing really new has come up on either side, and the rest of you are probably quite annoyed already :)

[Doom9]

Have you actually used Debian stable or Ubuntu?No.. my experience date back to suse and rpm.. it was a horrible experience that thought me just how good a rich API really is. And now that I write software myself, I think so even more strongly. I don't think Linux will ever be a serious contender to Windows on the Desktop until they throw the compartmentalization overboard. The whole approach just doesn't work for users that are inheritently dumb (and that's basically what you can expect from the average desktop user).. A lot of time and effort has been put into making an architecture that's just not meant for a stable system workable, when the much more obvious approach would've been to spend a moment thinking about the architecture instead. Compartmentalization works well for development, and considering the nature of Linux development it's understandable why it was chosen, but if you're not working on the compartment level but above.. it makes your life a lot harder.

They don't solve software updates, which is the part of package management that is actually useful to the end-user.But on an average Windows box.. how many software do you have to update every month? And those that you do, normally you can just run setup.exe and it uninstalls an eventual old version. I realize you have to download the new version manually, so that's a comfort package management gets you, but only if the app in question is supported.. it all comes down to this. The same service could be built up for Windows if the volunteers were there.. but why would anyone spend his time helping out commercial projects for no gain.. the problem is quite obvious why this can only work in a non profit world (unless you make the service a paid one).

And by the way, an installer can compile things automagically so that it is an entirely smooth operation. NVidia does this with their Linux driver, and when the compiler dependencies are handled by apt, there are really no problems at all.That's bound to change with changes in the kernel, isn't it? There are efforts to stop all non open source drivers such as this.

Installers alone won't solve updates and the unnecessary bloat that comes from shipping shared libraries with every program and then mixing them to DLL hell.Just keep the DLLs in your program path.. in the age of 500GB HDs we can handle a little redundancy. And the richer the API, the less bloat you have to ship with (or a package manager has to download ;) ) And .NET avoids DLL hell alltogether, without needing a package manager ;)

[nm]

Can't... Resist... Posting...

I don't think Linux will ever be a serious contender to Windows on the Desktop until they throw the compartmentalization overboard.
I disagree. Installing software that is available in the common repositories on Debian/Ubuntu is not hard for end users. It is much easier than on any other OS.

A lot of time and effort has been put into making an architecture that's just not meant for a stable system workable, when the much more obvious approach would've been to spend a moment thinking about the architecture instead.
That is too much to ask for when there is no central management. Also, if Linux had a wide, standardized API with slow changes like Windows, there would still be all the other software libraries and apps that depend on each other. In Windows they are just contained in every program that uses them. What if one of the libraries has a security problem? All the programs that use that library need to be updated. And if the developers are not around anymore, some programs might never be fixed. I still don't see anything terribly wrong with the Linux way of managing things compared to that.

But on an average Windows box.. how many software do you have to update every month?How many security holes are there in a month? Of course, a large portion of Windows software (esp. shareware and freeware apps) is not even reviewed. All software in Debian stable is.

The same service could be built up for Windows if the volunteers were there.. but why would anyone spend his time helping out commercial projects for no gain.. the problem is quite obvious why this can only work in a non profit world (unless you make the service a paid one).
There certainly would be such services if more people knew to demand something better (and if there weren't free alternatives). I didn't know when I used Windows in the 90's.

That's bound to change with changes in the kernel, isn't it? There are efforts to stop all non open source drivers such as this.
Even if it would happen in some kernel versions, dropping support for closed-source drivers wouldn't kill support for compiling kernel modules or anything else on the fly. I just brought NVidia in as an example of the possibility, but Gentoo is perhaps a better one. Anyway, blocking closed-source stuff completely is not going to happen as long as people need it. Kernel (and driver) developers are just trying to get the hardware people to open up their code more.

And .NET avoids DLL hell alltogether, without needing a package manager ;)
It must be a warm and sunny day in Utopia ;)

[Doom9]

It must be a warm and sunny day in UtopiaWell.. do you know anything about registering assemblies in the GAC?

Also, if Linux had a wide, standardized API with slow changes like Windows, there would still be all the other software libraries and apps that depend on each other. In Windows they are just contained in every program that uses them. What if one of the libraries has a security problem?That just shows that you're a Linux user.. on Windows the situation that the same library (if it's not a standard library) is used by 30 different applications is quite a rare case. The much more common case is that these programs depend on only common libraries, which in term are updated via Windowsupdate.. even automatically if you like. The broader the system provided APIs, the less use there is to use additional libraries.. you can't deny that (and on the con side.. harder to maintain for the developers.. it's convenient to only have to worry about your own littler corner of the world).

[unmei]

What I'd like to know (and I'm sure stax and Sirber as well), is why there are 9.5% using VfW and why people make their own scripts which is more effort than using a GUI with profiles.

Well at the time i initially decided that i really shouldn't use VDM for encoding any more, there was only MeGUI and something that was not complete/updated at all and i think was actually using the vfw. And the reason i didn't try MeGUI is pretty simple - it's .NET based. For a moment i then thought about writing a GUI myself, but then decided it was too much work in relation to what i need. Then when Sirber and Stax supported x264 i had my batches.

Also contrary to what you said, launching a script is IMO/case less work/stress than going via a GUI. It really comes down to 2 mouseclicks to open the CLI, writing the batch name and CRF parameter (that's maybe 10 keystrokes total), dropping the .avs onto the CLI, hit return and wait. Total mouse movement also is maybe half a screen width at most :) (i have the "open command line here" thingy, so the cli is always at my mouse menu in winExplorer).
Of course the occasional updating or new creation of a batch takes a bit more time, but that is always a good thing to also review my switches and make sure i still know what i use (and why).

Well maybe sometime i feel like playing with GUIs, but certainly not with a .NET one ;)

[Kurtnoise]

For me "other".

With GK modded for the cli.

[nm]

Well.. do you know anything about registering assemblies in the GAC?
Not really, but from what I quickly gathered, it is some kind of a local software registry. This could help DLL hell, if there wasn't the problem with native code that I already mentioned. It also doesn't solve the general problem of dependencies in a case of a wide array of software that exists outside the standardized .NET api. Like Gtk# and friends in Mono. If I install a program that requires Gtk# to run it on .NET, the system doesn't manage this dependency by downloading the needed parts automatically, does it (or if it does, isn't that package management already)? This still requires package management on top of .NET and for a Linux-like open-source system, it is easy to achieve with existing packaging systems.

That just shows that you're a Linux user.. on Windows the situation that the same library (if it's not a standard library) is used by 30 different applications is quite a rare case.
I know. I was trying to reflect the Windows solution to the Linux world to show that your idea of throwing package (and especially shared library) management away would not work, but wrote it the wrong way around. Again, if there was a Windows-like wide API on Linux, it would not be enough. Open source programs would still include code from each other and that is when the issues of code duplication will show their ugly faces.

By the way, it is easy to form a stable API from current Linux libraries. Actually this is pretty much done already in Debian stable, which is released in few year intervals. The hard part would be to get most of the people to use the same distribution. Ubuntu might achieve quite a wide support once it matures. With it the 3rd-party package maintainers only need to update their packages every 6 months. Also, as I already said, Autopackage (http://autopackage.org) is on its way to solve most of the problems that seem to be bugging you (complexity of maintaining custom software for multiple distributions and changing APIs).

The broader the system provided APIs, the less use there is to use additional libraries.. you can't deny that
Of course not. The difference with Linux and Windows is that the Linux "system-provided API" is modular and constantly changing. It can be reduced to the bare minimum of libc, or to the usual installation of all the desktop goodness that is present on every distribution. It is the job of a package manager to give the installed programs whatever they need, and the right tools do their job remarkably well.

[Doom9]

This still requires package management on top of .NET and for a Linux-like open-source system, it is easy to achieve with existing packaging systems.That is always assuming you install the app via package manager and that it's known to the package manager.

By the way, it is easy to form a stable API from current Linux libraries. Actually this is pretty much done already in Debian stable, which is released in few year intervals.Actually.. the forum server uses debian, and the admin has to compile mysql and co manually because you can't just get the latest security-fixed version via apt-get if you're running debian stable, can you? That's the main problem with your "stable api".. when security fixes come out (and they do.. just like they do on windows), because of dependency hell your stable api goes to hell.

@unmei: the megui process would be as follows: start app (= start cmd), drag&drop avs file (= drag & drop to commandline), select a profile (two clicks instead of 10 keystrokes), press queue (= press enter). So in the end it's just as efficient. The same process also goes for audio. So effort wise, they're about the same with no particular advantage on either side (assuming you can handle your ways with scripts.. most people cannot).

Well maybe sometime i feel like playing with GUIs, but certainly not with a .NET one Why? I'm sure you have plenty of other runtimes on your PC that you're completely oblivious about. Like Visual Basic or MFC. Those are just the same "evil" Microsoft utilities you so despise. So to be consistent, please get rid of every mfc dll and VB ocx and stop using those programs.. then at least you'd be consistent.

[Sirber]

Why? I'm sure you have plenty of other runtimes on your PC that you're completely oblivious about. Like Visual Basic or MFC. Those are just the same "evil" Microsoft utilities you so despise. So to be consistent, please get rid of every mfc dll and VB ocx and stop using those programs.. then at least you'd be consistent.M$ dev tools mostly use frameworks and runtimes. Development in Windows is not limited to M$ tools...

[nm]

That is always assuming you install the app via package manager and that it's known to the package manager.
Autopackage, for example, replaces installers used in Windows software. If someone wants to install manually, it is their problem.

Actually.. the forum server uses debian, and the admin has to compile mysql and co manually because you can't just get the latest security-fixed version via apt-get if you're running debian stable, can you?
Not the latest version, that would break the stability, but certainly security-fixed. Your admin is just doing things the hard way. Debian has a very committed security team (http://www.debian.org/security/index.html) that even patches old versions of programs just to keep the packages stable. There should be no known vulnerabilities for more than a few days in any of the 15490 packages on 10 different architectures (http://www.debian.org/ports/index.html)!!!

That's the main problem with your "stable api".. when security fixes come out (and they do.. just like they do on windows), because of dependency hell your stable api goes to hell.
With a strong community behind the product, this won't happen. Debian is a living proof of this.

[unmei]

@Doom9 of course it would take quite some effort to check no software is using one of these "suspect" dlls that already came with windows, but i am halfway positive that i don't use too many programs written in VB. Isn't it that mostly GUIs and other (sorry to say it like that) not so vital software is written in VB. But you are not entirely correct in assuming i only prefer not to install .NET because it comes from microsoft, i do have a java VM installed, but i avoid java programs as well. Undoubtedly an extra reason for avoiding .NET is simply that it comes from a company that has aready a bit much software on my comp (i _do_ like windows, tho, and to some extent visual studio, but that's about it).

[ok, i just realized that is hell off topic - feel free to delete if you think about cleaning the thread up]

[Dayvon]

Come on guys... Seriously there are better things to argue about. I mean, if you want MeGUI you need NET 2.0, it's the price of entry. Get over it or use something else. Obviously there are many other alternatives if that is not a price you are willing to pay.

I hate M$ too, but I need Office to have complete compatibility to my work files, but if not I would use OpenOffice. And honestly, if it wasn't for PC gaming, I'd probably switch to a Linux system. But I don't because giving up HDD space for 2 OS's or giving up the PC gaming is not a price I'm willing to pay. NET 2.0 for MeGUI is a small, negligable price to pay for what you get, even if you hate M$. At least IMHO.

Doom9 and the rest of the team made there choice, and they've written a dang good GUI. Let 'em be.

[Morte66]

Oh, and back on topic I'm currently using MeGUI for MPEG4 because:

- It encodes to h264 and he-aac if I want maximum compression
- It encodes to Xvid@AS5/MP3 in the same job queue, for good compression with wider compatibility
- It can put everything I might want to use (x264, Xvid, AC3, MP3, AAC, HE-AAC, VobSub, SubRip, chapters) into MKV
- It lets me do anamorphic pixel-for-pixel copies without grief
- Glory of glories, it will work from a DVD rip that wasn't made with DVD Decrypter in IFO mode
- I used my bandwidth for the month, so the DLL clash with eDonkey is over for the next two weeks (which is a long time in MPEG4 tool development)

AFAIK, it's the only tool to do all that. And the user interface is not so bad.

Mind you, I only use it 10% of the time. The rest of the time I do DVD backup with DVD Shrink. Quality is usually satisfactory if you strip unwanted streams, single layer DVD-R is cheap enough to throw bitrate away, it takes 3 minutes from disc insertion to prepare the encode instead of 45, it takes 2 hours instead of 20 to do the encode, and the output plays anywhere with a DVD drive.

[stax76]

AFAIK, it's the only tool to do all that.

StaxRip does all this except SubRip in MKV. Since you've posted to the StaxRip topic because of anamorphic problems: since version 0.9.24 there should be no more grief :)


new: Added automatic aspect ratio signaling, it is automatically used for XviD and x264 (not supported by DivX) whenever no resize filter is used. Muxer aspect ratio signaling was removed.

[Doom9]

i _do_ like windows, tho, and to some extent visual studio, but that's about itThe last two (or was it three) versions of Visual Studio do require the .NET framework ;) Windows 2003 has it onboard, Vista will have it onboard and make a lot more use of managed interfaces... there's simply no espacing.. you can stall all you want, unless you're willing to give up Windows, you'll get .NET eventually if you want it or not. I was really disappointed when MS didn't make it a mandatory component of SP2..

[handtruck]

To truly get back on the topic ;)

I started using Megui, read the generated command lines and said "I can do that myself." I now write my own batch files using besweet, x264, and mp4box commandlines. I typically don't do DVD's, but when I do, I use the DGIndex gui, although I know it does have a command line ability (I like to see the video visually, and generating a .d2v usually doesn't take long).

Actually, I just starting using VBA within excel (or the other Office products - it comes with them), which is a neat little tool to use since I don't have visual studio or anything, and just use simple file input/output functions to generate both the avs file and the bat file, because that's really all I need. I just make a command button, click it, select a file, and let the small program do the rest. I know VB isn't popular, but it does the job for small things like this.

[virus]

I've been told RealAnime 4.0 runs fine on wine ;)
If DGDecode, AVIFile and .NET run on WINE, then I'm pretty sure MeGUI would run as well.

Sorry, but that's a point that I can dismiss easily. Running in Linux through Wine has nothing to do with "supporting Linux". Proper Linux support means shipping a tarball or giving access to a source tree that builds on Linux and/or distributing Linux binaries that run natively on the platform. In the case of emulation via Wine, it's really just the Wine developers who are supporting (the APIs used by) your application, not your application supporting Linux.
And no, Wine-based emulation and native support are definitely not the same thing, not even from the average users' viewpoint.

Well, to our defense, those tools are all open source.. if you want something fixed, you can do it on your own.. and it should give you that warm fuzzy feeling since it's free software ;)
No need to "defend" against anything, since I'm not complaining about lack of support or anything like that - quite the contrary, in fact. I think my (little) spare time is better spent updating encoding scripts that I've written and that I know by the heart, instead of studying someone else's application, written in another language and whose code size is probably 1 or 2 orders of magnitude greater than my scripts, or even just making a proper bugreport/feature request for that application.
This way I get the job done, while saving both my and your time... think about the warm fuzzy feeling of *not* seeing threads like "why is MeGUI not updated with latest rev. xyz" or "MeGUI 0.2.2.1 is broken" yelling at you when you come back home after work ;)

Linux' main problem is that it has no multimedia framework built-in.There's little "built-in" in the Linux kernel itself, since GNU/Linux is a complete system where every component can be inserted at your wish... the "built-in" attribute has no real meaning in the Linux world. "Built-in software" is what your distro provides... and every distro provides a different selection of varying size. There's GStreamer, there's mplayer/mencoder, and a lot more. What is not built-in is customizable. Different philosophy altogether.

That's kinda offtopic, but if we want to refer to Windows, then there's a whole lot of stuff which isn't "built-in": an office suite (Office is a separate product), a development framework (VS2005 doesn't come preinstalled afaik), a whole lot of standard system utilities doing almost everything, from regexes-based searches, to complex file manipulation/search, as well as talking with other OSes (no support for reading ext2/ext3/reiserfs/HFS+ partitions) or just managing your hardware (can you mount an ISO without Daemon tools?).

Windows API are slow changing and anything that's in it, you can assume most people have.
Fast evolving APIs that provide full backwards compatibility are as useful as "slow changing APIs that most people have". By the way, DirectX is an all-important system API (to the point that Vista's GUI will be fully built around it), yet DirectX is not slow changing nor backwards compatible in several areas.

[stax76]

The last two (or was it three) versions of Visual Studio do require the .NET framework Windows 2003 has it onboard, Vista will have it onboard and make a lot more use of managed interfaces... there's simply no espacing.. you can stall all you want, unless you're willing to give up Windows, you'll get .NET eventually if you want it or not. I was really disappointed when MS didn't make it a mandatory component of SP2..

I was reading Mono was included in Fedora in some tech news titled as 'Hell freezes over...' and a year ago RedHad was the strongest opponent to Mono. I don't know what distributions include Mono as part of the default install, does anybody know?

[unmei]

The last two (or was it three) versions of Visual Studio do require the .NET framework ;)
That's why i "sacrified" one computer for the coding for school including a new visual studio and updated java with eclipse and what not =D.

As for vista, well from the new "features" i am aware of so far (i really didn't dig into that, just the internet background noise) vista only makes me think "please let me use my old windows for as long as possible"
..well, we'll see how long i will keep thinking like that once i have used it a few times :scared:

[madoka]

I voted for "batch, script", as I wrote a small bit of Perl to do what I needed before I discovered MeGUI. I'll probably switch to MeGUI eventually.

My 2 cents in the .NET debate: I agree that there's nothing wrong with using .NET in Windows (sure beats using MFC or the native APIs). But saying .NET is an ECMA standard (so it is in principle portable) is disingenuous. C# and CLI (no, the other one) are standardized, but other parts of .NET are not (such as WinForms which I assume MeGUI uses).

I think C# is a good language, but no one write useful programs that depends on just the core language. Of course, this is true for most any language. However, using Java as an example, one could also be confident that the Foundation classes are available in many platforms, as it's in Sun's best interest to do so. In contrast, Microsoft clearly don't have any intention of porting .NET to any non-Windows platforms. Although the Mono project is working on reimplementing WinForms, there are no assurances that MS won't sue Novell once it becomes mature enough. (A similar parallel can be drawn about gcj). So .NET really is de facto a Windows-only solution.

In summary, there are no reason to avoid .NET on Windows when portability is of little concern. However, its dependencies are more intricate than just that programmers are lazy.

[Sirber]

.NET (C#) can be compiled with mono and run on linux. It is portable.

[nm]

Source code portability is not new. Same can be achieved with C/C++ if you just use libraries that are available on all the target platforms. And concerning the available libraries, .NET doesn't really do much better than others, like madoka pointed out once again. Binary (or bytecode) portability is nice for some people, but binaries won't work without the full set of libraries either.

[Sirber]

I win!... by 6.8% :D

[siddharthagandhi]

You forgot Super.

[stax76]

You forgot Super.

Only ten options are possible.

[siddharthagandhi]

I'm checking out RealAnime it seems like a good application.

First off, I get a lot of errors and problems and more error messages when using MeGUI, I can't get one problem-free encode. For StaxRip, it would be nice if there was a version that would contain everything and would update automatically so I don't have to mess with everything. And not only update automatically but keep all the settings hidden. I just want a plain interface, with an input file, output file, codec, and bitrate. Real Anime seems to do that, but its still downloading so I can't check it out. For now I'm using Virtual Dub because i dont have .NET Framework installed and its too big to download on dialup, once I get DSL i'll download it.

[LoRd_MuldeR]

I'm checking out RealAnime it seems like a good application.

First off, I get a lot of errors and problems and more error messages when using MeGUI, I can't get one problem-free encode. For StaxRip, it would be nice if there was a version that would contain everything and would update automatically so I don't have to mess with everything. And not only update automatically but keep all the settings hidden. I just want a plain interface, with an input file, output file, codec, and bitrate. Real Anime seems to do that, but its still downloading so I can't check it out. For now I'm using Virtual Dub because i dont have .NET Framework installed and its too big to download on dialup, once I get DSL i'll download it.

Had a look at this (http://forum.doom9.org/showthread.php?t=108934) one? :D

[Sirber]

It's sad mencoder can do AAC HE and AAC HE+PS, nor MP4 and AAC ;)

[LoRd_MuldeR]

It's sad mencoder can do AAC HE and AAC HE+PS, nor MP4 and AAC ;)

Yes it's sad. But everything has it's advantages and disadvantages.
I like it, because it's an "all-in-one" tool and does everything in one step.

However MP4 output is already possible via "-of lavf". It only doesn't work properly yet...

[siddharthagandhi]

Yo man my computer is screwed up or something, because no matter what application I use, MeGUI, StaxRip, RealAnime or Virtual Dub I cannot encode 2 pass for xvid or x264...it just gives a corrupted video file

[Sirber]

run memtest86+ and see if your RAM is bad.

[siddharthagandhi]

I tested all of the encoders, including RealAnime, StaxRip, and all of that, and MeGUI suddenly works perfectly and it gives great encodes so I'm sticking with that

Its not like i actually use Xvid (Nero Digital all the way) or x264 (that codec doesnt give me good results for my Halo fraps captures) so I don't need these programs, but just in case

[SvenBent]

Fairs use wizard

have use the program back from the divx 3.11 days.
cant seem to let it go.

[Sirber]

does it supports AAC PS and AVC?

[SvenBent]

it suppory x264
but the audio still must be either the "raw" ac3 or recompressed to mp3 and vorbis.
no AAC support :-(
i have to do that manually

[celtic_druid]

It uses VfW and outputs avi or ogm. So basically you would vote for "other VFW" if you use FU.

[damrod]

so many gui :p

i vote others because i use mine...i like to switch in batch encoding between different codecs (audio and/or video)

[siddharthagandhi]

I have encountered a problem. I exported from Nero Vision a DV file Type 2....and even though I have ffdshow installed and the file plays in media player, when i do avisource, directshowsource, or any source, the file is unable to be opened, and the codec (dvds or something like that) is not found (thats the error message).

What do I do?

[b9AcE]

I use MeGUI for the actual encoding and for the source detection (interlaced/progressive).
But before I start MeGUI I do the croping/sizing/resolution-selection in GordianKnot.
Then I merge the AVISynth-script I get from MeGUI with the stuff I got from GK and load that script back into MeGUI.

It is a hassle, but the cropping/sizing stuff is sooo much easier in GK and I do want BPP calculated for me even if chronocrossdev will think I am an idiot for even looking at those numbers... ;)

Apart from this combo, I think StaxRip looks pretty nice, but it's too hard to get it into working shape when there is no Internet connection close by.
Would be more appealing to me if it was packed up into just one complete installer.

[stax76]

Apart from this combo, I think StaxRip looks pretty nice, but it's too hard to get it into working shape when there is no Internet connection close by.
Would be more appealing to me if it was packed up into just one complete installer.

It supports about 25 applications, DivX alone is about 15 MB, a all in one package would easiliy end up 40 MB. Maybe you can post to the StaxRip support topic what exactly you think is hard, StaxRip is supposed to easy.

[SeeMoreDigital]

Apart from this combo, I think StaxRip looks pretty nice, but it's too hard to get it into working shape when there is no Internet connection close by.
Would be more appealing to me if it was packed up into just one complete installer.For me... this is one of the aspects I like about StaxRip!

It only loads what it needs, when it needs it ;)

[siddharthagandhi]

I think there is a bug in the forums. I posted my previous post in the StaxRip Support thread, and somehow it ended up here. Could a mod look into this? I swear, I was looking at the StaxRip thread and I posted and it ended up here....

[sake42]

i was using megui before
but now i'm using x264gui it's like encoding by CLI but without need to post commands each time you encode