View Full Version : MeGUI development
Pages :
1
2
3
4
5
6
7
8
[
9]
10
11
12
13
14
15
16
17
18
19
berrinam
22nd March 2006, 07:47
0.2.3.2115 22 March 2006
Commit by berrinam:
- Source Detection now runs with the priority specified by the settings.
- Script Generation window is now smaller through the use of tabs.
dimzon
22nd March 2006, 12:29
0.2.3.2116 22 March 2006
Commit by dimzon:
- New tab - Changelog.txt.
Sharktooth
22nd March 2006, 14:13
CVS Update:
Updated compile.bat. It now creates a "Dist" directory and will copy all the necessary files for MeGUI binaries distribuition.
SF binaries are up to date too.
IMOON
22nd March 2006, 16:56
I think the prblem is in the "UpdateGUIStatus" function.
You dont check if next job was started or not, you only check if the current complete job has an error or if the queue was stoped.
here my solution, I have tested it and seems to work.
code from form1.cs in the UpdateGUIStatus function.
private void UpdateGUIStatus(StatusUpdate su)
{...
int nextJobStart = 0;
if (continueStatus <= 2 && this.queueEncoding)
{
nextJobStart = startNextJobInQueue(); //new with the return value to check if there was another job
}
else
{
nextJobStart=2;
}
if (nextJobStart == 2) { //new test if this was the last job or a job was stoped
this.isEncoding = false; //moved out the else before
this.queueEncoding = false;
this.startStopButton.Text = "Start";
this.abortButton.Enabled = false;
this.shutdown();
}
...}
ChronoCross
22nd March 2006, 18:21
great job. it works.
Doom9
22nd March 2006, 18:45
Question for you guys: since at the moment I just can't get myself to finish the work started, is anybody willing to look at the half-finished code? Mainly what's missing is a "codec" -> outputtype finder that goes along with the outputtype -> container finder and then integrate this into the autoencode and one click guis, and creating the proper mux jobs. It's not quite trivial but it's probably better if somebody else has a crack at it or this will loom over our heads for some time to come.. the work situation is going to get any better for the foreeable future.
dimzon
22nd March 2006, 18:49
Question for you guys: since at the moment I just can't get myself to finish the work started, is anybody willing to look at the half-finished code? Mainly what's missing is a "codec" -> outputtype finder that goes along with the outputtype -> container finder and then integrate this into the autoencode and one click guis, and creating the proper mux jobs. It's not quite trivial but it's probably better if somebody else has a crack at it or this will loom over our heads for some time to come.. the work situation is going to get any better for the foreeable future.
I can take look @ it
max-holz
22nd March 2006, 20:06
But cvs is working? No update in the public one for version 2115 and 2116
ChronoCross
22nd March 2006, 20:07
But cvs is working? No update in the public one for version 2115 and 2116
they only updated it this morning. it can take up to 8 hours for it to update. Be patient. I already posted another build.
Sharktooth
22nd March 2006, 20:41
CVS Update:
0.2.3.2117 22 March 2006
Commit by Sharx1976:
- Fixed the shutdown problem (patch by IMOON).
Sharktooth
22nd March 2006, 20:45
But cvs is working? No update in the public one for version 2115 and 2116
you can always find updated sources here:
http://files.x264.nl/Sharktooth/?dir=./megui/Sources
berrinam
23rd March 2006, 10:03
Thinking about the current system we have for AR signalling, I realised just how unreliable it is -- it only sets the AR if you encode the script immediately after creating it. This means that the unsuspecting user might create the script, then encode it some days later, and be surprised to discover that the AR turned out wrongly. I remembered dimzon's idea from back here (http://forum.doom9.org/showthread.php?p=785540#post785540) and I wanted to see what the conclusion on that was. Turns out, after an initial no by Doom9* and a yes by Sharktooth, it seems to just have been forgotten. I want to say now that I also think this is a good idea, and from a design viewpoint, it also makes sense; information about the source file should be contained in the source file, and since AviSynth can't signal AR, then it is up to us to create some form of compromise (unless there is a way to communicate directly with avisynth.dll so that the filters can keep track of the AR, but I suspect that would be too complex).
Just for reference, here is the suggestion that dimzon made:
Maybe we can add some magic macros to avs script? Something like
bla bla bla
bla bla bla
# $MeGUI_SAR(1.34)
and analyze avs when opening?
*Doom9 initially said no, but he was away for a while after dimzon's explanation of why, so I wanted to bring this up again. What do you think?
Sharktooth
23rd March 2006, 10:40
you know i like it and a lot of useful things can be done thru "macros".
for example you can even set codecs and their settings (usefull for debugging)...
sysKin
23rd March 2006, 14:57
Thinking about the current system we have for AR signalling, I realised just how unreliable it is -- it only sets the AR if you encode the script immediately after creating it.
At least in my case, I first create a script and then load a codec profile, which effectively ruins all AR calculations every time.
The only solution I can see is to redesign whole AR thing - it's not a codec setting at all, it's a picture setting.
Unfortunately I have no good ideas how to do that properly :(
Richard Berg
23rd March 2006, 18:57
@berrinam - I would prefer to see us read it from a "magic variable" instead of a "magic comment." That way we can use the Avisynth scripting language to calculate the AR for us. For example, I often use this function:
function ResizeAR(clip c, int "dest_x", int "dest_y", string "ar")
{
Assert(!ar.Defined || ar.LCase == "sar" || ar.LCase == "dar",
\ "rb-ResizeAR: If defined, 'print' must be 'sar' or 'dar'.")
dest_x = default(dest_x, c.width)
dest_y = default(dest_y, c.height)
dest_ar = float(dest_x)/dest_y
dar = (float(c.width)/c.height) * (4320./4739)
sar = dar / dest_ar
out = c.LimitedSharpen(dest_x = dest_x, dest_y = dest_y)
return !ar.Defined ? out : out.SubTitle(ar + ": " + string(eval(ar)))
}
It would be great if instead of printing the AR on the screen for manually typing into MeGUI, I could just stick the result into a magic variable.
berrinam
23rd March 2006, 23:07
I like that idea. While it is easier to calculate dars with floats, integers are used by most encoders. I propose that AviSynth scripts with AR signalling have two globals: outputDARX and outputDARY. MeGUI could read those globals and pass them directly on. We can then make two AviSynth script functions to manage that: SignalFloatDAR(float DAR) and SignalDAR(int x, int y), the first of which would convert the float to a fraction, and the second of which would just save x and y as outputDARX and outputDARY respectively.
ChronoCross
24th March 2006, 17:37
@devs
I did some work this week with mencoder compiling and finally managed to make a good working version specifically for megui using a MingW workaround for largefiles from the mplayer mailing list. It has xvid 1.1 final and libavcodec only everything else is disabled. This works well since megui only uses it for xvid and huffy.
I played around with the commandline for pre-rendering. Here's what I found.
"D:\OFFICE_SPACE\VIDEO_TS\Office.avs" -o "D:\OFFICE_SPACE\VIDEO_TS\hfyu_Office.avi" -of avi -forceidx -noodml -ovc lavc -lavcopts vcodec=ffvhuff:vstrict=-2:pred=2:context=1
Works only for lossless under 4GB(approx a single episode of an anime 24-25Mins). Once it hits the 4GB barrier it no longer produces a valid avi file. However the following command line works for all sizes.
"D:\OFFICE_SPACE\VIDEO_TS\Office.avs" -o "D:\OFFICE_SPACE\VIDEO_TS\hfyu_Office.avi" -of avi -forceidx -ovc lavc -lavcopts vcodec=ffvhuff:vstrict=-2:pred=2:context=1
I think the second one should be used. I will be posting the mencoder I built for megui later today. It's just a matter of removing the -noodml switch.
Doom9
24th March 2006, 17:46
@ChronoCross: mencoder for xvid encoding is at a dead end.. the next stable version won't support it anymore.
ChronoCross
24th March 2006, 17:59
Understood. In the current megui it's actually the method I prefer. With xvid_encraw not being totally stable yet(I'll do some tests later to try it out more) I think the important thing is the large file support for lossless in huffy. I can remove the xvid compilation at any time.
dimzon
24th March 2006, 18:15
@ChronoCross: mencoder for xvid encoding is at a dead end.. the next stable version won't support it anymore.
So it's time to change project name, isn't it? :eek:
sillKotscha
24th March 2006, 18:39
So it's time to change project name, isn't it? :eek:
why??
just name it: mediaencodingGUI :rolleyes:
dimzon
24th March 2006, 18:42
why??
just name it: mediaencodingGUI :rolleyes:
Fine trick :cool:
ChronoCross
24th March 2006, 18:44
why??
just name it: mediaencodingGUI :rolleyes:
To be honest I always thought that's what it stood for.....lol. I never thought the name had anything to do with mencoder.
sillKotscha
24th March 2006, 18:49
To be honest I always thought that's what it stood for.....lol. I never thought the name had anything to do with mencoder.
well, shall I copyright the name :D
just kiddin' and back on topic, 'cause that's not my cup of tea here :)
ChronoCross
25th March 2006, 02:32
after meeting brian fitzpatrick(one of the creaters of subversion) today I'm convinced moving to svn is a good idea lol.
berrinam
25th March 2006, 09:45
Ok, testing version of MeGUI with AviSynth-based AR support (it reads the variables darx and dary through dimzon's getintvariable function in the AviSynthWrapper) can be found at http://rapidshare.de/files/16365267/megui-avs_ar.zip.html
It also includes a patch based on v0.2.3.2117, so that you can recreate my sources.
It sets the AR upon opening the script file for previewing, or, failing that, immediately before encoding, in the CommandlineVideoEncoder.setup() function. This should actually be moved to a different location, because it probably won't work for non-commandline video encoders, but it works fine at the moment, and this is just a Proof-of-Concept version. Please try it out and say what you think.
dimzon
25th March 2006, 11:09
Ok, testing version of MeGUI with AviSynth-based AR support (it reads the variables darx and dary through dimzon's getintvariable function in the AviSynthWrapper) can be found at http://rapidshare.de/files/16365267/megui-avs_ar.zip.html
Seems like you need GetFloatVariable(). Ok, I will try to add it @ next week.
berrinam
27th March 2006, 08:00
I'm still working away at the AutoUpdate dialog and i have a few more questions.Any news on this front?
dimzon
27th March 2006, 21:50
Some GUI guide http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwui/html/iuiguidelines.asp
berrinam
29th March 2006, 12:28
0.2.3.2118 29 March 2006
Commit by berrinam:
- Changed mpeg2source() to DGDecode_mpeg2source() in AviSynth scripts to fix clashes with mpeg2dec(3)
Doom9
30th March 2006, 09:09
I haven't touched the code for weeks so it's high time somebody else had a crack at it. Sorry it took so long. Here are my current sources: http://forum.doom9.org/MeGUI-src.CVS.rar
What's done: automatic output format selection in function of the codec in the main GUI. Automatic limit of the available container formats in the autoencoding window based on the codec and output types selected in the main window. xvid_encraw full support, avc2avi support
What's missing: automatic output type selection based on the selected codec(s) in the main window, thus discarding and re-assigning output types.
Add the above to the one clicker
Generate jobs with the knowledge of these above checks and (and I don't like this conceptually but it's the best I can come up with), write which muxer is to be used into each mux job created so that come muxing time, you don't have to perform another lookup session that potentially disrupts everything. And then, avimuxgui support.. though that can come later.. the poing of the whole mux finding story is just to prevent output formats from showing up if they cannot be muxed at the end.. so without avimuxgui you'll end up being able to get AVC in AVI, but only if there's no audio.
Oh, and the same mechanisms can be used for the other mux windows.
To quickly see where to hook into, set a breakpoint that hits when you press the auto mode button.
@dimzon: you have a bug to fix: http://forum.doom9.org/showpost.php?p=804776&postcount=761
berrinam
5th April 2006, 09:40
Ok, testing version of MeGUI with AviSynth-based AR support (it reads the variables darx and dary through dimzon's getintvariable function in the AviSynthWrapper) can be found at http://rapidshare.de/files/16365267/megui-avs_ar.zip.html
It also includes a patch based on v0.2.3.2117, so that you can recreate my sources.
It sets the AR upon opening the script file for previewing, or, failing that, immediately before encoding, in the CommandlineVideoEncoder.setup() function. This should actually be moved to a different location, because it probably won't work for non-commandline video encoders, but it works fine at the moment, and this is just a Proof-of-Concept version. Please try it out and say what you think.
Any news on this? I think Sharktooth, Richard and dimzon all agree with the idea, how about Doom9?
Can I commit this to the CVS?
Doom9
5th April 2006, 10:39
so bottom line is that the avisynth script creator writes these to the script, and the encoder would read them out when available and use them to override the dar flags in the codec configuration?
berrinam
5th April 2006, 10:54
Yep. This is read through the AviSynth GetIntVariable function, so it also allows AviSynth scripts to perform calculations on these, which are then passed back into MeGUI, like Richard described.
edit: to signal it in a script, you just need to add
darx = 16
dary = 9 somewhere in your script
Richard Berg
5th April 2006, 11:05
Keep in mind the Avisynth scripting language doesn't have the concept of namespaces -- outside of functions, everything's global. As such we should use scoped names like MeGUI_darx.
dimzon
5th April 2006, 14:04
This is read through the AviSynth GetIntVariable function
through the AviSynthWrapper.GetIntVariable method :sly:
Doom9
5th April 2006, 16:10
No objections here.
@dimzon: did you get around to having a look at the code I posted?
dimzon
5th April 2006, 16:16
did you get around to having a look at the code I posted?
ATM I'm @ heavy deadline @ my primary work, sorry...
I'm planning to take look @ it @ weekend anyway
berrinam
6th April 2006, 01:02
0.2.3.2119 5 April 2006
Commit by berrinam:
- Supported macro-based AR signalling in AviSynth scripts, using variables MeGUI_darx and MeGUI_dary
- Converted Source Detection's hybrid threshold into a percentage of total
- Some updated deinterlacing filters suggested
max-holz
6th April 2006, 17:34
0.2.3.2119 5 April 2006
Commit by berrinam:
- Supported macro-based AR signalling in AviSynth scripts, using variables MeGUI_darx and MeGUI_dary
- Converted Source Detection's hybrid threshold into a percentage of total
- Some updated deinterlacing filters suggested
Sourceforge CVS is really a shit, not updated yet!!! It's not possible to pass to SVN seems to be a little better.
ChronoCross
6th April 2006, 19:25
yeah after 18 hours it's still not updated. it's rather annoying.
berrinam
6th April 2006, 23:04
Should ChronoCross perhaps have developer access? If you have a SF account, ChronoCross, then it should be possible to give you CVS access and file release rights, which would also mean that you can publish "official" builds as well.
squid_80
6th April 2006, 23:43
For those whining about sourceforge, it shat itself about a week ago and developer access was restored less than 2 days ago. As far as I know synching between anonymous and developer cvs has not been restored yet so you might not see any updates for some time.
berrinam
6th April 2006, 23:49
Ok, well here's a CVS snapshot:
http://rapidshare.de/files/17373995/MeGUI-src.CVS.zip.html
ChronoCross
7th April 2006, 03:02
I do indeed have a sf account...take a guess at what it is =D lol
ChronoCross
7th April 2006, 03:04
blah can someone post the sources somewhere else please? Rapidshare doesn't like my universities web proxy.
Sharktooth
7th April 2006, 03:16
http://files.x264.nl/?dir=./Sharktooth/megui/Sources
sorry for the delay
ChronoCross
7th April 2006, 03:36
thank you
ChronoCross
7th April 2006, 03:38
psst.....I believe the changes are there....however the version number isn't corrct in the main program....only in the changelog.
berrinam
7th April 2006, 07:12
psst.....I believe the changes are there....however the version number isn't corrct in the main program....only in the changelog.
My mistake. I see you've fixed it up, so no problem.
@Richard and all: What's the feasibility of putting MediaWiki on megui.org? I'm interested in continuing/extending the documentation of MeGUI, and I think that would be one of the easiest ways to manage it. What does everyone else think of this?
Richard Berg
7th April 2006, 18:33
No problem. We'll just need to move the autoupdate files to megui.org/auto or something.
berrinam
8th April 2006, 00:33
0.2.3.2120 7 April 2006
Commit by berrinam:
- Fix commandlines generated for MP4Box
berrinam
8th April 2006, 06:50
0.2.3.2121 8 April 2006
Commit by berrinam:
- Add ability to import/export profiles. This also manages the dependancies, like CQM files and One Click profiles. This works through the file menu and through dragdrop.
The reason for this: it means we don't have to trust users to muck around with what should really be program files in order to install ST's profiles. It also means that profiles can now be distributed with CQMs, and it is easier for people to distribute profiles, in particular One Click profiles, which require also an audio, video and avisynth profile. Finally, this paves the way to distributing profiles through an 'auto-update' mechanism.
max-holz
8th April 2006, 09:45
Public CVS is dead, please pass to SVN.
Sharktooth
8th April 2006, 13:35
new sources at the same place.
ChronoCross
8th April 2006, 20:59
I'll post another build soon. I'm also working on my new site so hopefully when I get some actual freetime I can finish that. it'll make the organization of stuff better lol.
berrinam
10th April 2006, 14:13
0.2.3.2122 10 April 2006
Commit by berrinam:
- Support any filetype through directshow in AviSynth script creator
- Make resize turn-off-able in AviSynth script creator
- Automatically set AR on non-d2v loaded sources as well as d2v sources in AviSynth script creator
- Add clear log button
- Remove main-tab restriction on drag/drop
berrinam
11th April 2006, 11:50
0.2.3.2123 11 April 2006
Commit by berrinam:
- Allow any video input in the main window, and generate an input scriptlet for it.
Sharktooth
11th April 2006, 17:23
sources archive updated
ChronoCross
12th April 2006, 01:42
What do you guys think of an installer? I finished the NSIS script I want to use along with all the files needed for MeGUI. I'll only change over to this if the devs agree it should be distributed in this form.
berrinam
12th April 2006, 09:02
What do you guys think of an installer? I finished the NSIS script I want to use along with all the files needed for MeGUI.An installer is obviously good for n00bs. However, getting the entire installer is a helluva download to just get an update of MeGUI (this happens a lot). I think that we will eventually want an installer which sets up MeGUI and gets everything else through the automatic update system, but until then, you should continue to distribute MeGUI without anything else. Distribute the installer as well, as far as I'm concerned, but don't abandon the single MeGUI executable yet, because I think people won't like being forced to download a huge package every update.
ChronoCross
12th April 2006, 17:23
I think what I'm gonna do is make an installer that installes everything including a build available at the time.
call it: MeGUI-Essentials-20060312.exe
And then from that point we can first have people install the essentials pack(which doesn't include neroAG's codec dll's due to licensing issues.) Then they can update the megui files using my standard .rar files.
Sharktooth
12th April 2006, 21:04
good news. i recovered all the lost data on my raid 0 array...
so, im still busy with my health problems but i intend to finish a couple of patches i was working on before being hospitalized.
shon3i
12th April 2006, 23:26
@berrinam and ChronoCross can you put in this package everything is need something like GK pack.
ChronoCross
12th April 2006, 23:40
@berrinam and ChronoCross can you put in this package everything is need something like GK pack.
It's what I had planned. everything cept nero's stuff.
shon3i
13th April 2006, 00:29
everything cept nero's stuff.
That is ok.
berrinam
13th April 2006, 09:37
0.2.3.2124 13 April 2006
Commit by berrinam:
- Intermediate file deletion now deletes *all* intermediate files except for besweet log files
- Fix crash with Delete Intermediate files and Delete Completed jobs
berrinam
13th April 2006, 15:51
0.2.3.2125 13 April 2006
Commit by berrinam:
- If aspect error due to non-ITU resizing exceeds an amount given in Settings, default to ITU resizing
max-holz
13th April 2006, 16:49
I repeat my request. It seems that the refactoring will not come out shortly,so could you pass the project to sourceforge SVN that works correctly please.
Sharktooth
13th April 2006, 17:33
well... we need the doom9 authorization
in the meantime im uploading the new sources to files.x264.nl <-- EDIT: done
Doom9
13th April 2006, 21:42
would you like to manually merge a couple dozen files?
berrinam
14th April 2006, 00:44
@Doom9: does a restructure of the Audio UI/AudioStreams stuff clash with your refactor? Specifically, this means modifications of all the event handlers for the Audio section in the main form, as well as a modification of convertLanguagesToISO in MuxWindow.cs. To be safe, I've submitted these modifications as a patch, but if they don't clash, then I'll commit them to the CVS.
Changes:
-Fixed 'audio/input types are incompatible' error message
-Freed up the users options regarding audio input/output
-Fixed crash in convertLanguagesToISO
Patch description on SF: http://sourceforge.net/tracker/index.php?func=detail&aid=1470138&group_id=156112&atid=798478
Patch file on SF: http://sourceforge.net/tracker/download.php?group_id=156112&atid=798478&file_id=174516&aid=1470138
When applying the patch, you'll have to add my changes to the changelog, as well as modify AssemblyInfo to reflect whatever version number you choose to call this.
Doom9
14th April 2006, 13:14
@berrinam: a couple pages ago I posted a link to the current status of my code.. dimzon wanted to have a look but I haven't heard anything yet. All the changes that concern the main window are finished.. changes are only forthcoming in the autoencoding and one click window, job generation and job processing (okay, that will have an influence on the main form).
I have made a few fixes to MeGUI for issues I was experiencing myself. Maybe someone can include these in the src?
1. One-click configuration dialog populates its audio profile combobox twice with all available profiles, because it does this when the container changes (during initialization) and later again when the audio profile combobox should be filled for the first time. Fix: comment out the second fill code. Or even better: have a single method which remembers the selected profile, repopulates the combobox and reselects the original profile again (if it's still available) or selects the first profile (otherwise). I would have done that but didn't want to change so much code without being able to check in.
OneClickConfigurationDialog.cs
...
if (videoIndex > -1)
videoProfile.SelectedIndex = videoIndex;
// FIX: stop audioProfile combobox from being populated twice with all
// profiles (one time as a sideeffect from setting containerFormat.SelectedIndex
// above, the second time here. XXXXX
/*
foreach (string name in mainForm.Profiles.AudioProfiles.Keys)
{
this.audioProfile.Items.Add(name);
}
if (audioIndex > -1)
audioProfile.SelectedIndex = audioIndex;
*/
foreach (string name in mainForm.Profiles.OneClickProfiles.Keys)
...
2. In one-click mode MeGui assumes that demuxed audio files have a T01, T02, T03... substring in their filename which indicates the track number. I have demuxed a PVA which was created by ProjectX and the audio file did not include a T01. The result was that no audio job was added to the queue and the video had no audio. I have worked around this in VideoUtil.cs getAllDemuxedAudio() by removing the "T0X" substring detection but hesitated to do more (because the code might have changed already and I couldn't check in). I suggest a fallback: if no audio file matches T?? all audio files should be added.
3. AviSynthWrapper.Dll dimzon_avs_init() does not support international characters in .d2v filenames. With parameter arg = "Wände.avs" I get this error:
MPEG2Source : unable to load D2V file \"Wände.d2v\" \n(Wände.avs, line 4)
if(0!=dimzon_avs_init(ref _avs, func, arg, ref _vi, ref _colorSpace, ref _sampleType, forceColorspace.ToString()))
{
string err = getLastError();
cleanup(false);
throw new AviSynthException(err);
}
DC
dimzon
14th April 2006, 14:42
3. AviSynthWrapper.Dll dimzon_avs_init() does not support international characters in .d2v filenames. With parameter arg = "Wände.avs" I get this error:
MPEG2Source : unable to load D2V file \"Wände.d2v\" \n(Wände.avs, line 4)
if(0!=dimzon_avs_init(ref _avs, func, arg, ref _vi, ref _colorSpace, ref _sampleType, forceColorspace.ToString()))
{
string err = getLastError();
cleanup(false);
throw new AviSynthException(err);
}
this is not AviSynthWrapper.Dll problem, this is avisynth problem
dimzon
15th April 2006, 00:27
@Doom9
I'm sorry. I'm @ heavy deadline pressure. I was @ work during last weekend and I will be @ work this and next weekend too..
So I have no time to take close look @ Your sources, I'm very sorry... Maybe I will have more free time after May 10...
PS. My office PC has been broken again (3-rd time diring last 4 month). Overheat caused motherboard condensers exploision... :devil: :devil: :devil: Seems like I'm cursed...
Doom9
15th April 2006, 10:22
well.. my work PC needs a windows reinstall.. the usual tricks (removing no longer used software and defragmenting) do not help anymore. Oh, and it needs tons more ram.
dimzon
15th April 2006, 13:26
Oh, and it needs tons more ram.
<offtopic>
My office PC has 1.5GB RAM, Yeah!
</offtopic>
goldencoin5
15th April 2006, 23:48
i m a new bie n the prob is that how can i convert my DIGITAL VIDEO to AVI with MEGUI ?
with staxrip i m doing it very easily but wann'a try MEGUI ?
when i open a .ts file it says CHECK YR PIDZZZ
i open it with d2v creator :helpful:
berrinam
16th April 2006, 01:42
0.2.3.2126 15 April 2006
Commit by berrinam:
- Fixed issue with audio combobox in OneClickProfileConfig'er being populated twice (thanks to DC)
2. In one-click mode MeGui assumes that demuxed audio files have a T01, T02, T03... substring in their filename which indicates the track number. I have demuxed a PVA which was created by ProjectX and the audio file did not include a T01. The result was that no audio job was added to the queue and the video had no audio. I have worked around this in VideoUtil.cs getAllDemuxedAudio() by removing the "T0X" substring detection but hesitated to do more (because the code might have changed already and I couldn't check in). I suggest a fallback: if no audio file matches T?? all audio files should be added.
Good idea, but there is the possibility of a better solution, which I posted about here (http://forum.doom9.org/showthread.php?p=813198#post813198)
Doom9
16th April 2006, 12:44
I suggest a fallback: if no audio file matches T?? all audio files should be added.megui only supports two audio tracks... I'd much prefer berrinam's approach.. it's more informative, and error resiliant as we could finally scrap the "find demuxed audio" routine and instead know for sure what it is we're looking for.
Mutant_Fruit
16th April 2006, 17:31
Hi,
Sorry for vanishing for so long. I was away on holidays in lavigno skiing over my easter break from college and i managed to damage myself a little :P
Anyway, with my summer exams coming up in less than a month i've been overloaded with study and whatnot, so i don't have much time to mess around with code. Here's the current status on the AutoUpdate:
Firstly, i havn't really touched it in a few weeks, so i may have forgotten some problems with it. I went through it today, commented some bits of it and wrote a little .doc with some info on what has to be done (that i remember) and what i have done. It's mostly done. It just needs a few tweaks here and there
If anyone does want to continue it on, feel free to PM me (i mightn't be on the forums too much, so i might miss a post).
Once again, sorry for vanishing off for so long, i got quite distracted with all the work i have to be doing.
In the zip file there are two folders. The CVS version is the CVS version of MeGUI that i was working off when i started this. The New Version is the version with the AutoUpdate code and all that. The document is just a list of TODO's and a quick explanation of the code and some of the important points.
Source code (http://www.fileshack.us/files/741/Update.rar)
EDIT: The "server" url in the code needs to be changed as the files are now in http://megui.org/auto/ as opposed to http://megui.org/
megui only supports two audio tracks... I'd much prefer berrinam's approach.. it's more informative, and error resiliant as we could finally scrap the "find demuxed audio" routine and instead know for sure what it is we're looking for.
I realize that there are problems with my suggestion, first of all the order. Currently one-click allows to select a generic Track 1, Track 2, ... but if we add all available tracks it can be hard to determine which one is track 1.
However, I have a bunch of already demuxxed m2v/mp2 files which come from ProjectX. And I need ProjectX to read my .rec files (which come from a Topfield receiver) and I also need it to fix audio sync problems - which requires it to demuxx the media. I tried having ProjectX convert to PVA and DGIndex demuxx but the result was bad audio sync (really bad, variable offset). Seems I have to stick with PX and its demuxxing (and I also cut with PX).
Bottomline is I have demuxxed audio already and DGIndex can't know any better than MeGui which audio it is. But it's not like there were dozens of totally unrelated filenames for audio tracks. Usually there one or two with the same name as the video and extension ac3 or mp2. If one-click could have the real audio filename in its combobox (instead of Track 1, 2, ...) neither MeGUI nor the user would have to guess which track to use...
berrinam
17th April 2006, 03:09
If anyone does want to continue it on, feel free to PM me (i mightn't be on the forums too much, so i might miss a post).I've managed to compile this, integrate it with the newest CVS, and make a few changes. I'll try to get this finished and committed into CVS soon.
@Richard: Could you sort out some way of me getting access to megui.org please, so I can play around with the auto-update files? Also, what's up with http://megui.org/mediawiki/ ? There seems to be a folder there, but it redirects to http://megui.avisynth.org/mediawiki/index.php/Main_Page which gives a 'can't find server' error.
ChronoCross
17th April 2006, 03:46
Okay everyone. Now that my easter break is over, I've finished the installer for the essentials package. This should be installed by everyone who is new to megui and having problems.
Note: Nero Audio codecs not included due to licensing issues. Please download nero from www.nero.com and find aac.dll and accenc32.dll to encode using nero.
Essentials Package with MeGUI 2.3.2125 (http://chronocrossdev.com/apps/megui/MeGUI-Essentials.exe)
Doom9
17th April 2006, 14:05
If one-click could have the real audio filename in its combobox (instead of Track 1, 2, ...) neither MeGUI nor the user would have to guess which track to use...You want something else: being able to manually select audio streams instead of having dgindex demux them. If you have a DVD, where the 8 streams really come from, if you don't have the info file it's your own bad.. those that rip as they ought to for megui will have a nice dropdown with all the languages the DVD has.
When it comes to digiTV streams, dgindex just offers the track1-8.. what could megui do different than offer the same so that it would be more clear?
Keep in mind, you have an entire different workflow. the one clicker is for people who demux with dgindex. And this is a discussion for the suggestion thread.
sillKotscha
18th April 2006, 02:52
Okay everyone. Now that my easter break is over, I've finished the installer for the essentials package.
thank you for that installer... very nice :)
two things to mention:
1. for the beginners there should be a hint to put the aac.dll and the aacenc32.dll into the besweet folder (if they want to use nero for audio encoding) and
2. you should definitely remove your logs ;)
thank you
Sill
Edit: you'll find mencoder doubled... as it should (mencoder.exe) but mencoder.rar as well -> does make the package smaller if removed ;)
Edit 2: and you'll find another mencoder.exe within \tools\MKVtoolnix\mencoder.exe -> another 11,4 MB to remove from the package...
you seem to love mencoder :) that leads to my last question... why isn't the xvid encoder xvid_encraw but mencoder?
ChronoCross
18th April 2006, 04:20
sorry I forgot about all the copies I had floating around in there. there are issues with mencoder and largefiles. I had been working on a fix for that. I finally got it however I think there is a problem with the current one I have unzipped. the one in the rar is probably the best to use. I will have that fixed in the next updated release(atomorrow sometime)
berrinam
18th April 2006, 07:05
I believe the newest xvid_encraw isn't supported by MeGUI at the moment, so it is best to stay with mencoder for the time being.
@ChronoCross: The AviSynth plugins need to go in the AviSynth plugin directory (given by LocalMachine\Software\AviSynth\plugindir2_5 in the registry). Also, you may have noticed that I Mutant_Fruit uploaded the source code to his autoupdate code, and I am working on it. I hope to finish it soon, so that could eliminate the need for all the extra files required in a package.
ChronoCross
18th April 2006, 07:14
I'll make a readme of things needed to be done manaully( I have not figured out how to do things such as reading from the registry. but yeah the next version will be greatly improved.
Oh also could you remove -noodml from the mencoder huffy commandline in cvs? it won't allow for greater than 4GB.
sillKotscha
18th April 2006, 07:14
I believe the newest xvid_encraw isn't supported by MeGUI at the moment, so it is best to stay with mencoder for the time being.
thanks for clarification :)
ChronoCross
19th April 2006, 00:34
I've redid the essentials package to make the corrections. It also has a readme. The size is now greatly reduced. 10MB.
berrinam
19th April 2006, 01:44
I'll make a readme of things needed to be done manaully( I have not figured out how to do things such as reading from the registry. but yeah the next version will be greatly improved. Don't overstress yourself with making the installation do everything right now. Maybe we should come up with a verdict on how we will do distributions (auto-update or not) from my post (http://forum.doom9.org/showthread.php?p=814983#post814983) first.
Oh also could you remove -noodml from the mencoder huffy commandline in cvs? it won't allow for greater than 4GB. Have you now managed to make an mencoder build that works with big files? In that case, I will certainly remove it.
ChronoCross
19th April 2006, 04:04
yeah the one that I have included in the package works with large filesizes. it took 2 different patches and some time reading and asking questions on the mplayer mailing list.
As for the auto update I'm all for that. all we need is a place to store the stuff, decisions on directory structure and the ability for someone to update and check for other updates when necessary.
berrinam
19th April 2006, 04:49
yeah the one that I have included in the package works with large filesizes. it took 2 different patches and some time reading and asking questions on the mplayer mailing list.Great. I'll update the commandlines, then.
As for the auto update I'm all for that. all we need is a place to store the stuffmegui.org
decisions on directory structureAt the moment, this follows what is already set up. As in, it is currently designed for updating an already-configured system, so it simply replaces the files wherever they are with a new version. I'm considering adding a 'setup' preset/mode of operation, which will get everything and put it in a new directory structure (my idea is listed at the end of this post).
the ability for someone to update and check for other updates when necessary.I don't get that. Are you basically saying that we need the ability to run auto-update? Isn't that obvious?
My proposed directory structure:
%meguidir%\tools\x264\
\mencoder\
\xvid_encraw\
\neroraw
\faac\
\lame\
\besweet\
\mkvmerge\
\mp4box\
It's similar to what you currently do with your installer, but it ensures that files with the same names in various packages (especially things like readme.txt) don't override each other.
ChronoCross
19th April 2006, 04:59
I don't get that. Are you basically saying that we need the ability to run auto-update? Isn't that obvious?
I actually meant an admin to control the files that need updating. Someone to actually go out, look for any updates and then place them on the site for updating. (filters, programs among other things)
berrinam
19th April 2006, 05:23
0.2.3.2127 19 April 2006
Commit by berrinam:
- Allow relative pathnames for encoder files
riggits
19th April 2006, 10:16
0.2.3.2127 19 April 2006
Commit by berrinam:
- Allow relative pathnames for encoder files
This is a landmark moment in MeGUI history :)
Thanks berrinam!
berrinam
19th April 2006, 10:52
This is a landmark moment in MeGUI history :)
Thanks berrinam!
Hahahaha! :D The changes for that revision are just overwhelming: two extra lines, both executable = Path.Combine(Application.StartupPath, executable);
Just goes to show that the amount of work required for a change has absolutely no relation to the value that the users place on it.
max-holz
19th April 2006, 12:21
I have a silly question.
What Sourceforge thinks about his ridicolous cvs? :D
ChronoCross
19th April 2006, 16:44
I haven't been able to update in about a month. So I haven't made a build past 2125
Sharktooth
19th April 2006, 22:40
latest sources are here: http://files.x264.nl/?dir=./Sharktooth/megui/Sources
However, time to move to SVN... at least it works.
max-holz
20th April 2006, 01:28
From Sourceforge:
( 2006-04-14 11:18:04 - Project CVS Service ) As of 2006-04-14 we have an estimate on when the replacement CVS hardware for the new infrastructure will arrive. As soon as we get in into our hands, we'll actively work on it, with a goal of having it online by the end of the month of April. This is a best guess, and may not get hit due to the aggressive timeline we have placed on this project. However, be assured that recovery of this service in full is our highest priority. The sync process between developer and anonymous CVS (ViewCVS, etc.) is disabled now until the new infrastructure is in place, to ensure we have maximum coverage for the small number of data corruption issues that have been detected. We understand this is sub-optimal, but strongly believe that the protection of the data is paramount.
ChronoCross
20th April 2006, 07:01
with sharktooth's sources I added the latest build. Stupid sourceforge.
berrinam
20th April 2006, 12:57
0.2.3.2128 20 April 2006
Commit by berrinam:
- Fix SAR labels to DAR in config windows
Sharktooth
20th April 2006, 15:12
2128 sources are up.
ill try to keep the archive updated as much as i can.
berrinam
21st April 2006, 00:33
0.2.3.2129 20 April 2006
Commit by berrinam:
- Allow the user to choose how to achieve mod16 in AR in the script creator
berrinam
23rd April 2006, 09:24
*Bump*
@Richard: Could you sort out some way of me getting access to megui.org please, so I can play around with the auto-update files? Also, what's up with http://megui.org/mediawiki/ ? There seems to be a folder there, but it redirects to http://megui.avisynth.org/mediawiki/index.php/Main_Page which gives a 'can't find server' error.
Sharktooth
24th April 2006, 04:08
0.2.3.2129 bins: http://files.x264.nl/force.php?file=./Sharktooth/megui/MeGUI-0.2.3.2129.7z
berrinam
24th April 2006, 07:27
I had another look at Doom9's sources for his refactor, and I've now got a working copy. I have to merge these sources with the latest revision (a task I'm not looking forward to), and then after some testing, I hope I can commit.
Doom9
24th April 2006, 12:14
and I've now got a working copyUmm.. you finished all that was left open (starting with codec -> outputtype finding)? Because without that, the autoencoding thing is very unlikely to work. The one clicker will work since it uses old code, bit it should be upgraded to use the new code as well.
berrinam
24th April 2006, 23:19
I had a primitive working copy that compiled and generated paths. There's more left to do than I thought, but the path-building seems to be working.
ChronoCross
24th April 2006, 23:39
Berrinam could you update the x264 config dialog to include the new switches?
berrinam
24th April 2006, 23:50
Can you tell me what they are, because I haven't been following x264 development too closely?
I believe that some of these are non-SVN. Should I split up MeGUI into SVN and non-SVN again?
ChronoCross
25th April 2006, 00:01
SVN
--no-dct-decimate
non-svn
--aq-tcplx <int> non-svn however I don't recommend using it as it's still not working right with bframes.
--aq-strength <float>
--aq-sensitivity <float>
I don't think there is any need to split it up again. Just to add the first and save the other 3 for reference in future builds.
Doom9
25th April 2006, 08:29
I had a primitive working copy that compiled and generated paths.Well.. the paths were already working.. but it was based on the audio/video output type selected in the main window.. not just the codec. And if a path contained more than one muxer, that wouldn't work.
berrinam
25th April 2006, 10:03
Well, I've now got a recursive path-finding algorithm, that *should* work based on the codec, not the output type, and it can find mux paths with any number of muxers.
I made some changes to your path-finding algorithm, so that it doesn't need the muxers to be in the order they are listed within the code, and also so that all possible mux paths are considered. I also added another class which helps choose the 'best' mux path, so that further additions to that are easier.
I was also a bit confused by a few of the methods, like the one called 'humba,' but I figure they weren't used.
Also, I'm not convinced that this mux path method is the best one. The reason is that it presumes that once something has been muxed into the big thing (ie it has been removed from the unhandled set), it is sorted. This isn't necessarily the case. I can't actually see any problems with our current feature set, but let me just give a (somewhat stupid) hypothetical situation:
Let's say that we need to mux TWO AVC streams into VFW-based mkv (as I said, it's stupid, but it illustrates my point). What this needs is avc2avi being run once on each of those streams, followed by mkvmerge joining these AVIs. However, the current algorithm won't work with this because:
1. It assumes that if you can mux one file in, you can mux as many as you want.
2. Assuming assumption 1 is not the case (because it is quite easy to change that) the first avc file would be converted to avi, and then the next muxpathleg would try to import that avi and add another, but avc2avi can't import avis. This is a problem of the serial nature of the mux-paths.
Ok, so it's a stupid example, but imagine we had some tool like that for audio. Then we might get some problems. I'm thinking about doing a even more complex algorithm which can handle parallel mux steps which all get muxed together at the end.
EDIT: I'm getting carried away. It's overly hypothetical, and I think KISS works for now.
Doom9
25th April 2006, 12:57
Let's say that we need to mux TWO AVC streams into VFW-based mkvNever going to happen for two reasons: 1) megui won't support vfw mode for avc and if you have asp, the best mux path is avi -> mkv. The asp encoders can do direct avi output, in case of encraw even mkv. Then two video streams will never be supported either as it's a special 0.000000001% usecase.
Basically what I've been thinking of is single video stream two audio stream scenarios with the current video output and audio output types and the current containers. There's no new container on the horizon and the same goes for video and audio output types so I figure even if there's a new muxer, we'll be okay.
When you mention audio I know what you're getting at but I think that scenario is a bit too far fetched.. in the end I presume that one muxer can handle all audio types that a particular container supports, or we just don't support all audio types. mkvmerge supports all mkv supported audio types (or at least the once that make sense supporting), the same goes for avimuxgui and for mp4box.
I was also a bit confused by a few of the methods, like the one called 'humba,' but I figure they weren't used.I'm sorry about that.. the code was really left completely unfinished.. I had the basic thing working then I started to make some changes and they were left without ever being completed.
Sharktooth
26th April 2006, 21:27
0.2.3.2130 26 April 2006
Commit by Sharx1976:
- Fixed a glitch in x264 command line generation: Direct mode was set even with 0 b-frames.
berrinam
28th April 2006, 11:53
@Doom9: In your refactor, why is there both the enum VideoType and the class VideoOutputType? Similarly for AudioType/AudioOutputType. I suggest a single class:
OutputType, which is just the same as what is currently called ContainerOutputType. The only difference at the moment between ContainerOutputType and VideoOutputType is that VideoOutputType has a VideoType property (similarly for AudioType). Then, we just statically create one instance of OutputType for every video type (mp4, mkv, avi, rawavc, rawasp, etc), every audio type, and every subtitle type.
This means we won't be needing to keep lists of types in List<object>s any more, and it means that there are no problems with finding, say, the file extension given an AudioType, something which before required listing the audiooutputtypes and checking them against the the AudioType to see if they match.
berrinam
30th April 2006, 09:37
0.2.3.2131 30 April 2006
Commit by berrinam:
- Added x264 '--no-dct-decimate' option
Sharktooth
1st May 2006, 16:36
CVS commit:
updated x264 Context Help.
new .2131 sources are available here: http://files.x264.nl/?dir=./Sharktooth/megui/Sources
Eric B
2nd May 2006, 21:33
3 pure GUI remarks about MeGUI:
- why is the main form not resizable (Locked property) ? You can set the current size as min size.
- why is Ctrl+C used as Chapter Creator? Is is usually reserved for copy (e.g from log) ?
- could you add an Icon (application properties) ?
berrinam
2nd May 2006, 23:09
Please look in the Feature Request thread and post there for feature requests. However,
1. If it was resizable, then all that would happen is that you would get a lot of blank space. The GUI is not set up to scale.
2. This is already listed on the Feature Request thread.
3. As is this. If someone could provide us an icon, that would be really good.
berrinam
3rd May 2006, 00:19
@Doom9: Could you post a link to the version of xvid_encraw that you want MeGUI to support in the refactor please?
ChronoCross
3rd May 2006, 01:28
ftp://squid80.no-ip.com/xvid_encraw.zip
this is the most recent version. I think it supports everything already in terms of encoding features. I would have to check.
@berrinam: the version chronocross linked to is exactly what should work.. the commandline creator should be uptodate as shoul d the options but I did that in March.. something might have changed.
In your refactor, why is there both the enum VideoType and the class VideoOutputType?Because videooutputtype includes containers whereas VideoType doesn't. VideoType was there before (I think). .and it just wasn't enough so I created something new without bothering too much about going over existing stuff (I didn't want to break everything at once).
But ContainerOutputType.. RAW ASP isn't a container output type.. it's a video output type.. whereas VideoOutputType.MP4 = just video in MP4.. and ContainerType.MP4 = MP4 containing whatever. So there's a difference. But basically it comes down to the question if you can manage every scenario when you make some changes, keeping in mind that for instance you have an encoder that does raw avc output, then you mux that into an avi (just the video stream) and another muxer adds audio to that (it's the worst case scenario I think we have to deal with.. but if you feel like it you can consider using another two muxers to add a subtitle type each ;)
Sharktooth
3rd May 2006, 14:30
0.2.3.2132 3 May 2006
Commit by Sharx1976:
- Removed all the remaining #if SVN
- Some x264 config dialog cosmetics
sources: http://www.webalice.it/f.corriga/megui/MeGUI-src.CVS-0.2.3.2132.7z
bins: http://www.webalice.it/f.corriga/megui/MeGUI-0.2.3.2132.7z
Kostarum Rex Persia
3rd May 2006, 16:37
Sharktoothj, do you include explanation for "--no-dct--decimate" option.
What do you suggest, should I use this option or not?
ChronoCross
3rd May 2006, 18:19
Sharktoothj, do you include explanation for "--no-dct--decimate" option.
What do you suggest, should I use this option or not?
sigh I can't believe your posting again.....to answer your question it will raise quality so yes you should use it.
Kostarum Rex Persia
3rd May 2006, 19:58
Thank you, but MeGUI doesn't have explanation for that option.
I want to know how --no-dct--decimate increases quality, and in which cases?
and I want to know why you are posting in a development thread when you obviously have no clue about development. Don't bother to answer though because it just further pollutes this thread.
berrinam
4th May 2006, 02:36
@berrinam: the version chronocross linked to is exactly what should work.. the commandline creator should be uptodate as shoul d the options but I did that in March.. something might have changed.That's fine, I just wanted to know what to test with.
It's all getting there, gradually. Both the AutoEncode window and the OneClick window are now aware of this pathfinding method, which seems to be working (and it is based on the codec type, not the container it is put in, so that's also finished).
Integration of AviMux_GUI is a problem... as far as I can tell, it doesn't support everything through commandlines. That in itself is not a problem, but there also seems to be no way to close the window through its own scripting language, and there is also no progress report sent to the commandline. Unless you have any other ideas, I will go ahead without it (which means that AVI muxing won't be possible, but thanks to path-finding, this won't appear in the places it isn't supported).
Sharktooth
4th May 2006, 03:02
FFS, why adding AVI muxing when you already have MKV and MP4?
FFS, why adding AVI muxing when you already have MKV and MP4?Because AVI is still the most used containers for codecs other than AVC. Putting XviD for instance into MP4 is more of a hassle than sticking with AVI.. and there's the standalone angle for some people, too.
As far as the avimux gui integration goes.. you have to write a script in the gui's language.. but it allows you to control everything. Then you launch the process and register a callback for the exit method, but there's no stdout and stderr processing. As far as aborting goes, you kill the process, plain and simple.. you could send a close command to the GUI but that might trigger a question box and that's not really what we want and it would be inconsistent with aborting dgindex where the process is just being killed - no questions asked.
berrinam
4th May 2006, 13:00
With the script provided on the reference manual, the GUI doesn't quit after it has finished the job, and I can't find any script command which closes the GUI.
I think you missed this part from the scripting manual:
SET OPTION CLOSEAPP n If set to 1, the application will be closed as soon as the muxing process is finished.
berrinam
4th May 2006, 14:23
I did indeed miss it. However, it is in the test file I was using (from the manual): CLEAR
LOAD h:\movies\akte-x-mv.avi
LOAD h:\movies\akte-x-eng.ac3
LOAD h:\movies\akte-x-fr.ac3
SELECT FILE 1
ADD VIDEOSOURCE
SET OUTPUT OPTIONS
WITH SET OPTION
WITH AUDIO
NAME 1 english
NAME 2 french
DELAY 2 -88
END WITH
OVERWRITEDLG 0
CLOSEAPP 1
ALL AUDIO 1
OPENDML 1
LEGACY 0
REC LISTS 1
AUDIO INTERLEAVE 250 KB
NUMBERING OFF
MAXFILESIZE OFF
MAXFILES OFF
END WITH
START h:\movie\akte-x.aviand it does not close after muxing. Experimenting with CLOSEDLG also does not help...
could not having SET OPTION DONEDLG n be a problem? If you get a dialog after muxing, then presumably the app wouldn't be closed until the dialog has been clicked away. If it isn't that.. time to ask Alex.. either we are misreading the specs or the app doesn't do what it's supposed to (make sure you're using at least version 1.15 as this is the one in which those commands were introduced).
Romario
5th May 2006, 03:47
Doom9, when we should expect MeGUI with new code, with your refactor. Soon, or...
ChronoCross
5th May 2006, 04:10
Doom9, when we should expect MeGUI with new code, with your refactor. Soon, or...
okay your an ass. it will be here when it's here. until then we have a stable version that is perfectly good for use. do not bug developers for stupid things like that.
Yama4050242
5th May 2006, 07:03
0.2.3.2131 30 April 2006
Commit by berrinam:
- Added x264 '--no-dct-decimate' option
any reading about this setting?
soresu
5th May 2006, 07:14
Suggestion here: Maybe all the MeGUI devs should have a warning added on to any post when they add something/commit, otherwise people will repeat questions on things that have no relevance to the developers thread?
:stupid:
Sharktooth
5th May 2006, 15:10
or we just need to get the dev discussion private...
or we just need to get the dev discussion private...I think that would be a waste of time considering it takes time to set something up and then you have one forum more to check out. I just have to be more active in enforcing the "no non development discussion" guidelines and back it up with rule 16 strikes.. it worked for the x264 download sticky so it will work here, too.
berrinam
6th May 2006, 09:00
0.2.3.2133 6 May 2006
Commit by berrinam:
- First commit of mux-path-finding refactor. Work in progress (development build)
Ok, the refactor is committed. IT IS NOT A STABLE BUILD. It's got pathfinding, and the autoencode window and one click window are aware of it. There is also a new mux window: adaptive muxer, which is a direct interface to the path-finding.
Avi mux gui integration is still missing, simply because I haven't got around to it. However, the committed version thinks that it exists (only one line needs to be commented out to fix that, but it's still in there just so you can see how it _would_ work), and it will simply throw an exception if you try to run it.
The Mux windows have been redone so that they use visual inheritance, and there are in fact only two mux windows: adaptive muxer as described above
A mux window which adapts itself to a given IMuxing instance
The One Click Window has been modified in a few ways to allow more control, especially over audio inputs.
The audio section has hardly been changed, because I have never looked at that section, and I have no idea what is going on there. As a result, there is still a 'Use Besweet' checkbox in the config dialogs, but there are no BeSweet encoders registered (I think).
xvid_encraw is supported, and from a single test I did, it seems to be working. Some of the commandlines are wrong, according to squid_80, but I haven't touched that at all. I've just committed this so that the massive changeset can finally be part of CVS.
Let's move to SVN now since the biggest pending code change is over.
@dimzon: Hopefully the refactor should mean that MeGUI is just about ready for many new audio encoders. Can we do that soon?
dimzon
6th May 2006, 09:06
@dimzon: Hopefully the refactor should mean that MeGUI is just about ready for many new audio encoders. Can we do that soon?
I will unaccessable up to May 15 (some sort of vacation). Please wait for me.
I'm already write some code yesterday (for BeHappy but we can use it in MeGUI too)
New ND AAC dialog in action
http://img522.imageshack.us/img522/5394/untitled4dp2.jpg
Let's move to SVN now since the biggest pending code change is over.No objections here, but another sf admin should do it.. somebody familiar with CVS and SVN.. I've never even used SVN so I don't know what to expect.
berrinam
6th May 2006, 14:40
Looking into AVIMux GUI, it seems like it may not be the right thing for MeGUI after all, because it is specifically designed as a GUI, which means error messages are shown in a message box, which disrupts the automated flow of things. I've spoken with Alex Noe about this, and it seems that it would take too much time to give it a nice CLI.
Sharktooth
6th May 2006, 15:22
ok... i've just finished backing up the CVS.
I started the SVN migration...
I'll update this post later... it may take some hours.
PLEASE DO NOT COMMIT NEW CODE UNTIL THE MIGRATION IS FINISHED!
EDIT: Good news... import failed... working on a fix
EDIT2: Uhm... i starting loosing hope, i cant download the latest CVS tarball since the Anonymous CVS is still down so i cant do a manual cvs2svn. I swear at SF (will they ever learn to make snapshots from the dev CVS?!?!?).
EDIT3: I started populating the SVN just importing data. That means all the CVS version changes will be lost. However the CVS will still work...
EDIT4: I enabled the SVN access for developers. Info on accessing the SVN are located here: https://sourceforge.net/docs/E09.
SVN is up to date: http://svn.sourceforge.net/viewcvs.cgi/megui/
Sharktooth
6th May 2006, 16:17
If the version changes are crucial we should wait until the anon CVS is working again.
At that point i can eventually migrate the CVS to SVN again and keep the version changes.
EDIT: Just a remark: DEV CVS IS STILL WORKING.
@berrinam: well, is there any alternative? It's not like there's any useful muxer that can handle all kinds of formats.
Kurtnoise
6th May 2006, 18:08
Why not using DivxMux ? It supports mp3, ac3 for audio; all mpeg-4 asp for video streams and srt, idx/sub or txt for subtitles.
[edit]Forgot to add the link. This is of course a cli tool :: http://download.divx.com/labs/DivXMediaFormat_SDK_r2.rar
what about avc video (previously muxed into avi with avc2avi) and is there a way to get traditional avis out of it? I know they're supposed to be compatible.. but are they really?
ChronoCross
6th May 2006, 19:50
I've started working with the svn. the following profile needs to be removed fromt he build list, or fixed. Compile.bat doesn't work cause I think it's using this profile.
------ Build started: Project: MeGUI, Configuration: test Any CPU ------
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Csc.exe /noconfig /unsafe- /checked- /nowarn:1701,1702 /nostdlib- /errorreport:prompt /warn:1 /baseaddress:285212672 /reference:.\ICSharpCode.SharpZipLib.dll /reference:MessageBoxExLib.dll /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.VisualBasic.dll /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Data.dll /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.dll /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Drawing.dll /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Windows.Forms.dll /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll /debug+ /debug:full /filealign:4096 /optimize- /out:obj\test\MeGUI.exe /resource:obj\test\MeGUI.AutoEncodeWindow.resources /resource:obj\test\MeGUI.AviSynthWindow.resources /resource:obj\test\MeGUI.avsConfigurationDialog.resources /resource:obj\test\MeGUI.baseAudioConfigurationDialog.resources /resource:obj\test\MeGUI.Calculator.resources /resource:obj\test\MeGUI.ChapterCreator.resources /resource:obj\test\MeGUI.baseMuxWindow.resources /resource:obj\test\MeGUI.CropDialog.resources /resource:obj\test\MeGUI.AdaptiveMuxWindow.resources /resource:obj\test\MeGUI.faacConfigurationDialog.resources /resource:obj\test\MeGUI.MeGUI.resources /resource:obj\test\MeGUI.lameConfigurationDialog.resources /resource:obj\test\MeGUI.MuxWindow.resources /resource:obj\test\MeGUI.neroConfigurationDialog.resources /resource:obj\test\MeGUI.lavcConfigurationDialog.resources /resource:obj\test\MeGUI.ProfilePorter.resources /resource:obj\test\MeGUI.snowConfigurationDialog.resources /resource:obj\test\MeGUI.x264ConfigurationDialog.resources /resource:obj\test\MeGUI.xvidConfigurationDialog.resources /resource:obj\test\MeGUI.OneClickConfigurationDialog.resources /resource:obj\test\MeGUI.OneClickWindow.resources /resource:obj\test\MeGUI.ProgressWindow.resources /resource:obj\test\MeGUI.QuantizerMatrixDialog.resources /resource:obj\test\MeGUI.SettingsForm.resources /resource:obj\test\MeGUI.SourceDetectorConfigWindow.resources /resource:obj\test\MeGUI.VideoConfigurationDialog.resources /resource:obj\test\MeGUI.VideoPlayer.resources /resource:obj\test\MeGUI.VobinputWindow.resources /resource:obj\test\MeGUI.ZonesControl.resources /resource:obj\test\MeGUI.App.ico /resource:obj\test\MeGUI.pause.ico /resource:obj\test\MeGUI.play.ico /resource:obj\test\MeGUI.Changelog.txt /target:winexe /warnaserror- /win32icon:App.ico AssemblyInfo.cs AudioCodecSettings.cs AudioEncoder.cs AudioJob.cs AudioProfile.cs AutoEncodeWindow.cs Avc2AviMuxer.cs AVCLevels.cs AviSynthAudioEncoder.cs AviSynthJob.cs AviSynthProfile.cs AviSynthProcessor.cs AviSynthSettings.cs AviSynthWindow.cs AvisynthWrapper.cs avsConfigurationDialog.cs AvsReader.cs baseAudioConfigurationDialog.cs BeSweetEncoder.cs CodecManager.cs CommandlineAudioEncoder.cs CommandlineMuxer.cs CommandlineVideoEncoder.cs BitrateCalculator.cs Calculator.cs ChapterCreator.cs CommandLineGenerator.cs baseMuxWindow.cs CropDialog.cs d2vReader.cs AdaptiveMuxWindow.cs AdaptiveMuxWindow.Designer.cs DeinterlaceFilter.cs DGIndexer.cs DGIndexPostprocessingProperties.cs DialogManager.cs DialogSettings.cs DirectShow.cs Encoder.cs EnumProxy.cs faacConfigurationDialog.cs FaacSettings.cs Form1.cs hfyuSettings.cs IMuxing.cs ISettingsProvider.cs IJobProcessor.cs IndexJob.cs IVideoEncoder.cs Job.cs JobHandler.cs JobUtil.cs lameConfigurationDialog.cs LanguageSelectionContainer.cs lavcSettings.cs MeGUISettings.cs mencoderEncoder.cs MencoderMuxer.cs MkvMergeMuxer.cs MP3Settings.cs MP4BoxMuxer.cs Muxer.cs MuxJob.cs MuxPath.cs MuxPathComparer.cs MuxProvider.cs MuxSettings.cs MuxWindow.cs MuxWindow.Designer.cs NeroAACSettings.cs neroConfigurationDialog.cs lavcConfigurationDialog.cs lavcConfigurationDialog.Designer.cs ProfilePorter.cs ProfilePorter.Designer.cs snowConfigurationDialog.cs snowConfigurationDialog.designer.cs x264ConfigurationDialog.cs x264ConfigurationDialog.designer.cs xvidConfigurationDialog.cs xvidConfigurationDialog.designer.cs OneClickConfigurationDialog.cs OneClickConfigurationDialog.Designer.cs OneClickProfile.cs OneClickSettings.cs OneClickWindow.cs OneClickWindow.Designer.cs Profile.cs ProfileManager.cs ProgressWindow.cs QuantizerMatrixDialog.cs ScriptServer.cs SettingsForm.cs Shutdown.cs snowSettings.cs SourceDetector.cs SourceDetectorConfigWindow.cs SourceDetectorConfigWindow.Designer.cs SourceDetectorSettings.cs StatusUpdate.cs VideoCodecSettings.cs VideoConfigurationDialog.cs VideoConfigurationDialog.designer.cs VideoEncoder.cs VideoJob.cs VideoPlayer.cs VideoProfile.cs VideoReader.cs VideoUtil.cs VobinputWindow.cs x264Encoder.cs x264Settings.cs XviDEncoder.cs xvidSettings.cs ZonesControl.cs ZonesControl.designer.cs
C:\msys\1.0\home\ChronoCross\MeGUI\ProfilePorter.cs(210,10): warning CS1030: #warning: 'We are generating a list of failed attempts, but we aren't doing anything with it (below).'
C:\msys\1.0\home\ChronoCross\MeGUI\CommandlineVideoEncoder.cs(207,10): warning CS1030: #warning: 'Must look into XviD PAR code.'
C:\msys\1.0\home\ChronoCross\MeGUI\Form1.cs(3385,10): warning CS1030: #warning: 'avi code over here'
C:\msys\1.0\home\ChronoCross\MeGUI\MuxWindow.cs(32,10): warning CS1030: #warning: 'muxjobs generated here have no knowledge of PAR'
C:\msys\1.0\home\ChronoCross\MeGUI\VideoUtil.cs(959,10): warning CS1030: #warning: 'This should be rearranged to work better'
C:\msys\1.0\home\ChronoCross\MeGUI\AviSynthWindow.cs(1556,10): warning CS1030: #warning: 'This is just quickfix, please check it!'
C:\msys\1.0\home\ChronoCross\MeGUI\d2vReader.cs(46,10): warning CS1030: #warning: 'Why load the video here? This means that we can't apply force film unless the video unless it is playable in AviSynth'
C:\msys\1.0\home\ChronoCross\MeGUI\Calculator.cs(1575,10): warning CS1030: #warning: 'look here'
C:\msys\1.0\home\ChronoCross\MeGUI\VideoUtil.cs(141,35): error CS0227: Unsafe code may only appear if compiling with /unsafe
C:\msys\1.0\home\ChronoCross\MeGUI\VideoPlayer.cs(668,23): error CS0227: Unsafe code may only appear if compiling with /unsafe
Compile complete -- 2 errors, 8 warnings
Edit: also I think it would be great if in the changelog we started a new numbering scheme. Since this build is drastically different from pre-refactor.
just use SVN 1
as for program version control we could instead of using 0.2.3 we should start using something like: 1.0.0.1 Alpha Since you are basically working on the more advanced version....but that's just MHO.
I'm not going to post a build until we figure out the naming scheme. Cause it has to be different from what the current cvs uses. Due to the differences.
Kurtnoise
6th May 2006, 21:02
what about avc video (previously muxed into avi with avc2avi)
Mux works fine with xvid or divx 4CC but doesn't work with h264 4CC.
and is there a way to get traditional avis out of it? I know they're supposed to be compatible.. but are they really?
What do you mean by traditional avis ?
berrinam
7th May 2006, 00:19
Since we need to add ffmpeg anyway (for m4v->avi muxing), we could *just* have that now, and add avimuxgui later, if it becomes more accessible (because avimuxgui is really the only tool that beats ffmpeg in avi muxing).
Muxers are basically dead simple to add now, and they should smoothly be able to drop in and out (they need a muxprovider, a commandline generater, and a Muxer class).
SVN is working for me. What do other people think about the situation with history from CVS? Following up on that, is it ok to commit to SVN now, or should we just wait until we have the full history imported?
Numbering system.... why not just use the SVN numbering system (like x264 does)?
ChronoCross
7th May 2006, 01:38
I think for the program versioning we should use
1.0.???? -> where ???? is the svn version. so right now it's 0001.
berrinam
7th May 2006, 02:06
MeGUI is nowhere near version 1 yet (IMO). Before that, I think it needs:
Support for extra muxers, including PSP's atomchanger
Auto update
Extra audio encoders
Video cutting
Sharktooth
7th May 2006, 02:38
versioning could be 0.9.r???? (where ???? is the SVN revision).
when refactoring and other crucial features will be completed we could move to a more convenient versioning like 1.0.r????.
for what concerns the CVS version history, there is ACTUALLY no way to keep it since the anon CVS isnt working but it can be migrated as soon as it gets up.
That means we should keep commiting changes to the dev CVS... or screw the CVS history by commiting changes to the SVN ignoring the old history...
ChronoCross
7th May 2006, 02:42
either way just make a decision and I'll go with it.
Sharktooth
7th May 2006, 02:43
either way just make a decision and I'll go with it.
... edited my previous post ...
berrinam
7th May 2006, 02:48
versioning could be 0.9.r???? (where ???? is the SVN revision).Yep.
That means we should keep commiting changes to the dev CVS... or screw the CVS history by commiting changes to the SVN ignoring the old history...Sourceforge now says they aim to have anon CVS back by May 12th if they're lucky, so I think we might as well wait the little extra time in case losing the history causes something drastic to happen
Sharktooth
7th May 2006, 02:53
ok, then keep commiting changes to the CVS. I'll migrate the whole thing (including history) again when anon CVS is back.
in the meanwhile ill take down the SVN.
Sharktooth
7th May 2006, 03:31
I've started working with the svn. the following profile needs to be removed fromt he build list, or fixed. Compile.bat doesn't work cause I think it's using this profile.
------ Build started: Project: MeGUI, Configuration: test Any CPU ------
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Csc.exe /noconfig /unsafe- /checked- /nowarn:1701,1702 /nostdlib- /errorreport:prompt /warn:1 /baseaddress:285212672 /reference:.\ICSharpCode.SharpZipLib.dll /reference:MessageBoxExLib.dll /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.VisualBasic.dll /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Data.dll /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.dll /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Drawing.dll /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Windows.Forms.dll /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll /debug+ /debug:full /filealign:4096 /optimize- /out:obj\test\MeGUI.exe /resource:obj\test\MeGUI.AutoEncodeWindow.resources /resource:obj\test\MeGUI.AviSynthWindow.resources /resource:obj\test\MeGUI.avsConfigurationDialog.resources /resource:obj\test\MeGUI.baseAudioConfigurationDialog.resources /resource:obj\test\MeGUI.Calculator.resources /resource:obj\test\MeGUI.ChapterCreator.resources /resource:obj\test\MeGUI.baseMuxWindow.resources /resource:obj\test\MeGUI.CropDialog.resources /resource:obj\test\MeGUI.AdaptiveMuxWindow.resources /resource:obj\test\MeGUI.faacConfigurationDialog.resources /resource:obj\test\MeGUI.MeGUI.resources /resource:obj\test\MeGUI.lameConfigurationDialog.resources /resource:obj\test\MeGUI.MuxWindow.resources /resource:obj\test\MeGUI.neroConfigurationDialog.resources /resource:obj\test\MeGUI.lavcConfigurationDialog.resources /resource:obj\test\MeGUI.ProfilePorter.resources /resource:obj\test\MeGUI.snowConfigurationDialog.resources /resource:obj\test\MeGUI.x264ConfigurationDialog.resources /resource:obj\test\MeGUI.xvidConfigurationDialog.resources /resource:obj\test\MeGUI.OneClickConfigurationDialog.resources /resource:obj\test\MeGUI.OneClickWindow.resources /resource:obj\test\MeGUI.ProgressWindow.resources /resource:obj\test\MeGUI.QuantizerMatrixDialog.resources /resource:obj\test\MeGUI.SettingsForm.resources /resource:obj\test\MeGUI.SourceDetectorConfigWindow.resources /resource:obj\test\MeGUI.VideoConfigurationDialog.resources /resource:obj\test\MeGUI.VideoPlayer.resources /resource:obj\test\MeGUI.VobinputWindow.resources /resource:obj\test\MeGUI.ZonesControl.resources /resource:obj\test\MeGUI.App.ico /resource:obj\test\MeGUI.pause.ico /resource:obj\test\MeGUI.play.ico /resource:obj\test\MeGUI.Changelog.txt /target:winexe /warnaserror- /win32icon:App.ico AssemblyInfo.cs AudioCodecSettings.cs AudioEncoder.cs AudioJob.cs AudioProfile.cs AutoEncodeWindow.cs Avc2AviMuxer.cs AVCLevels.cs AviSynthAudioEncoder.cs AviSynthJob.cs AviSynthProfile.cs AviSynthProcessor.cs AviSynthSettings.cs AviSynthWindow.cs AvisynthWrapper.cs avsConfigurationDialog.cs AvsReader.cs baseAudioConfigurationDialog.cs BeSweetEncoder.cs CodecManager.cs CommandlineAudioEncoder.cs CommandlineMuxer.cs CommandlineVideoEncoder.cs BitrateCalculator.cs Calculator.cs ChapterCreator.cs CommandLineGenerator.cs baseMuxWindow.cs CropDialog.cs d2vReader.cs AdaptiveMuxWindow.cs AdaptiveMuxWindow.Designer.cs DeinterlaceFilter.cs DGIndexer.cs DGIndexPostprocessingProperties.cs DialogManager.cs DialogSettings.cs DirectShow.cs Encoder.cs EnumProxy.cs faacConfigurationDialog.cs FaacSettings.cs Form1.cs hfyuSettings.cs IMuxing.cs ISettingsProvider.cs IJobProcessor.cs IndexJob.cs IVideoEncoder.cs Job.cs JobHandler.cs JobUtil.cs lameConfigurationDialog.cs LanguageSelectionContainer.cs lavcSettings.cs MeGUISettings.cs mencoderEncoder.cs MencoderMuxer.cs MkvMergeMuxer.cs MP3Settings.cs MP4BoxMuxer.cs Muxer.cs MuxJob.cs MuxPath.cs MuxPathComparer.cs MuxProvider.cs MuxSettings.cs MuxWindow.cs MuxWindow.Designer.cs NeroAACSettings.cs neroConfigurationDialog.cs lavcConfigurationDialog.cs lavcConfigurationDialog.Designer.cs ProfilePorter.cs ProfilePorter.Designer.cs snowConfigurationDialog.cs snowConfigurationDialog.designer.cs x264ConfigurationDialog.cs x264ConfigurationDialog.designer.cs xvidConfigurationDialog.cs xvidConfigurationDialog.designer.cs OneClickConfigurationDialog.cs OneClickConfigurationDialog.Designer.cs OneClickProfile.cs OneClickSettings.cs OneClickWindow.cs OneClickWindow.Designer.cs Profile.cs ProfileManager.cs ProgressWindow.cs QuantizerMatrixDialog.cs ScriptServer.cs SettingsForm.cs Shutdown.cs snowSettings.cs SourceDetector.cs SourceDetectorConfigWindow.cs SourceDetectorConfigWindow.Designer.cs SourceDetectorSettings.cs StatusUpdate.cs VideoCodecSettings.cs VideoConfigurationDialog.cs VideoConfigurationDialog.designer.cs VideoEncoder.cs VideoJob.cs VideoPlayer.cs VideoProfile.cs VideoReader.cs VideoUtil.cs VobinputWindow.cs x264Encoder.cs x264Settings.cs XviDEncoder.cs xvidSettings.cs ZonesControl.cs ZonesControl.designer.cs
C:\msys\1.0\home\ChronoCross\MeGUI\ProfilePorter.cs(210,10): warning CS1030: #warning: 'We are generating a list of failed attempts, but we aren't doing anything with it (below).'
C:\msys\1.0\home\ChronoCross\MeGUI\CommandlineVideoEncoder.cs(207,10): warning CS1030: #warning: 'Must look into XviD PAR code.'
C:\msys\1.0\home\ChronoCross\MeGUI\Form1.cs(3385,10): warning CS1030: #warning: 'avi code over here'
C:\msys\1.0\home\ChronoCross\MeGUI\MuxWindow.cs(32,10): warning CS1030: #warning: 'muxjobs generated here have no knowledge of PAR'
C:\msys\1.0\home\ChronoCross\MeGUI\VideoUtil.cs(959,10): warning CS1030: #warning: 'This should be rearranged to work better'
C:\msys\1.0\home\ChronoCross\MeGUI\AviSynthWindow.cs(1556,10): warning CS1030: #warning: 'This is just quickfix, please check it!'
C:\msys\1.0\home\ChronoCross\MeGUI\d2vReader.cs(46,10): warning CS1030: #warning: 'Why load the video here? This means that we can't apply force film unless the video unless it is playable in AviSynth'
C:\msys\1.0\home\ChronoCross\MeGUI\Calculator.cs(1575,10): warning CS1030: #warning: 'look here'
C:\msys\1.0\home\ChronoCross\MeGUI\VideoUtil.cs(141,35): error CS0227: Unsafe code may only appear if compiling with /unsafe
C:\msys\1.0\home\ChronoCross\MeGUI\VideoPlayer.cs(668,23): error CS0227: Unsafe code may only appear if compiling with /unsafe
Compile complete -- 2 errors, 8 warnings
Edit: also I think it would be great if in the changelog we started a new numbering scheme. Since this build is drastically different from pre-refactor.
just use SVN 1
as for program version control we could instead of using 0.2.3 we should start using something like: 1.0.0.1 Alpha Since you are basically working on the more advanced version....but that's just MHO.
I'm not going to post a build until we figure out the naming scheme. Cause it has to be different from what the current cvs uses. Due to the differences.
change /unsafe- with /unsafe+ in compile.bat
however i have other compilation errors:
mkvMuxWindow.cs(861,18): error CS0103: The name 'MUXTYPE' does not exist in the
current context
mkvMuxWindow.cs(878,23): error CS1501: No overload for method
'generateMkvmergeCommandline' takes '3' arguments
CommandLineGenerator.cs(1143,17): (Location of symbol related to previous error)
What do you mean by traditional avis ?AVIs that are compatible with whatever AVI players are out there. I guess I'm just a bit sceptical about the whole divx format thing.
As far as version numbering goes, right now we're at 0.2.x.y.. so it could be 0.2.r#svn-revision#.. there's nothing in there that warrants a bump in the version number..
I've been looking at divxmux and it does look interesting. It would make avi muxing very similar to mp4 and mkv muxing. It also supports vobsubs and since mp4box now also supports that, we can start thinking about subtitle ripping.
The drawback is obviously that there's no avc support, but then again avc in avi isn't such a great idea to begin with.
What do you guys think? scrap avc2avi, avimuxgui and use divxmux instead?
berrinam
7th May 2006, 21:09
Yeah, might as well use divxmux. We can always replace it or add another avi muxer if necessary (say, ffmpeg or avimuxgui if it becomes accessible).
Sharktooth
7th May 2006, 21:10
it's ok for me as long as avc is not muxed in AVI... :)
ChronoCross
7th May 2006, 22:42
it's ok for me as long as avc is not muxed in AVI... :)
Agreed. I for one am In favor of keeping things within certain standards. MeGUI should avoid hacks as often as possible. The naming scheme sounds good. I'll wait till the next commit to make a build.
Sharktooth
8th May 2006, 14:11
0.2.3.2134 8 May 2006
Commit by Sharx1976
- Expanded bitrate fields to 5 chars in x264 config dialog.
- Fixed an aesthetic glitch (video config button position) in main form.
Sources: http://www.webalice.it/f.corriga/megui/MeGUI-src.CVS-0.2.3.2134.7z
Bins: http://www.webalice.it/f.corriga/megui/MeGUI-0.2.3.2134.7z
ChronoCross
9th May 2006, 00:44
I've also posted my version. I'll within the next few days be updating the Essentials package for the stable build 2132.
Here's the Readme for the current builds.
MEGUI is currently in a highly unstable developmental build. As it stands right now all features may not work.
Use at your own risk. Please report any bugs you find to our BugReport Thread at http://forum.doom9.org/showthread.php?t=105160
Compiler: ChronoCross
ChronoCross
9th May 2006, 07:37
Okay so for the refactor we are going to remove the following(correct me if I'm wrong)
1) Besweet support
2) Nero 6 and 7 dll neroraw encoding replaced by the new and improved free nero encoder
3) Scraping avc2avi, avimuxgui support and instead preventing avc in avi by using divxmux for ASP in AVI muxing.
Requests made:
1) Added support for Coding technologies AAC
2) Added support for additional Audio processing techniques. Support for things that besweet supports but instead supporting them using avisynth.
3) Vorbis Encoding
is there anything I missed?
berrinam
9th May 2006, 07:44
3) Scraping avc2avi, avimuxgui support and instead preventing avc in avi by using divxmux for ASP in AVI muxing.I know that you and Sharktooth think that AVC in AVI is a terrible thing, but when I was playing around with the refactor and muxing, it didn't give me any of the problems I used to have (crashes, jerkiness, etc). I know there's a big debate about whether it should be done, but at the moment, editability is still the best in AVI. should we really abandon AVI muxing for AVC? Why not just leave AVC2AVI in, meaning that AVI muxing is only supported for audio-less files, and if we ever add ffmpeg or avimux gui, then we can actually get avc in AVI.
is there anything I missed?Vorbis audio encoding. More general refactoring, perhaps.....
berrinam
9th May 2006, 07:47
Anyone else having problems with CVS at the moment?
ChronoCross
9th May 2006, 07:54
I know that you and Sharktooth think that AVC in AVI is a terrible thing, but when I was playing around with the refactor and muxing, it didn't give me any of the problems I used to have (crashes, jerkiness, etc). I know there's a big debate about whether it should be done, but at the moment, editability is still the best in AVI. should we really abandon AVI muxing for AVC? Why not just leave AVC2AVI in, meaning that AVI muxing is only supported for audio-less files, and if we ever add ffmpeg or avimux gui, then we can actually get avc in AVI.
Vorbis audio encoding. More general refactoring, perhaps.....
As for AVC in AVI although it might work with certain settings some of the more complex profiles would not work in AVI. AVI has those limits. Which would mean all of sharktooths profiles would then have to be banded to a particular format. it would add a level of complexity to the way things are done. plus alot of people will start to see undesired results and complain about it.
By supporting the formats that support it natively we can aleiviate the issues and keep from having to impose further restrictions.
Why not just leave AVC2AVI in, meaning that AVI muxing is only supported for audio-less files, and if we ever add ffmpeg or avimux gui, then we can actually get avc in AVI.
I was thinking about that, too. The most important to me is that we don't have to bend over backwards to make it work.. if avimuxgui isn't an option, then there's simply no muxer that can handle the requirements and that means either we leave just avc2avi in there, so people can use all the facilities but if they try audio and video, it won't work, or remove it. Of course there's using Nandub as a muxer, but nah..
is there anything I missed?It's a start.. obviously there are more features to come, like cutting, vobsub subs for all formats (including extraction.. with divxmux we have the three containers supporting these subs so it makes sense to have that option).
berrinam
9th May 2006, 14:16
I can't access CVS (many people have reported this on SF), so here is the source code and bins for 0.2.3.2135:
Source: http://www.savefile.com/files/4964492
Bins: http://www.savefile.com/files/3709502
Changes:
0.2.3.2135 8 May 2006
Commit by berrinam:
- Enabled XviD CQMs (there are two fields, but only the first one is active)
- Fixed loading of video jobs -- the PAR is now retained.
- PAR is now in the video player, not the codec config (it's not a codec-specific thing, conceptually)
- Added support for DivXMux.exe (no statuses yet, though... no lines to parse, so filesize-based status required)
- Removed registration of AVIMux_GUI (but didn't remove code... hopefully it will get stderr error messages soon, so we can use that again)
- Fixed up annoying video profile bug that's been around for ages
Still not finished. In particular, there is currently no way for the mux path finder to tell the difference between an avi with avc and a video with asp. Anyone have suggestions?
Sharktooth
9th May 2006, 16:42
CVS is ehrr... down...
there is currently no way for the mux path finder to tell the difference between an avi with avc and a video with asp.aargh.. that's one thing I hadn't thought of.. gotta mull this over in my head for a bit.. it would be nice to have something better than a cheap hack solution.
berrinam
9th May 2006, 23:18
Two possible solutions:
two video types: AVCAVI and ASPAVI.... I'm not sure how that would work, though.
The muxers have a list of videocodecs that they support. So, not only does a mux path need to be found, but every muxer after the one that muxes it in needs to support that video codec. (Similar for audio codecs). I like this solution, but it still doesn't work when you just select an avi input file.... you don't know what codec it is. Perhaps MediaInfo would be useful for this?
EDIT: About MediaInfoLib. The things I see it as perhaps useful for are:
Finding the fps of sources that will be DirectShowSource'd. This should solve one of the main reasons that files can't be loaded into MeGUI
Used for muxing as mentioned above
Possible use in One Click Encode to allow DirectShow inputs there.
Use when muxing unknown inputs to determine the number of frames of the source file (because at the moment, there is no way to know, so it is set to 100 (arbitrary decision).
It could be made into a fourth kind of video reader: DirectShowReader. This would mean getting its properties via MediaInfo, and getting the video display via AviSynth.
berrinam
9th May 2006, 23:48
Why are there two CQM fields in XviD config, although xvid_encraw only allows one CQM file, and all of Sharktooth's ASP CQMs are a single file?
Doom9
10th May 2006, 09:16
Why are there two CQM fields in XviD config, although xvid_encraw only allows one CQM fileBecause mencoder wants the Intra and Inter matrix separately. iirc inly the intra matrix is used these days, the other is useless.
Finding the fps of sources that will be DirectShowSource'd. This should solve one of the main reasons that files can't be loaded into MeGUIAre we wrapping those sources into an AviSynth script? If so, wouldn't it not make any difference since the encoder would have the exact same issue?
So, not only does a mux path need to be found, but every muxer after the one that muxes it in needs to support that video codec.Hmm.. I initially thought of that but then scrapped the idea because it would just add another layer of complexity which at this point I didn't need (every muxer supported all kinds of content in input that was already in the desired container). It's the cleanest way though.
berrinam
10th May 2006, 09:27
Because mencoder wants the Intra and Inter matrix separately. iirc inly the intra matrix is used these days, the other is useless. Well, in that case, I will remove the inter matrix textfield. I think it would also be good to get someone to redesign the XviD config dialog.
Are we wrapping those sources into an AviSynth script? If so, wouldn't it not make any difference since the encoder would have the exact same issue?I meant the problem with using AviSynth to load files via DirectShowSource -- AviSynth sometimes complains and says, "Can't load source. Can't detect framerate". If you provide it with the framerate, then it loads fine. So, finding out the framerate via MediaInfo would solve that problem.
Hmm.. I initially thought of that but then scrapped the idea because it would just add another layer of complexity which at this point I didn't need (every muxer supported all kinds of content in input that was already in the desired container). It's the cleanest way though.I think it won't make it overly complex to do that. I'll just add a supported Video/Audio codec property to IMuxing, and register another Mux Path checker.
berrinam
10th May 2006, 09:51
0.2.3.2136 10 May 2006
Commit by berrinam:
- Fixed Profile Importing/Exporting's CQM handling for XviD
- Added tritical's fix for AviSynthWrapper
- Fixed OneClick window loading
- Fixed LMP4 config loading
bins: http://rapidshare.de/files/20081273/megui-bin.2136.zip.html or http://www.savefile.com/files/8710945
src: http://rapidshare.de/files/20081338/megui-src.2136.zip.html
Enjoy.
Doom9
10th May 2006, 09:55
AviSynth sometimes complains and says, "Can't load source. Can't detect framerate". If you provide it with the framerate, then it loads fine. So, finding out the framerate via MediaInfo would solve that problem.Ahh.. I know that one. You make a compelling argument to include MediaInfoLib.
shon3i
10th May 2006, 12:57
0.2.3.2136 10 May 2006
Commit by berrinam:
- Fixed Profile Importing/Exporting's CQM handling for XviD
- Added tritical's fix for AviSynthWrapper
- Fixed OneClick window loading
- Fixed LMP4 config loading
bins: http://rapidshare.de/files/20081273/megui-bin.2136.zip.html
src: http://rapidshare.de/files/20081338/megui-src.2136.zip.html
Enjoy.
Can you upload binaries somewhere else because i have net with proxy which is not supported by rapidshare. Thanks
berrinam
10th May 2006, 13:48
I think it won't make it overly complex to do that. I'll just add a supported Video/Audio codec property to IMuxing, and register another Mux Path checker.Well, it's more complex than I realised.:o
The main difficulty arises from the fact that we now need to know the codec at every level, as opposed to just knowing the VideoType (these aren't always interchangeable). It isn't a terrible problem; it should just require working through all of the code and replacing OutputType with MuxableType (a struct which will contain an OutputType and the codec used). Unfortunately, this sort of tedious work can't be done right now. I'll have to leave it for a little while.
@shon3i: edited my above post.
Sharktooth
11th May 2006, 02:38
Since the CVS is down, latest sources can be found on the anon SVN: https://svn.sourceforge.net/svnroot/megui (use a svn client)
EDIT: i updated the version number in AssemblyInfo.cs to 0.2.3.2136
bob0r
11th May 2006, 12:32
Until the CVS is down, latest sources can be found on the anon SVN: https://svn.sourceforge.net/svnroot/megui (use a svn client)
EDIT: i updated the version number in AssemblyInfo.cs to 0.2.3.2136
I guess you mean "because CVS is down" or "until CVS is back online", latest sources can be found on the anon SVN....
The checkout went fine, are there are problems for using SVN then?
(besides the fact that i can't compile again, see bug report thread)
Sharktooth
11th May 2006, 13:35
yeah... no, but the old versions history is gone. so it preferable to still use the CVS until we can migrate the whole thing to the SVN.
Sharktooth
12th May 2006, 15:20
Sources and Bins are available here too (from now on):
http://mirror05.x264.nl/Sharktooth/?dir=./MeGUI
Sharktooth
12th May 2006, 18:03
CVS is BACK.
Read the SF email to know how to access the new service.
berrinam
13th May 2006, 00:38
Committed 0.2.3.2135 and .2136 to CVS. I'll finish and commit the update I'm working on now, and then let's move to SVN?
ChronoCross
13th May 2006, 00:42
anon cvs is still broken so svn would be great lol. I just wish gpac would move to subversion as well.
berrinam
13th May 2006, 01:02
Well, if anon CVS is still broken, then a transition won't be so easy. EDIT: Anonymous CVS is working now -- I just tested. You need to reconfigure the settings, though: http://sourceforge.net/docs/E04/
berrinam
13th May 2006, 03:16
0.2.3.2137 13 May 2006
Commit by berrinam:
- Added a check for whether muxers support the codec in mux path finding
- Added a warning message on the bitrate calculator (it needs a refactor)
- Fixed the mp4 bug with the calculator
- Fixed a bitrate calculation bug in AutoEncode
Sharktooth
13th May 2006, 15:47
I'll try to migrate again...
EDIT: migration from CVS is "currently not available"
dimzon
13th May 2006, 20:46
Is this settings valid ???
http://img71.imageshack.us/img71/9485/cvs8jz.png
In C:\MeGUI: "C:\Program Files\TortoiseCVS\cvs.exe" "-q" "checkout" "-P" "MeGUI-src.CVS"
CVSROOT=:ext:dimzon@megui.cvs.sourceforge.net:443/cvsroot/megui
cvs.exe checkout: bad CVSROOT - Cannot specify port: :ext:dimzon@megui.cvs.sourceforge.net:443/cvsroot/megui
cvs.exe [checkout aborted]: Bad CVSROOT.
Error, CVS operation failed
Sharktooth
13th May 2006, 21:35
port number is wrong. remove it.
dimzon
13th May 2006, 21:38
port number is wrong. remove it.
wow! thanx!
dimzon
13th May 2006, 23:16
CVS Commit
0.2.3.2138 14 May 2006
Commit by dimzon:
- New free NeroDigital CLI AAC encoder support (instead of neroraw)
M AssemblyInfo.cs
M AviSynthAudioEncoder.cs
M Changelog.txt
M CommandLineGenerator.cs
M ISettingsProvider.cs
M JobUtil.cs
M MeGUISettings.cs
M NeroAACSettings.cs
M SettingsForm.cs
M neroConfigurationDialog.cs
dimzon
14th May 2006, 00:48
silent CVS commit
initial OggVorbis support (not complete yet)
dimzon
14th May 2006, 08:39
0.2.3.2139 14 May 2006
Commit by dimzon:
- Partial OggVorbis encoder support (only VBR Q mode yet)
Compiled binary (SFX archive)
http://www.mytempdir.com/664555
dimzon
14th May 2006, 10:03
0.2.3.2140 14 May 2006
Commit by dimzon:
- Aud-X MP3 5.1 (surround) support
berrinam
14th May 2006, 10:04
dimzon's on fire!!!
Keep up the good work.
dimzon
14th May 2006, 11:08
0.2.3.2141 14 May 2006
Commit by dimzon:
- CT AAC support
compiled binary (http://www.mytempdir.com/664792)
don't forget that latest oggenc2 build support 5.1 channel in correct order
Oh Shit...
Please, provide me download link for fresh valid oggenc2
Keep in mind current build using old (improper) Oggenc 5.1 channel order
nurbs
14th May 2006, 11:26
Please, provide me download link for fresh valid oggenc2
Rarewares (http://rarewares.org/ogg.html) normally has up to date builds, but I don't know if it supports the proper channel mapping yet.
dimzon
14th May 2006, 12:50
0.2.3.2142 14 May 2006
Commit by dimzon:
- OggVorbis 5.1 channel mapping based on OggEnc2 version
- small bugfixes
compiled binary (http://www.mytempdir.com/664969)
shon3i
14th May 2006, 12:57
ohhh dimzon Roks!, Thanks a lot
about ogg, which to use
- Oggenc2.83 using libVorbis v1.1.2
- Oggenc2.83 using libVorbis v1.1.2 with IMPULSE_TRIGGER_PROFILE Option
- Oggenc2.83 using aoTuVb4.51
dimzon
14th May 2006, 14:56
Please, provide me link to fresh FFMPEG binary (i want to add AC3 and MP2 encoding)
shon3i
14th May 2006, 14:58
Here lastest
http://www.free-codecs.com/ffmpegGUI_download.htm
berrinam
14th May 2006, 15:02
You haven't committed AudXConfigurationDialog.cs, AudXSettings.cs, WinAmpAACConfigurationDialog.cs, WinAmpAACSettings.cs. I can't compile.
bob0r
14th May 2006, 17:16
@dimzon
Hmm mytemp dir?
http://mirror05.x264.nl/dimzon/ this account never stopped working, you probably lost it's info?
max-holz
14th May 2006, 17:43
Could you update the public SVN on sourceforge?
dimzon
14th May 2006, 17:56
0.2.3.2143 14 May 2006
Commit by dimzon:
- AC3 encoding via FFMPEG
- MP2 encoding via FFMPEG
compiled binary (http://www.mytempdir.com/665655)
dimzon
14th May 2006, 18:01
You haven't committed AudXConfigurationDialog.cs, AudXSettings.cs, WinAmpAACConfigurationDialog.cs, WinAmpAACSettings.cs. I can't compile.
Sorry, already commited in previous commit.
btw. Does anybody need more audio codecs?
Doom9
14th May 2006, 19:38
I think we already have too many audio codecs. For instance I don't really see the point of MP2 and AC3 encoding in MeGUI.. it's not like we're creating DVDs so there are better options for both stereo and multichannel audio.
asdfsauce
14th May 2006, 20:53
AC3 and MP2 would be usefull if you ever added MPEG2 encoding, which would be nice. (please don't hurt me)
dimzon
14th May 2006, 21:04
AC3 and MP2 would be usefull if you ever added MPEG2 encoding, which would be nice. (please don't hurt me)
Complete agreed. Why not to add Mpeg2 video support in far future. AFAIK FFMPEG MPEG2 3-pass is one of the best MPEG2 encoder avaluable (it's even beat commercial analogs in quality terms). In other side it's really easy to add new audio encoders to MeGUI so why not add something like WavPack etc (in future)
ChronoCross
15th May 2006, 00:31
I've come up with a new design for the essentials package based on berrinam's suggestions for when auto update functionality is added.
MeGUI
Audio
Audx
Coding Technologies
FAAC
ffmpeg
Lame
Nero
OggVorbis
Containers
AVC2AVI
avimuxgui
DGIndex
Divxmux
MKVToolnix
mp4box
Data
Filters
Jobs
Logs
Profiles
audio
avs
oneclick
video
Video
Huffy-Snow-LMP4
x264
xvid
Does anyone see anything I might have missed? I think I pretty much covered every features as of right now in the devl build.
dimzon
15th May 2006, 00:40
0.2.3.2145 15 May 2006
Commit by dimzon:
- refactoring: IAudioSettingsProvider implementation via Generics
- refactoring: Small cosmetic ClassName renaming (faacConfigurationDialog -> FaacConfigurationDialog etc)
now take look how it looks:
public class NeroAACSettingsProvider : AudioSettingsProviderImpl<NeroAACSettings, NeroAACConfigurationDialog>
{
public NeroAACSettingsProvider():base("ND AAC")
{
}
}
dimzon
15th May 2006, 00:42
I think I pretty much covered every features as of right now in the devl build.
AFAIK we can/planing to use ffmpeg for Video encoding too
asdfsauce
15th May 2006, 01:05
-ChronoCross
How's the "settings file" generation/installing going to be handled? ...If you don't mind me asking here.
dimzon
15th May 2006, 01:05
0.2.3.2146 15 May 2006
Commit by dimzon:
- refactoring: IVideoSettingsProvider implementation via Generics
siddharthagandhi
15th May 2006, 02:49
"Huffy-Snow-LMP4"
Does that mean one out of those three? And Huffy=Huffyuv?
Kostarum Rex Persia
15th May 2006, 03:34
Where is binary for 0.2.3.2146? Link for download?
ChronoCross
15th May 2006, 03:45
-ChronoCross
How's the "settings file" generation/installing going to be handled? ...If you don't mind me asking here.
Unfortunately I have no solution at the moment. Right now I'm making it beofrehand, it's set to the default install path(which is what everone should use for consistency.
"Huffy-Snow-LMP4"
Does that mean one out of those three? And Huffy=Huffyuv?
mencoder currently handles all 3. but to make it more informative for users I used that folder name
@KRP
be patient I'll have a build up shortly.
buzzqw
15th May 2006, 14:26
@dimzon
attention to normalize() fuction... try with an audio of more than 2hr... i got crash from neroaacenc and oggvorbis
afaik normalize() don't work well with piping
BHH
dimzon
15th May 2006, 15:20
try with an audio of more than 2hr... i got crash from neroaacenc and oggvorbis
please, provide bug report
buzzqw
15th May 2006, 20:34
i have done some more test
my bad ! i used a broken ac3
sorry again !
BHH
Would it be a good idea to switch from SourceForge to Microsoft CodePlex (http://www.codeplex.com/) in light of the recent problems?
Microsoft Watch article (http://www.microsoft-watch.com/article2/0,1995,1962726,00.asp?kc=MWRSS02129TX1K0000535)
ChronoCross
16th May 2006, 18:15
Would it be a good idea to switch from SourceForge to Microsoft CodePlex (http://www.codeplex.com/) in light of the recent problems?
Microsoft Watch article (http://www.microsoft-watch.com/article2/0,1995,1962726,00.asp?kc=MWRSS02129TX1K0000535)
I would say no.
Carpo
16th May 2006, 18:54
anything to do with ms is a bad idear ;)
stax76
16th May 2006, 19:44
You probably missed it but MeGUI is already for Windows only, based on .NET 2 and coded with VisualStudio or to say it short evil Microsoft all over the place.
Carpo
16th May 2006, 20:32
You probably missed it but MeGUI is already for Windows only, based on .NET 2 and coded with VisualStudio or to say it short evil Microsoft all over the place.
no i never missed it although you might have missed i was taking the micheal ;p
stax76
16th May 2006, 20:56
What did you expect? Do you think it's appropriate to post things like 'anything to do with ms is a bad idear' in a dev thread of a application that is MS through and through, I doubt so. This thread is about MeGUI development and not random MS bashing.
ChronoCross
16th May 2006, 21:18
anything to do with ms is a bad idear ;)
I would tend to agree with this statement in some cases (DRM, TC, and WMP) however my reasoning is a bit different and goes more along the lines of what the dev's have been saying about the project.
The whole point of not moving somewhere else is not only the fact that it is our current known location but also that all the version history would be lost. Also having to learn a new site would slow development considerably. Additionaly all our second hand resources would have to be changed such as the megui home page and whotnot. moving is a big hassle. The new cvs is online and asap they are going to move to svn.
dimzon
16th May 2006, 23:42
I would tend to agree with this statement in some cases (DRM, TC, and WMP) however my reasoning is a bit different and goes more along the lines of what the dev's have been saying about the project.
The whole point of not moving somewhere else is not only the fact that it is our current known location but also that all the version history would be lost. Also having to learn a new site would slow development considerably. Additionaly all our second hand resources would have to be changed such as the megui home page and whotnot. moving is a big hassle. The new cvs is online and asap they are going to move to svn.
:goodpost: :goodpost: :goodpost: :goodpost:
btw. Doom9, is it possible to add smile "100% Agreed"?
Ajaja2005
16th May 2006, 23:57
Latest sources for anonymous users from cvs.sourceforge.net:
cvs -z9 -d: pserver:anonymous@megui.cvs.sourceforge.net:/cvsroot/megui co -P MeGUI-src.CVS
:)
Carpo
17th May 2006, 20:40
I would tend to agree with this statement in some cases (DRM, TC, and WMP) however my reasoning is a bit different and goes more along the lines of what the dev's have been saying about the project.
The whole point of not moving somewhere else is not only the fact that it is our current known location but also that all the version history would be lost. Also having to learn a new site would slow development considerably. Additionaly all our second hand resources would have to be changed such as the megui home page and whotnot. moving is a big hassle. The new cvs is online and asap they are going to move to svn.
spot on :goodpost:
berrinam
19th May 2006, 15:30
0.2.3.2147 19 May 2006
Commit by berrinam:
- Add support for auto update
shon3i
19th May 2006, 19:40
Oh man, auto update work perfetcly, Thanks a lot, but one missing, enc_aacplus.dll, i know this licence shits, but put it on the server please? because encAACplus, is unuse without this dll.
Sharktooth
19th May 2006, 20:19
6) No warez, cracks, serials or illegally obtained copyrighted content! Links to content of a questionable nature, asking for, offering, or asking for help/helping to process such content in any way or form is not tolerated.
ChronoCross
19th May 2006, 20:22
it's a little tacky in terms of organization. but what can I argue. I'm going to discontinue work on the essentials package since it's no longer going to be used.
See bug report thread for problems with auto update.
shon3i
19th May 2006, 20:41
6) No warez, cracks, serials or illegally obtained copyrighted content! Links to content of a questionable nature, asking for, offering, or asking for help/helping to process such content in any way or form is not tolerated.
Sorry i just ask, but not in that way am not ask for piratated version, for example Media Coder use it but from winamp. btw coding technologies is free but winamp ripping technology isn't so then MeGUI dev's can ask Winamp devs on winamp forums and found the real truth.
berrinam
19th May 2006, 23:54
it's a little tacky in terms of organization.Huh? I don't understand.
Anyway, this is naturally just the first commit. Any suggestions/modifications are always welcome. Also, I just put the files on the web from what I could get. If anyone has better builds (eg of mencoder) please let me know. Also, contact Richard Berg to see if you can also get access to the megui.org server, so that you can add stuff if you want.
Some things I'm looking at for the future:
Managing installation from an archive (a local repository, no downloads needed. For an offline install)
Managing processor dependencies and OS dependencies. This is because some builds are specifically for some processors, etc, and mkvtoolnix is also distributed in unicode and non-unicode forms. Unfortunately, I don't know how to find out the processor and OS, so someone else will need to give a hand there.
Some way to properly detect the versions of files that are already installed. Perhaps also a 'urgency of update' rating, so for AviSynth and AviSynth plugins, if they are simply there, that is sufficient (they don't need to be the latest version). If someone would like to suggest an architecture for this and/or implement it, that would be great.
Anything else to add?
ChronoCross
20th May 2006, 07:33
I meant by tacky because each program has it's own folder (which is fine) cept that it puts them all in the root directory. There doesn't seem like any method to the madness.
berrinam
20th May 2006, 07:46
Ahhh, ok. I've fixed that in my local version.
berrinam
20th May 2006, 08:46
0.2.3.2148 20 May 2006
Commit by berrinam:
- Added support for the 'needsrestart' parameter in autoupdate. Please delete your AutoUpgrade.xml files to enable this.
- Edited compile.bat to divide MeGUI into core, libs, avswrapper, updatecopier and data
- Made it check for updates in the background, then notify only if there are any
- fixed installation of multifile core packages
- files are now installed to meguiroot/tools/appname/ instead of meguiroot/appname/
- fixed mencoder commandlines for xvid
- fixed up huffy commandline
- fixed exception with adaptive muxer
vBulletin® v3.8.5, Copyright ©2000-2012, Jelsoft Enterprises Ltd.