MeGUI development

[Doom9]

your refactoring using the IJobProcessor interface means that vEnc, aEnc, muxer, indexer can all be put into one variable -- processor.Yup, that's definitely the plan. The main form should only link the buttons to the appropriate processor commands.

Should this be distributed?Yup. For the PSP I guess we could define a virtual level which is a combination of actual buffer requirements and resolutions compatible with the PSP. And once encraw is up to the task and I add levels there as well, we can do the same for xvid.

It is harder to see exactly if there is any black on one side of a line (your approach) than if there is any black at all.I second that. Initially, I thought about just drawing a line over the video like VDub, but thinking of how hard it is to take arbitrary rectangular screenshots with the line rectangle, I opted for blanking out everything that's going to be cropped away.

[dimzon]

my main beef with having everything in one window is that crop values and preview don't necessarily go together.
100% Agreed. It means we must keep crop controls & AvsGenerator form BUT allow opening CropDialog with it's own crop controls (We can combine this 4 Numeric UpDown in custom control for better reusing)

You apparently are more used to VDub which explains your liking of that approach.
Actually I'm using VirtialDub for cropping only. I'm opening uncropped AVS via VD, then going to cropping, perform visual cropping and coping crop values to my script back...

But let's not forget that in VDub, once the dialog disappears, so does your opportunity to make any further changes.
You can open this dialog again && it will "remember" it's cropping values. Just only one think you lost is current frame. My CropDialog does not complete yet (development is frozen && i'm waiting for Doom9 decision) so it does'nt do it...

I second that. Initially, I thought about just drawing a line over the video like VDub, but thinking of how hard it is to take arbitrary rectangular screenshots with the line rectangle, I opted for blanking out everything that's going to be cropped away.
Seems like You && berrinam take my CropDialog as comlete solution. But it still incomplete, I know about odd cropping for YV12 and it's no problem to replace blue lines by white regions (we can even add checkbox right @ CropDialog ;) )

[stax76]

And it's also important to point out that my approach comes from GKnot.. people with a GKnot background are used to it. You apparently are more used to VDub (which I've given up on ages ago.. except for VfW encoding I do nothing in VDub anymore) which explains your liking of that approach.


It's just too obvious where both approaches are derived ;), personally I don't have high requirements regarding advanced crop features and also did't had/denied too many advanced crop requests (don't recall anything I could understand and reproduce) and I didn't get much positiv or negativ feedback about the cropping feature. I like to do things quick and easy which I achieve by mouse hovering, clicking, dragging and wheel, needs some habituating but then I think it's fun.

[dimzon]

0.2.3.2060 31 Jan 2006
Commit by dimzon:
-Using NicMPASource instead of MPASource in AviSynthAudioEncoder.cs

[Inc]

I had cleaned up the suggestResolution method, and documented the algorithm for calculating the Sample Aspect Ratio (which is, as I see it, a stretching amount, when taken as a fraction, sarx/sary). As I said earlier, I believe the problem with all of this is that only x264 uses sarx and sary -- I think lavc uses an overall ratio like DAR, which prescribes the ratio of displayWidth / displayHeight. SMD says it doesn't but from my testing..... I think it does.

I did some tests on Lavc's ASP and x264's AVC, both muxed into mp4.

I used a straight 16:9 (in here I mean anamorph) Pal stream left at 720x576.

When using the mp4 container in my tests x264 uses SAR or PAR where Lavc ASP and lavc XVID do use the DAR. Both (x264 and lavc ASP) played back properly in a std. Dshow appl. like MPC or Zoomplayer (via FFdshow) but not the xvid one. VLC and its internal routines/codecs did show the x264, lavc ASP and lavc XVID ones properly. - But VLC compensates the SAR by squeezing the height!

When using the avi container (mencoder/Lavc's ASP or mencoder/Xvid ) the DAR-Flag isn't recognised when using a std. Dshow appl. (see above).
VLC does playback these avis properly.


Also ...
When I do enter the avisynth Script creator and importing a d2v (PAL 720x576) it shows me a DAR of straight 16:9 1,778 which isnt correct D1 ITU anamorph 720 results in 1.832 which equals almost to 175/96.

http://img494.imageshack.us/img494/3408/unbenannt18gw.gif (http://imageshack.us)

When using PARanoia's SAR of 35/24 in x264 or DAR of 175/96 in lavcASP .. each muxed into a mp4 container the circle results 1:1 round in a sw/player like Zoomplaer or MPC:

http://img471.imageshack.us/img471/2964/720x576anamorph5gy.th.gif (http://img471.imageshack.us/my.php?image=720x576anamorph5gy.gif)


At the very end of my resulted script I do see that here the therm "SAR" is used for the "16:9" -DAR-.

# Set SAR in encoder to 16 : 9

I think that could result in confusings? Or is it only Lavc ASP encoding related?

[berrinam]

@incredible: Thanks for doing the tests

When using the mp4 container in my tests x264 uses SAR or PAR where Lavc ASP and lavc XVID do use the DAR.Hang on, XviD isn't part of libavcodec. I assume you simply mean through mencoder?
Both (x264 and lavc ASP) played back properly in a std. Dshow appl. like MPC or Zoomplayer (via FFdshow) but not the xvid one. VLC and its internal routines/codecs did show the x264, lavc ASP and lavc XVID ones properly. - But VLC compensates the SAR by squeezing the height!Yep, in my testing, I used mplayer for checking my results, and everything worked in mplayer, although not necessarily in all the other players. mplayer also upscales, instead of downscaling (or so it claims). I am somewhat surprised that XviD works so reliably, because, from my testing, mencoder has a bug with signalling XviD's AR, which means that it can only be set using one of XviD's four presets. As a hack, MeGUI rounds any AR to the closest preset (see the function VideoUtil.roundXviDPar), so there can be quite a discrepancy with the AR.

Also ...
When I do enter the avisynth Script creator and importing a d2v (PAL 720x576) it shows me a DAR of straight 16:9 1,778 which isnt correct D1 ITU anamorph 720 results in 1.832 which equals almost to 175/96.This is also the case when not doing anamorphic encodes. It's not my area, though -- Doom9 decided against ITU resizing, and I have had no problems with the resulting resizing (as in, no stretching-related problems. Perhaps there is a slight distortion, but too small for me to notice).

At the very end of my resulted script I do see that here the therm "SAR" is used for the "16:9" -DAR-.I've added that to the list of bugs. Perhaps it will be fixed sometime.

[Inc]

Hang on, XviD isn't part of libavcodec. I assume you simply mean through mencoder?Yep, sorry, I meant the mencoder way via its inlcuded xvid library
from my testing, mencoder has a bug with signalling XviD's AR, which means that it can only be set using one of XviD's four presets.
yep, I figured that out too this mornig. Only the ntsc/pal preset DARs do work.
It's not my area, though -- Doom9 decided against ITU resizing, and I have had no problems with the resulting resizing
ok, his decision, but if a ITU compilant input is assumet as 1,7778 then finally you "could" end up in a 1024/1050 error factor if not treating the source ITU compilant as a 720x576 content just gets scaled to 1024x576 and not to 1050 in the sw/player ... but everything depends on the specific users eyes ;).

[dimzon]

to ALL
Maybe just drop LMP4 support at all (XviD is better in all - it's free, faster and provide better quality...
Why you are spenting time writing workaround for unusable codec - let's spent this time for more important things

[dimzon]

0.2.3.2061 1 Feb 2006
Commit by dimzon:
-Upmix stereo to 5.1 seems to work now
http://forum.doom9.org/showthread.php?p=778156#post778156

[Doom9]

@dimzon: actually.. the workaround is for xvid because there's no commandline tool that properly signals custom DARs. Custom DARs work fine for LMP4.

[Inc]

I do think its also up on the used containerformat and the Playback appl.
As said, VLC does recognise the DAR or SAR signals of menc_XVID, menc_ASP and x264 properly (all in mp4), if I do remeber even in Avis. But when using Dshow decoders via Dshow playback apps. then the mess begins in case of menc_XVID and btw. AVIS in general.

[dimzon]

Just now first time take look @ Avisynth_c API embeded into avisynth.dll
Seems like I can remove AvisynthWrapper.dll at all (maybe not right now, bcz i'm a little busy)

[dimzon]

0.2.3.2062 1 Feb 2006
Commit by dimzon:
-Fixed bitrate parameter when encoding FAAC via BeSweet

[Doom9]

@dimzon: I'm looking forward to the removal of avisynthwrapper.dll ;)

Now, compiling the latest build returns a bunch of warnings:
VideoUtil.cs(54,10): warning CS1030: #warning: 'Seems like no one call this
method!'
AviSynthWindow.cs(1019,26): warning CS0618: 'MeGUI.VideoUtil.getResizeLine(int,
int, int)' is obsolete: 'Use ScriptServer.GetResizeLine instead. Use
ScriptServer.ListOfResizeFilterType to fill your comboboxes'
AviSynthWindow.cs(1020,28): warning CS0618:
'MeGUI.VideoUtil.getDenoiseLines(bool, int)' is obsolete: 'Use
ScriptServer.GetDenoiseLines instead. Use
ScriptServer.ListOfDenoiseFilterType to fill your comboboxes'
JobUtil.cs(761,28): warning CS0618: 'MeGUI.VideoUtil.getDenoiseLines(bool, int)'
is obsolete: 'Use ScriptServer.GetDenoiseLines instead. Use
ScriptServer.ListOfDenoiseFilterType to fill your comboboxes'
JobUtil.cs(762,26): warning CS0618: 'MeGUI.VideoUtil.getResizeLine(int, int,
int)' is obsolete: 'Use ScriptServer.GetResizeLine instead. Use
ScriptServer.ListOfResizeFilterType to fill your comboboxes'
Microsoft (R) Visual C# 2005 Compiler version 8.00.50727.42
for Microsoft (R) Windows (R) 2005 Framework version 2.0.50727
Copyright (C) Microsoft Corporation 2001-2005. All rights reserved.
I don't know who added them but as a general rule, double clicking on compile.bat should not return any warnings whatsoever. If there's unused code, get rid of it, if methods in one class are not to be used anymore, make sure nobody uses them anymore.

[Inc]

Just now first time take look @ Avisynth_c API embeded into avisynth.dll
Seems like I can remove AvisynthWrapper.dll at all (maybe not right now, bcz i'm a little busy)

An 'approach' of accessing the dll .... (till now I didnt went into the C Interface, so you have to try)

AVS_ScriptEnvironment * env =
avs_create_script_environment(AVISYNTH_INTERFACE_VERSION);
AVS_Value arg = avs_new_value_string(script);
AVS_Value args = avs_new_value_array(&arg, 1);
AVS_Value res = avs_invoke(env, "Eval", args, 0);
if (avs_is_error(res))
{
// Error mess. here
return -1 ;
}
arg = res;
res = avs_invoke(env, "ConvertToRGB32", args, 0);
AVS_Clip * clip = avs_take_clip(res, env);
avs_release_value(res);
const AVS_VideoInfo * inf = avs_get_video_info(clip);

[Doom9]

if anybody has an idea how to get x264's output if it aborts immediately (see http://forum.doom9.org/showthread.php?t=106667) please let me know.. it's pretty annoying not to get any feedback.. obviously that indicates something went terribly wrong, but having the error right there in the log would make things easier.

[Doom9]

here's one for dimzon: I'm finally trying out avisynth audio encoding.. works like a charm. I'm just curious about the first pass.. I sorta figured that would go away with AviSynth.. so exactly what is happening during the first pass? Oh, and can we parallelize that because right now only one core is busy ;)
By the way, during the second pass, the cores seem better utilized.. and while I haven't verified yet, I think I'm even seeing a speed boost (akin what you get when encoding in VfW for single threaded codec thanks to the separation of input reading/decoding and encoding.. ).

[dimzon]

@dimzon: I'm looking forward to the removal of avisynthwrapper.dll ;)
After analyzing Avisynth_C API i decide to recall this proposal. Unfortunally Avisynth_C API is callable via PInvoke but is very nonoptimal for it.
Mosly every function in this API recieve STRUCT like AVS_Value by value.
int someFunc(AVS_Value value)
It means dotNet Marshaller will be used for every invokation and there are no way for optimization... And Avisynth_C API is more atomic - You need 4x more invocation to achive same effect (and mostly every invocation recieve struct ByVal)

In other way using ByRef (like AvisynthWrapper.dll)
int someFunc(AVS_Value* value)
Is much more friendly for dotNet PInvoke bcz You can create GCHandle and pin your structure in memory then just transmit structure address directly into function.




I don't know who added them but as a general rule, double clicking on compile.bat should not return any warnings whatsoever.
First of all please point me @ this rule.
Second - using custom warnings allows and ObsoleteAttribute is very helpfull when you working @ big project with many developers. I does not wont to touch too much files at ones bcz I afraid onyone else will change this code @ same time and I dos'nt wont perform merging at all... But using custom warnings and ObsoleteAttribute I can tell to other developers and it will act as reminder @ every compilation. As You can see this warnings will be eluminated by me or other developers during 5-10 commits...


I'm just curious about the first pass.. I sorta figured that would go away with AviSynth.. so exactly what is happening during the first pass?
first pass (I name it prepocessing) is 100% controlled by AviSynth. it caused by using Normalize() function.

[dimzon]

@Doom9
I still waiting meaningfull response from You
What I must do now?

[Doom9]

I does not wont to touch too much files at ones bcz I afraid onyone else will change this code @ same time and I dos'nt wont perform merging at allAre you the same guy who started out telling everybody megui needs to be redone from scratch? Shouldn't the first rule of refactoring be that you must realize you're going to create conflicts and break a lot of stuff? I recall 300 compiler errors just when putting dgindex processing in as a job instead of something the form does.

What I must do now?There are no musts in a volunteer project. But perhaps a should. For instance, I could imagine a job having a method/property to return a string array that can be used to construct a listviewitem being something useful since the whole bind job to listview will have to be rethought during refactoring. I noted that we can use the ListViewItem.tag to attach a job to the GUI, but then the item and object are still not bound and ideally they ought to be (so if you move an item up/down, its position element gets incremented/decremented, likewise for setting status, etc).
Then you can consider what a generic jobprocessor and jobqueue will have to do. The processor will implement ijobprocessor of course, but there's the little annoying detail that somebody someplace needs to be aware of jobtypes (and not the job itself) and does the proper postprocessing. For instance, after audio encoding comes video encoding so we have to update the bitrate (of 1 up to 3 video jobs). Or after indexing comes audio processing so you first have to find those audio files.. that kind of thing. Make sure you step through the current handling in the debugger once to get a feeling what really has to be done.. there's a lot of interdependency between jobs I'm afraid.

[dimzon]

Are you the same guy who started out telling everybody megui needs to be redone from scratch?
FYI: refactoring != from_scratch
Shouldn't the first rule of refactoring be that you must realize you're going to create conflicts and break a lot of stuff?
No. The first rule of refactoring is: ALL DEVELOPMENT ARE FROZEN DURING REFACTORING PROCESS (nobody adds new features etc). Refactoring reques EXCLUSIVE source lock until it will be done (to avoid merge hell).

There are no musts in a volunteer project. But perhaps a should.
Sorry, this is my poor english ;)

For instance, I could imagine a job having a method/property to return a string array that can be used to construct a listviewitem being something useful since the whole bind job to listview will have to be rethought during refactoring. I noted that we can use the ListViewItem.tag to attach a job to the GUI, but then the item and object are still not bound and ideally they ought to be (so if you move an item up/down, its position element gets incremented/decremented, likewise for setting status, etc).
I believe you need update position property only before saving joblist. In this case can just enumerate ListViewItem collection and reassign it

For instance, after audio encoding comes video encoding so we have to update the bitrate (of 1 up to 3 video jobs).
Just fast incomplete proposal - Add something like "Content Job" term - job wich produce some data to be included in target file (Audio, Video). Set of "Content Job" may be managed by special manager:

JobManager m = new ContentJobManager();
m.RegisterJob(audioJob, JobSubtype.IntermediateData)
m.RegisterJob(videoPass1Job, JobSubtype.TempData || JobSubType.AdjustBitrate)
m.RegisterJob(videoPass2Job, JobSubtype.IntermediateData|| JobSubType.AdjustBitrate)
m.RegisterJob(muxJob, JobSybtype.FinalData || JobSubType.UseAsBitrateProvider)

Or after indexing comes audio processing so you first have to find those audio files.. that kind of thing.
Maybe better to write our own VOB parser to know dgindex output before job start?

[Doom9]

Maybe better to write our own VOB parser to know dgindex output before job start?VOB isn't the only input ;) You seem to be forgetting about the multitude of different things megui supports quite a lot. Digital TV is becoming more and more important..
No. The first rule of refactoring is: ALL DEVELOPMENT ARE FROZEN DURING REFACTORING PROCESS (nobody adds new features etc). Refactoring reques EXCLUSIVE source lock until it will be done (to avoid merge hell).well.. if more than one person works at it, manual merges are still a very real possibility.. and that isn't limited to a refactoring process.. it can happen all the time, especially since there's so much intelligence sitting in the main class.

[cc979]

i've re-install windows, avisynth and megui and that
i setup megui plugins using "C:\Program Files\GordianKnot\AviSynthPlugins"

but it wants decomb.dll in the "C:\Program Files\AviSynth 2.5\plugins" is that normal or a little bug ?

[dimzon]

VOB isn't the only input ;) You seem to be forgetting about the multitude of different things megui supports quite a lot. Digital TV is becoming more and more important..
Maybe I can take look @ DGIndex code and split it into 2 parts (or we can ask neuron2 to do it) - stream parsing library (Dll) and GUI (exe). In this case we can use this stream parsing library directly ;)

well.. if more than one person works at it, manual merges are still a very real possibility.. and that isn't limited to a refactoring process..
Yes, but during refactoring process merging is headbreaking, really!

it can happen all the time, especially since there's so much intelligence sitting in the main class.
It's the reason why we need split it ASAP.

[Dayvon]

i've re-install windows, avisynth and megui and that
i setup megui plugins using "C:\Program Files\GordianKnot\AviSynthPlugins"

but it wants decomb.dll in the "C:\Program Files\AviSynth 2.5\plugins" is that normal or a little bug ?

LOL. Wrong thread buddy, and possibly even wrong sub-forum. Go post this question in this thread (http://forum.doom9.org/showthread.php?t=105920).

[Doom9]

[qutoe]stream parsing library (Dll) and GUI (exe). In this case we can use this stream parsing library directly[/quote]That's not nearly good enough. Didn't I already tell you once the major issue with digital TV streams? A TS can contain multiple PIDs, audio and video. You could have a TS that contains broadcasts from multiple channels. You can't have any sensible mapping with a TS player that allows you to pick the chain and in function of the video makes different audio streams available.. And if the input is VOB, we have the DVD Decrypter info file so we know the output.. not the precise name since we have the delay in the filename, but extension and the beginning of the track name.
Yes, but during refactoring process merging is headbreaking, really!Remember that I was up till 4 am one Sunday when I merged in my new audio encoding and muxing code.. I consider it inevitable. Even if you refactor your own software, I actually like to just move things around without too much help.. then I break things all over the place, but fixing them shows me all the code that I need to recheck to make sure nothing has been broken in the end. If you just have your refactoring tools that rename anywhere, and you still screwed up somewhere.. it'll be so much harder to find where things went wrong. And you know how I am when it comes to testing what changes you've made.. there's no such thing as testing enough.. only testing too little. My major change releases generally come out hours after I finished coding.. in between all I do is testing various scenarios.

[dimzon]

That's not nearly good enough. Didn't I already tell you once the major issue with digital TV streams? A TS can contain multiple PIDs, audio and video. You could have a TS that contains broadcasts from multiple channels.
Sorry, never read about it, i doesn't know nothing about TVStreams


And if the input is VOB, we have the DVD Decrypter info file so we know the output.. not the precise name since we have the delay in the filename, but extension and the beginning of the track name.
That's why I don't like current solution at all. We are using to many dependecies ( DVDDecrypter is dead, isn't it). And we have no full control over them ( filenames is unpredictable etc). That's why we need better solution (like parsers in Dll's or rewritten in C# from scratch). When I take look @ OneClickMode implementation I decide NEVER USE IT MYSELF (really) bcz I don't trust such potencial-unstable solution... And as You can see this solution create a huge problems in MeGUI architecture



Remember that I was up till 4 am one Sunday when I merged in my new audio encoding and muxing code.. I consider it inevitable. Even if you refactor your own software, I actually like to just move things around without too much help.. then I break things all over the place, but fixing them shows me all the code that I need to recheck to make sure nothing has been broken in the end. If you just have your refactoring tools that rename anywhere, and you still screwed up somewhere.. it'll be so much harder to find where things went wrong. And you know how I am when it comes to testing what changes you've made.. there's no such thing as testing enough.. only testing too little. My major change releases generally come out hours after I finished coding.. in between all I do is testing various scenarios.
Actually I do not understand what does you want to tell me. I know what is refactoring well, I perform it @ my work.

[Doom9]

DVDDecrypter is dead, isn't itNot really.. combine it with any on-the-fly decryption layer and it'll live forever.
bcz I don't trust such potencial-unstable solutionPhew, that's just what you want to tell the potential user. Come on.. it works quite well for those who've actually tried it.
Actually I do not understand what does you want to tell me.If you're just going to rename methods, using the built-in tools is fine. But if you're going to change parameters (and thus logic inside the method), it's better to actually break things, compile, see where the errors are, and thus finding all the places that could potentially cause problems. Say you're changing video job creation.. then you need to test every scenario where video jobs are being created to know your changes didn't silently break something that you'll only see at runtime. Any fancy pants refactoring help tool can't figure that one out, in fact they make you forget about those things, where plain manual refactoring results in a lot of break then fix scenarios.. and during the fixing you can strategically place breakpoints for later testing.

[dimzon]

But if you're going to change parameters (and thus logic inside the method), it's better to actually break things, compile, see where the errors are, and thus finding all the places that could potentially cause problems. Say you're changing video job creation.. then you need to test every scenario where video jobs are being created to know your changes didn't silently break something that you'll only see at runtime. Any fancy pants refactoring help tool can't figure that one out, in fact they make you forget about those things, where plain manual refactoring results in a lot of break then fix scenarios.. and during the fixing you can strategically place breakpoints for later testing.
Agreed by 100%. Just one exception - at starting refactoring phase I strongly prefer to keep original methods (redirecting it on newer one inside) and mark original methods by [Obsolete]

[berrinam]

My 2 cents: with the various function changes (like you moving some things to ScriptServer), I think MeGUI is small enough for that not to be a particularly serious problem. Those functions were only called in at most two places (AviSynth Creator, and OneClick encoder), and so the changes are small. Merging with that sort of thing should not be a problem.

WinMerge, from my experience, is able to pick that sort of thing up. The real problems come from trying to merge WinForms generated code....

[dimzon]

0.2.3.2063 3 Feb 2006
Commit by dimzon:
-New very experimental stereo->5.1 upmix modes (using Sox avisynth filter) - try it && report!

thanx to NorthPole
http://forum.doom9.org/showthread.php?p=779538#post779538

[berrinam]

configAudioButton_Click -> explore possible simplifications

I'm working on this at the moment, and I am trying to do this by making all of the configuration dialogs extend a VideoConfigurationDialog, and this also uses visual inheritance, like described in the Feature Request thread. The thing I am wondering is whether it is worth extending this to the entire GUI, which would mean making a ProfilableConfigurationDialog class, which handles profiles. This could be extended by the four things that use profiles (video, audio, avs, oneclick), and that would save using all the profile code multiple times. However, it's a lot of work, and I thought that (a) it is better to check whether you agree first, and (b) it might be easier to do it for the Video config dialogs, then extend it to all of MeGUI later. Well, option (b) is clearly not easier, but it is for the present time.

So, what do you think?

[Doom9]

The audio configuration dialogs already use visual inheritance (dimzon introduced that). Do all dialogs that contain profiles really act the same? If so, a three tiered architecture (ProfileDialog, AudioDialog: ProfileDialog, NaacConfigurationDialog: AudioDialog) could make sense.. but it really comes down to how much in common there is. I know audio and video have a lot but I'm somewhat unsure about the rest. I guess in the spirit of breaking the least amount, going just for video might be preferable as an intermediate step.

BTW, I have no plans for the weekend so chances are I go on a refactoring spree. so please keep Form1 and JobUtil untouched, or at least everything that concerns the generation and management of jobs.

[Doom9]

@dimzon: with the avisynth encoding (I haven't heard anything negative about it.. people just need to set it up properly but with berrinam's guide that's not really a problem either and so I'm even considering disabling the radiobutton to see where it leads.. ) we can now look into more encoders again. You already have a winamp aac encoder wrapper so perhaps we could support that now. And then there's vorbis for mkv.

[Richard Berg]

So, what do you think?
I think better to keep the AudioConfig & VideoConfig inheritance hierarchies separate. But make a general Profile class that all of them use. So that if we decide something like "nullable means don't overwrite current value" (idea from another thread), it automatically applies to all dialogs that use profiles.

[berrinam]

but it really comes down to how much in common there is. I know audio and video have a lot but I'm somewhat unsure about the rest. I guess in the spirit of breaking the least amount, going just for video might be preferable as an intermediate step.The bit that they all have in common is the profile management. At the moment, the occurrences of profiles behave slightly differently -- video profiles have a load defaults button, as well as safe profile alteration. But yes, the way I am currently looking at would make changes throughout the program, because it would mean reducing everything to a Profile and a Settings base class, and there would be a lot more casting as the result. While I think it would be a worthwhile change, I'll stick with the video for the moment.

I think better to keep the AudioConfig & VideoConfig inheritance hierarchies separate. But make a general Profile class that all of them use. So that if we decide something like "nullable means don't overwrite current value" (idea from another thread), it automatically applies to all dialogs that use profiles.
There is already a Profile class which Video-, Audio-, AviSynth-, and OneClick- Profiles all extend, but all it has is a Name value. I don't see how something like that can be used easily in all dialogs... I think I've missed something

[pcaca]

About the problem in x64 discused here:
http://forum.doom9.org/showthread.php?t=106740
I managed to do anonymous CVS checkout and get the latest source files. I changed platform to x86 in configuration properties for MeGUI and neroraw projects in VS2005 and succsesfuly compiled the solution. Now the bug is fixed in Windows XP x64 and task manager shows that MeGUI is 32-bit application, so I can open d2v files and avs scripts in MeGUI.

I am student of Computer Science and maybe sometimes in future (when i learn more C#) i will join the developement of MeGUI.

[Doom9]

Major announcement: since I started refactoring (currently doing profiles.. with the provider as dropdown items as dimzon suggested), and considering all the changes that lie ahead, I decided to dump conditional compilation effective immediately. I'll make a commit after redoing the profiles so that you can resynch and I think it would be prudent to let development rest until then as this is a major change that affects every single file.

[Doom9]

grr.. SN25P is at it again.. won't boot from my Raptor anymore. Thank good I kept the somewhat messed up XP on my Deathstar.

[Doom9]

Man was that a bad idea moving profiles out of form1.. I'm still working on it, but I'll leave something for berrinam. A few points to be considered: attach profiles to dropdowns like I did with codecsettings in the main form (see dimzon's sample code). Make the dropdown non editable.. right now adding, switching and deleting is sort of a chance game.. you don't really know if it works the way you intended. E.g. you select a profile, then type something, then press delete.. the profile you selected is being deleted.. but on screen you have a profile name that doesn't exist. So that could be made to be perfectly deterministic.

Also, in my next commit you'll see that the audio dialog launching has been extremely streamlined.. the same should be done for video.. the reason I didn't do this yet is because the different video dialogs have different parameters that are given to it so the streamlining has to start there.

[Mutant_Fruit]

What files other than the ones i've listed below could be updateable from the AutoUpdate window? I got that list from all the "filepaths" in the settings section.

mencoder
besweet
mp4box
mkvmerge
x264
xvid_encraw
dgindex
faac
neroraw

Basically, anything that is needed by MeGUI that a user might need should be included in this list. This will allow for on-the-fly downloading (if the user wants) so if a plugin isn't found, it can be downloaded and set up in the background.

[Doom9]

I wouldn't worry about besweet anymore.. it's going to be phased out. For mp3 encoding via avisynth we need lame. On top of that, for audio processing via avisynth we need nic's audio plugins.

[Doom9]

0.2.3.2053 5 Feb 2006
Commit by Doom9
- Moved all profile handling to the new ProfileManager class
- Use of List<> and IDictionary<,> instead of ArrayList and HashTable (not all classes have been checked)
- Refactored audio / video codec settings in the main GUI. Using the SettingsProvider approach dimzon suggested
- Simplified a bunch of methods in the main GUI
- Output name textboxes are disabled where applicable if the output selection button is disabled
- Conditional compilation removed

I also tried to live up to the coding guidelines I outlined a few pages ago.. at times it was news for me too so I hope I managed to do a halfway passable job.

Now for the future:
@berrinam: if you're going to create a common base class for the video codec settings, you might also want to look into the possibility to attach profiles to the dropdown as I did with video/audio settings in the main GUI.. and then propagate that throughout the program.

My next stop will be the encoding refactoring now to further cut down the size of the main class and while I'm add it, give the whole avi thing a serious review.

[berrinam]

What files other than the ones i've listed below could be updateable from the AutoUpdate window? I got that list from all the "filepaths" in the settings section.Have a look at my MeGUI guide in the sticky. It should have a list of everything that might possibly be required (in particular, various dlls, like audio encoding dlls, avisynth filter dlls). Just go through the first post and find all the links. The second post should have no links, just instructions. Also, don't forget that AviSynth should be downloadable. I didn't think of putting that in my guide, because everyone on this forum already knows about AviSynth.

This will allow for on-the-fly downloading (if the user wants) so if a plugin isn't found, it can be downloaded and set up in the background.
I think that AviSynth plugins should also be checked for. As far as they go, you will either have to find the location of the AviSynth plugins folder by using the registry, and then check whether the files exist, OR you could have a series of test scripts to see if each particular plugin works. Basically, the scripts would look as follows:
blankclip(possibly some settings, like colorspace here)
TDeint()
And then dimzon's AviSynth wrapper could tell us whether this produces an error, basically telling us whether the plugin is correctly set up. However, I just realised you would need to know the AviSynth plugins location anyway, so that you can install them there. Still, I think the second approach is better, because it is actually testing what we want to know, instead of doing another test to approximate it.

[berrinam]

Does anyone know if YV12 codecs are still required for MeGUI? Doesn't dimzon's Avisynthwrapper.dll remove the need for the YV12 codecs?

[Doom9]

Does anyone know if YV12 codecs are still required for MeGUI? Doesn't dimzon's Avisynthwrapper.dll remove the need for the YV12 codecs?Afaik, the encoders still use AVIFile to read the AviSynth script.. so while MeGUI could live without it, the encoder chain still needs it.

Has anybody ever thought the audio handling was cumbersome (at least for programmers), there are a lot of checks in there to make sure the output name and settings for each audio stream are correct. Would it be bad if instead of having so many checks, just have the encoder check if a stream is properly set up and return an error if it's not (possibly with an option to adjust whatever is wrong.. I'd tend to say the settings should override the output extension)?

[dimzon]

@dimzon: with the avisynth encoding (I haven't heard anything negative about it.. people just need to set it up properly but with berrinam's guide that's not really a problem either and so I'm even considering disabling the radiobutton to see where it leads.. ) we can now look into more encoders again. You already have a winamp aac encoder wrapper so perhaps we could support that now. And then there's vorbis for mkv.
I'm happy after you refactoring ;) It's easy to add new encoders now!

[dimzon]

@Doom9
just proposals:
private void initializeDropdowns()
{
this.fileType.SelectedIndex = (int)VideoJob.FileType.MP4; // MP4
this.videoCodec.Items.AddRange(new object[] { new LavcSettingsProvider(), new X264SettingsProvider(), new SnowSettingsProvider(), new XviDSettingsProvider() });
this.videoCodec.SelectedIndex = (int)VideoJob.CodecType.AVC;
this.audioCodec.Items.AddRange(new object[] { new NeroAACSettingsProvider(), new LameMP3SettingsProvider(), new FaacSettingsProvider() });
this.audioCodec.SelectedIndex = 0;
}
1) I prefer to use Singleton pattern
public class LavcSettingsProvider : IVideoSettingsProvider
{
...
private static IVideoSettingsProvider instance = new LavcSettingsProvider();
public static IVideoSettingsProvider Instance {get{return instance}}
}


So yor array initialization code can look like this:
new object[] { NeroAACSettingsProvider.Instance...)

2) I strongly prefer to use static readonly field wich contains encoders array:

public static readonly object[] VideoCodecs = new object[] {...}
...
this.videoCodec.DataSource=VideoCodecs;


3) Using Singleton pattern you can use such code:

this.videoCodec.SelectedItem = X264SettingsProvider.Instance;

instead this:
his.videoCodec.SelectedIndex = (int)VideoJob.CodecType.AVC;
so you does'nt need to add items in predefined order

[dimzon]

Does anyone know if YV12 codecs are still required for MeGUI? Doesn't dimzon's Avisynthwrapper.dll remove the need for the YV12 codecs?
By the way - I think "installed XviD" is good requemrnt for your guide. I do not recommend Helix YV12 at all - it caused bugs (HW falture, system halts) @ my office PC...

[dimzon]

0.2.3.2065 6 Feb 2006
Commit by dimzon
- Fixed bug opening Avs Generator window
- Fixed BlockAlign bug in AviSynthAudioEncoder
- Simplified d2vReader code (now it just forwards it's calls to AvsReader executed on Mpeg2Source(fileName) script)


@Doom9
d2vReader still experimental, we can undo it any time ;)