Log in

View Full Version : MeGUI Bug-Report Thread


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 [16] 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

cc979
23rd March 2006, 20:37
i rechecked it does show a fatal error tho

Doom9
23rd March 2006, 21:01
well.. that's because the error goes unchecked.. no error is supposed to happen at this stage. But in this case, it's you the user that's causing this error. And everything uncatched shows up as fatal.. whether or not it really is can only be found out by going on about your things and see what happens.

cc979
23rd March 2006, 21:15
cheers, (was a quick response btw)

found this error:
using noise filter --heavy noise - script preset error: movie, animeHQ

from avs script creator:
Convolution3D("movielq") # Heavy Noise

cc979
23rd March 2006, 22:25
my mistake sorry, was using wrong .dll
found out after i changed the line 37: of ScriptServer.cs into
[EnumTitle("Heavy Noise", @"Convolution3d (preset=""movieLQ"")")]

cc979
24th March 2006, 16:31
using 0.2.3.2117 on avs script creator found that, if you open a .d2v then hit preview before autocrop you get a fatal error

ChronoCross
24th March 2006, 16:49
using 0.2.3.2117 on avs script creator found that, if you open a .d2v then hit preview before autocrop you get a fatal error

Doesn't happen on my end. You seem to be having alot of fatal errors..........

cc979
24th March 2006, 21:57
Doesn't happen on my end. You seem to be having alot of fatal errors..........

might be time to re-install windows, then try some more

this is error i get, if you hit preview first then autocrop straight after loading .d2v
http://i1.tinypic.com/s4syg3.png

bond
25th March 2006, 11:54
ok i now have heard from three different people about "mp4 muxing problems" when encoding audio and video in megui

it has turned out that the audio.mp4 they get is defacto no .mp4 file but a .mp3 file with the wrong extension

in the next step it turned out that the people are indeed setting in megui to encode with aac but megui doesnt tell besweet to encode with aac and therefore it encodes with mp3 (but still gives the output file the wrong extension)

as seeable in the besweet log here:
http://forum.gleitz.info/showpost.php?p=260799&postcount=28
(the aac options are placed into the -azid options)

therefore it seems as megui has a bug wrongly generating besweet commandlines

bob0r
25th March 2006, 13:35
http://files.x264.nl/megui-0.2.3.2117-changelog-layout-bug.jpg

Changelog Layout not as it should be i think.

(Was ok in 2116)

dimzon
25th March 2006, 14:34
http://files.x264.nl/megui-0.2.3.2117-changelog-layout-bug.jpg

Changelog Layout not as it should be i think.

(Was ok in 2116)
Seems like wrong line ends in changelog.tx (MUST be windows-style - \0x0D\0x0A)

Doom9
25th March 2006, 17:20
reproducability bond, you of all people should know better. What nobody bothered to post is that this commandline comes out if you configure megui as follows:
encode via besweet
source is multichannel unchecked

Why megui creates an mp3 is beyond me, why things even work as well since the commandline is crap.
The error has been there introduced in version 1.20 of CommandlineGenerator.cs - so that means it's been around since January 23rd.. it came with the introduction of AviSynth audio encoding. What is missing in the code is handling for
nas.SourceIsMultichannel == false
we still need the -c normal flag for azid, close the azid braket, and start the -bsn options.

Kurtnoise
25th March 2006, 17:54
Some hint about that : if bsn.dll is missing (or libvorbis.dll concerning vorbis or bad/broken additional cmd line), BeSweet transcodes files into mp3.

cc979
26th March 2006, 19:09
@bob0r
my change log screen is ok, what did you use get the cvs

ChronoCross
27th March 2006, 04:04
I thought I'd ask about this since it hasn't happen before


Log for job job1

Channels=2, BitsPerSample=16, SampleRate=48000Hz
D:\My Downloads\Encoding Tools\MeGUI\audio\neroraw.exe -o "D:\OFFICE_SPACE\VIDEO_TS\Office T01 2_0ch 192Kbps DELAY 29ms.mp4" -rr 48000 -rb 16 -rc 2 -cbr 128 -codecquality_high -aacprofile_lc Error:
System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
at MeGUI.AviSynthClip.dimzon_avs_destroy(IntPtr& avs)
at MeGUI.AviSynthClip.cleanup(Boolean disposing)
at MeGUI.AviSynthClip.System.IDisposable.Dispose()
at MeGUI.AviSynthAudioEncoder.encode()


it seriously writes all the data until it gets to the finalization...then it just errors out. I know I have no memory errors as I did the whol memtest thing after this first occured. plus I'm not having any problems with my other encoding apps. any suggestions?

I'd like to add that the encode was successful with besweet....

Edit 2: I reinstalled avisynth and that fixed the problem. seriously how does avisynth always manage to break out of nowhere.

dimzon
27th March 2006, 07:16
I thought I'd ask about this since it hasn't happen before


Log for job job1

Channels=2, BitsPerSample=16, SampleRate=48000Hz
D:\My Downloads\Encoding Tools\MeGUI\audio\neroraw.exe -o "D:\OFFICE_SPACE\VIDEO_TS\Office T01 2_0ch 192Kbps DELAY 29ms.mp4" -rr 48000 -rb 16 -rc 2 -cbr 128 -codecquality_high -aacprofile_lc Error:
System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
at MeGUI.AviSynthClip.dimzon_avs_destroy(IntPtr& avs)
at MeGUI.AviSynthClip.cleanup(Boolean disposing)
at MeGUI.AviSynthClip.System.IDisposable.Dispose()
at MeGUI.AviSynthAudioEncoder.encode()


this problem is caused by some AviSynth plugin. If, sometimes, you will get this error again you must remove all plugins then add them by one per once in order to find problematic plugin and report about it.

Explanation: this is some side-effect running AviSynth under .NET. .NET Runtime has very strong memory control/protection. So this error (access to non-owned memory block) still exists when you runnung it without .NET but is not detected.

ChronoCross
27th March 2006, 16:00
I'll try finding the broken plugin later. I had indeed added some plugins to the dir yesterday but I removed them after a clean install of avisynth. good thing I have all my filters in a anon auto loading dir.

Kurtnoise
28th March 2006, 22:22
Sorry to ask this but is it fixed or not this kind of command line ?

Job is a mux job. Commandline:
-add "H:\Final\final.264" -add "H:\Final\test.mp4":lang=eng -new "H:\Final\hit.mp4"
successfully set up muxer
Processing ended at 8:29:49 AM
----------------------------------------------------------------------------------------------------------

coz I've received today some bugs reports about MP4Box, so I try to find the problem and I don't use meGUI personally so...

berrinam
28th March 2006, 22:32
What's wrong with it?

Kurtnoise
28th March 2006, 22:38
MP4Box don't understand this kind of cmd...must be :

...-add "H:\Final\final.264" -add "H:\Final\test.mp4:lang=eng" -new "H:\Final\hit.mp4"

cc979
29th March 2006, 18:41
just updated to 0.2.3.2118
problem with DGDecode_mpeg2source, i had to copy DGDecode.dll into avisynth_installed plugin folder, even it is the megui_avisynth_folder

everything was ok, with 0.2.3.2117

ChronoCross
29th March 2006, 20:07
just updated to 0.2.3.2118
problem with DGDecode_mpeg2source, i had to copy DGDecode.dll into avisynth_installed plugin folder, even it is the megui_avisynth_folder

everything was ok, with 0.2.3.2117

the avisynth plugins directory is the default used and that's been the behavior for some time. The megui one set in the settings dialog will be removed during doom9's refactoring and currently isn't really doing anything. maybe your megui is working correctly now =D

berrinam
29th March 2006, 20:13
just updated to 0.2.3.2118
problem with DGDecode_mpeg2source, i had to copy DGDecode.dll into avisynth_installed plugin folder, even it is the megui_avisynth_folderThey should be the same folder, because MeGUI just gets the AviSynth's location from the registry...

@Kurtnoise13: Thanks. Added to the buglist.

dimzon
29th March 2006, 20:50
They should be the same folder, because MeGUI just gets the AviSynth's location from the registry...
And writes it back to the registry when you change it

cc979
30th March 2006, 15:47
cheers all, avisynth plugin and megui plugin should be the same ... so megui plugin folder on the settings page will be removed ?

thanks all

JoeBG
31st March 2006, 07:21
Bug in the commandline of xvid_encraw
---------------------------------------

wrong parameter for avi output.
- used: -o output.avi
- correct: -avi output.avi

maybe squid will change this.

Yong
31st March 2006, 08:13
http://img83.imageshack.us/img83/8219/megui5ag.png
the "avoid b-frames in high motion scenes" option is unclickable.
im using the cvs build. ;)

Doom9
31st March 2006, 08:19
Bug in the commandline of xvid_encrawNo.. bug in your bugreport. I've told you multiple times that public megui builds do not support squid's encraw mods. Is that so hard to remember?

squid_80
31st March 2006, 11:39
wrong parameter for avi output.
- used: -o output.avi
- correct: -avi output.avi
No.. bug in your bugreport. I've told you multiple times that public megui builds do not support squid's encraw mods. Is that so hard to remember?
Not related to my build; with original encraw, using -o creates a raw m4v stream. I don't see how MeGUI would attempt to use -o to create an .avi file.

Doom9
31st March 2006, 11:44
well.. asking for avi output from a cvs encraw build is, well, not going to happen. Unless your output is raw/mp4 forget about using encraw in the current state.

squid_80
31st March 2006, 12:47
Oh, so it only knows to add the mux job for mp4? I'll make encraw's -o option more intelligent then (probably the easiest solution).

Doom9
31st March 2006, 14:15
don't worry about it.. megui is about to get a lot smarter if somebody finishes what I started and currently can't see through. If you look at the code I posted in the dev thread, I fully support the new syntax and megui is already capable of knowing when it needs what kind of mux jobs.

JoeBG
31st March 2006, 17:18
No.. bug in your bugreport. I've told you multiple times that public megui builds do not support squid's encraw mods.
:cool: The mistake would also have hapenned with a normal build and is not specially related to a build from squid


Is that so hard to remember?
Yes, I canīt remember that we have been talking about mistakes that could happen with normal builds. :D

cmw
4th April 2006, 17:06
I don't know if it has already been reportet (though it's in the newest release, 2118 (it was in earlier releases aswell).

If I got an input file with a DELAY Tag (like a ripped AC3 Stream) and want to rename it for me to be easily recognizeable (when using multiple languages), and the file ends with e.g. DELAY 200ms eng.ac3, MeGUI will bring up an error when loading the file, saying something like "invalid lenght" or sth.

However renaming to eng DELAY 200ms.ac3 does work without error.

+The Changelog got messed up in 2118 ;)

ChronoCross
4th April 2006, 18:08
@cmw
It's not a bug. It's just that meGUI is looking for the file format specified by DGIndex. it expects nothing after the delay. which is why it works in the second example

shon3i
5th April 2006, 14:16
It is not a strange bug but when calculate bitrate for MKV i always get undersize. I always use 695MB for final file and always get 691 or 692MB in final file. Comparing to Gordian Knot which have right calculation the bitrate is different about 5-6 bits

greggerm
7th April 2006, 19:02
Folks,

I've done some searches and have come up nuts for this problem, so I will pose the problem I am having out here to see if I am either totally missing something, or if there is a hiccup.

MeGUI 0.2.3.2118
x264 v485
AVISynth 2.5.6 (w/plugins recommended in the MeGUI Guide)
NAAC encoding (w/neroraw and the req'd Nero dll's in place)

I enqueued about a dozen jobs using the one-click encoder, set up with my video and audio profiles. Each job was set to disregard file size, and use the profile's bitrate.

One-click performed the DGIndex process and created the .AVS files against all my queued movies first. It then returned to the first movie and processed in it's "4" steps in the queue - (Audio, Video Pass 1, Video Pass 2, Mux). I then have a ready-to-go encode of the first movie. (yay!)

Immediately following the mux, MeGUI simply stops, and closes completely. The remaining jobs for the remaining movies are not processed, and I am left with nothing running on the desktop or in the task manager. The computer does not attempt to power itself down. (MeGUI was up on the screen and the active window at the time)

It may be worth noting that NONE of the "Shutdown on completion" checkboxes are activated.

If I look in the log directory for megui, it is *empty* - barren - desolate. Not a single file in it. Sadly, I wanted to post the logs from the encoding process, but they simply don't exist. I am operating on the computer as a local administrator.

Also, if I look in the queue directory, there are no job entries anywhere.
Understandably, when I relaunch MeGUI, all the sub-jobs for audio, video, and muxing that were there before are gone.

The second movie which was to encode has an AVS file, and that AVS file plays back nicely through WMP.

This behavior exibits itself both on my home computer, as well as on my work computer... so either I'm doing something horribly wrong, or the program may be a little broken.

Insights?
Thanks!

-Greg Germ

Edits:
* I am grabbing MS VSE C# now to try out Berrinam's test below.
* The problem did NOT appear when I tried to encode a single chapter (ripped via IFO mode) from a movie this afternoon. The short 10 minute encodes flowed from one job to the next as one would expect them to. Will try full encodes tonight with the C# debugger going.

berrinam
7th April 2006, 22:51
So it's a silent, fatal crash. That sort of thing is very hard to reproduce without all of your files. If you're willing to, you could try to help with finding the bug:

Get Visual Studio Express (C#) from
http://msdn.microsoft.com/vstudio/express/visualcsharp/default.aspx

It's free.

Once you have set it up, get the latest sources for MeGUI from Sharktooth's source repository: http://files.x264.nl/?dir=./Sharktooth/megui/Sources

Then, open the MeGUI.csproj file in Visual Studio, and press Run (F5). You will then have a copy of MeGUI which should display the error and line when it crashes. So just do the same thing there, and see if it tells you which line the error is on.

greggerm
8th April 2006, 00:26
I had to set up the application again (profiles, paths, etc), but I am running through debug now.

DGIndexing movie No. 1... will be a bit before it gets done encoding, perhaps I won't see it until tomorrow...

At this early stage before any crashes, should I see anything in the VSE windows? (THey're all empty/dark grey)


UPDATING my problem:
I ran into a different error when running it through debug that had to do with AVISynth, well before the crash/close I was observing. Apparently somewhere along the lines, the .dll "ColorMatrix" was needed in my AVS Plugins dir. I found a copy and installed it. (It didn't ask for it or provide warning that it was missing until I used v.2119)

I then ran MeGUI without any debugging (normally) and queued up two movies. When I woke up this morning, MeGUI was still on the desktop, and I had two encoded movies!

I doubt the error I was seeing was due to the number of movies queued, because at home I had three movies queued up when it closed, and at work I had nearly two dozen.

Perhaps there was somethine else amiss?

Either way, it would appear that I am functioning with One Click as designed. Should it crop up again, I'll be certain to provide more info...

Thanks for the help, Berrinam!
-Greg

berrinam
8th April 2006, 01:30
No, not if you haven't opened any of the files. It should open the problem file when it gets to the error, though

shon3i
8th April 2006, 13:40
@berrinam what about This (http://forum.doom9.org/showthread.php?p=809588#post809588)

berrinam
8th April 2006, 13:48
I'll add it to the list. It's not a particularly serious bug, is it, though? Granted, it's wrong, but (a) undersizes are better than oversizes, (b) there's always going to be some guesswork involved anyway, due to the nature of the overheads, as they depend on what type of frame is used, which isn't known beforehand.

shon3i
8th April 2006, 14:12
undersizes are better than oversizesTrue, true, Thanks

Doom9
8th April 2006, 16:05
if you can improve on the formula for mkv overhead, we'd all be grateful. MKV calculations involve a lot of guesswork since the overhead is only known after the video has been encoded.. and on top of that it depends on the distribution of frame types (I/P/B). So my calculations calculate a ratio of I/P/B based on whether b-frames are used or not (and how many? I don't recall). And then there's also some guesswork for the audio but that should be more precise (not taking into account vorbis audio.. that's the worst kind of guessing you'll ever have to do unless you are capable of reading vorbis streams to get its properties).

berrinam
8th April 2006, 23:23
UPDATING my problem:
I ran into a different error when running it through debug that had to do with AVISynth, well before the crash/close I was observing. Apparently somewhere along the lines, the .dll "ColorMatrix" was needed in my AVS Plugins dir. I found a copy and installed it. (It didn't ask for it or provide warning that it was missing until I used v.2119)Yep. There was something missing in the changelog which I just remembered -- ColorMatrix was enabled by default since 2119. That would explain your Avisynth problem. So I think your other error is unrelated and yet to be found. Thanks for your testing, though

chipzoller
9th April 2006, 21:55
@ berrinam

I got it to reproduce, but no line was specified.

If you change the settings to:

both audio tracks default: english
check 'delete completed jobs'
(in addition to the defaults it sets on its own)

it will exit silently

maybe this isn't a "crash"?


EDIT: Yep, it's the "delete completed jobs" that's doing it. That isn't supposed to close the program, is it? It doesn't look like it depends on the status of the queued items. As soon as the queues are completed, successful or not, the app. will exit.

shon3i
10th April 2006, 12:13
if you can improve on the formula for mkv overhead, we'd all be gratefulI can't but GK developer team can becouse when i calculate bitrate in GK everything is fine

SCIF
11th April 2006, 13:21
I changed priority in jobN-N.xml manualy to "Normal" and while it start to encode priority was a "Low".
If enqueue job with default "normal" than all right.
One bug else - while my computer is idle(only megui encode in x264) i had a 10 fps, while i change a priority to "Normal" it(fps) growth to 10.5(or 10.7). x264 use "idle" system priority at "low" in megui and it's reason not effective use cpu time. May be "low" in megui need change to "below normal"?
Sorry for my english.

Doom9
11th April 2006, 17:08
I didn never intend to match all priority classes.. 3 are way more than enough.. I even think this shouldn't be selectable because idle is the way to go. Anything else, if you get lower encoding speed you have too much crap running on your PC. On my machine, process priority has a negligible effect on encoding speed if I don't touch the machine (and if I touch it, I absolutely must have idle as I want to use the PC.. not fall asleep in front of it)

Jobs are started at the priority you have in the settings.. you can change a job's priority (that's a dynamic and not stored property) during encoding, but that only applies to the current encoder process.. when the next job is started, it defaults to priority set in the settings again. This is exactly how other popular programs do it, for instance... drumroll please... Virtualdub. Offering two ways to do the same thing will confuse people, hence that priority selector in the status window will always only influence the process that's currently active.

SCIF
11th April 2006, 18:45
Jobs are started at the priority you have in the settings.
What's for <PRIORITY> tag in jobN-N.xml??

chipzoller
11th April 2006, 23:32
Berrinam: Anything on the bug I found? Or is this behavior intentional?