MeGUI: bug reports and feature requests

[Zathor]

If you go to the megui main site and download the archive file 2237 core and try to extract it. For me it will give an error that the archive is corrupted.
Thanks - I have fixed that yesterday. As I do not have direct control of the mirror site I have uploaded the same file with another name and it seems to work now. Additionally I have uploaded a fully extracted archive to SF.

I understand that there is a "delete intermediate files" option, but it should not do that if there has been a muxing error.
For sure - please upload the full log file covering all involved jobs.

[Zathor]

Zathor, MeGUI stable got mkvtoolnix updated to 5.9.0, but that version of mkvmerge has a bug (https://trac.bunkus.org/ticket/807) on muxing date, you might want to push a pre-release (https://www.bunkus.org/videotools/mkvtoolnix/win32/pre/) build.
Thanks - but I would like to do a downgrade to 5.8.0 to avoid problems with a pre-release.

[unknownsoldierX]

Here's the log file.

13202

[Zathor]

Thx - can you please upload it somewhere else so that we do not need to wait for approval?

[LigH]

There are many "pastebins" available, like http://paste.frubar.net (supports line highlighting by prepending lines with '@@'; you can limit the storage duration).

[unknownsoldierX]

http://paste.frubar.net/15367

[Zathor]

I cannot reproduce it. Was the mux job part of an AutoEncode or OneClick job? Or did you created this mux job with the tools\muxer tool? If yes which one (Adaptive / AVI)?

[unknownsoldierX]

I used AutoEncode.

[Zathor]

I used AutoEncode.
Ok, in that case it is intended as the input vide file is a true intermediate file. Those files will be deleted when the corresponding job is finished successful or the job will be deleted. The second part has happened in your case. I have to think about the ways to handle that better - currently I have only the idea that a warning message box should appear when deleting such a job.

[unknownsoldierX]

Well, I don't think it makes sense to delete intermediate files if there is an error. It would be great if there were a warning message saying which file(s) were affected. Maybe a prompt asking if MeGUI should delete the involved intermediate file(s).

In my situation, I simply forgot to update the mux job. So the encoding when perfectly fine, but then MeGUI couldn't find the audio file it was told to mux, so it deleted the video file. If there is no prompt before deleting such files, I'd rather MeGUI just leave them. Better to leave a couple gigabytes in a folder, which I would easily find and deal with myself, than delete a perfectly fine video stream that took hours to encode.

Disabling the deleting of intermediate files altogether avoids this issue, but then I'd manually be deleting files all the time.

In short, if MeGUI has a file missing error, it shouldn't freak out and delete all the other files which are most likely still viable.

[Zathor]

In short, if MeGUI has a file missing error, it shouldn't freak out and delete all the other files which are most likely still viable.
Correct, MeGUI will not do that on his own in case of an error. The files will still be available.
Instead you have deleted the job in the queue which will then delete the intermediate files - this is the part of the cleanup process. As said before for this part a warning message should be added.

[unknownsoldierX]

I don't remember deleting the job, but perhaps I did. Maybe with the warning message, you could have a prompt asking if the files should be deleted?

[Zathor]

Maybe with the warning message, you could have a prompt asking if the files should be deleted?
Yes, something like that will be added in the future.



2239 [AviSynth Script Creator] added "Aspect Ratio Error"
2238 [AviSynth Script Creator] enabled upsizing

[Overdrive80]

Hey Zathor, I have perceived that value of aspect error is diferent to mine. I attach snapshot:

http://s2.postimage.org/p2f17fkvp/Algorithm.jpg (http://postimage.org/image/p2f17fkvp/)

I use this algorithm:

Function aspect_error(clip B, int "L_crop", int "U_crop", int "R_crop", int "B_crop", int "Op_width", int "Op_height")
{
#Defaults

In_width = B.width()
In_height= B.height()

Op_width = default( Op_width, In_width)
Op_height = default( Op_height, In_height)

#Crop & calc

Crop_width=In_width - abs(L_crop) - abs(R_crop)
Crop_height=In_height - abs(U_crop) - abs(B_crop)

Calc=(1-(float(Op_width*Crop_height))/(float(Crop_width*Op_height)))*100

return Calc
}

If you change crop value (that case) or resize, not exists autorefresh aspect error value.

http://s2.postimage.org/xlyf56t85/Captura2.jpg (http://postimage.org/image/xlyf56t85/)

[TSoft]

After update today to last build (2239), I am unable to open AVS Script Creator. :helpful:

[Zathor]

Any error? How are you trying to open the ASC?

[Zathor]

If you change crop value (that case) or resize, not exists autorefresh aspect error value.
Thank you very much - indeed the crop event was not checked (resize is checked) and it will be fixed in the next build. Beside that I use already more or less the same code as you so the result should be the same:

int iHeight = (int)file.VideoInfo.Height - Cropping.top - Cropping.bottom;
int iWidth = (int)file.VideoInfo.Width - Cropping.left - Cropping.right;
double aspectError = Math.Abs(1 - (iWidth * (double)verticalResolution.Value) / (iHeight * (double)horizontalResolution.Value));

[Overdrive80]

@Zathor I believe that the use of abs, in this case, is not necessary. Negative values ​​also represent a valid case, indicate zoom or upsize.

[Zathor]

2242 [AviSynth Script Creator] show signed "Aspect Ratio Error"
2241 [Worker] a finished temporary worker will not start anymore idle workers. Bug #691
several small optimizations
2240 [AviSynth Script Creator] "Aspect Ratio Error" will also be changed if cropping is changed

[TSoft]

Any error? How are you trying to open the ASC?


From menu tools.

This appears now:

http://i46.tinypic.com/35k4a6c.jpg

Here the log:
http://pastebin.com/J7FuzANK

[Zathor]

Thx, (hopefully) fixed in 2243.

[TSoft]

Thx, (hopefully) fixed in 2243.

Thanks now it works again :):thanks:

[hello_hello]

Wow! Ask and you shall receive..... and over the xmas period too!

Just a thank you for changing MeGUI's resizing to allow resizing "up" and for the addition of the aspect error information. If I had a first born, he/she would now be yours Zathor. :)

A few things.....(MeGUI 2243)
The light grey text is pretty hard to read when the background turns red. At least using my monitor.

When you activate the resizing, the aspect ratio error turns red when it's equal to or greater than the acceptable aspect error set it MeGUI's options (I assume). Which means, as I have the acceptable aspect error set to 0%, the aspect ratio error box is always red, even when I'm not actually resizing. Just checking anamorphic encoding or enabling resizing will turn it red.

The resize dimension colour change doesn't seem to take cropping into account, only the original source resolution, so it can fail to turn red when you're resizing up even when you are, after cropping. Personally I think as soon as you crop a couple of pixels, the appropriate width or height should turn red if it's not automatically reduced accordingly.

There's a minor GUI oddity between the way the anamorphic encoding options and the "suggest resolution" option interacts. When enabling anamorphic encoding and "resize to mod16", the "suggest resolution" option is available. Change the anamorphic option to something else and it becomes greyed out. Switch back to the "resize to mod16" anamorphic option and it remains greyed out until the anamorphic encoded option is disabled completely and then re-enabled.

Currently the aspect error calculation seems to work based on the source storage aspect ratio rather than the display aspect ratio and I'm not sure it's offering the correct aspect ratio error when using anamorphic encoding. Is it supposed to?? For example when opening a 704x384 AVI and cropping 2 pixels from one side, with resizing still at 704x384 the aspect error displayed is 0.235%. With anamorphic encoding enabled and the resolution the same, MeGUI adds 170:93 as the aspect ratio to the script which seems correct, in which case shouldn't the aspect ratio error reduce accordingly?
When opening a PAL 16:9 DVD with resizing left at 720x576 (non-anamorphic), MeGUI displays a 0% aspect error. Using "suggest mod16 resolution" resizes to 720x400 but increases the aspect error to around 30%, so I guess the calculation isn't taking the source pixel aspect ratio into account.

MeGUI's anamorphic encoding option seems to do it's resizing in an odd fashion since the changes, when using the anamorphic resize to mod16 option.... which I guess becomes resize to mod2 or mod4 depending on the "suggest resolution" setting. It's the same when resizing to square pixels with "suggest resolution" enabled. With it set to mod2, cropping 2 pixels from the side of a PAL DVD automatically changes the resizing to 720x578 while the height displays red, rather than resize down to 718x576. Cropping 4 pixels gives me 720x580 instead of 716x576. Of course it's easy enough to manually change the width to 716 and MeGUI will change the height back to 576 but it seems to be calculating the wrong way. A week ago MeGUI wouldn't let me resize up, today it's almost insisting. ;) It'd be more consistent if cropping the width reduces the width the same way cropping the height reduces the height.

The aspect error being displayed and the aspect ratio MeGUI adds to the script can't always both be correct, as the aspect ratio being added to the script changes according to the "acceptable aspect error" setting in MeGUI's options, however the aspect ratio error calculation does not. I'm still not sure if the aspect error being displayed is supposed be correct when using anamorphic encoding, but if it's supposed to be, I guess it isn't.
For instance if you have the "acceptable aspect error" set to 2% in MeGUI's settings, cropping a few pixels from a DVD won't change the aspect ratio being added to the script. It'll stay as 16:9 until you've cropped more than a few more pixels. The Aspect Ratio Error being displayed increases with each crop, which is at least the expected result.
When you change the acceptable aspect error option to 0%, the aspect ratio being added to the script changes each time you crop as it should, but the aspect error calculations remain the same as before. I assume if the aspect ratio being added to the script changes according to the "accpetable aspect error" setting, so too should the aspect error calculation?

Anyway, thanks again for the resizing improvements!! I guess either there's still a few bugs, or I'm simply not understanding how it should work. It's really only since the changes I've started using MeGUI to do the resizing. Until a few days ago I've been adding it to the script manually, so maybe I've still got to get my head around how MeGUI does it. :)

[Zathor]

The light grey text is pretty hard to read when the background turns red.
Changed

When you activate the resizing, the aspect ratio error turns red when it's equal to or greater than the acceptable aspect error set it MeGUI's options (I assume). Which means, as I have the acceptable aspect error set to 0%, the aspect ratio error box is always red, even when I'm not actually resizing.
Fixed - it is now only red if the value is greater than (and not equal) to the selected error value.

The resize dimension colour change doesn't seem to take cropping into account, only the original source resolution, so it can fail to turn red when you're resizing up even when you are, after cropping.
Fixed

I guess either there's still a few bugs, or I'm simply not understanding how it should work.
The point is that I am not using the resizing part myself very often and I have never used the anamorphic resizing part for productive videos. Not the best prerequisites for rewriting that part (and that is one reason I did that not before) - I will likely miss some options and therefore I am glad that you provide so much and constructive feedback. I will come back to your other points later as I have to check several things and I have no time for that at the moment.

[hello_hello]

Thank you Zathor.

While I was playing around with MeGUI I had a look at StaxRip and it appears I was wrong when I posted a while back and said it displays the correct aspect ratio error for anamorphic encoding. It doesn't. I'm pretty sure HDConvertToX only calculated it correctly when resizing to square pixels and the Yoda Resize Calculator does the same (well it displays the correct aspect ratio to use for anamorphic encoding but the aspect error calculation assumes square pixels).

As MeGUI didn't seem to be always calculating the aspect error correctly when resizing DVDs to square pixels I didn't go as far as trying to work out whether it should be getting it right when using anamorphic encoding, and given none of the above programs do I thought maybe it's hard to implement, or just not necessary when using anamorphic encoding, given MeGUI basically takes care of the aspect ratio via the script.

If that's the case, maybe relabelling the aspect error calculation as "non-anamorphic aspect error" might avoid confusion, or disabling the calculation completely when anamorphic encoding is enabled to make it clear it's not required might be an idea.

Anyway.... thanks for all the hard work on MeGUI. It's greatly appreciated.

[Zathor]

There's a minor GUI oddity between the way the anamorphic encoding options and the "suggest resolution" option interacts. When enabling anamorphic encoding and "resize to mod16", the "suggest resolution" option is available. Change the anamorphic option to something else and it becomes greyed out. Switch back to the "resize to mod16" anamorphic option and it remains greyed out until the anamorphic encoded option is disabled completely and then re-enabled.
Thx - fixed.

Also I changed it so that the aspect error will only be shown when not using the anamorphic options.

Therefore only one of your remarks below is open - the resizing behavior when using anamorphic options.

[durwood]

I updated to version 2237 the other day and it does some strange things that I cannot figure out how to change. If it's by design and not a bug I apologize.

Using the oneclick it forces pgcdemux even if I have the movie only? Maybe I don't understand the purpose.

Also in oneclick, it encodes all audio tracks even if there is only 1 selected and no other additional ones selected.

[Kurtnoise]

2226 [HD Streams Extractor] fixed handling of input files with a + in the file name

I believe that this revision breaks EVO files & Seamless branching extraction. I've an error when I trigger the Jobs Creation...I'm investigating.

[hello_hello]

Thx - fixed.

Also I changed it so that the aspect error will only be shown when not using the anamorphic options.

You're awesome Zathor!

I was thinking a little about anamorphic encoding vs resizing to square pixels and how the "suggest resolution" mod16/8/4/2 option interacts with each. Maybe the "resize to mod16" anamorphic option could now use a new name. Something like "resize to mod16/8/4/2" to reflect the fact it now changes according to the mod setting? Just to make it less ambiguous. I know it's only a little thing.

And I guess one day it'd be nice if the overcrop and undercrop anamorphic options all followed suit and obeyed the mod/16/8/4/2 setting to keep everything consistent, as mod16 only is kind of obsolete these days. The "encode non-mod16" option would be a handy one to keep though as then there'd still be one anamorphic option which ignores the mod16/8/4/2 setting.

Just some thoughts anyway.....

Thanks again!

[invy]

Hello, I just updated to 2237 and I have a couple of questions:

1. Is there a reason why when I use the OneClick, it is adding a duplicate/extra audio job to the queue, and therefore making it encode the same exact track twice?

2. I used the OneClick and selected a folder of 5 MPGs to encode. Why, then, when I check the Queue, do I only see 1 set (idx,oneclick) of jobs appear for the 1st MPEG? The 2nd set doesn't appear until the 1st is done, the 3rd set doesn't appear until the 2nd is done, etc etc.

Was this intentionally done so MeGUI doesn't stall for so long while adding an entire folder that could contain a large amount of files?

[Zathor]

Using the oneclick it forces pgcdemux even if I have the movie only?
To avoid problems with multiple PGCs.

Also in oneclick, it encodes all audio tracks even if there is only 1 selected and no other additional ones selected.

1. Is there a reason why when I use the OneClick, it is adding a duplicate/extra audio job to the queue, and therefore making it encode the same exact track twice?

This does not happen for me. Are you sure that you have selected only one audio track? Also please provide the complete log.

I believe that this revision breaks EVO files & Seamless branching extraction. I've an error when I trigger the Jobs Creation...I'm investigating.
Are you sure? I just extracted some files from a EVO and two combined VOB files without problem.

2. I used the OneClick and selected a folder of 5 MPGs to encode. Why, then, when I check the Queue, do I only see 1 set (idx,oneclick) of jobs appear for the 1st MPEG? The 2nd set doesn't appear until the 1st is done, the 3rd set doesn't appear until the 2nd is done, etc etc.
Was this intentionally done so MeGUI doesn't stall for so long while adding an entire folder that could contain a large amount of files?
No, the reason is that if you have several large files which need to be demuxed your hard disk space may be not sufficient. Therefore one job will be handled completly and then the next one will be created - deleting the intermediate files inbetween.

[invy]

I think it may be because I pressed the "+" next to where it says Audio 1 in the One Click Encoder window? Could that have been the reason for 2 identical audio jobs?

Also, is there a way to make it add all of them to queue at once? (for those that are certain hdd space won't be an issue)

EDIT: Fixed. Yeah I think that's why it was adding duplicates...

[Zathor]

Also, is there a way to make it add all of them to queue at once? (for those that are certain hdd space won't be an issue)
Maybe I will add that in the future. But I do not understand the reason. Why do you want to see all jobs?

[invy]

Maybe I will add that in the future. But I do not understand the reason. Why do you want to see all jobs?

Well, for one, so I could queue some to a secondary worker.

And two, every once in a while I may have a MPEG file that would stall while its being indexed due to some minor corruption (OTA caps that could usually be fixed by a quickstream fix in VideoRedo). So as you could imagine, the result would be nothing further being processed from that point on in the queue.

Whereas, typically, before the update, I could just wait around a few minutes to make sure all the jobs were indexed. And from there on, I could start a secondary queue if need be (back to my first reason...) .

[Zathor]

MeGUI's anamorphic encoding option seems to do it's resizing in an odd fashion since the changes, when using the anamorphic resize to mod16 option.... which I guess becomes resize to mod2 or mod4 depending on the "suggest resolution" setting. It's the same when resizing to square pixels with "suggest resolution" enabled. With it set to mod2, cropping 2 pixels from the side of a PAL DVD automatically changes the resizing to 720x578 while the height displays red, rather than resize down to 718x576. Cropping 4 pixels gives me 720x580 instead of 716x576. Of course it's easy enough to manually change the width to 716 and MeGUI will change the height back to 576 but it seems to be calculating the wrong way. A week ago MeGUI wouldn't let me resize up, today it's almost insisting. ;) It'd be more consistent if cropping the width reduces the width the same way cropping the height reduces the height.
Thx & fixed. Btw. this was not caused by the recent changes. MeGUI "since ages" did an upsize in such a case. With the recent changes (mod2 and marked red) it is now better visible.

[TSoft]

Zathor,

is now the 2243 the last build ???

[Zathor]

Yes, a newer build will be uploaded in the next days.
EDIT: Changelog of the at the moment implemented changes can be found here:
http://megui.svn.sourceforge.net/viewvc/megui/megui/trunk/Changelog.txt
Some local changes are missing

[aegisofrime]

Hi Zathor,

Firstly, thanks for this excellent tool and the hard work you have put into it :)

I'm just wondering, any plans to add Vapoursynth support? It gives a nice speed-up over Avisynth in my tests. :o

Thanks again!

[Kurtnoise]

Are you sure? I just extracted some files from a EVO and two combined VOB files without problem.

Index: packages/tools/hdbdextractor/HDBDStreamExtractor.cs
===================================================================
--- packages/tools/hdbdextractor/HDBDStreamExtractor.cs (revision 2248)
+++ packages/tools/hdbdextractor/HDBDStreamExtractor.cs (working copy)
@@ -345,9 +345,9 @@

// Load to MeGUI job queue
if (FolderSelection.Checked)
- job = new HDStreamsExJob(new List<string>() { dummyInput }, this.FolderOutputTextBox.Text + "xxx", args.featureNumber, args.args, inputType);
+ job = new HDStreamsExJob(new List<string>() { dummyInput }, this.FolderOutputTextBox.Text, args.featureNumber, args.args, inputType);
else
- job = new HDStreamsExJob(input, this.FolderOutputTextBox.Text + "xxx", null, args.args, inputType);
+ job = new HDStreamsExJob(input, this.FolderOutputTextBox.Text, null, args.args, inputType);

lastJob = job;
mainForm.Jobs.addJobsToQueue(job);
@@ -464,10 +464,20 @@
// create dummy input string for megui job
if (feature.Description.Contains("EVO"))
{
- if (FolderInputTextBox.Text.ToUpper(System.Globalization.CultureInfo.InvariantCulture).Contains("HVDVD_TS"))
- dummyInput = FolderInputTextBox.Text + feature.Description.Substring(0, feature.Description.IndexOf(","));
+ if (feature.Description.Contains("+"))
+ {
+ if (FolderInputTextBox.Text.ToUpper(System.Globalization.CultureInfo.InvariantCulture).Contains("HVDVD_TS"))
+ dummyInput = FolderInputTextBox.Text.Substring(0, FolderInputTextBox.Text.IndexOf("HVDVD_TS")) + "HVDVD_TS\\" + feature.Description.Substring(0, feature.Description.IndexOf("+"));
+ else
+ dummyInput = FolderInputTextBox.Text + "HVDVD_TS\\" + feature.Description.Substring(0, feature.Description.IndexOf("+"));
+ }
else
- dummyInput = FolderInputTextBox.Text + "HVDVD_TS\\" + feature.Description.Substring(0, feature.Description.IndexOf(","));
+ {
+ if (FolderInputTextBox.Text.ToUpper(System.Globalization.CultureInfo.InvariantCulture).Contains("HVDVD_TS"))
+ dummyInput = FolderInputTextBox.Text.Substring(0, FolderInputTextBox.Text.IndexOf("HVDVD_TS")) + "HVDVD_TS\\" + feature.Description.Substring(0, feature.Description.IndexOf(","));
+ else
+ dummyInput = FolderInputTextBox.Text + "HVDVD_TS\\" + feature.Description.Substring(0, feature.Description.IndexOf(","));
+ }
}
else if (feature.Description.Contains("(angle"))
{

Otherwise megui crashes coz the job Input contains several names...

From the log:

-[Information] HD Streams Extractor
--[Information] [30/12/2012 10:24:32] Input: G:\
--[Information] [30/12/2012 10:24:32] Arguments: "G:\"
--[Information] [30/12/2012 10:24:32] Feature Retrieval Completed
--[Information] [30/12/2012 10:24:37] Arguments: "G:\" 1) -progressnumbers
--[Information] [30/12/2012 10:24:38] EVO, 1 video track, 4 audio tracks, 10 subtitle tracks, 2:39:01
--[Information] [30/12/2012 10:24:38] Stream Retrieval Completed
-[Error] Log for job1 (ext, feature_01.EVO+feature_02.EVO -> Eyes Whide Shut)
--[Information] [30/12/2012 10:26:15] Started handling job
--[Information] [30/12/2012 10:26:15] Preprocessing
--[Error] [30/12/2012 10:26:15] Error starting job
---[Error] [30/12/2012 10:26:15] Exception message: Calling setup of processor failed with error 'Required file 'G:\HVDVD_TS\feature_01.EVO+feature_02.EVO' is missing.'
---[Error] [30/12/2012 10:26:15] Stacktrace: à MeGUI.core.gui.JobWorker.startEncoding(TaggedJob job)
---[Error] [30/12/2012 10:26:15] Inner exception: null

[invy]

@Zathor: Is it possible to put only muxing jobs in higher priority (or normal at least) by default? It's always bothered me that muxing always goes hell slow when it's on "low" priority.

Like right now, I came back to my PC to see it was muxing a 1.23 GB file. The time elapsed was over 5 MINUTES and it was not even half way done. The moment I put it on below normal, normal, or above normal priorities, it zipped right through and finished it within a minute.

I want to keep audio/video jobs on low, though. And, as it stands right now, I believe MeGUI remembers the priority of the last/current job, and when the status window of the next job pops up it will use the same priority of the last one that finished.

It would great if there is a way, or if not, I'd like to put in a request for it. :)

[Zathor]

Otherwise megui crashes coz the job Input contains several names...
Thx, I never tested it with two EVO files.

[Zathor]

2253 [Queue] warn if intermediate files of an incomplete job are going to be deleted
2252 [Worker] if a job is aborted the corresponding worker will be stopped
2251 [OneClick] pgcdemux will only be used if more than one PGC is found
2250 [AVS Script Creator] avoid upsizing when resizing a cropped source
[AVS Script Creator] added option to enable upsizing in the profile (disabled by default)
[AVS Script Creator] added option to select the default mod value in the profile (mod16 by default)
[AVS Script Creator] adjusted "Clever (TM) anamorphic encoding" so the new mod values are used
[OneClick] obey the new AVS Script Creator settings
2249 [HD Streams Extractor] fixed handling of seamless branching EVO files
2248 [OneClick] warn if identical tracks are about to be processed
2247 [AVS Script Creator] hide "Aspect Ratio Error" when doing an anamorphic encoding
fixed handling of the "Aspect Ratio Error" if dealing with an anamorphic input file
2246 [AVS Script Creator] enhanced readability of the "red parts"
the "Aspect Ratio Error" only turns red if the value is bigger than the acceptable aspect error
crop values will be used also for the upsize warnings
2245 [Queue] related jobs are highlighted when selecting a job
2244 [Queue] when deleting a job warn always if it is part of a related job series

[TSoft]

Hello Zathor,

thanks for all the work.

I often use MeGui with the option Oneclick to bring avi (with audio ac3 or mp3) in mp4 (video x264 and audio aac 48kbps).
Sometimes it doesn't work properly:

1. I noticed that when the audio in the avi was muxed with delay (positive or negative) Oneclick gives an error and was not able to extract the audio.
2. Sometimes all seems to go on well, but at the end (but not always) the muxed mp4 files was not in syncro though the avi was perfect.

The one point I can get around with having the avi no delay in the audio track, but point 2.... I don't know.
Now I'm using AutoEncoder, is it not the same thing... OneClick is better for me.

Please sorry for my english. I wish you a good new year and thanks again.

[Shevek]

Hi Zathor, I have found a bug in the Http Proxy code.

If you check the Use Proxy option in settings but don't enter server details then you get an error the next time MeGUI is launched:

MeGUI encountered a fatal error and may not be able to proceed. Reason: Invalid URI: The hostname could not be parsed.

This is un-recoverable and MeGUI exits and so you cannot fix the settings through the UI.

I could only fix it by editing the settings.xml file:

<UseHttpProxy>true</UseHttpProxy>

to

<UseHttpProxy>false</UseHttpProxy>

Whilst you are looking at this part of the code, could you implement system proxy details pass through for the user credentials as well?

Without knowing how you are implementing your call to the update server, I can't provide a full code sample but, as a starting point, to access the system proxy settings you can use:

System.Net.CredentialCache.DefaultCredentials

[Zathor]

1. I noticed that when the audio in the avi was muxed with delay (positive or negative) Oneclick gives an error and was not able to extract the audio.
2. Sometimes all seems to go on well, but at the end (but not always) the muxed mp4 files was not in syncro though the avi was perfect.
Please post the log and also try an older FFMS build (like 2.17).

If you check the Use Proxy option in settings but don't enter server details then you get an error the next time MeGUI is launched
Thx, fixed in 2254.

Whilst you are looking at this part of the code, could you implement system proxy details pass through for the user credentials as well?
As I do not have a proxy I cannot test it. If you can provide a patch I will implement it. The relevant code part is core\gui\UpdateWindow.cs:1270


WebClient serverClient = new WebClient();
WebProxy wprox = null;
ICredentials icred = null;
if (meGUISettings.HttpProxyUid != null)
icred = new NetworkCredential(meGUISettings.HttpProxyUid, meGUISettings.HttpProxyPwd);
wprox = new WebProxy(meGUISettings.HttpProxyAddress + ":" + meGUISettings.HttpProxyPort, true, null, icred);
WebRequest.DefaultWebProxy = wprox;
serverClient.Proxy = wprox;

[Shevek]

As I do not have a proxy I cannot test it. If you can provide a patch I will implement it. The relevant code part is core\gui\UpdateWindow.cs:1270


WebClient serverClient = new WebClient();
WebProxy wprox = null;
ICredentials icred = null;
if (meGUISettings.HttpProxyUid != null)
icred = new NetworkCredential(meGUISettings.HttpProxyUid, meGUISettings.HttpProxyPwd);
wprox = new WebProxy(meGUISettings.HttpProxyAddress + ":" + meGUISettings.HttpProxyPort, true, null, icred);
WebRequest.DefaultWebProxy = wprox;
serverClient.Proxy = wprox;

I only have a proxy at work, so I'll do some tests tomorrow and get back to you

[hello_hello]

Zathor,
I just updated to version 2253 and the adjustments to the resizing are great. Thanks! But.......

The calculations for the aspect ratio/error must be a little off at times.
16:9 PAL DVDs resized to 704x396 show an aspect error of 0%, which is correct, yet if you open a video of different dimensions, tell MeGUI the input aspect ratio is 16:9 and resize to 704x396 again, it shows a slight aspect ratio error. A very tiny one admittedly but 704x396 is still exactly 16:9 regardless of the input resolution.
The one which stands out the most is when resizing 4:3 DVDs to 640x480. The aspect ratio error shown is 0.13%. Oddly enough I opened a 704x384 AVI and told MeGUI it's input aspect ratio was 4:3, and a 640x480 resize showed a 0% aspect ratio error. I've sometimes wondered in the past if the aspect ratio MeGUI adds to the script was just a little off.....

A couple of little nitpicks if I may......
The anamorphic "to the selected mod" change works well, only using the undercrop and overcrop anamorphic options you can't actually select the mod because it's greyed out. I guess the "selected mod" setting is connected to the resizing so maybe it's not worth worrying about, but I'm OCD when it comes to consistency.
The anamorphic options aside from "resize to" disable the resizing, but the resize fields sometimes turn red when you crop. Maybe fixing that is already on your to-do list?

Anyhow..... thanks once more.

[hello_hello]

While I'm here...... :)

When you open a video via DirectShow MeGUI automatically adds frame rate conversion to the script, which I think is a good idea, but I've often wondered, why not do the same thing for ffmsindex? AVISource uses Assumefps instead, although maybe there's a good reason for that, but given ffmsindex can open all kinds of video including AVIs, I can't think of a reason why adding it's own frame rate conversion to the script would be a bad idea. I'd assume if the video is CFR then adding it would make no difference, but if it's VFR at least MeGUI could encode it without losing audio sync. Am I missing something?

Cheers.

[Zathor]

The one which stands out the most is when resizing 4:3 DVDs to 640x480. The aspect ratio error shown is 0.13%. Oddly enough I opened a 704x384 AVI and told MeGUI it's input aspect ratio was 4:3, and a 640x480 resize showed a 0% aspect ratio error.
Changing the input AR did not refresh the aspect error calculation. That is now fixed. Beside that I can not reproduce your problem. Will test later.

I've sometimes wondered in the past if the aspect ratio MeGUI adds to the script was just a little off.....
The calculation of the aspect error is complety new and has nothing in common with the other logic regarding SAR/PAR/DAR values which will be used and applied to the script for anamorphic encodings.


The anamorphic "to the selected mod" change works well, only using the undercrop and overcrop anamorphic options you can't actually select the mod because it's greyed out.
Fixed


The anamorphic options aside from "resize to" disable the resizing, but the resize fields sometimes turn red when you crop.

Also fixed - now the same logic as for the non-anamorphic upsizing takes place. Therefore the width/height will be reduced accordingly if upsizing is not enabled.

Thanks again for your feedback!

[Zathor]

The one which stands out the most is when resizing 4:3 DVDs to 640x480. The aspect ratio error shown is 0.13%. Oddly enough I opened a 704x384 AVI and told MeGUI it's input aspect ratio was 4:3, and a 640x480 resize showed a 0% aspect ratio error.

When doing a non-anamorphic encode the target SAR is 1:1 (square pixel). Therefore the input video must be converted also to SAR 1:1 to get the aspect ratio error:
720x576 with an aspect ratio of 4:3 has a SAR of 16/15 which results in 768x576 in SAR 1:1. Therefore you have an slight error with 640x480. Instead an 704x384 4:3 file has a SAR of 8/11 resulting in 512x384 for square pixels - wich is the same as 640x480 and therefore 0% aspect ratio error.

When you open a video via DirectShow MeGUI automatically adds frame rate conversion to the script, which I think is a good idea, but I've often wondered, why not do the same thing for ffmsindex?
Adding AssumeFPS can cause problem with telecined video as FFMS will alter the frame rate. At least that is the reason I remeber.