MeGUI development

[dimzon]

If I were to suggest a "big" architectural change, it would be to eliminate all of the conditional compilation. Even if a user is only interested in the x264 or Snow features, it's not like the full MeGUI is more difficult to use than the special versions. Meanwhile the extra bugs, developer time, and (necessary but lacking) testing that come from separate versions affects everybody.
Agreed by 100% !!!
Let's remove conditional compilation!

[Sharktooth]

well, x264 conditional compilation is needed by my x264 and bobor's builds.
Just give us some time to integrate the full MeGUI before removing x264 CC.
However it would be much better if the x264 CC will remain.

[dimzon]

Because it breaks things. Every encoder I add, I have to take care of all possible consequences. Let me give you an example: if I could just plug in any video encoder, I could add my xvidencrawvideoencoder. However, that encoder can only output raw files... MeGUI is painfully obvlivious of that and will offer mkv/mp4/avi output.. while the output files may just be named like that, they are indeed renamed raw files. S by making sure I get to see every encoder and write the full workflow for it, I can ensure that people can only try to do what makes sense. Asking for avi from xvid_encraw makes no sense.
...
Add Ogg Vorbis.. affects container selection and bitrate calculation.

It means encoder must provide list of supported formats and MeGUI must handle it! I does not say - whe must support ANY format, i just say - we can support wide set (raw, mkv, mp4, avi) and every encoder must provide supported subset...


Please do show a better way
Polyphormism

You are mistaken. In fact, you could create an x264 job with a mencoder commandline, then if you change the x264 encoder to x264.exe in the settings, then try to start it.. it will try to send that job to the x264.exe commandline encoder ;) ...
This means - invalid architecture! Definitly You must use 2 different job types - one for mencoder another for x264 :)

And it does.. they're called properties. The GUI has to decide which date it wants to show.
Yet again - MeGUI has multiple ugly if(zzz is TypeName) here!

If you look at the queue, you have the codec type, and a lot more information about input/output/state/etc.. so yet, it's very informative.
Hey, i dont's say nothing about overall joblist! I just say jobname itset is not informative - it does not hold any sensitive information! So you does not need it except for management - so you can switch from jobname to jobID - so you can implement editable job titles to allow user mark some jobs :)

PS. Why nobody except Doom9 don't support this discussion?

[berrinam]

Did I miss something on the One-Click mode? Sorry about that, I'll take a look at the changes you made with a DIFF and make sure the same problem doesn't occur again when I add the subtitle names.
Well, I don't think that it is likely to be a problem with subtitles and OneClick (OneClick will probably never support subtitles), but it may occur with the AutoEncode mode. Have a look at the change I made to the generateMP4BoxCommandLine in version 2009 (the bug caused by the AutoEncode window). Basically, if you just check wethere they are null before checking their length, it should be fine. (Mind you, as adding subtitles in AutoEncode requires the Mux Window to be opened, you should check to make sure that the AutoEncode window also supports track names).

Cheers, berrinam

[Sharktooth]

CVS Update:

0.2.3.2011 11 Jan 2006
Enlarged the MeGUI-x264 video profile combobox in the main Form.

Sources: http://files.x264.nl/?dir=./Sharktooth/megui/Sources

[Doom9]

It means encoder must provide list of supported formats and MeGUI must handle it! I does not say - whe must support ANY format, i just say - we can support wide set (raw, mkv, mp4, avi) and every encoder must provide supported subset...I know you'd say that and I'm tempted to say over my dead body now. This is not the architecture I want to create. With each amount of flexibility you introduce, you complicate matters two, three, fourfold and I just don't have time to handle that. The architecture you want is about a 100 times as complex as the current one, making it virtually impossible for anyone to figure out how it works unless he's devised that architecture.

PolyphormismI said a working example.... throwing fancy words at me is not way to make a point. You can take a look at the source I posted very early this morning.. most code doesn't use that many levels of inheritance, yet there are still parts that need to be common but cannot be put in a common class. E.g. the setup in the various commandline encoders.. linking the event callback is an operation that has to be done prior to starting the process or you'll miss the first few commandline outputs. So, here you have your chance to make your point with those classes...

This means - invalid architecture! Definitly You must use 2 different job types - one for mencoder another for x264Actually, the new code can handle this just fine.. and it's all still one job type. It's up to the videoencoder to decide what kinda VideoJob it is and how it's to be encoded. I know you can twist that by 180 degrees and have all the logic in the job, but frankly I don't like that approach. If we take cars and drivers instead of encoders and jobs, your approach means the drivers has to know how the motor of the car needs to work... my approach with the intelligence in the encoder means the driver gets in, turns the key, and drives off.. the car does a lot under the hood that the driver never has to be bothered with.

Yet again - MeGUI has multiple ugly if(zzz is TypeName) here!In case of a job, that is a sideeffect of the upbringing of MeGUI.. it can be changed there. But please give an example of job dispatching to the encoder. Say you have a Job, and a JobHandler. So you pick a job from the queue, send it to JobHandler and tell it... process this. Let's further assume that the Job is of type VideoJob. So at some point, the JobHandler needs to figure out what kind of job it is to send it to the proper class for encoding (a class deriving from VideoEncoder in this case). How other than if (job is VideoJob) are you going to figure that one out? You could to a switch(job.JobType) so you don't use the is command, but it's essentially the same. And you could argue that the JobType property is in fact not necessary because the type can be derived from a Job via (job is OfTypeX).
The only way I see to not do any of this identification, is if a job knows how to encode itself.. and then we're in the situation of the car that knows how to drive itself. There's another way, and that's the job returning the encoder, but that's essentially the same approach.. car knows how to drive itself.. and if it cannot, it spits out a driver via the exhaust so that the driver can do the driving.

so you can implement editable job titles to allow user mark some jobs I completely and utterly fail to see the point of that. You can easily identify jobs with all the info you have in the queue, changing names just a way to introduce more hassle, starting with editable listviews, how you're going to assign names in a mode that returns multiple jobs, hassling the user to come up with names after indexing (keep in mind how one click works.. there's first one job.. then after indexing more are added)..

[dimzon]

With each amount of flexibility you introduce, you complicate matters two, three, fourfold...
I believe Your opinion is wrong. Just take look @ .NET Framework itselt architecture - it's fine, flexible and easy to use!

But please give an example of job dispatching to the encoder. Say you have a Job, and a JobHandler. So you pick a job from the queue, send it to JobHandler and tell it... process this.


void StartJob(Job someJob)
{
m_jobExecutor = someJob.CreateExecutor(); // Create executor
m_jobExecutor.StatusUpdate += ...; // Attach universal simplified event handler
m_jobExecutor.Priopity = m_priority; // Setup initial priority
m_jobExecutor.Start(); // Start processing!
}

Simple and elegant, isn't it?

is if a job knows how to encode itself.. and then we're in the situation of the car that knows how to drive itself.
No! Car don't know how to drive itself but it know how it works! MeGUI tell to Job "Start" and job starts. MeGUI tell to job "Abort" and it aborts :)

[Doom9]

Just take look @ .NET Framework itselt architecture - it's fine, flexible and easy to use!I've never looked at the source, but looking at how painful making a good GUI and creating controls that are standard in todays programs is, I dare doubt your statement. E.g. a good treeview with drag and drop, as it standard in Windows Explorer... it's a major pain in the ass unless you buy a pre-made component. Or another thing are listviews that are searchable by typing.. standard behavior in many windows programs.. yet you need to derive your own controls and extend them to get done what imho should already be available as pre-built components. I've been coding with C# for two years now but I hardly ever build derived components, and it's just the standard inheritance for forms, nothing more.
Simple and elegant, isn't it?Just as I feared, you want to make the care aware of the driver. It shouldn't be.

And by the way, image signatures are no longer enabled so you can safely remove those urls from your signature.

[dimzon]

Does anybody can connect to CVS via anonimous login? I can't
No tag specified for Export, using HEAD

In C:\Documents and Settings\DAlexandrov\My Documents\Visual Studio 2005\Projects\MeGUI: "C:\Program Files\TortoiseCVS\cvs.exe" "-q" "export" "-r" "HEAD" "MeGUI-src.CVS"
CVSROOT=:ext:dimzon@cvs.sourceforge.net:/cvsroot/megui

cvs export: failed to create lock directory for `/cvsroot/megui/MeGUI-src.CVS' (/cvsroot/megui/MeGUI-src.CVS/#cvs.lock): Permission denied
cvs export: failed to obtain dir lock in repository `/cvsroot/megui/MeGUI-src.CVS'
cvs [export aborted]: read lock failed - giving up

Error, CVS operation failed



In C:\Documents and Settings\DAlexandrov\My Documents\Visual Studio 2005\Projects\MeGUI: "C:\Program Files\TortoiseCVS\cvs.exe" "-q" "checkout" "-P" "MeGUI-src.CVS"
CVSROOT=:pserver:anonymous@cvs.sourceforge.net:80/cvsroot/megui

connect to cvs.sourceforge.net:80 failed: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
Success, CVS operation completed

[Sharktooth]

Try several times :)
However a copy of the latest sources is here: http://files.x264.nl/?dir=./Sharktooth/megui/Sources

[stax76]

I've never looked at the source, but looking at how painful making a good GUI and creating controls that are standard in todays programs is, I dare doubt your statement. E.g. a good treeview with drag and drop, as it standard in Windows Explorer... it's a major pain in the ass unless you buy a pre-made component. Or another thing are listviews that are searchable by typing.. standard behavior in many windows programs.. yet you need to derive your own controls and extend them to get done what imho should already be available as pre-built components. I've been coding with C# for two years now but I hardly ever build derived components, and it's just the standard inheritance for forms, nothing more.

Regarding missing winforms bits, I know what you mean just to good. I had to implement lot's of that missing bits, great help was stuff found at CodeProject or somewhere else. In the beginning it can be rather painful, lot's of stuff requires knowing the framework internals (use Reflector, it outputs C# code almost as good as the source), knowing the Win32 API (read Petzold) or simply subclassing and owner drawing but once you get the hang of it most stuff can be done easy. Let's hope once WPF (codename Avalon) arrives Microsoft will still be committed to winforms.

[godhead]

Hmm.. did I never change that? At least the video commandlines are all generated by a StringBuilder.. feel free to change the muxing commandlines as well, it definitely makes sense.[/QUOT]

I didn't look at the video command lines, but I'll go ahead and make the changes to the muxing command lines.

[QUOTE=Doom9]Which keyboard shortcut?

in your code window type: prop (by the time you type the pr) your code complete window should be on the prop item, now press TAB twice and it will stub out a private member and property get/set for you. You can then use TAB to go between each of the portions that you need to change. VS2K5 has added a bunch of these code snippets.

Here's more information about code snippets and how to use the right click context menu to add snippets or surround code with snippets. Also includes instructions ont he snippet XML schema and how to create your own.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/codesnippets.asp

This article has a short list of the built-in snippets.

http://www.developer.com/net/net/article.php/11087_3557701_1

[DeathTheSheep]

Woah, um, about the "Quantisation" tab in the MeGUI x264 settings page...
Who's in charge of the spelling around here?? :D

[Doom9]

more trouble with that void StartJob(Job someJob)
{
m_jobExecutor = someJob.CreateExecutor(); // Create executor
m_jobExecutor.StatusUpdate += ...; // Attach universal simplified event handler
m_jobExecutor.Priopity = m_priority; // Setup initial priority
m_jobExecutor.Start(); // Start processing!
}
What do you do after that? An Indexing job has extensive postprocessing. In the simple case, it's just opening another window.. it then goes over loading demuxed audio tracks into the GUI, and ends up with automatic cropping, resizing, AviSynth script creation (based on profiles), audio, video and mux job creation.. so something must be very aware of the different jobtypes.. you can't just abstract everything. And since two video encoders are allowed for the same job, you can't abstract that either.. somebody needs to be there and say "okay, here's an x264 job, let's check the settings to see which encoder we're going to take".

When an audio job ends, it's not just up to a JobProvider to get the next job and a JobExecutor to execute the next job.. the next job can depend on the finished audio one, so the video job has to be consulted for a desired filesize, and for a desired final output size, then the audio size has to be gotten, bitrate has to be recalculated, in function of container and codec (xvid bitrate calculation is different because at least in case of mencoder it includes the container overhead), then the commandline has to be regenerated.

[Doom9]

About CSV: how do I get tortoise to store my password?
And can anybody enlighten me regarding the release process? I don't suppose that has anything to do with the CSV at all, does it but instead you have to download the latest code, build and upload that separately, right?

[berrinam]

Find out about storing your password from the TortoiseCVS FAQ: http://www.tortoisecvs.org/faq.shtml#sshkeys

I have no idea about releases, as I am not an admin and I can't do them.

PS. It's CVS, not CSV

[Doom9]

PS. It's CVS, not CSVArgh, I always get that wrong. But it's a shit system anyway.. now I'm stuck with a bunch of files that I can't upload... CVS conflict my ass.. my worst fears come true right away.

[Doom9]

new build is up. Changelog:

0.2.3.2012 12 Jan 2006
Completely rewrite the video encoder part. Should be less error prone, return more commandline feedback and it supports xvid_encraw
xvid_encraw support: For now, only raw and mp4 output will work properly because encraw can only output raw. Automated bitrate calculation will be
off because mencoder takes container overhead into account for xvid.. encraw won't (and it uses bit/s for the bitrate but that's handled)
Please test encraw in manual mode and report how it works
Removed various .Net 1.1 workarounds that are no longer needed and code that would cause warnings in .NET 1.1
Commandline generation has been changed for the video part to not include the binary name.. this allows the latest executable path to be used for encoding

0.2.3.2011 11 Jan 2006
Enlarged the MeGUI-x264 video profile combobox in the main Form.

I spent at least two hours for this release instead of the usual 10 minutes or so. Did I mention I hate CVS? I basically had to redo the code for a bunch of classes (all GUI classes incidentally).

[bob0r]

If i only wasn't so lazy and unskilled to install SVN on files.x264.nl :rolleyes:

[Richard Berg]

I wonder if the TFS MSSCCI (http://blogs.msdn.com/bharry/archive/2005/12/29/507993.aspx) plugin will work with VS Express...

[Doom9]

what would make SVN better (other than speed perhaps.. the speed of sourceforge is abysmal)? CVS chockes big time with GUI files, and I just have a feeling it has something to do with conditional compilation.. the diffs didn't look that much different, just the whole conditional stuff moved around a bit.. and my changes were really minor (like 2 or 3 lines only in many cases.. I had to adapt the commandline preview because the new video encoders only take the commandline parameters from the commandline parameter, the encoder path is given to them seperately)

[buzzqw]

the build "0.2.3.2012 12 Jan 2006" crash on start

while previus build 2010 is full fuctional

BHH

[dimzon]

I still can't start any work: http://forum.doom9.org/showthread.php?p=766164#post766164

And conditional compilation is breaking VS2005 code analyzer and refactoring, let's remove conditional compilation ASAP

[Doom9]

let's remove conditional compilation ASAPThat will never be fully possible. For starters, there's the CSC flag which is needed to make builds from the commandline (why there is a difference on how resources that are compiled in are handled between VS and csc I don't know, but it's a fact that they're different and that #if is needed to support both), then there's the SVN vs custom x264 build angle. I have no quarrel removing the snow build but I'm not so sure about the x264 one.

[Sharktooth]

what would make SVN better (other than speed perhaps.. the speed of sourceforge is abysmal)? CVS chockes big time with GUI files, and I just have a feeling it has something to do with conditional compilation.. the diffs didn't look that much different, just the whole conditional stuff moved around a bit.. and my changes were really minor (like 2 or 3 lines only in many cases.. I had to adapt the commandline preview because the new video encoders only take the commandline parameters from the commandline parameter, the encoder path is given to them seperately)
The revisioning system. It's much easier to manage and more functional.

However i updated the setenv.bat for .NET 2.0

[berrinam]

@dimzon: Perhaps you could persuade one of the MeGUI project admins to give you developer CVS access.

[Sharktooth]

CVS Update:

0.2.3.2013 12 Jan 2006
Updated Setenv.bat for .NET 2.0
Fixed all warnings in SettingsForm.cs for x264 conditional compilation


@Doom9: i can elaborate a method for identifying the x264 build and enable/disable different options so conditional compilation of x264 and x264 svn can be merged.

[Doom9]

@Doom9: i can elaborate a method for identifying the x264 build and enable/disable different options.But when do you do that? I mean it would have to be done upon loading of the program, at which point the x264.exe executable may not have been defined yet. And I don't see why you should have the executable defined until the point you're actually going to start encoding. Of course you could block all features unless properly configured, which may actually help n00bs, but which makes our lifes a lot more complex.. I may work on features despite being unable to use them with the current configuration.

Updated Setenv.bat for .NET 2.0I have never used that file.. I can build just fine with the latest compile.bat and calling nothing else.

[Sharktooth]

well... the latest compile.bat is not the "right" way to do things:)
just create a shortcut with this target:
C:\WINDOWS\system32\cmd.exe /k ""drive:\megui_sources_directory\setenv.bat""
and you will have a command prompt with all the variables set (set the correct path):
csc.exe and the other commandline compilers will be in the OS PATH, libs and includes paths will be defined, etc...

[Doom9]

csc.exe and the other commandline compilers will be in the OS PATH, libs and includes paths will be defined, etc...But you need nothing if that.. in compile.bat we have the path to a normal .NET 2.0 installation.. it will always be at that path regardless of whether you install just the runtime, sdk or even visual studio.. There's no need for include paths and the likes, to specify where the libraries are, nothing of that sort.

[Sharktooth]

But when do you do that? I mean it would have to be done upon loading of the program, at which point the x264.exe executable may not have been defined yet. And I don't see why you should have the executable defined until the point you're actually going to start encoding. Of course you could block all features unless properly configured, which may actually help n00bs, but which makes our lifes a lot more complex.. I may work on features despite being unable to use them with the current configuration.
when setting the x264.exe path in the configuration.

But you need nothing if that.. in compile.bat we have the path to a normal .NET 2.0 installation.. it will always be at that path regardless of whether you install just the runtime, sdk or even visual studio.. There's no need for include paths and the likes, to specify where the libraries are, nothing of that sort.
Ok. However i just use that way... and worked with both the old and new compile.bat with both NET 1.1 (with the old setenv.bat) and 2.0 without any problems

[Doom9]

when setting the x264.exe path in the configuration.So you start the GUI, go directly to the x264 configuration, configure a non SVN feature, then configure the x264 path to a svn build, which limits the GUI, but the job is already there, so when you start the job you have the usual "unrecognized commandline" error. Even worse, if after configuration of the executable, you go back to the settings, the program will crash because the subme dropdown only has 6 entries now, not 7.

[Richard Berg]

For starters, there's the CSC flag which is needed to make builds from the commandline (why there is a difference on how resources that are compiled in are handled between VS and csc I don't know, but it's a fact that they're different and that #if is needed to support both),
Use MSBuild instead of calling csc.exe directly.

then there's the SVN vs custom x264 build angle.
I don't think we need to work so hard to prevent users from selecting options that are incompatible with their encoder. Conditional compilation, tri-state, avc levels, etc. -- these have been the source of many bugs, several of them far worse for the user than a mere x264 error message. Most n00bs will use premade profiles.

Alternatives:
- nice friendly tooltips for options that won't work with standard SVN compiles
- package a few (not all; too many = confusing) of Sharktooth's profiles with main MeGUI releases
- like we did with "validate avc level", move all tricky to a menu choice like "validate encoder parameters", i.e. the user has to ask us validate instead of us doing it behind the scenes after every change
- even better: instead of replicating all of x264's logic ourselves, have "validate encoder parameters" call x264 with dummy input/output files and parse the log for "unrecognized commandline" errors
- I'm sure there are other solutions

[ShAQ]

Bug:
Missing dot (".") in Status Window.
http://img314.imageshack.us/img314/1774/zwischenablage011wy.png

Found in build 0.2.3.2012

[Doom9]

Missing dot (".") in Status Window.Where do you expect a dot? And where's the logfile? What's the locale of your windows, what's the comma separator on your windows, how does commandline output look if you run the encoder commandline from an actual commandline?

[Doom9]

@dimzon: here's the latest CSV checkout: http://forum.doom9.org/MeGUI-src.CVS.rar

I've never used anonymous CVS and I have no time to make tests for you.. CVS is more than a major pain in my butt already and it took me quite a while to get the whole thing set up..

[berrinam]

CVS Update:

0.2.3.2014 13 Jan 2006
Add Autmatic interlace detection in Avisynth window and OneClick

[berrinam]

CVS Update:

0.2.3.2015 13 Jan 2006
Apply Richard Berg's Progress Status menu item patch (makes it checkable, like VDub)

[charleski]

Does anybody can connect to CVS via anonimous login? I can't
No tag specified for Export, using HEAD

In C:\Documents and Settings\DAlexandrov\My Documents\Visual Studio 2005\Projects\MeGUI: "C:\Program Files\TortoiseCVS\cvs.exe" "-q" "export" "-r" "HEAD" "MeGUI-src.CVS"
CVSROOT=:ext:dimzon@cvs.sourceforge.net:/cvsroot/megui


You're using export? That may be the problem.
Just use Checkout to set up the files, Update to grab the latest versions later on, and Commit to send your changes back to the CVS repository.

SourceForge is slow at times, but that may be related to the fact that's it's free, despite having an international network of servers and a deep integrated backup system. After setting up the SSH part all I needed was 30 mins of RTFM with TortoiseCVS, so I'm not sure why people are having problems.

[charleski]

Exactly as Charleski said (a disabled checkbox that's checked has still a "checked" value but it cant be edited = forced). However we have different needs so we may stay away from the MS guidelines for a better usability.
I've been away for the past few days so couldn't check the board, but it looks like I need to reinforce the point. GUI standards are as important as standards anywhere else. GUI elements are supposed to work in a consistent manner across applications, we aren't working in a vacuum. Users have a right to expect the application to function in a similar manner to other tools that they run, and using the Enable property to double-up for Checked is a severe violation of that. Also, the GUI is not a memory. If you want to store a collection of settings for future reference, there's the profile system that can do exactly that. It's not unrealistic to expect users to realise that the Profile (Baseline, Main or High) and Level are important decisions that should be made first before you go twiddling other options for the encode.

Breaking GUI standards is just setting yourself up for a bunch of 'WTF's going on?' support posts further down the line and isn't worth it for the minimal returns it offers.

[Richard Berg]

I had problems with anonymous CVS the past few days -- I even posted to the tortoisecvs-users DL. Whatever was wrong, it works now.

[berrinam]

Another architectural query: why does MeGUI store currentX264Settings, currentLavcSettings, etc, and access these through huge if statements, when the current settings could be accessed through ((VideoProfile)videoProfiles[videoProfile.SelectedItem]).Settings It seems to be a little bit left over so that you can configure the settings without a profile, but the moment you have any profiles, this doesn't happen. As a result, it almost always is useless, and it clogs up the code (similarly with audio profiles). Can this be replaced?

[berrinam]

0.2.3.2016 13 Jan 2006
Add support for Drag 'n' Drop


Also added an Open menu item in the file menu, which uses the same code as drag'n'drop.

[foxyshadis]

If you really need GUI standards conformance:
Since disabled mode always means "unusable", why bother with a "disabled but checked" state at all? When updating the GUI to a more restrictive mode, uncheck anything about to be disabled, and when bringing it back to a mode that enables them, check whether they're supposed to be checked and recheck them. Then you still only need tristate, and shouldn't need to muck with actual tristate code much.

This is presuming your event handlers to change the internal options are for clicking the box, not for the box's state changing. If not, perhaps there's a way to disable it during the update?

[Yay! Drag & Drop!]

[Richard Berg]

Another patch attached. New features:
- context menu for queue (supports multiselect :))
- loading a video or audio job now switches to the Input tab

We should continue to debate massive refactoring if it's needed for big new features like audio filtering. Personally, I only refactor when something's actively annoying me. For example, the code cleanup in this patch:
- changed all job status variables from int -> enum JobStatus, eliminated all casts
- changed 'jobs' from old style Hashtable -> generic Dictionary<string, Job>, eliminated all casts

[sillKotscha]

Where do you expect a dot?

I'd say 677fps are not bad :D

[Doom9]

- changed all job status variables from int -> enum JobStatus, eliminated all castsurgh.. and I just did that on my own.. I expect another very painstaking commit process coming my way :( :( :(

It seems to be a little bit left over so that you can configure the settings without a profile, but the moment you have any profiles, this doesn't happen. As a result, it almost always is useless, and it clogs up the code (similarly with audio profiles). Can this be replaced?I often don't use profiles. If you see a better way, I'm sure I could warm up to it, but I don't want to force profiles on the users.. looking at the early days, most people didn't even realize there is such a thing as profiles.

By the way, does anybody know why when I did a CVS update on my whole directory, it didn't pick up all the new files and changes that berrinam recently added? I had to rever to my latest commited build (safely stored away.. fortunate for me) to start with ripping apart the muxer and implement it like the video encoders (as a stopgap.. the next thing is one more level of generalization).

[dimzon]

You're using export? That may be the problem.
Just use Checkout to set up the files
I'm trying both with same result. Every time I trying to get sources via anoninous access I get
A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
and I can't get sources via developer access (i get ACCESS DENIED)

@dimzon: here's the latest CSV checkout: http://forum.doom9.org/MeGUI-src.CVS.rar

I've never used anonymous CVS and I have no time to make tests for you.. CVS is more than a major pain in my butt already and it took me quite a while to get the whole thing set up..
Please add me to project administrators...

[Doom9]

- changed 'jobs' from old style Hashtable -> generic Dictionary<string, Job>, eliminated all castsNeat.. while we're at it.. what posessed them not to make a typed ArrayList? I mean come on.. that's the feature I fell in love with in Java 1.5... typed Vectors, and the .NET equivalent would be an ArrayList. Why oh why can't I create an ArrayList<int> or ArrayList<Job>? That's the one feature in .NET 2.0 I've been looking forward to the most.

[stax76]

List<T>