MeGUI development

[charleski]

Sorry I haven't been around. Work has kept me off the net (unless I sign up for some costly coverage, to which I might succumb).

It's good that you're arguing about the whole private/public issue. My own take on it would be that readability is paramount - C sacrificed that a long time ago and C# is, in part, an attempt to make the language intelligible again. On that score, any extra characters, like '_' are a NO-NO, and need to be consigned to the dustbin along with *, ^, @ and their relatives. (Unfortunatley '@' still survives courtesy of the lingering evil of printf).

Prefix camel notation wins for a simple reason: a complete stranger can take a look at the code and work out what's going on (as long as they have the basic logical ability), without having to wonder if there's some arcane messaging that he/she is missing.

I spend enough of my professional life inwardly screaming at the problems junior (and often senior) docs have at providing properly intelligible message streams, so I'm sensitive to this :).

[Mutant_Fruit]

@dimzon:

What do you mean by this warning you put in:

#warning use Property pattern for this
if(player == null)
player = new Player();


What do you mean by Property Pattern?

[Mutant_Fruit]

Patch for the calculator up in SourceForge. Fixes quite a few bugs, increases max length to 24 hours, 59 mins, 59 secs (doesn't seem to have any reprecussions that i know of). Added DVD-9 as a destination medium.

Fixed a bug in the main form aswell when you tried to queue a job with no input selected.

[berrinam]

There's a discrepancy in AR handling between x264 and xvid and lavc ASP. x264 uses Sample Aspect Ratio, lavc ASP uses PAR, and xvid has to use a rounded version of PAR. I was going to suggest that MeGUI removes this discrepancy by modifying the SARX and SARY properties so that subclasses of VideoCodecSettings override them in the correct way. This would mean that every interface would just have to select the PAR (which seems more intuitive to me), and MeGUI would convert that into the correct format.

The problem is that the conversion requires knowledge of the videos resolution. As it is, the AR in MeGUI is all wrong, and the code is hard to manage. What do you suggest?

[Kostarum Rex Persia]

Peoples, can anyone post a link to newest build of MeGUI, 0.2.3.2055, because I can't find download link on the MeGUI official project page on SourceForge.

Thanks.

[Doom9]

look who's popping up on my radar the same day they got unsuspended. There's a sticky with a guide and a download link.

@berrinam: what's the diff between x264's SAR and lavc's PAR anyway? Isn't it the same (and by the same token the same as XviD's custom PAR option). Am I correct to assume that if custom PAR were implemented, the exact same code could be used?

[SeeMoreDigital]

@berrinam: what's the diff between x264's SAR and lavc's PAR anyway? Isn't it the same (and by the same token the same as XviD's custom PAR option). Am I correct to assume that if custom PAR were implemented, the exact same code could be used?Agreed... There's no difference as far as I have been able to determine ;)

[stax76]

@SeeMoreDigital

Thanks for clearing this, everytime I read terms like AR, PAR, SAR, DAR and the likes I feel a sudden headache.

[SeeMoreDigital]

You're not the only one :eek:

[berrinam]

Agreed... There's no difference as far as I have been able to determine ;)Well, when I was testing it out, I entered the same two numbers into lavc and x264 in MeGUI, and x264 was properly scaled, whereas lavc was not.....
I thought that lavc was Picture Aspect Ratio, or Display Aspect Ratio, whereas x264 was Sample Aspect Ratio. Perhaps I got incredibly confused, because it seems not to be working for me, although it does for everyone else....

[Doom9]

I've finally had a look at the sources to look for possible refactoring in the future, and made some (rather random) notes:

configAudioButton_Click -> explore possible simplifications

videoConfigButton_Click -> explore possible simplifications

difference between video and audio: for video there's but one settings object per codec, for audio the settings of a stream do not necessarily correspond to a settings object accessible via dropdowns

isFirstPass, verifyVideoSettings -> VideoUtil

verifyOutputFile -> jobUtil

verifyInputFile -> jobUtil

startEncoding -> jobUtil

startNextJobInQueue -> jobContainer

loadJobs -> jobContainer

getFreeJobNumber -> jobContainer

addJobToQueue -> ??

getVideoJobs, addVideoJob -> jobUtil

removeJobFromQueue -> jobContainer


ideas: automatic script checking upon opening even if preview is not being opened. store properties of the script right away


getAudioJob() -> move to another place
addVideoJob(bool autostart) -> move to another place

improve profile -> dropdown mapping

discard audio streams only when accessing the auto encoder -> the two audio streams are always accessible in the main gui

jobs should provide a means to get a string array with everything required to create a ListViewItem for the queue
Use ListViewItem.Tag to attach the job to the listviewitem

improve profile management.. attach profiles to dropdown in a way

move containment to a new ProfileManager


Other things I'd like to achieve: easy encoding for specific devices (like PSP, video iPod). In case of the PSP that will require running an additional job.
I also found that ffmpeg can mux raw avc into AVI and generally mux AVIs so I'll be using that as a muxer in the future (I haven't found the syntax for splitting yet). Would it perhaps make sense to use ffmpeg only for raw -> video avi and then use a tool like avimuxgui for muxing/splitting.. the advantage of that would be multiple audio tracks, splitting, more allowed input types. The downside is job generation that gets more complex.

I also think the automated job generation for video should look something like this: you send the I/O and configuration and the desired output type. The JobUtil has to ask the VideoEncoder if it can provide the output type. If not, it should return a list of alternatives. JobUtil would then ask the Muxer if it has a muxing path from one of the possible encoder outputs to the desired output types. If that's the case, a job of the desired type has to be created.

[berrinam]

Other things I'd like to achieve: easy encoding for specific devices (like PSP, video iPod). In case of the PSP that will require running an additional job.
Well, that's partly what I had in mind for the new types of profiles I added. Profiles could be made for these specific tasks, and distributed, just like Sharktooth's AVC video profiles.

I've made one according for the iPod to the arstechnica settings. I can't test this, as I don't have a video iPod, but I've attached the group of profiles so you can get an idea as to how they work.

While it would be possible to make a profile that works with PSP (restricting the width to 320 maximum), from what I've read, this wouldn't get the best out of the PSP, as it supports a maximum of 76800 (320x240), but they can be at different ratios, like 368x208. I can't see a way to make the current OneClick structure (I presume OneClick is the way to go if you want an easy way for the users) manage both. Perhaps it needs another way of signalling the resolution than just maximum width?

[dimzon]

I've finally had a look at the sources to look for possible refactoring in the future, and made some (rather random) notes
WOW! Seems like you change your mind :cool:
Perfectly!!!

By the way: what I can do now? I'm planning to write Cropping dialog (like one in VirtualDub) but I can switch to refactoring

What do you mean by Property Pattern?
Somethink like this (not shure yet)

private Player playerInstance;
private Player player
{
get
{
if(playerInstance==null)
playerInstance = new Player()
return playerInstance;
}
}


@Mutant_Fruit
I'm still waiting avi samples wich you are not able open via DirectShow without direct FPS specification

[Inc]

Well, when I was testing it out, I entered the same two numbers into lavc and x264 in MeGUI, and x264 was properly scaled, whereas lavc was not.....
I thought that lavc was Picture Aspect Ratio, or Display Aspect Ratio, whereas x264 was Sample Aspect Ratio. Perhaps I got incredibly confused, because it seems not to be working for me, although it does for everyone else....


Imho "Lavc" uses Aspect or AR (here DAR) and "x264" SAR (here PAR).

[Doom9]

I'm planning to write Cropping dialogUh, why is this necessary? We already have a video player that can do everything.. just showing the video, setting of intro end and credits start frames, zone management and even crop preview (keep in mind cropping is done via the AviSynth script creator window). Of course, we could have a BasePreview class, and subclasses that expose additional capabilities, but then we'd once again have to pick the proper class somewhere and end up needing a lot if/then/else or case statement.

@berrinam: couldn't we use the level enforcement to adjust the resolution for the PSP? That should take AR into account and thus always result in the optimal resolution. It only gets complicated if we move outside the one click domain.. e.g. having a "PSP" and "iPod" checkbox in the AviSynth script creator..

[berrinam]

@berrinam: couldn't we use the level enforcement to adjust the resolution for the PSP? That should take AR into account and thus always result in the optimal resolution. It only gets complicated if we move outside the one click domain.. e.g. having a "PSP" and "iPod" checkbox in the AviSynth script creator..I thought of that, but there's no suitable level: http://forum.doom9.org/showthread.php?t=101345

Level 1.2 doesn't allow 320x240 at 29.97, and Level 1.3 allows up to 352x288, which is too high.

Imho "Lavc" uses Aspect or AR (here DAR) and "x264" SAR (here PAR).
I've given up trying to work out what the situation with all of the various ARs is. There is more about it here: http://forum.doom9.org/showthread.php?t=105809, where some people say they've had no problems with MeGUI's AR handling, and others say it is useless. I remember that when I did AR signalling for OneClick, I tried it out and it worked on my samples. I have no idea what the current situation is now, and no-oen seems to agree with anyone else.

[dimzon]

keep in mind cropping is done via the AviSynth script creator window
it means i need to set crop values and open file in preview to see - does I perform proper cropping or not and return to AviSynth creator window again and fix croppping values if not etc...

And I want to do something like this:
http://img89.imageshack.us/img89/7026/untitled5uc.jpg

[berrinam]

it means i need to set crop values and open file in preview to see - does I perform proper cropping or not and return to AviSynth creator window again and fix croppping values if not etc...Huh? It automatically opens a preview window that updates as you change the cropping values.

[Inc]

My next step is to include an auto-cropper code based on a border luma threshold and an individual count of samples to be parsed to the new avsredirect.dll, so Dimzon could merge that future piece of c++ code to his AvsWrapper which is used in MeGui. Also it would be imho helpful to build a dll from PARanoias internal resize routines so that feature also could be used in MeGUI.

I've given up trying to work out what the situation with all of the various ARs is. There is more about it here: http://forum.doom9.org/showthread.php?t=105809, where some people say they've had no problems with MeGUI's AR handling, and others say it is useless. I remember that when I did AR signalling for OneClick, I tried it out and it worked on my samples. I have no idea what the current situation is now, and no-oen seems to agree with anyone else.


There are only a few things I have to know:
As I catched in here that PAR equals to SAR, then the values could be easely calculated, BUT! Maybe Im wrong as I also heared that the PAR values should be vice versa if using as SAR? Like 128/117 in PAR is 117/128 in SAR mode ?
Also how does x264's decoder show the image when using a non 1:1 SAR? Means will the image resized in the decoder correctly to its final state by resizing the height or the width?
In PAL a 720x576 should later be shown as 788x576 (1:1) for example.

[dimzon]

Huh? It automatically opens a preview window that updates as you change the cropping values.
Anyway i think VirtualDub - like window is much more comfortable (you can drag cutting lines with mouse)

[Doom9]

@dimzon: as berrinam pointed out.. the minute you load a file into the avisynth creator, a preview pops up and you can see the effects of any cropping changes in real-time.

@incredible: we already have these two features in MeGUI.. and they work quite well.

[Doom9]

Level 1.2 doesn't allow 320x240 at 29.97, and Level 1.3 allows up to 352x288, which is too high.You gotta love Sony.. standards my lower backside...

I have no idea what the current situation is now, and no-oen seems to agree with anyone else.it goes to show that telephony people should stay far away from video. What's wrong with square pixels everywhere and one stretch factor for playback? That's easy and everybody can understand it if you show them three images. I have yet to see anyone who can give a formula on how to relate DAR, image width, height and SAR/PAR.

[dimzon]

http://img300.imageshack.us/img300/2603/untitled14it.jpg
You can drag blue cropping lines via Mouse - exatly like in VirtualDubMod!

[dimzon]

0.2.3.2057 30 Jan 2006
Commit by dimzon:
-New experimantal crop dialog (not complete working yet)

[Doom9]

I don't think using the mouse serves much of a purpose other than being eye candy. When you get right down to it, in the end you have to use the up/down buttons to fine control your cropping. And the AViSynth dialog is closely connected to the reader.. you do realize that by creating another dialog, you'll have to redo everything. Cropping also has to be done either on an avs script or a d2v. Then you have the whole autocrop thing, which also goes straight to the script creator, and the anamorphic story (which requires knowledge about input and output resolution).
VDub also doesn't have autocrop.. a very useful feature.. plus you need to see the results of autocropping.

I also think VDub's ordering of the values is suboptimal.. the way I resolved it, the 4 values are placed with respect to the image in a gamepad like order.. everybody knows immediately which is which.

[dimzon]

And the AViSynth dialog is closely connected to the reader.. you do realize that by creating another dialog, you'll have to redo everything.
Mostly no. Current VideoReader API is fine - is very easy to create "yet another player connected to VideoReader"... If my solution will be Approved by You we can perfor a little refactoring to make this dialog & player ancessors of same class...

And I really doesn't like how current MeGUI implementation works with cropping preview.

By the way
Using current powerfull avisynth wrapper is possible to mimic VirtualDub (name it standard de-facto) in filters tuning (it's easy to create filter tuning dialog with preview ability)



I also think VDub's ordering of the values is suboptimal.. the way I resolved it, the 4 values are placed with respect to the image in a gamepad like order.. everybody knows immediately which is which.
Ok, I hink You are right...

[Doom9]

And I really doesn't like how current MeGUI implementation works with cropping preview.Why? What's wrong with it?

[dimzon]

Why? What's wrong with it?
I'm sorry, but it is uncomfortable for me.
Just get from CVS latest CropDialog (rev 1.2) and compare usability a little... Is'nt CropDialog a more comfortable?

http://img202.imageshack.us/img202/3364/untitled35xo.jpg

[Doom9]

Is'nt CropDialog a more comfortable?I don't see how. Plus the existing dialog is freely resizeable ;) Being a dialog, once you close it, you no longer get to see anything.. with the existing one.. you can close it all you want, the values stay visible and accessible.

[dimzon]

Plus the existing dialog is freely resizeable ;)
This feature doesn't need for cropping
Being a dialog, once you close it, you no longer get to see anything.. with the existing one.. you can close it all you want, the values stay visible and accessible.
It means I just must transfer cropping values to AviSynth creator window, is'nt it? My dialog still uncomplete yet...
I don't see how.
Well... If You don't like it I will remove it ASAP. Just answer - to remove or not to remove (to be or not to be ;) )

[Doom9]

This feature doesn't need for croppingUmm.. I know my screen can handle HDTV natively, but most people are not that lucky.. which results in a window that is larger than their screen and that's not very convenient, would you not agree?
What I like about my approach (and GKnot, where I took the idea from), is that you can theoretically crop without ever seeing the preview, and that you can tend to other related tasks with the preview still on screen. I just don't see how the new approach is better, not just different.

it's easy to create filter tuning dialog with preview abilityNow that would be a useful feature. Even more useful would be a before - after view.

[SeeMoreDigital]

Hi dimzon,

For those (few) of us who like to keep the black mattes....

Would it be possible to add a function that could intentionally "add" black mattes to a source that's found to have furry and/or poorly aligned matte-to-image edges?


Cheers

[Dayvon]

Hey guys... I posted this earlier, but it either got ignored or missed since it was at the bottom of a page. So I'm reposting it....

I was messing around in Paint Shop the other day, and I decided to make an icon for MeGUI. I use this dock thing and the default icon looks pretty boring so I made this thing up. I figured I'd let you guys have at it if you want, if not, then by all means it'll just be my personal MeGUI icon.

If you do like it however, you're totally free to use it. The fonts are freeware fonts, and the I have a higher resolution version if you want it. I tried to run with the same colors as Gordian Knot just for familiarities sake.

Anyway, I can't do code developing, but I can do this. So let me know what you think...

http://church.crossingatwoodland.com/ChurchFiles/SermonText/MeGUI2Icon.png

[dimzon]

@SeeMoreDigital
Sorry, misunderstood you. Can You repeat it using a little more cmplex english?

@Dayvon
Looks fine for me, waiting for Doom9 response

[dimzon]

0.2.3.2058 30 Jan 2006
Commit by dimzon:
-Some refactoring (AVS generation code moved from VideoUtil to ScriptServer)

@Doom9
please, take look @ changed files, does You approve such refactoring?

[SeeMoreDigital]

@SeeMoreDigital
Sorry, misunderstood you. Can You repeat it using a little more cmplex english?Sure...

If I had a source with poor looking mattes, like this: -

http://img235.imageshack.us/img235/1180/badmattesexample5ip.jpg


Would it be possible to configure your application to "overlay" mattes, so the source/encode could (in theory) look like this: -

http://img371.imageshack.us/img371/5404/overlaymatte9wz.jpg


Cheers

[Doom9]

why would you not simply cut away bad borders? Keeping black bars is detrimental to image quality.
And the last time I checked, we have a feature request thread ;)

[dimzon]

why would you not simply cut away bad borders?
Agreed

@Doom9
I'm waiting for your solution about crop Dialog (remove or continue) and for futher refactoring.

[SeeMoreDigital]

why would you not simply cut away bad borders? Keeping black bars is detrimental to image quality.Agreed.... but far less so if the matte is razor sharp, ie: pixel perfect. As true "black" does not require many bits to process.

And the last time I checked, we have a feature request thread ;)Sorry about that, it's easy to get carried away in the excitement. Please move my posts accordingly ;)


Cheers guys

[berrinam]

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

Anyway, assuming I am correct about what methods of signalling these codecs use, how would you do the MeGUI architecture? I still think that it would be nice for the user if they could enter the same number in any codec in MeGUI and have the correct aspect ratio come out. Similarly, the programmer would want to avoid codec-specific handling of AR. It should just work out one AR and tell it to each codec, which works out how to convert that.

That would mean that MeGUI would have to handle conversion between AR methods. So here's the problem: the algorithm for conversion between formats is not so hard, but it requires that it knows the number of pixels. In some cases, the number of pixels is only known at the moment the job is run (look at the case where you add a non-working AviSynth script to the job and you then fix it up later -- this could happen in three cases I see: prerendering, two-pass scripts, and the user just being annoying). Perhaps the solution would be to regenerate the commandline just before the job is run, and tell the commandline generator what the resolution is (it does make sense that it should convert it -- it is just a triviality of what to put in the commandline:D)

So..... what do you think?

Also, for your reference, the cleaned up suggestResolution code:
public static int suggestResolution(double readerHeight, double readerWidth, double customDAR, CropValues cropping, int horizontalResolution,
bool signalAR, out int sarX, out int sarY)
{
double fractionOfWidth = (readerWidth - (double)cropping.left - (double)cropping.right) / readerWidth;
double inputWidthOnHeight = (readerWidth - (double)cropping.left - (double)cropping.right) /
(readerHeight - (double)cropping.top - (double)cropping.bottom);
double sourceHorizontalResolution = readerHeight * customDAR * fractionOfWidth;
double sourceVerticalResolution = readerHeight - (double)cropping.top - (double)cropping.bottom;
double realAspectRatio = sourceHorizontalResolution / sourceVerticalResolution; // the real aspect ratio of the video
realAspectRatio = getAspectRatio(realAspectRatio); // Constrains DAR to a set of limited possibilities
double resizedVerticalResolution = (double)horizontalResolution / realAspectRatio;

int scriptVerticalResolution = ((int)Math.Round(resizedVerticalResolution / 16.0)) * 16;

if (signalAR)
{
resizedVerticalResolution = (double)horizontalResolution / inputPixelCountRatio; // Scale vertical resolution appropriately
scriptVerticalResolution = ((int)Math.Round(resizedVerticalResolution / 16.0) * 16);

// sarX
// ---- must be the amount the video needs to be stretched horizontally.
// sarY
//
// horizontalResolution
// -------------------------- is the ratio of the pixels. This must be stretched to equal realAspectRatio
// scriptVerticalResolution
//
// To work out the stretching amount, we then divide realAspectRatio by the ratio of the pixels:
// sarX horizontalResolution realAspectRatio * scriptVerticalResolution
// ---- = realAspectRatio / -------------------------- = --------------------------------------------
// sarY scriptVerticalResolution horizontalResolution


sarX = (int)Math.Round(realAspectRatio * resizedVerticalResolution);
sarY = (int)Math.Round(horizontalResolution);

return scriptVerticalResolution;
}
else
{
sarX = 0;
sarY = 0;
return scriptVerticalResolution;
}
}

[berrinam]

@dimzon: I find the current way of cropping nicer, in that it gives white bars instead of a line where you are cropping to. My reason for saying this is nicer is that you can look at it and see what the film you are going to get is, and you won't be distracted by the junk on the outside. It is harder to see exactly if there is any black on one side of a line (your approach) than if there is any black at all.

Finally, you can't crop by odd values in YV12.

[SeeMoreDigital]

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


Cheers

[Doom9]

Perhaps the solution would be to regenerate the commandline just before the job is run, and tell the commandline generator what the resolution isUh.. regeneration is okay by me (I was meaning to do that myself), but I don't think there should be any knowledge of resolution in the commandline generator. When doing things manually (so from the avisynth script creator).. you should assume the resolution won't change anymore. In case of one click job series, it should be taken care off. And then I guess I will have to wonder why we have that prerender job that breaks things ;) It's that sort of inter job type dependency (the dgindex postprocessing and automated job series consisting of audio and video put that to the extreme) that makes it really hard to have a structure where each job is really separated.

BTW, I haven't heard a word about my brainstorming on refactoring.

[berrinam]

0.2.3.2059 31 Jan 2006
Commit by berrinam:
-Fixed up AR handling in MeGUI. Everything is now set as PAR, and any conversions required are done just in time for encoding
-Fixed up compile errors
-Applied Mutant_Fruit's bitrate calculator patch

[ChronoCross]

Damn I just compiled 2058 about an hour ago. doesn't matter cause the anoncvs won't be updated for a few hours. I'l prepare another release before work.

[dimzon]

BTW, I haven't heard a word about my brainstorming on refactoring.
http://forum.doom9.org/showthread.php?p=777457#post777457


@Doom9 && @berrinam
I do not like current cropping solution bcz of window overlapping problem. Really, crop controls are placed in one window && preview is in another window. When you trying to change cropping values AvsGenarator window && underlayng MeGUI main vindow overlaps preview window. And when I clicking to preview window it overlaps AvsGenarator window incl. cropping controls.

@berrinam
I still waiting answer for a question: where I can get sources of MessageBoxExLib.dll

[berrinam]

@Doom9 && @berrinam
I do not like current cropping solution bcz of window overlapping problem. Really, crop controls are placed in one window && preview is in another window. When you trying to change cropping values AvsGenarator window && underlayng MeGUI main vindow overlaps preview window. And when I clicking to preview window it overlaps AvsGenarator window incl. cropping controls.I agree. That should just be fixed by correcting the ordering of the windows, though. It doesn't warrant a redesign of the cropping.

I still waiting answer for a question: where I can get sources of MessageBoxExLib.dll
I've added the sources to the CVS repository. They come from a codeproject sample, with some stripping down by me. However, there is still a lot left there which isn't used.

[dimzon]

I agree. That should just be fixed by correcting the ordering of the windows, though. It doesn't warrant a redesign of the cropping.
Unfortunally no - it can't be complete solved via windows ordering. It can be solved only bying monitor with bigger resolution and/or placing preview & crop controls in same window

[Doom9]

my main beef with having everything in one window is that crop values and preview don't necessarily go together. I sometimes make scripts where I already know the crop values so I don't need any preview.. same goes for autocrop.. basically you could live without preview. That's where the separation approach comes in very handy. And it's also important to point out that my approach comes from GKnot.. people with a GKnot background are used to it. You apparently are more used to VDub (which I've given up on ages ago.. except for VfW encoding I do nothing in VDub anymore) which explains your liking of that approach. But let's not forget that in VDub, once the dialog disappears, so does your opportunity to make any further changes.
I'm further assuming that your screen solution is rather smallish.. is it not?

[berrinam]

Unfortunally no - it can't be complete solved via windows ordering. It can be solved only bying monitor with bigger resolution and/or placing preview & crop controls in same window
It hasn't really caused me much problems (except for the main window coming back on top), but it would also be good if you could look at what I said about your cropping window: http://forum.doom9.org/showthread.php?p=777764#post777764



verifyOutputFile -> jobUtil

verifyInputFile -> jobUtil

startEncoding -> jobUtil

startNextJobInQueue -> jobContainer

loadJobs -> jobContainer

getFreeJobNumber -> jobContainer

addJobToQueue -> ??

getVideoJobs, addVideoJob -> jobUtil

removeJobFromQueue -> jobContainer
addJobToQueue sounds like it should go in jobContainer. Similarly for addVideoJob. I think jobUtil should be able to generate the jobs, but not be at all connected to management of the queue, because jobcontainer is about managing the queue.

Also, your refactoring using the IJobProcessor interface means that vEnc, aEnc, muxer, indexer can all be put into one variable -- processor. Since we are only running one thing at once, we only need one processor, and it saves all the if statements which are all over the place.

ideas: automatic script checking upon opening even if preview is not being opened.Agreed
store properties of the script right awayWhy? If there are any problems that can be fixed, they can be fixed immediately. If not, the user might have fixed them without MeGUI realizing it, and storing the values would mean that MeGUI thinks the script still doesn't work even if it does. I think it would be better to call checkVideo() twice.


Other things I'd like to achieve: easy encoding for specific devices (like PSP, video iPod). In case of the PSP that will require running an additional job.What is the situation with this? iPod is perfectly feasible, as I think I have shown you. Should this be distributed? Perhaps also the other method of choosing resolution I mentioned (maximum total pixels)?