MeGUI Bug-Report Thread

[Gehenna]

Im getting the same error as AMED,i think the problem could lie here

Command line from my custom NAAC
Build 0.2.3.2024

"C:\Program Files\MP3 Utils\BeSweet\BeSweet.exe" -core( -input "G:\DVD\02x25\VTS_02_PGC_01_1 T01 3_2ch 448Kbps DELAY 0ms.ac3" -output "G:\DVD\02x25\VTS_02_PGC_01_1 T01 3_2ch 448Kbps DELAY 0ms.mp4" -logfile "G:\DVD\02x25\VTS_02_PGC_01_1 T01 3_2ch 448Kbps DELAY 0ms.besweet.log" ) -azid( -s stereo -c normal -L -3db ) -bsn( -2ch -vbr_internet -codecquality_high -aacprofile_lc ) -ota( -g max )

Build 0.2.3.2033

-core( -input "G:\DVD\02x25\VTS_02_PGC_01_1 T01 3_2ch 448Kbps DELAY 0ms.ac3" -output "G:\DVD\02x25\VTS_02_PGC_01_1 T01 3_2ch 448Kbps DELAY 0ms.mp4" -logfile "G:\DVD\02x25\VTS_02_PGC_01_1 T01 3_2ch 448Kbps DELAY 0ms.besweet.log" ) -azid( -s stereo -c normal -L -3db ) -bsn( -2ch -vbr_internet -codecquality_high -aacprofile_lc ) -ota( -g max )

This part is missing "C:\Program Files\MP3 Utils\BeSweet\BeSweet.exe" in build 2033

[Richard Berg]

I tracked down AMED's messagebox, worried because it originates from my new error checking code. Turns out it's not my bug ;)

In MeGUI.getDelay(), fix this line:

// wrong: string delay = openFileDialog.FileName.Substring(start + 6, openFileDialog.FileName.LastIndexOf("ms.") - start - 6);
string delay = fileName.Substring(start + 6, fileName.LastIndexOf("ms.") - start - 6);


AMED: please confirm that it does not happen if you rename your audio file to not have "delay" in the name.

[Doom9]

This part is missing "C:\Program Files\MP3 Utils\BeSweet\BeSweet.exe" in build 2033Thanks for an insightful report.. I'm afraid this is most likely an error on my part.. I can verify when I get home.

[stax76]

Not necessary better but a different approach:


public int ExtractDelay(string value) {
Match m = Regex.Match(value, @"(-?\d+)ms\.");
if (m.Success) return int.Parse(m.Groups[1].Value);
return 0;
}

[Doom9]

Turns out it's not my bugWell.. somebody moved around stuff and it wasn't me.. I still recognize my openDialog ;)

@stax: while I have no doubt it does the same, it is incomprehensible for anybody not familiar with regexps.. that's why I think they are to be avoided at all cost. Regexps all but kill Perl and invite people to write code nobody else can comprehend. While that may be good for job security, there are also the obvious drawbacks of such an approach.

[AMED]

AMED: please confirm that it does not happen if you rename your audio file to not have "delay" in the name. When i change the filename from VTS_02_1 T01 2_0ch 192Kbps DELAY -15ms.ac3 to VTS_02_1 T01 2_0ch 192Kbps.ac3, the unsupported configuration error box does not appear.

[Morte66]

When you hit "Auto Encode" on the "Input" tab with no audio file selected, then check "Add additional content" on the "Automatic Encoding" dialogue and hit "Queue", there is an error launching the "Mux" dialogue. It pops up a message to say "Problem with audio input filename: The path is not of a legal form." Of course, at this point you have not selected any audio (since you are e.g. muxing original AC3 without encoding it).

You can just ignore the message, select sound/subtitles/chapters, and hit "Go". The output filename is disabled so you can't change it, but it loads the mux job in the queue with the default name.

[Doom9]

@Richard: what morte66 reports.. could it be caused by the changes you've made? I know when I wrote this I tested it and I don't recall making changes there

[Richard Berg]

Yes. I had it call my filename error checking during AutoEncode. Is it legal to AutoEncode w/o audio? What is it supposed to do?

[Doom9]

Is it legal to AutoEncode w/o audio? Yes it is..
What is it supposed to do?
if (noAudio2BeEncoded && noAudioToBeMuxed)
bitrate = calculateBitrate (for the given container given the desired target size... make nothing if the "don't care" flag is set for bitrate)
if (noAudio2BeEncoded && audioToBeMuxed)
bitrate = calculatebitrate(target size - audio size - audio muxing overhead )
if (audioToBeEncoded)
just create jobs and write the desired target size in the video job so that once we switch from audio to video, we can recalculate the bitrate.

[digidragon]

When deleting some jobs from the queue, I got an error (MeGui 0.2.3.2033):
---------------------------
Fatal error
---------------------------
MeGUI encountered a fatal error and has to close. Reason: The given key was not present in the dictionary. Source of exception: mscorlib stacktrace: at System.ThrowHelper.ThrowKeyNotFoundException()

at System.Collections.Generic.Dictionary`2.get_Item(TKey key)

at MeGUI.MeGUI.deleteJobButton_Click(Object sender, EventArgs e)

at System.Windows.Forms.Control.OnClick(EventArgs e)

at System.Windows.Forms.Button.OnClick(EventArgs e)

at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)

at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)

at System.Windows.Forms.Control.WndProc(Message& m)

at System.Windows.Forms.ButtonBase.WndProc(Message& m)

at System.Windows.Forms.Button.WndProc(Message& m)

at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)

at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)

at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
---------------------------
OK
---------------------------

Although it said it had to close, it didn't.

BTW, this was when deleting some duplicate jobs (jobs 2 through 4) - jobs 1-1, 1-2, and 5 would have remained afterwards.

[Doom9]

@digidragon: can you be more specific as how anybody can reproduce this scenario? Start out with a vanilla MeGUI build (extract it to another directory), then set up jobs and try to make it crash again.. that's what we need to reproduce and identify the problem.

Although it said it had to close, it didn't.Yippie.. my code to catch fatal flaws works... I was never sure since I hardly manage to crash it anymore.

[digidragon]

Well, it was actually a virgin install...

I just loaded an avisynth script. I added the video to the queue (avc-mp4). Then I tried to add the audio (ac3->FAAC) to the queue. But it complained that the input/output formats were incompatible. I altered some parameters and tried to queue it again, but had the same error. I tried again, but got the same error. I tried yet again, and finally it seemed to work. But then I noticed that although it had given me the incompatibility errors, it had actually added all those the jobs to the queue. That's why I deleted the duplicate jobs mentioned in my above post.

[bob0r]

Not really a bug, but just pointing this warning out again:

dimzon creates them, sharktooth fixes them (just to promote one megui version here comes):

megui-x264-svn.exe

Microsoft (R) Visual C# 2005 Compiler version 8.00.50727.42
for Microsoft (R) Windows (R) 2005 Framework version 2.0.50727
Copyright (C) Microsoft Corporation 2001-2005. All rights reserved.

SettingsForm.cs(111,25): warning CS0169: The private field 'MeGUI.SettingsForm.textBox3' is never used
SettingsForm.cs(112,23): warning CS0169: The private field 'MeGUI.SettingsForm.label3' is never used
SettingsForm.cs(113,24): warning CS0169: The private field 'MeGUI.SettingsForm.button3' is never used
SettingsForm.cs(114,25): warning CS0169: The private field 'MeGUI.SettingsForm.textBox2' is never used
SettingsForm.cs(115,23): warning CS0169: The private field 'MeGUI.SettingsForm.label2' is never used
SettingsForm.cs(116,24): warning CS0169: The private field 'MeGUI.SettingsForm.button2' is never used
SettingsForm.cs(117,25): warning CS0169: The private field 'MeGUI.SettingsForm.textBox1' is never used
SettingsForm.cs(118,23): warning CS0169: The private field 'MeGUI.SettingsForm.label1' is never used
SettingsForm.cs(119,24): warning CS0169: The private field 'MeGUI.SettingsForm.button1' is never used

"SettingsForm.cs 1.19 dimzon lame/faac/neroaac path selection some little code cleanup"

EDIT:
DOH that was irontic:
http://forum.doom9.org/showthread.php?p=771938#post771938

Bloody slow SF CVS :)

[puffpio]

Not a bug, but warning

Using megui 0.2.3.2033

Created a cbr mp3 w/ megui, created an xvid avi w/ megui using the mencoder program.

When I tried muxing them together with the avi muxer, I selected the audio and video, chose CBR for audio, and when I added it to the queue, I get an error saying the avi could not be loaded...a problem with loading the avi and to check the avs script (even though the avi I'm loading i an avi..not avs)

However the job still added to the queue and I was able to mux succesfully

[puffpio]

Using megui 0.2.3.2033

When loading an avs file into the program, then going into the bitrate calculator, the video length, framerate, and framecount is incorrect

This occurs both when I loaded an avs script taht was @ 29.97fps and also at 23.97fps. In both cases the framerate the bitrate calculator displayed was 25fps, and the video length was short by a couple minutes.

It used to work correctly a couple versions ago...maybe I need to delete some configuration files?

[Doom9]

It used to work correctly a couple versions ago...maybe I need to delete some configuration files?I suspect the fps reported is not exactly 23.976 anymore.. did you recently upgrade dgindex or avisynth? those changes aimed at getting around QT's and mplayers inability to play all kinds of MP4 files were bound to break other applications...

[puffpio]

ahh..yeah im running the latest beta of dgindex..i'm running 2.56 of avisynth

o well..not a big problem..i just get the framecount by opening the avs in vdub..and i know what the framerate is, so I can just it manually

[The Link]

A bug I reported here (http://forum.doom9.org/showthread.php?p=772455#post772455).

[Richard Berg]

@Doom9 - here is a patch to fix the two bugs we discussed. Please review.
http://richardberg.net/bin/temp/filechecking-bugfixes.rar

[Doom9]

@Richard: if you're going to use List instead of ArrayList (no objections to that at all.. I'm glad we can remove them one by one.. ), why not go all the way and get rid of all the casts that are no longer necessary?

[Richard Berg]

What casts? Maybe the patch didn't work correctly...here's that function:
private AudioStream[] getConfiguredAudioJobs()
{
List<AudioStream> list = new List<AudioStream>();
foreach (AudioStream stream in audioStreams)
{
if (String.IsNullOrEmpty(stream.path))
{
// no audio is ok, just skip
break;
}
string settingsError = stream.isEncodable();
if (settingsError != null)
{
MessageBox.Show(settingsError, "Unsupported audio configuration", MessageBoxButtons.OK, MessageBoxIcon.Stop);
break;
}
if (mp4Output.Checked)
{
if (stream.isMP4Muxable())
list.Add(stream);
}
else if (aviOutput.Checked)
{
if (stream.isAVIMuxable())
{
list.Add(stream);
break; // only one avi stream is allowed
}
}
else if (mkvOutput.Checked)
{
if (stream.isMuxable())
{
list.Add(stream);
}
}
}
return list.ToArray();
}
The List<> is a local variable -- I didn't change the method signature -- so casting elsewhere in the program isn't affected.

[Doom9]

hmm.. looks like somebody already did quite a bit of cleaning up.. I don't recall using the ToArray function at all. I only had a look at the patch, not the result of applying it, sorry.

[Richard Berg]

ToArray() is in the patch :)

[Doom9]

well.. it looks like it's all good then. And as far as the audio config goes in the main screen.. I think we can do away with the mp3 limitation.. just offer both configurations and in case of avi output, the second stream will be dumped (with a message to the log perhaps.. or display a message to the user).

I was also thinking about a feature that might be useful: warn the user if his job is likely to fill up his HD. It doesn't have to be an accurate size prediction.. but if a simplified calculation returns that the output might become too big.. it might not hurt to be warned (especially some people with PCs that have no business encoding AVC since they're too slow, are willing to wait for days for an encode to complete).

[Richard Berg]

Sounds good. A rough check can't hurt, so long as you can override it.

[ChronoCross]

I really wish I could give a better but report than I'm about to but I don't have alot of information due to the nature of the bug.

MeGUI freezes when trying to load the avs it creates in the pre-render step.
The AVI is 19GB and is unloadable in any player. The created avs also crashes vdubmod and virtualdub(stable).

That's all the info I can give cause no output is given to logs and no error message is displayed.

[berrinam]

I've updated the bug list at the beginning of the thread. I'm not sure of the status of these, so I listed all the new ones as not yet solved.

@ChronoCross: Do you have the newest build of mencoder? What is the error when trying to load the avi with vdubmod?

[ChronoCross]

I've updated the bug list at the beginning of the thread. I'm not sure of the status of these, so I listed all the new ones as not yet solved.

@ChronoCross: Do you have the newest build of mencoder? What is the error when trying to load the avi with vdubmod?
yeah first time around I used C_D's build. Then I built my own copy of it and ran the test again using the cvs from today.

MeGUI and vdubmod don't give an error with the avs. When I load the .avi straight into vdub mod it says the following:

"Reconstructing missing block index (Aggressive mode)"

After reconstruction:
[!] AVI: Index not found or damaged -- reconstructing via file scan.

[!] AVI: Keyframe flag reconstruction was not specified in open options and
the video stream is not a known keyframe-only type. Seeking in the video
stream may be extremely slow.

[berrinam]

Weird.... I got that same problem with VDubMod, when I was testing with mencoder output. Then I added the commandline switches, --noodml --forceidx, and it was fixed. It sounds like you have the opposite problem. I'm not convinced as to the reliability of mencoder for large files, but I stuck with it because I didn't think it was worth adding another dependancy. Perhaps mencoder shouldn't be used...

[ChronoCross]

Do you think we could do x264 lossless rather than huffy? The load it in DirectShowSource with a known fps? I know this presents a problem in terms of vfr but for cfr it would be an possible solution.

[berrinam]

Do you think we could do x264 lossless rather than huffy? The load it in DirectShowSource with a known fps? I know this presents a problem in terms of vfr but for cfr it would be an possible solution.
It's a possibility. However, the problem is speed, as x264 is quite slow when compared to huffyuv. I suppose with most options disabled, it wouldn't be so bad, though.

No matter which codec is used, though, there is still the problem of a hidden dependancy on being able to play H264 files. I'm not even sure that MeGUI has any way of checking that except .... oops, getting carried away again. I suppose that it could be tried.

My idea when getting carried away is that as well as doing a check for all required programs (which has been suggested somewhere), MeGUI could also create a few dummy scripts/clips to see whether they could be rendered, eg it could create a blank yv12 avs script to see if it can be loaded, and it could create a blank lossless x264 clip to see if it can be directshowsource'd. If not, MeGUI should download and install CoreAVC+Haali. Ah well, this is the wrong thread for that, and it's not going to happen until autoonlineupdate is supported.

[foxyshadis]

h.264 lossless is not that efficient. I mean, entirely aside from being abominally slow to encode and play, it's only slightly smaller than lagarith (that's on my filtered anime, but I've heard it's even worse with rl) with every x264 quality setting maxed out. (Encoding time 30x lags.) With most options disabled it's actually usually larger than lags and huffy, and still slower. :p

[berrinam]

The efficiency is not the point. If you have enough space to losslessly compress, and be able to account for variances in compressibility, it really doesn't matter how efficient it is. However, speed is of course important, and, as you said, it IS slower. The real reason why x264 lossless is worth considering for MeGUI is that the output files _work_, whereas that doesn't seem to be certain with mencoder.

[ChronoCross]

Well I finished another test using ffdshow to encode the Huffy AVI. It was 26GB rather than the 19 of the mencoder version. There were no avi errors and it loaded perfectly in Megui. Seems mencoder has a problem with huffy or with avi itself when doing large files. ffdshow to huffy is another idea to consider.

[Doom9]

Seems mencoder has a problem with huffy or with avi itself when doing large files. ffdshow to huffy is another idea to consider.I think avi is the culprit, I've seen similar report for > 4 GB XviD output. I'm hoping encraw won't have these problems. Has anybody tried ffmpeg? I'm about to look into it for muxing (mencoder's raw -> avi muxing has issues as well). I don't think x264 lossless would be a good idea either.. there's no avi output so you'd have to open the input via directshowsource and that's where parser issues enter the game.

[foxyshadis]

http://forum.doom9.org/showthread.php?p=772934#post772934
and the following posts.

Sorry, I was in a hurry: problem is that command-line inloop filter settings are incorrectly generated.

[Richard Berg]

mencoder doesn't like my slow AVS scripts, period. It quits before the first frame is returned, saying it can't figure out the input format. Works fine with simple test scripts in the same rez/colorspace.

[Razorholt]

Bug: The small arrows for the "Birate Variance" don't increase/decrease the values well... unless I'm wrong?

- Dan

[puffpio]

Bug: The small arrows for the "Birate Variance" don't increase/decrease the values well... unless I'm wrong?

- Dan
Happens to me too..but only in certain situations

If you open the bitrate calc and use the arrows, it works.
However, if you start changing numbers manually (maybe even start changing other fields in different parts of that window) And then go back to the up and down arrows, they don't work anymore

[Richard Berg]

Bugs:

1) pre-rendering checkbox does nothing with AutoEncode

2) I get the "audio input file" error even when AutoEncoding with valid audio. I won't after my fix, but this makes me worry I made the wrong fix (i.e. I'm checking the wrong filenames to begin with)

These bugs convince me that we need to refactor AutoEncode so that it uses the regular audio & video queueing codepaths. Having to fix everything in 2 places is killing us, especially when those 2 places operate with very different internal logic.

3) Have some jobs going. Dragdrop a d2v file and queue the index job. The d2v creator dialog will sit there, and the rest of MeGUI will be unresponsive, until you kill it. Waiting for the index job would probably work too, but that might be days away...

[Tima]

Bugs and one feature request for Bitrate Calculator

- when selecting audio file, there's no 'ogg' extension in filetype box.
- when I change framerate, Number of frames (instead of length!) changes. It's confusing. :)
+ there'd be good to take into account other files I want to put on CD. This feature is present in Gordian Knot, for example.

[berrinam]

I think avi is the culprit, I've seen similar report for > 4 GB XviD output. I'm hoping encraw won't have these problems. Has anybody tried ffmpeg? I'm about to look into it for muxing (mencoder's raw -> avi muxing has issues as well).ffmpeg seems to be the solution for a lot of problems that mencoder has. What does mencoder do that ffmpeg doesn't? Perhaps a complete switch to ffmpeg could be a solution?

I don't think x264 lossless would be a good idea either.. there's no avi output so you'd have to open the input via directshowsource and that's where parser issues enter the game.Yes... with all of these methods, there is the issue of an implicit dependency on ffdshow (afaik, that's the only vfw decoder of ffvhuff).

[Doom9]

does ffmpeg support snow?

[dimzon]

does ffmpeg support snow?

ffmpeg -formats

produce


...
DEV snow
...

[puffpio]

Using megui 0.2.3.2033

When loading an avs file into the program, then going into the bitrate calculator, the video length, framerate, and framecount is incorrect

This occurs both when I loaded an avs script taht was @ 29.97fps and also at 23.97fps. In both cases the framerate the bitrate calculator displayed was 25fps, and the video length was short by a couple minutes.

It used to work correctly a couple versions ago...maybe I need to delete some configuration files?


further comment..i've used avisynth 2.56 for quite a while now..and it's worked always..so I believe the problem can be narrowed down to just dgindex and not avisynth. not a big deal, but since this bug report made it's way to the first post, I felt I should narrow down the search space :P

[Doom9]

so I believe the problem can be narrowed down to just dgindex I think so to. I think the breaking change has been introduced in 1.4.6 beta 3 (http://forum.doom9.org/showthread.php?p=764522#post764522) so if you could try to create your project again using an older beta (or just the latest stable version) and verify that it works there, that would be much appreciated.


- when selecting audio file, there's no 'ogg' extension in filetype box.That's right.. that's because the calculator doesn't support Vorbis.. it's almost impossible to accurately calculate it (you can find some details in a thread in the container form).
+ there'd be good to take into account other files I want to put on CD. I approach this a different way: you can set the output size ;) As you may want to include X files from Y different directories, it would become quite complex rather quickly to handle this all.. so it's better that you get the filesize in KB from your files and set the output size accordingly.

- when I change framerate, Number of frames (instead of length!) changes. It's confusingWell.. it's a question of your approach, isn't it? If you have your input already configured, lenght and FPS will be set correctly so there's no need to change the FPS dropdown, is there? The only reason I could imagine is that the source script (but that's really far fetched when I think of it because the source script should already include IVTC commands), would be 29.97 and you know you're going to IVTC (in GKnot you even have to manually change the FPS in that case).. but that doesn't change the movie's length, but the number of frames is to be changed. However, assume somebody is using the calculator as a standalone tool, thus having to manually input the source length and FPS. I think it's more likely that this person would enter the movie's length rather than the number of frames, then select the FPS, which in turn calculates the proper number of frames.

Now who volunteered to have a go at the calculator? It should be somebody headache resistant.. it's a major PITA.

[Morte66]

MeGUI 0.2.3.2033: In the "OneClickConfigurationDialog" launched from the "One Click Profile Setup" menu, there is a checkbox for "Automatic Deinterlacing". If I set that and then bring up "One Click Encoder" to set up the actual job, the other settings are copied from the profile but "Automatic Deinterlacing" is not set on the "Advanced Config" tab.

It seems this one is not propagating.

[berrinam]

@Morte66: This bug is fixed in the newest CVS update (0.2.3.2037). I'm pleased at the interest in the One Click Encoder that my guide seems to have brought (enough to actually find the bugs ;)).

[Tima]

That's right.. that's because the calculator doesn't support Vorbis.. it's almost impossible to accurately calculate it (you can find some details in a thread in the container form).
Hmm.. ок, but 'vorbis' is present in Type dropdown.. ;)

Well.. it's a question of your approach, isn't it? If you have your input already configured, lenght and FPS will be set correctly so there's no need to change the FPS dropdown, is there?
Agreed. Waiting for a fix for getting framerate from new DGIndex project correctly. :)

I think it's more likely that this person would enter the movie's length rather than the number of frames, then select the FPS, which in turn calculates the proper number of frames.

Maybe, but it may happen that he'll not get the correct number of frames, because he can set time with precision only to 1 second. ;)


Another issue with calculator - Ctrl-C doesn't copy the selection in some boxes (e.g. frame count) -- I have to copy it by right-click and it's not convenient..