View Full Version : MeGUI Bug-Report Thread
Pages :
[
1]
2
3
4
5
6
7
8
berrinam
5th January 2006, 11:40
This thread is intended to be a place for everyone to post their MeGUI-related bug reports, and is also intended to be a list of known bugs, so that the some bugs are not repeatedly reported. Naturally, as MeGUI is high-quality software, written by many skilled developers, this thread should not see much activity :sly:
Before posting here, please read the bug-reporting guidelines.
Guidelines
Follow these steps, and the process of finding and fixing the bug will become much speedier. Don't follow them, and you won't find much help here.
Check the known bugs list (below) to see if your bug has already been reported. No point in filling up this thread if we already know about the bug
POST YOUR LOGFILE. MeGUI writes lots of valuable information in the logfile. Try reading the log yourself, and see if you find the error, or any outrageous values (ones which are clearly wrong). If you can solve it based on that, good for you. Otherwise, it may help someone else solving your problem.
Describe the simplest way to reproduce your problem. Imagine the people reading your instructions are idiots, so you have to tell them exactly what to do, in a fool-proof way.
No-one is going to spend 2 days running 10 encodes, on the off-chance that at the end of them, they might crash. Work out how to cause your problem to happen again, and then it is much easier for the problem to be solved.
If it is an obscure bug that happens only once in a while, and you can't work out when, try debugging it yourself:
Get Visual Studio Express (C#) from http://msdn.microsoft.com/vstudio/ex...p/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 run all your jobs in that, and see if it tells you which line the error is on.
Too much information is better than too little. Don't make the developers pry the information out of you, as it is too much work for them, and they will just ignore you.
If encoding/muxing doesn't start at all check your sources (e.g. open AviSynth script in a media player and VirtualDub, play the soundtrack in a media player, try playing the files to be muxed, etc.)
Use a build from the latest series of MeGUI releases (at the moment, 0.2.3.2137 or later). Only bugs in this series will be documented, as all known bugs are fixed before going onto a new series.
Don't post here if the problem is clearly not caused by MeGUI. If you aren't sure about which program caused the error, then there is a simple way of being pretty sure:
If MeGUI crashed, then it is almost certainly causing the problem. If MeGUI stays active, but flags the job as an error, then look at the commandline in the MeGUI log. If there are any outrageous values in the commandline (especially negative/very low/very high bitrates), then the commandline MeGUI generated had a problem, and so it is MeGUI's fault. In almost any other situation, it is the fault of an external program, so it is not MeGUI's fault.
Run your job commandline manually. If your commandline is "--bitrate 700 --level 1.3 --no-cabac --subme 6 --analyse p8x8,b8x8 --qpmin 22 --me umh --threads 2 --progress --no-psnr --output "c:\videos\video.mp4", start a commandprompt (start - run - type "cmd" without the "'s, and press enter), go to the path where you have your encoder (e.g. "cd c:\program files\ripping software\x264\"), then type the name of your encoder (e.g. x264.exe ) and paste the commandline and press enter. Alternatively, you can install the "open commandprompt here" powertoy (http://download.microsoft.com/download/whistler/Install/2/WXP/EN-US/CmdHerePowertoySetup.exe) and then you can just right click on your encoder folder in windows explorer, and select open commandprompt, type the name of your encoder and paste the commandline and press enter to get started right away.
Known bugs in series in builds 0.2.3.2137 or later
If a job (say, a mux job) errors out and 'Delete Intermediate Files' is checked, then those files will be deleted anyway, meaning there is no output whatsoever
Description: N/A
Status: Not yet solved.
Fatal error in some cases with the preview window in the AviSynth Script Creator
Description: See http://forum.doom9.org/showthread.php?p=795502#post795502
Status: Not yet solved
Queue sometimes does not proceed to next item, at random.
Description: See http://forum.doom9.org/showthread.php?p=798255#post798255
Status: sysKin is looking into it.
The matroska overhead calculation leads to undersized files
Description: See http://forum.doom9.org/showthread.php?p=809588#post809588
Status: Not yet solved
huffy mencoder commandlines have a -noodml which shouldn't be there
Romario
5th January 2006, 15:53
I post in file one big bug in MeGUI 0.2.3.1031, never before I havn't that problem.
Older builds works.
Doom9
5th January 2006, 18:02
We're off to a bad start here.. first of all you didn't post all the info we request, and second you posted a bugreport in the feature request thread.. that's definitely the wrong place so I moved it.
Sharktooth
5th January 2006, 19:58
I cant see the picture coz it's not approved but i think it's the tri-state bug introduced in that relase...
Romario
5th January 2006, 20:03
Download the picture which I provided.
Sharktooth
5th January 2006, 20:04
It's still not approved.
Doom9
5th January 2006, 21:35
I've seen it a long time ago.. it's your usual "input cannot be read" error.. but no info as to what the script looks like, if it can be played in a media player and opened in virtualdub.
bob0r
5th January 2006, 23:41
not updating: lossless --qp 0 show commandline
1: -
2: -
3: When selecting lossless, Show Commandline does not update to --qp 0
4: using megui-x264-svn.exe
5: -
6: -
Edit
When selecting lossless, i guess the qp box should be greyed out too, or the value changed to 0.
And possible when you enter 0, lossless will be set active (on high profile)
/Edit
not updating: Number of Threads --threads X show commandline
1: -
2: -
3: When changing Number of Threads, Show Commandline does not update to --threads X (not showing it when changing to 2 or higher)
4: using megui-x264-svn.exe
5: -
6: -
Romario
6th January 2006, 01:38
I've seen it a long time ago.. it's your usual "input cannot be read" error.. but no info as to what the script looks like, if it can be played in a media player and opened in virtualdub.
Ok, here how I wrote my Avisynth script:
DirectShowSource("f:\test video.mpg", fps=25)
Nothing more or less, and with build 1029 it worked without any errors. So, it is very clear that we have a bussines with strange bug.
And yes, script can, without any problems, open and play in VirtualDub Mod 1.5.4.1 and media player.
ChronoCross
6th January 2006, 03:22
I remember a small error I got awhile back when messing with 1 pass TIVTC vfra nd the auto seeking that megui does in the preview pane. by trying to seek using a on demand vfr it caused a buffer overflow and the application to crash. it does the same thing when seeking in vdubmod so I'm guessing it's inherint to the filter. perhaps the file you are loading in Directshowsource is suffering from the same thing in that a non-existent frame is being loaded by the preview pane. perhaps from you giving the incorrect framerate or even from megui loading it at a random spot.
Romario it is probably best if you didn't constantly bug the devs about this issue. However what I do recommend is finding another mpg sample with similarities with the sample you are currently working with and see if it occurs with all mpg files using the current release.
godhead
6th January 2006, 06:39
Romario it is probably best if you didn't constantly bug the devs about this issue. However what I do recommend is finding another mpg sample with similarities with the sample you are currently working with and see if it occurs with all mpg files using the current release.
Actually he just responded with the information that Doom9 requested in the other thread and has moved his request to the appropriate thread. So, please don't be too hard on him :) . But, your suggestion of trying other samples is helpful.
Doom9
6th January 2006, 09:17
perhaps from you giving the incorrect framerate or even from megui loading it at a random spot. The framerate doesn't matter at the initial setup.. it could be anything and it would still work. All the preview window does is get the number of frames from the source, then jump to floor(#frames/2).
Romario's error is "unsupported colorspace YUY2".. I take it that means the input has to be YV12.. it's quite simple to test that.. add a ConverToYV12() at the end of the AviSynth script (check the AviSynth wiki to see if this command is correct just in case). If it's that.. it's definitely not a MeGUI bug but a user error. In fact, MeGUI has nothing to do at all with the fact that it worked in a previous release.. it's an error that comes directly from x264.exe.. so either something changed inside x264.exe, or you changed something at the source/playback filters that are being used via directshowsource. And then there's the thing that you should run mpg files through dgindex anyway.. DirectShowSource is probably the most dangerous source loading command AviSynth offers.. and in my own experience the most error prone.
bob0r
6th January 2006, 16:11
not updating: turbo 2pass - 1st pass and 3pass- 1st pass
1: -
2: -
3: When selecting turbo, Show Commandline does update, then when disable it does not set previous state back
Same goes for automated pass 2 and 3, not sure how it should update on that thouigh.
4: using megui-x264-svn.exe
5: -
6: -
bob0r
6th January 2006, 16:24
FourCC for x264.exe is not used, is it?
How is it used, and if its used should show commandline update?
When you click config the title says: x264 Codec Configuration, i think that should be:
1 x264 Configuration or
2 x264 Encoder Configuration, but id go for option 1 :)
bob0r
6th January 2006, 16:30
Done what? :) title or fourcc explaination? :p
Edit your previous post, then ill delete this msg, to keep this thread clean.
Sharktooth
6th January 2006, 16:30
When you click config the title says: x264 Codec Configuration, i think that should be:
1 x264 Configuration or
2 x264 Encoder Configuration, but id go for option 1 :)
Done (option 2) for x264, snow and xvid.
EDIT: i forgot lavc... updated now.
Also fourCC is not a x264 option so it will not be shown in x264 command line.
Sharktooth
6th January 2006, 16:55
not updating: turbo 2pass - 1st pass and 3pass- 1st pass
1: -
2: -
3: When selecting turbo, Show Commandline does update, then when disable it does not set previous state back
Same goes for automated pass 2 and 3, not sure how it should update on that thouigh.
4: using megui-x264-svn.exe
5: -
6: -
This is not a bug. Those settings are set to accelerate the first pass when clicking turbo. MeGUI does not remember what happens when one option excludes other ones so you have to manually set them back to what are your preferred values in the second (or third) pass.
Doom9
6th January 2006, 17:28
This is not a bug.umm.. isn't that a case tri-state should also handle, not only levels and avc profiles? turbo shouldn't change anything in the GUI, just in the commandline.
Sharktooth
6th January 2006, 17:41
tri-state is a delicate thing. i made some changes to some conditions to restore the default values when a higher level or some options that enables a group are selected and when clicking on Config, MeGUI crashes without any message and wont let me debug too...
i will revert those changes back btw...
Romario
6th January 2006, 18:15
Romario's error is "unsupported colorspace YUY2".. I take it that means the input has to be YV12.. it's quite simple to test that.. add a ConverToYV12() at the end of the AviSynth script (check the AviSynth wiki to see if this command is correct just in case). If it's that.. it's definitely not a MeGUI bug but a user error. In fact, MeGUI has nothing to do at all with the fact that it worked in a previous release.. it's an error that comes directly from x264.exe.. so either something changed inside x264.exe, or you changed something at the source/playback filters that are being used via directshowsource. And then there's the thing that you should run mpg files through dgindex anyway.. DirectShowSource is probably the most dangerous source loading command AviSynth offers.. and in my own experience the most error prone.
Thank you for explanation, but could you provide me exact way to convert YUY2 to YV12 output, because I am so new in AviSynth scripts.:o
Doom9, why DirectShowSource is " probably the most dangerous source loading command AviSynth offers ", can you tell me?:scared:
I can tell you that that MPG file worked fine with 0.2.3.1029 build, and I don't change anything in that MPG source file, everything is same as earlier.
It seems that something is changed in x264.exe.
Sharktooth
6th January 2006, 18:28
as doom9 said add ConverToYV12() at the end of your avisynth script.
Richard Berg
6th January 2006, 18:38
The command is ConvertToYV12(). If the source is interlaced, be sure to use ConvertToYV12(interlaced=true)
Romario
6th January 2006, 18:41
Ok, I will try with that.
charleski
6th January 2006, 20:26
Another bug:
MP3 audio output is disrupted: If you select MP3 as an output format in the main form and then go to configure it, on returning the format is reset to NAAC mp4.
I'll fix this.
[Fixed in 0.2.3.1037 - turns out it was an issue with rogue profiles with empty names]
charleski
6th January 2006, 20:32
DirectShowSource is " probably the most dangerous source loading command AviSynth offers ", can you tell me?:scared:
DirectShowSource is easily the flakiest part of Avisynth, and the bit I wish the Avisynth developers would work on. In many cases it just doesn't work and returns 'the filter graph manager won't talk to me' errors even though DirectShow is quite capable of rendering the file (this even happens if you feed it a filtergraph previously rendered by graphedit...).
If you have an avi file, then Avisource(<filename>) is probably a more robust method of loading it into Avisynth.
Romario
7th January 2006, 02:22
No, I don't have an avi file, only MPEG2 files.
Can I use Avisource instead DirectShowSource, for mpg files?
berrinam
7th January 2006, 02:39
For mpg files, use index them with DGIndex first, and then use mpeg2source. MeGUI will do this automatically for you. Go to Tools->D2V Creator, select your input file, and check the other settings, check 'On completion load files', then press queue. Run the job from the main window. You can now configure your file properly.
Sharktooth
7th January 2006, 16:23
In x264 config, setting the turbo option in a first pass mode changes GUI options (macroblock options) which it shouldn't
Description : Checking turbo will get rid of all macroblock options (correct), but unchecking it will leave it that way (incorrect). Also, the P4x4 option is diasbled after unchecking turbo.
Status : Fixed in 1040
bob0r
7th January 2006, 16:37
Will this update show commandline also?
(And dont worry, files.x264.nl is being fixed with some updates and have stuff load @ startup, last uptime 300+ days, now power outage also :p)
Sharktooth
7th January 2006, 22:30
What you mean?
jmk
8th January 2006, 02:45
i hve a problem with the autocrop feature in the avisynth script generator dialog. somehow it can not find the right crop values for "2001: a space odyssey". how does it work anyhow?
and another thing thats odd: i recently started using the "SAR" feature. what i do is that i select "auto-detect" aspect ratio on one click mode (since i have some odd ones here, "2001..." for example seems to have the actual ar of 2,15:1). so far everything seems fine. if i check the final muxed files with mp4box -info i can see the that the video track has an aspect ration set. but somehow these values are to large for mplayer or vlc for example:
Track # 1 Info - TrackID 1 - TimeScale 25 - Duration 01:22:16.560
Media Info: Language "und" - Type "vide" - Sub Type "avc1" - 123412 samples
MPEG-4 Config: Visual Stream - ObjectTypeIndication 0x21
AVC/H264 Video - Visual Size 640 x 384 - Profile Unknown @ Level 5.1
Pixel Aspect Ratio 640:1067 - Indicated track size 640 x 384
Self-synchronized
thx for this grat program,
jmk
ps: can anyone explain, or point me in the right direction, how i can change the aspect ratio in these files? and why does it say 640:1067 and not something like 2,35:1 ???
berrinam
8th January 2006, 03:06
@jmk: You haven't given enough information. Read the guidelines in the first post of this thread.
Just clearing up a few other things:
-auto-detect in oneclick is actually supposed to read Auto-Detect Later, but the end of it is chopped off. You see, there are two stages at which the Aspect Ratio can be found out: immediately, when you load the file, or later, after you've pressed Go, and it's done some processing. Now, normally, it will detect the Aspect Ratio immediately upon loading the file, and set it to the correct value (ie 16:9, 4:3, 1:1), but if something goes wrong, then it will default to Auto-Detect Later. If you think it is detecting it wrong, then it is probably set wrong on the DVD. In that case, what you want to use is the 'Custom' option, so that you can enter 2.35 yourself. If you are sure that it is correct on the DVD, then post a MeGUI bug report with everything asked for on the first post of this thread.
-You don't seem to be aware of the difference between Pixel Aspect Ratio (PAR) and Aspect Ratio, or Display Aspect Ratio. There are links about it Q17 of the x264 FAQ on the x264 win32 daily builds sticky.
Doom9
8th January 2006, 03:12
and as far as autocrop goes.. you know we need a vob sample to reproduce that ;) but I'm not ruling out the code works for everything.. for instance your black bars could be less than black (for instance if you pick the wrong color range in dgindex), or if you have a lot of black scenes, the algorithm can't tell between what's black bars and what's part of the movie..
nurbs
8th January 2006, 09:34
Since I haven't used autocrop lately I don't know if this is still an issue, but I noticed that on pictures that it should not crop at all it always crops 2 pixels form the right. I'm sorry I couldn't check, but I just read this and I am not at the PC I use for encoding till friday.
berrinam
8th January 2006, 11:16
Cropping must be in multiples of two, and autocropping favours over-cropping by one line to under-cropping by one line, so as to ensure removal of the borders. Perhaps this is causing what you are talking about. OTOH, it could actually be a bug. I'll wait for confirmation of this.
Doom9
8th January 2006, 18:41
In the x264 config, starting from the default settings, if you uncheck chroma, the commandline doesn't update. The same goes for bime.. seems showcommandline isn't called when those two options are changed.
Sharktooth
8th January 2006, 18:49
I already fixed that... how come it's back?
It's now re-fixed... and CVS is updated
Raithmir
9th January 2006, 22:02
0.2.3.2001 - AVISynth creator
Should enabling the deinterlace, noise filter, and colour correction tick boxes load the appropriate dll in the script for you? It doesn't for me, hence I just get a black narrow band when previewing the script. Using the load dll bit on the edit tab I would expect to just add the relevant load line to the existing script, but it deletes everything else.
MPEG2 deblocking checkbox does nothing?
ticking IVTC checkbox, then ticking the deinterlace box should remove the IVTC settings and add the selected deinterlace option, but it keeps the IVTC settings.
When does the AVI options section get enabled? or is that a future feature?
Raithmir
9th January 2006, 22:08
Loading the MeGUI snow version complains about the video profiles on startup ("is this a valid profile?" etc.).
berrinam
9th January 2006, 22:44
Should enabling the deinterlace, noise filter, and colour correction tick boxes load the appropriate dll in the script for you?Not everyone agrees on this, but in the current mode of operation, it shouldn't. The AviSynth plugins directory is very useful, and if you put your plugins there (why wouldn't you?), you don't need the loadplugin lines.
Using the load dll bit on the edit tab I would expect to just add the relevant load line to the existing script, but it deletes everything else.Bug confirmed and added to the list
MPEG2 deblocking checkbox does nothing?Not true. It's called mpeg2 deblocking because it is only for mpeg2 sources. Have a look at the mpeg2source(...) line when you press it -- it adds 'cpu=4'.
ticking IVTC checkbox, then ticking the deinterlace box should remove the IVTC settings and add the selected deinterlace option, but it keeps the IVTC settings.Confirmed and added to the list
When does the AVI options section get enabled? or is that a future feature?When you load an AVI file.
Loading the MeGUI snow version complains about the video profiles on startup ("is this a valid profile?" etc.).Only for non-Snow profiles. It makes sense, doesn't it? Why should MeGUI-Snow be able to load x264/xvid/lavc profiles? If you want that functionality, use the full version.
Raithmir
9th January 2006, 22:56
Not everyone agrees on this, but in the current mode of operation, it shouldn't. The AviSynth plugins directory is very useful, and if you put your plugins there (why wouldn't you?), you don't need the loadplugin lines.
So you're saying if I've got the plugins directory configured then the encode should work fine... but that preview won't work?
Only for non-Snow profiles. It makes sense, doesn't it? Why should MeGUI-Snow be able to load x264/xvid/lavc profiles? If you want that functionality, use the full version.
True. I just stick the three exe's in the same folder. Perhaps an additional tag could be added to the profile xml files to state whether the profile is for x264 or snow etc., then the x264 ones could just be ignored if you chose to run the snow only exe. I appreciate in typical usage you'd probably only use one of the exe's exclusively, so I supose it's a minor thing.
Raithmir
9th January 2006, 23:06
Actually, I've figured out why I was just getting a black band. My plugins path in the registry (HKLM\SOFTWARE\AviSynth\) was pointing to an old location. Corrected that and it now works.
Doom9
9th January 2006, 23:19
erhaps an additional tag could be added to the profile xml files to state whether the profile is for x264 or snow etc.If you look at the profiles, it's already there, however I see no point in opening each profile manually first and check what type of VideoCodecSettings it includes, then based on that decide if I really want to load it or not. I think it's kinda obvious that the snow edition can only handle snow profiles and that the x264 edition can only handle x264 profiles.. it's like if you try to play a video for which you don't have the proper codec installed.. it just won't work.
godhead
10th January 2006, 00:13
If you look at the profiles, it's already there, however I see no point in opening each profile manually first and check what type of VideoCodecSettings it includes, then based on that decide if I really want to load it or not. I think it's kinda obvious that the snow edition can only handle snow profiles and that the x264 edition can only handle x264 profiles.. it's like if you try to play a video for which you don't have the proper codec installed.. it just won't work.
What if the profiles were just placed under the appropriate subdirectories so we could load off those and if they fail, fall back to the root directory? Or do you not think it's worth it?
The Link
10th January 2006, 00:19
If you look at the profiles, it's already there, however I see no point in opening each profile manually first and check what type of VideoCodecSettings it includes, then based on that decide if I really want to load it or not. I think it's kinda obvious that the snow edition can only handle snow profiles and that the x264 edition can only handle x264 profiles.. it's like if you try to play a video for which you don't have the proper codec installed.. it just won't work.
Perhaps I don't understand the issue completely but what about making the "Video Profile" dropdown menu dependent on the state of the "Codec" dropdown menu. Hmm ... perhaps this is more a feature request (wrong thread?).
Doom9
10th January 2006, 08:26
but what about making the "Video Profile" dropdown menu dependent on the state of the "Codec" dropdown menu.Personally I name my profiles with the codec name.. I rather not have to select the codec first just so that I can then select a profile.. that kinda seems redundant seeing that profiles already contain which codecs they are meant for.
And yes, that would be a feature request, though the above is my answer to it.
The Link
10th January 2006, 09:28
Personally I name my profiles with the codec name.. I rather not have to select the codec first just so that I can then select a profile.. that kinda seems redundant seeing that profiles already contain which codecs they are meant for.
And yes, that would be a feature request, though the above is my answer to it.
Since it's just a minor thing in the end I can live with that. But it quite much confused me that the codec dropdown menu depends on the profile dropdown but not the other way round. So you can change the codec settings of a different codec than the visible (but unrelated) codec profile indicates.
digidragon
10th January 2006, 09:39
When aborting an encoding, MeGUI shuts down. I don't have the 'Shutdown at end of coding' checkbox checked.
(version 0.2.3.2)
Doom9
10th January 2006, 13:24
@digidragon: what about the corresponding checkbox in the settings?
digidragon
10th January 2006, 15:45
The 'Shutdown at end of coding' checkbox in the settings dialog is also unchecked.
Doom9
10th January 2006, 17:15
alright, then please share the easiest possible procedure from starting a virgin megui to reproduce this problem (I won't be looking into it... I have my own little subproject to worry about right now but the person that will look at it will appreciate that info).
digidragon
10th January 2006, 20:17
Well, I don't think this will help much, but anyway...
I used the d2v creator and avs creator to create an avisynth script:
LoadPlugin("C:\Program Files\GordianKnot\DGMPGDec\dgdecode.dll")
mpeg2source("C:\FS\fs50.d2v")
LeakKernelDeInt(order=1,sharp=true)
crop(2,0,-4,-2)
LanczosResize(640,512)
I then loaded the avs script, left the setting on 1P-Goodquality, hit Queue, then hit start on the Queue tab. I left it encoding for 30 seconds or so, then hit Abort. I was asked to confirm if I wanted to abort, and as soon as I clicked Yes, MeGUI closed. No log was created. Also, MeGUI is not running in task manager, so it's not just "hidden".
If I leave the encoding run, it completes successfully.
Using version 0.2.3.2001 of MeGUI.
Doom9
10th January 2006, 20:28
left the setting on 1P-Goodquality,I don't have any idea what that is.. Which means the report doesn't fullfill the criteria of being reproducable by dummies ;) And I don't wanna hear anything about d2v creator, avs creator and the like.. it needs be "I started MeGUI, selected this avs script", set codec to X, did that and that, etc.
Sharktooth
10th January 2006, 20:42
He's using one of my x264 video profiles.
digidragon
10th January 2006, 20:43
It's the '1P-Goodquality' Video Profile preset, which MeGUI defaults to when it starts.
The other settings were Codec: AVC; File Type: MP4; (no audio)
I don't know what other info to give. To recap...
I selected an avs file
The Preview window opened
I closed it
I hit Queue (video)
I switched to the Queue tab
I hit Start
I clicked the Abort button on the status window
MeGUI closed itself
Sharktooth
10th January 2006, 20:46
digidragon the MeGUI-x264 version that comes with x264 has profiles (coz i made and added them) while the standard MeGUI doesnt come with any profiles.
digidragon
10th January 2006, 20:56
So I shouldn't be using those profiles with MeGUI? And would that explain the Exception I get when trying to AutoEncode...?
System.NullReferenceException: Object reference not set to an instance of an object.
at MeGUI.CommandLineGenerator.generateMP4BoxCommandline(String mp4BoxPath, MuxSettings settings, String input, String output)
at MeGUI.JobUtil.generateMuxJob(VideoJob vjob, SubStream[] audioStreams, SubStream[] subtitleStreams, String chapterFile, MUXTYPE type, String output)
at MeGUI.VideoUtil.generateJobSeries(String videoInput, String videoOutput, String muxedOutput, VideoCodecSettings videoSettings, AudioStream[] aStreams, SubStream[] audio, SubStream[] subtitles, String chapters, Int64 desiredSize, Int32 splitSize, Double containerOverhead, MUXTYPE muxtype)
at MeGUI.AutoEncodeWindow.queueButton_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)
Sharktooth
10th January 2006, 21:19
You should use the profiles but Doom9 said to do a proper bugreport (it means post the entire x264 commandline and not just what profile you used).
digidragon
10th January 2006, 21:29
Okay, no problem.
"x264.exe" --bitrate 791 --ref 3 --bframes 3 --b-pyramid --b-rdo --bime --weightb --subme 6 --trellis 1 --analyse all --8x8dct --progress --no-psnr --output "C:\FS\fs50.mp4" "C:\FS\fs50.avs"
Sharktooth
10th January 2006, 21:49
ok... bugreport:
with .2003, .2004 and .2005 version whenever a profile is loaded in x264 config the macroblock options are wrongly set.
Can anyone look at this one? i think the problem is in level -> mb code (i modified it in .2003), but im not completely sure and have no time to check it now.
lexor
11th January 2006, 04:09
ok does megui records stuff somewhere other than the log tab? becouse after about 12 hours of first pass of HQ-Slow, it seems to have terminated with Status as "error" and log just says:
Next job job1-1 is a video job. encoder commandline:
"x264.exe" --pass 1 --bitrate 1597 --stats "sourcename.stats" --bframes 3 --b-pyramid --filter -2,-1 --subme 1 --analyse none --me dia --progress --no-psnr --output NUL "sourcename.avs"
successfully set up video encoder and callbacks for job job1-1
----------------------------------------------------------------------------------------------------------
Log for job job1-1
avis [info]: 1280x720 @ 29.97 fps (185578 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2 3DNow!
I am understandably disheartened having wasted 12 hours, and nothing but 15.2 MB of sourcename.stats.temp to show for it, not even a decent error message to tell me why it broke.
my script is:
mpeg2source("pathtosource.d2v")
LeakKernelDeint(order=1)
crop(0,0,0,-8)
LanczosResize(1280,720)
fft3dGPU(sigma=1.2, plane=4, sharpen=0.3)
I have encoded a shorter clip of that same source (using avisynth's Trim function) no problem earlier, output to mkv if that matters.
Since it did seem to run pass 1 to the end, can I start pass2 with that temp file? or is it all lost? using sharktooth's r396D package.
berrinam
11th January 2006, 05:23
So I shouldn't be using those profiles with MeGUI? And would that explain the Exception I get when trying to AutoEncode...?
System.NullReferenceException: Object reference not set to an instance of an object.
at MeGUI.CommandLineGenerator.generateMP4BoxCommandline(String mp4BoxPath, MuxSettings settings, String input, String output)
at MeGUI.JobUtil.generateMuxJob(VideoJob vjob, SubStream[] audioStreams, SubStream[] subtitleStreams, String chapterFile, MUXTYPE type, String output)
at MeGUI.VideoUtil.generateJobSeries(String videoInput, String videoOutput, String muxedOutput, VideoCodecSettings videoSettings, AudioStream[] aStreams, SubStream[] audio, SubStream[] subtitles, String chapters, Int64 desiredSize, Int32 splitSize, Double containerOverhead, MUXTYPE muxtype)
at MeGUI.AutoEncodeWindow.queueButton_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)
This has been fixed in 0.2.3.2009.
berrinam
11th January 2006, 05:32
I am understandably disheartened having wasted 12 hours, and nothing but 15.2 MB of sourcename.stats.temp to show for it, not even a decent error message to tell me why it broke.Yes, I can understand how you feel. Unfortunately, it may not be MeGUI causing the problem. Since the job is flagged as an error, it appears that x264 returned an error code, suggesting some problem external to MeGUI. As x264 normally will return an error message if it has an error, and MeGUI will always return this, I think that this error could be an AviSynth error. Try just doing a pass through this file to see if it causes any errors. You could do this with mplayer.
mplayer commandline:
mplayer -benchmark -vo null your-file.avs
Since it did seem to run pass 1 to the end, can I start pass2 with that temp file? or is it all lost? using sharktooth's r396D package.
Well, you can check if it ran to the end by looking at the file in a text editor, and seeing if the highest frame number is equal to, or close enough to, the number of frames. If not, you can also take this an estimate of where it failed, and trim the video to just that section and see if it fails again.
And finally, good bug report. Thank you. Pity there's not much information to work with.
Doom9
11th January 2006, 09:32
the new video encoders will only "swallow" status updates and the "syntax" message that comes up when a wrong commandline was used (the error will be identified as such though)... the rest will be dumped to the log.. but there are only two types of lines currently not being returned in addition to the abovementioned two.. it's quite unlikely that this is what happened in this case. It's very likely that had you encoded via commandline, the output would look just the same... x264 just exited.. if it exits properly or is being aborted, you should see a few additional lines indicating how many frames were encoded and where it was aborted. The new encoders have an additional bonus: even though the process exists, I make sure to read every last one line from stdout and stderr and put that to the log... this is another potential (though I've never seen it happen with x264.exe) case where certain messages might be lost.
Sharktooth
11th January 2006, 11:50
ok... bugreport:
with .2003, .2004 and .2005 version whenever a profile is loaded in x264 config the macroblock options are wrongly set.
Can anyone look at this one? i think the problem is in level -> mb code (i modified it in .2003), but im not completely sure and have no time to check it now.
fixed: http://forum.doom9.org/showthread.php?p=766085#post766085
lexor
11th January 2006, 14:46
i dunno if this helps at all to track the origin of the problem but the last few lines of the stats.temp are:
in:160651 out:160651 type:P q:21.00 itex:25638 ptex:30810 mv:25159 misc:1425 imb:1762 pmb:1562 smb:276;
in:160652 out:160652 type:P q:21.00 itex:25415 ptex:28250 mv:24528 misc:1711 imb
that so it stopped about 20 000 frames short and in the middle of writing down a line. I just trimmed (160200, 170000) avs played back in MPC, with obvious lag due to high rez (1080i) + deinterlace + resize.
now the weired part, I tried loading that in MeGUI, preview pops up, same HQ-Slow with same bitrate set in the calc, I add job to que, but when I start it megui just crashes immediately. I tried 1P-Maxspeed, I tried not trimming (so just use the script I quoted above), megui now just crashes immediately when I click start the new job. but as I said mpc plays avs just fine though with lag due to all the editing.
the only possibly unstable part of the script is fft3dGPU, and I tried commenting it out, doesn't help.
berrinam
11th January 2006, 21:59
@lexor: Do you get any error message when MeGUI crashes?
I'm grasping for straws because this problem seems hard to find. Would you perhaps be able to narrow down the problem and upload a sample?
Doom9
11th January 2006, 22:19
I think he needs to spend the 12 hours again but this time encode from the commandline. I cannot rule out that megui misses a line in the end but it wouldn't be the first time x264.exe crashes without giving any notice... it has happened to quite a few people..
lexor
11th January 2006, 22:47
lol doom that's the problem I can't do 12 hour encode anymore, it crashes right away now, click start, progress window pops up, boom it all closes and if I start megui again the job is not there. I do everything exactly the same way I did before. It just closes, no errors
Also I tried pasting that command line for the first pass into dos window, and it ran for a few minutes, and when I force quit (ctrl-c) it gave the following output:
avis [info]: 1280x720 @ 29.97 fps (185578 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2 3DNow!
x264 [info]: slice I:1 Avg QP:21.00 size: 173
x264 [info]: slice P:20 Avg QP:12.25 size: 13255
x264 [info]: slice B:60 Avg QP:13.98 size: 4699
x264 [info]: mb I I16..4: 100.0% 0.0% 0.0%
x264 [info]: mb P I16..4: 14.5% 0.0% 0.0% P16..4: 11.6% 0.0% 0.0% 0.0% 0
.0% skip:73.9%
x264 [info]: mb B I16..4: 0.9% 0.0% 0.0% B16..8: 36.3% 0.0% 0.0% direct:
4.9% skip:57.9%
x264 [info]: final ratefactor: 17.51
x264 [info]: kb/s:1619.8
aborted at input frame 81
encoded 81 frames, 3.94 fps, 1624.71 kb/s
so it does work in command line, just megui terminates without any output. This is done on the script above, so no trimming or anything. Weired thing is when it crashes it creates the .mkv file (empty) but no stat. Command line creates stat, but not mkv (logical since only first pass is requested of it). I'm testing all this with HQ-Slow now (but as I said above any profile does this), no editing by me.
I didn't try reinstall (or update to newest build) since I want to explore the problem before overwriting any files. I could call this a fleuk and reinstall.
/quick edit: I just tried my speed clicking skills to switch to log tab before it crashes, and I get the first part of the log the same untill the long --------------- delimeter line (it and subsequent information doesn't appera)
Doom9
11th January 2006, 23:00
I meant.. encode the whole 12 hours from the commandline.. see if this crashes as well. You wouldn't happen to be able to find your way around in Visual Studio Express, would you? You can configure it in a way that whatever causes the crash will break to the debugger.. so even if you don't know what to do, you can take a screenshot with the info.. it would really be helpful.
lexor
11th January 2006, 23:03
but megui crashes immediately, how would x264 crashing at frame 160 000 affect the beginning (on which megui not crashes in command line)?
Doom9
11th January 2006, 23:08
but megui crashes immediately, how would x264 crashing at frame 160 000 affect the beginning (on which megui not crashes in command line)?That would be for your initial problem ;) You remember reporting a crash after 12 hours, don't you?
lexor
11th January 2006, 23:48
That would be for your initial problem ;) You remember reporting a crash after 12 hours, don't you?
see that's what I don't understand, so it hit an error with that encode, but I'm not trying to continue that old job, I create a new one, and it doesn't even start the encoding. I mean I can't grasp how error which is not hit for 12 hours will terminate the process right now?
on the VS.net note, I have 2003 installed, but I warn you, debuggers hate me (prolly becouse I hate them) so unless there are instructions that leave me with no choice but to pick the correct settings, it might not go too well.
Doom9
12th January 2006, 00:38
I'm afraid you'll need Visual Studio Express (or VS 2k5). Then you go to the Exceptions menu in the Debug dropdown, and check "thrown" under common language exceptions. That way, when an unhandled exception is thrown (which is what causes MeGUI to crash), the debugger will stop and display the exception. Also, make sure you're using the latest release (you'll have to redo your jobs.. there's a new commandline generation)
kurt
12th January 2006, 01:01
compiler error?
can't start latest MeGUI 0.2.3.2012...
all 3 variants don't work (megui, megui x264, megui snow)
http://img48.imageshack.us/img48/8156/image10nq.jpg (http://imageshack.us)
(no problems with MeGUI 0.2.3.2010)
lexor
12th January 2006, 02:04
well I upgraded to the latest greatest by sharktooth, it started first pass no problem... I'll be back in 12 hours.
lexor
12th January 2006, 04:03
ok I found out what causes it to break, if someone switches user (not logout) under WinXP, now I again can't start another job. gonna reinstall again.
ShawnFumo
12th January 2006, 05:56
Just to note that 0.2.3.2012 won't start for me either. This was my first time trying a .NET 2.0 build so I was worried that was the problem, but I just tried 2010 and that started up fine.
Shawn
Gehenna
12th January 2006, 07:49
Im also having similar problems with buiild 0.2.3.2012
megui-snow.exe
megui-x264.exe
megui.exe
All fail to start with the same error `MeGUI has encountered a problem and needs to close`
I have Net 1.1 & Net 2 installed + Sharktooth latest x264 build
As already noted,if i jump back to build 0.2.3.2010 all is well.
bob0r
12th January 2006, 10:45
(Just posting what i did, not saying these warnings are a problem)
megui.exe:
compile full
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.
megui-x264.exe:
compile x264
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(97,23): warning CS0169: The private field 'MeGUI.SettingsForm.xvidEncrawLabel' is never used
SettingsForm.cs(98,24): warning CS0169: The private field 'MeGUI.SettingsForm.selectXvidEncrawButton' is never used
SettingsForm.cs(99,25): warning CS0169: The private field 'MeGUI.SettingsForm.xvidEncrawPath' is never used
SettingsForm.cs(100,26): warning CS0169: The private field 'MeGUI.SettingsForm.xvidEncoder' is never used
SettingsForm.cs(101,23): warning CS0169: The private field 'MeGUI.SettingsForm.xvidEncoderLabel' is never used
megui-snow.exe:
compile snow
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.
(compile all - works, same files, same ouput text)
megui.exe: (megui-svn.exe would be a better output, now its the same as full)
compile full-svn
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.
megui-x264-svn.exe:
compile x264-svn
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(97,23): warning CS0169: The private field 'MeGUI.SettingsForm.xvidEncrawLabel' is never used
SettingsForm.cs(98,24): warning CS0169: The private field 'MeGUI.SettingsForm.selectXvidEncrawButton' is never used
SettingsForm.cs(99,25): warning CS0169: The private field 'MeGUI.SettingsForm.xvidEncrawPath' is never used
SettingsForm.cs(100,26): warning CS0169: The private field 'MeGUI.SettingsForm.xvidEncoder' is never used
SettingsForm.cs(101,23): warning CS0169: The private field 'MeGUI.SettingsForm.xvidEncoderLabel' is never used
- All files run and work for me.
What i can think of is what other users don't have, and what may help running the files "Microsoft (R) Visual C# 2005 Compiler version 8.00.50727.42".
Maybe some .dll or extra files are required when you do not have this installed? Just a wide guess.
Did you guys install http://www.microsoft.com/downloads/details.aspx?FamilyID=0856eacb-4362-4b0d-8edd-aab15c5e04f5&DisplayLang=en (or the 64 bit version) or did .net 2.0 install via Microsoft Update?
And do you guys have this dir: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 ?
Test my compiles also: http://files.x264.nl/megui/
Doom9
12th January 2006, 10:51
@bob0r: since I compiled the files myself.. I'm very aware of the compiler warnings, but after having wasted hours with the stupid CVS, I wasn't in the mood for more compilation fixing. And you should note that the standing of conditional compilation is currently less than favorable.. I suggest you strongly consider distributing the full release in the future.
I also have no problem running bob0r's build.. but mine crashes for some weird reason.
Gehenna
12th January 2006, 10:56
Did you guys install http://www.microsoft.com/downloads/details.aspx?FamilyID=0856eacb-4362-4b0d-8edd-aab15c5e04f5&DisplayLang=en (or the 64 bit version) or did .net 2.0 install via Microsoft Update?
Yep,that was where i originally obtained my version 2.0 net install,via the dotnetfx.exe download
And do you guys have this dir:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 ?
I also have this directory.
Doom9
12th January 2006, 11:11
weird.. I have recompiled using the updated compile file and now everything works out just fine. I've re-uploaded the release.
megui.exe: (megui-svn.exe would be a better output, now its the same as full)I've changed the compile script accordingly.
bob0r
12th January 2006, 11:30
@Doom9
Yah, i will pack any version, just what is available.
Then its just best to go for one full version (none svn features i am still not for, i guess like sharktooth's own x264 builds, he can create his own megui builds.)
But just do whatever you feel is best, i will pack megui as long as its most wanted :D
Sharktooth
12th January 2006, 15:06
(Just posting what i did, not saying these warnings are a problem)
megui.exe:
compile full
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.
megui-x264.exe:
compile x264
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(97,23): warning CS0169: The private field 'MeGUI.SettingsForm.xvidEncrawLabel' is never used
SettingsForm.cs(98,24): warning CS0169: The private field 'MeGUI.SettingsForm.selectXvidEncrawButton' is never used
SettingsForm.cs(99,25): warning CS0169: The private field 'MeGUI.SettingsForm.xvidEncrawPath' is never used
SettingsForm.cs(100,26): warning CS0169: The private field 'MeGUI.SettingsForm.xvidEncoder' is never used
SettingsForm.cs(101,23): warning CS0169: The private field 'MeGUI.SettingsForm.xvidEncoderLabel' is never used
megui-snow.exe:
compile snow
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.
(compile all - works, same files, same ouput text)
megui.exe: (megui-svn.exe would be a better output, now its the same as full)
compile full-svn
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.
megui-x264-svn.exe:
compile x264-svn
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(97,23): warning CS0169: The private field 'MeGUI.SettingsForm.xvidEncrawLabel' is never used
SettingsForm.cs(98,24): warning CS0169: The private field 'MeGUI.SettingsForm.selectXvidEncrawButton' is never used
SettingsForm.cs(99,25): warning CS0169: The private field 'MeGUI.SettingsForm.xvidEncrawPath' is never used
SettingsForm.cs(100,26): warning CS0169: The private field 'MeGUI.SettingsForm.xvidEncoder' is never used
SettingsForm.cs(101,23): warning CS0169: The private field 'MeGUI.SettingsForm.xvidEncoderLabel' is never used
- All files run and work for me.
What i can think of is what other users don't have, and what may help running the files "Microsoft (R) Visual C# 2005 Compiler version 8.00.50727.42".
Maybe some .dll or extra files are required when you do not have this installed? Just a wide guess.
Did you guys install http://www.microsoft.com/downloads/details.aspx?FamilyID=0856eacb-4362-4b0d-8edd-aab15c5e04f5&DisplayLang=en (or the 64 bit version) or did .net 2.0 install via Microsoft Update?
And do you guys have this dir: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 ?
Test my compiles also: http://files.x264.nl/megui/
All warnings fixed in 0.2.3.2013
lexor
13th January 2006, 15:25
ok since the problem with my encode got narrowed down to user switching under WinXP, and I'm not the only user of this computer and user switching capability is important, I began thinking about how I did it in the past, and I'm pretty sure the older builds of megui (in sharktooth's package back with old .net framework) did work fine with user switching, I mean it would slow down to almost 0 but it would pick up when I switched back to my account.
so, yeah... what did you guys do?
Sharktooth
13th January 2006, 16:30
Bug in 0.2.3.2017 (maybe in earlier versions too):
Found in MeGUI-x264: Clicking Start in queue it says there are no "waiting" jobs (and consequently it doesn't proceed encoding) even if there are.
http://www.webalice.it/f.corriga/megui/megui_bug.png
Razorholt
13th January 2006, 18:16
Go to Settings and re-enter the links. That fixed it for me.
- Dan
charleski
13th January 2006, 20:35
becouse after about 12 hours of first pass of HQ-Slow, it seems to have terminated with Status as "error"
my script is:
mpeg2source("pathtosource.d2v")
LeakKernelDeint(order=1)
crop(0,0,0,-8)
LanczosResize(1280,720)
fft3dGPU(sigma=1.2, plane=4, sharpen=0.3)
I've experienced similar problems with fft3dgpu, which is where the problems lies, I think. It's not entirely stable and can cause the entire thread to terminate unpredictably, even though it works fine with other inputs.
lexor
13th January 2006, 21:13
I've experienced similar problems with fft3dgpu, which is where the problems lies, I think. It's not entirely stable and can cause the entire thread to terminate unpredictably, even though it works fine with other inputs.
nah, read my subsequent posts, it's a Switch User issue under WinXP, it's reproducible, and it doesn't just crash current encode it makes megui not work at all untill you reinstall.
berrinam
13th January 2006, 21:47
Bug in 0.2.3.2017 (maybe in earlier versions too):
Found in MeGUI-x264: Clicking Start in queue it says there are no "waiting" jobs (and consequently it doesn't proceed encoding) even if there are.
http://www.webalice.it/f.corriga/megui/megui_bug.png
Added this to the list.
berrinam
13th January 2006, 22:02
Added The Link's bug to the list.
Doom9
13th January 2006, 22:07
Added this to the list.I saw that too.. the reason is the following: the encoder setup fails and the error isn't properly propagated back... startNextJobInQueue returns false both if there's nothing to do and if the encoder setup fails :/
berrinam
13th January 2006, 23:00
I saw that too.. the reason is the following: the encoder setup fails and the error isn't properly propagated back... startNextJobInQueue returns false both if there's nothing to do and if the encoder setup fails :/
Yep. I was going to fix that, but it needs some more significant changes to manage it properly, so I'll just wait.
AgentX
13th January 2006, 23:02
Unfortunatly, or as being a programmer I should say of course ;) , I found some bugs which aren't yet solved in latest MeGUI version 0.2.3.2017, so I will report them here.
General:
Video Profile list in main window gets unordered.
When you enter a profiles configuration, change the bitrate, hit [OK], then the list on the main window isn't alphabetically ordered anylonger.
AviSynth Script Editor:
Silent crash (no logfile nor dialog) when you open a .d2v video input (the preview opens correctly) and you hit [Analyse].
Wrong AVI-fps value on Spanish Windows system. Open an AVI as Video Input (the preview opens correctly) and then hit preview to launch mplayerc with generated .avs file. It fails to show the video.
Explanation: The fps value is set with "," as decimal separator, like fps=23,97.
This fails the DirectShowSource(...), it has to be fps=23.97
I mentioned that I proved that on a spanish Windows system, maybe on other non-english ones like german that could happen also.
You should make sure that the .NET string conversion uses an english locale, not the systems one.
Changing settings in Options does delete previously created lines by Load DLL.
Not possible to add own lines of code to AviSynth-Script. They are deleted each time you change some options.
Doom9
13th January 2006, 23:02
I might attack it.. as it is with the video encoder rewrite and the impending adjustments in the muxer and audio sections, we'll get a nice bool return from the encoder and a meaningful error message as string that could be displayed.. it just has to be propagated all the way back and that's the part still missing.
berrinam
13th January 2006, 23:11
Changing settings in Options does delete previously created lines by Load DLL.
Not possible to add own lines of code to AviSynth-Script. They are deleted each time you change some options.
Well, these both have obvious user-solutions: configure your settings FIRST, and then do the manual stuff. It's the same in GK.
I've added the other bugs to the list
lexor
14th January 2006, 02:01
sorry to be a nag about it, but Sharktooth, could you please upload older (.net 1.0 or 1.1 whichever was used) version of you x264 package? I can only find latest on that link in your sticky thread. I mean it's unlikely you guys set down and decided to make it not work with user switching, so I got to wondering maybe its .net2.0 that's screwing it up? I'm confident I remember the older builds working with user switching.
charleski
14th January 2006, 02:15
sorry to be a nag about it, but Sharktooth, could you please upload older (.net 1.0 or 1.1 whichever was used) version Going back to .NET 1.1 would be a lot of work right now as .NET 2.0 has a lot more functionality, so that's not going to happen.
I doubt that the problem is related to .NET 2.0, anyway. I suspect you have a couple of different problems which are augmenting each other. BTW I assume you've reproduced this with the simplest script available (just an mpeg2source input).
When you say you have to reinstall, what does that mean? (Megui doesn't use any installation.) Does the same thing happen if you pause the encode before switching the User?
lexor
14th January 2006, 03:19
Going back to .NET 1.1 would be a lot of work right now as .NET 2.0 has a lot more functionality, so that's not going to happen.
I doubt that the problem is related to .NET 2.0, anyway. I suspect you have a couple of different problems which are augmenting each other. BTW I assume you've reproduced this with the simplest script available (just an mpeg2source input).
When you say you have to reinstall, what does that mean? (Megui doesn't use any installation.) Does the same thing happen if you pause the encode before switching the User?
I'm not asking to rebuild the current source, I want to find old package of sharktooth's so I can test that. and by reinstall I mean reinstall sharktooth's package (current build)
charleski
14th January 2006, 03:55
There are older .NET 1.1 versions of megui on the SourceForge Files page
https://sourceforge.net/project/showfiles.php?group_id=156112#files.
The ones compiled for 1.1 are 0.2.3.1029a and before.
stax76
14th January 2006, 04:16
I know what's up with the native error dialog on startup because I learned it the hard way recently. If you run a .NET application and it crashes with the native error dialog while startup then you got a exception somewhere in the ctor of the startup form, simply use a try catch block and add some logic to handle the exception.
MetalPhreak
14th January 2006, 12:04
Problem can be seen in the screenshot here: http://img65.imageshack.us/img65/4308/progress0ql.jpg
The time remaining and time elapsed are both completely wrong.
This is using Sharktooths' r399 build.
berrinam
14th January 2006, 12:50
Me too. A fix will come soon. For the time being, turn off Autostart Queue.
Doom9
14th January 2006, 13:22
@lexor: you can build your own megui-x264 build.. it should be compilable under 1.1 with no changes except for the compile.bat file.. it has links to the 2.0 compiler (%windir%\Microsoft.NET\Framework\v2.0.50727\csc), replace the v2.0 directory with the name of your 1.1 directory and you should be fine. The full release however will not compile under 1.1. That way, you know you have the same code for both builds and the only thing different is the runtime.
de66ka
14th January 2006, 13:48
Since I've updated Megui from 02.3.1b to 02.3.2017 the Avisynth Generator doesn't work anymore. It gaves me the error "DGIndex reported......" (see snap1.jpg) when i load the *.d2v file into the generator. When I downgrad again to 02.3.1b all work fine.
berrinam
14th January 2006, 14:06
A fix will come soon.
Fixed
Mutant_Fruit
14th January 2006, 16:40
When using the AviSynth script creator and choosing an AVI file, a dodgy avs file is generated. The resulting file that is saved is loading up the "temp.avs" file as opposed to the actual video file selected. This means that if i make a few avs files with the generator, they'll all point to teh same temp.avs file, and if i delete the temp.avs file, none of em will work at all.
Gonna make a fix now assuming i can spot the error :p
lexor
14th January 2006, 16:41
I'm at a loss at the apathy towards this issue. I mean don't you guys share your computer with other family members? An encode that takes 12 hours for first pass and 15 hours for second, bound to conflict with your family's desire to use the mahcine. Doom I know you have win xp installed, don't you get this problem with user switching? I mean it's so easy to check, just start some job, switch users and switch back again. What's this suddent need for me to be a compiler and debugger? Someone must have old sharktooth's build lying around (sharktooth for one), I'm willing to put up time for testing an reporting, but I have neither energy nor time to pretend like I'm one of the developers.
Sharktooth
14th January 2006, 17:13
Another bug (MeGUI-x264):
http://www.webalice.it/f.corriga/megui/meguiibug2.png
Menues vanished and same problem as the previous bug.
Mutant_Fruit
14th January 2006, 17:14
@lexor: I'll try to take a look at it, but i'm really new to MeGUI, so i spend a lot of time just browsing the code trying to get a feel for it. Webpages are no bother to me, they're simple as compared to Windows applications :p
Doom9
14th January 2006, 17:51
I'm at a loss at the apathy towards this issue.Apathy? Why did I waste my time explaining to you then how you can compile on your own (without any programming knowledge whatsoever..) can create a .NET 1.1 build based on the latest build for your tests? Oh wait, you expect me to do that for you, including reinstalling .NET 1.1 which I already eliminated from my machine. Am I on the right track?
In addition, wouldn't it be reasonable that YOU would first try on another box before pointing the finger at us? While I'm very possessive of my box and would never let anybody else us it, just for you I created another user account. Then I started encoding on my primary account (an admin account), switched to the second one.. encoding kept going. Then I aborted, went to the second account (one with limited privileges), started megui there (the latest CVS checkout.. done just 10 minutes ago, built with the compile script that comes with it), then switched back to the account I'm typing this from. I see from the CPU usage that encoding is still going strong, in fact, it hardly takes a performance hit at all since I only have a few resource-friendly apps running. By the way the job I'm encoding is a standard x264 one with all the default settings, and my x264 build is revision 389 from Sharktooth. Bottom line, I can't reproduce it.. it works as it's supposed to.
Mutant_Fruit
14th January 2006, 18:14
can create a .NET 1.1 build based on the latest build
That won't work afaik. There are a good few .net 2.0 specific items in the code now, so its now impossible to compile the current source against .Net1.0 without changing the source code.
Doom9
14th January 2006, 18:30
That won't work afaik. There are a good few .net 2.0 specific items in the code now, so its now impossible to compile the current source against .Net1.0 without changing the source code.I tried and indeed.. but the thing is.. all errors come from classes that should be inside an #if directive and not be compiled anyway in the x264 mode..
However, the point is now moot because the problem seems unreproducible.. perhaps you can make the same experiment I did (MeGUI is still encoding on the secondary account and has been throughout my dinner).
lexor
14th January 2006, 19:04
Well I'll be damned, it is fft3dgpu that's incompatible with user switching, but I did test it without that filter before though, and it would still break, now it does not. I reinstalled Std package since then though. Perhaps that first time it crashed it corrupted some files while writing to them? Dunno, anyway sorry for the inconvenience.
And for the record I never asked anyone to compile anything for anyone at any point, all I wanted was old .7z or Sharktooth's, that's all.
I'll go bug fft3d dev now :)
Pasqui
14th January 2006, 21:46
Since a few versions (0.2.3.2017 if I remember correctly) I do not get the FPS displayed in the Progress Status window when encoding with x264. All the other parameters (current video frame, video data, projected filesize, time elapsed and time remaining) are correctly displayed with version 0.2.3.2022.
Mutant_Fruit
14th January 2006, 22:04
what exactly is the problem, it seems to show up fine for me.
Are you using the full version, or x264 specific version? Show a screenshot of the problem if you can.
Doom9
14th January 2006, 22:18
@Pasqui: they use a comma as decimal separator in your country, correct?
Pasqui
14th January 2006, 22:24
I'm facing the fps bug with the complete megui version on a French WinXP (where the separator between digits is a comma and not a dot).
Here is the picture:
http://img304.imageshack.us/img304/7537/statuswindow7cf.gif (http://imageshack.us)
Doom9
14th January 2006, 22:28
Do you remember the old problem where you never got a status update? This is the same.. the fps parser chokes because I forget to force the neutral locale that uses the dot as decimal separator. But I set up all line parsing to catch all errors and just return 0.. that's why you get the rest of the updates. The progress is directly calculated by MeGUI and not taken from the x264 commandline.. that's why you have that.
Pasqui
14th January 2006, 22:33
Do you remember the old problem where you never got a status update? This is the same.. the fps parser chokes because I forget to force the neutral locale that uses the dot as decimal separator. But I set up all line parsing to catch all errors and just return 0.. that's why you get the rest of the updates. The progress is directly calculated by MeGUI and not taken from the x264 commandline.. that's why you have that.
Thanks for the info. I thought it was probably due to our "evil" comma ;)
berrinam
14th January 2006, 23:16
Menues vanished and same problem as the previous bug.
Do you mean by same problem as the previous bug the 'no jobs waiting. nothing to do' error message? That hasn't been fixed yet
Pasqui
14th January 2006, 23:27
Using deinterlace detection on a 4:3 vob file, I got the following error: "unexpected value". Here is the log file:
charleski
15th January 2006, 00:42
Well I'll be damned, it is fft3dgpu that's incompatible with user switching
What did I say in my first post about this? &$%£
There are some basic tactics to adopt in diagnosing any fault, and the first is to isolate it. Remove anything that might be contributing to the problem until you have the most basic configuration possible that still fails. Obviously fft3dgpu won't survive user-switching (!!!!) - the status of the GPU is not preserved across user-states. The miracle of fft3dgpu is that it works at all, as it's running on such a wide range of different hardware while interfacing through DirectX while the host processor and bus is running flat-out. If it works, great, if it doesn't just use the original host version.
Doom9
15th January 2006, 00:51
@Pasqui: as soon as I upload my latest sources, the FPS indication will be back for those locales not using a dot as decimal separator.
Doom9
15th January 2006, 01:05
hot damn.. CVS is screwing me again.. tortoise crashes when I try to run an update and pretty much anything.. how the heck am I suppose to add my changes now?
berrinam
15th January 2006, 01:09
Which version are your sources based on?
Doom9
15th January 2006, 01:11
based on the build I last checked in.. so that's 2012. I'm not quite sure what I'm supposed to do now.. I have 28 changes files.. I managed to add the new ones, and that doesn't break anything, but I'm scared as hell to do anything else and break everything.
berrinam
15th January 2006, 01:39
Gee, 2012 is quite a long time ago...
One thing you could do, but I know you're not going to like it, is start a new folder with the latest source, and individually merge each file (assuming you have WinMerge, it's not TOO hard a job).
Alternatively, I've just generated a patch from version 2012 to 2023, so perhaps that could be applied to your version. Maybe that would be slightly less work
Doom9
15th January 2006, 01:40
@berrinam: please have a look here: http://forum.doom9.org/showthread.php?t=95863&page=63 . And do you have MSN?
Pasqui
15th January 2006, 10:05
@Pasqui: as soon as I upload my latest sources, the FPS indication will be back for those locales not using a dot as decimal separator.
Thanks Doom9, it's working fine now :D
AgentX
15th January 2006, 12:39
AviSynth script generator has a cosmetic bug:
In Mpeg Options you can read Colour Correctio.
Obviously it should be Colour Correction.
AgentX
15th January 2006, 12:42
Crash on 'Analyse' because of missing Decomb.dll. This should be caught
Description: N/A
Status: Fixed in version 0.2.3.2020
Well, I just tried it in 0.2.3.2024 and MeGUI still does crash silently.
I should copy that Decomb.dll somewhere. :rolleyes:
EDIT:
Okay, now I know what's going wrong.
It's not the decomb.dll, but it seems that AviSynth doesn't support Unicode characters in directory names.
Look, I'm using a spanish Windows system, and the 11th line in the temporary autodeinttemp-avs.avs fails:
<snip>
file="C:\Documents and Settings\AgentX\Configuración local\Temp\interlace.log"
<snip>
c = WriteFile(c, file, "a", "sep", "b")
<snip>
Being a spanish system, there's a "ó" and a several spaces in the filename.
One of these make trouble.
BTW, I'm using AviSynth 2.56 (sep 4 2005).
Temporary solution, use file="%SystemDrive%\interlace.log".
Doom9
15th January 2006, 12:56
ie. user installs it in "c:\windows" and uninstaller removes whole "c:\windows". That's not a GUI bugreport though, is it? However, it teaches people the hard way that the windows directory is not meant for software installation ;)
foxyshadis
15th January 2006, 13:14
Odd, though, sharktooth fixed that ages ago. (Someone else did the same to their system32 folder.) He must have updated the installer or something.
Doom9
15th January 2006, 13:24
btw, here are two known and already fixed (not yet in the CVS) bugs:
1) FPS indication for xvid_encraw is completely wrong in the queue
2) elapsed and projected end time can go out of whack in video encoding and muxing.
berrinam
15th January 2006, 14:02
Well, I just tried it in 0.2.3.2024 and MeGUI still does crash silently.
I should copy that Decomb.dll somewhere. :rolleyes:
Temporary solution, use file="%SystemDrive%\interlace.log".
See if you can break version 0.2.3.2026:D
I've put a lot of error catching around, because no AviSynth bug should cause MeGUI to crash.
AgentX
15th January 2006, 21:12
See if you can break version 0.2.3.2026:D
I've put a lot of error catching around, because no AviSynth bug should cause MeGUI to crash.
I would like to, but on Sourceforge there's still 0.2.3.24 :(
starkebn
16th January 2006, 06:32
In the Audio Encoding section setting a encoding profile then switching to Audio Radio button 2 will set the same profile. Changing the profile will then also change it for radio button 1.
In the MP4 muxer Audio section setting a name then switching to radio button 2 will keep the same name. Changing the name will then also change it for radio button 1.
This happens in 2.3.2024 as well.
Avish
16th January 2006, 07:58
I hope I've posted in the correct thread...;)
I'm using all the latest versions: meGUI 14th Jan Version, DGIndex 1.4.6b4, x264 13th Jan Version.
Here is the script created using AviSynth script generator :
LoadPlugin("N:\Softwares\Audio-Video-related\Video related\DVD_related\XviD_Encoding_Tools\dgmpgdec146b4\dgdecode.dll")
mpeg2source("M:\DVDs\Indiana Jones & The Last Crusade\Indi_3.d2v")
tfm(d2v="M:\DVDs\Indiana Jones & The Last Crusade\Indi_3.d2v").tdecimate()
#crop
LanczosResize(720,320)
#denoise
Here is what MeGui says after doing Deinterlacing Analysis:
Source type: Source is declared telecined.
Source is declared tff by a margin of 234 to 15.
& then it automatically chooses TIVTC option...
When i press preview...there is nothing in it...just a thin black stripe...
Then I saved the script, queued it, clicked Srart...it finished in 1-2 seconds giving me this error:
avis [error]: unsupported input format (DIB )
could not open input file 'M:\DVDs\Indiana Jones & The Last Crusade\Indi_3.avs'
desired video bitrate of this job: 1298 kbit/s - obtained video bitrate: 0 kbit/s
Here is a complete log from meGUI:
Next job job2 is a video job. encoder commandline:
--bitrate 1298 --ref 3 --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --subme 6 --trellis 1 --analyse all --8x8dct --me umh --progress --no-psnr --output "M:\DVDs\Indiana Jones & The Last Crusade\Indi_3.mkv" "M:\DVDs\Indiana Jones & The Last Crusade\Indi_3.avs"
successfully started encoding of job job2
job commandline: --bitrate 1298 --ref 3 --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --subme 6 --trellis 1 --analyse all --8x8dct --me umh --progress --no-psnr --output "M:\DVDs\Indiana Jones & The Last Crusade\Indi_3.mkv" "M:\DVDs\Indiana Jones & The Last Crusade\Indi_3.avs"
----------------------------------------------------------------------------------------------------------
Log for job job2
avis [error]: unsupported input format (DIB )
could not open input file 'M:\DVDs\Indiana Jones & The Last Crusade\Indi_3.avs'
desired video bitrate of this job: 1298 kbit/s - obtained video bitrate: 0 kbit/s
----------------------------------------------------------------------------------------------------------
I searched what is TIVTC in the forum, downloaed it & put the dll in avisynth plugin folder & also in the meGUI folder...but still the same thing...same error...
Just 2 days back I successfully encoded War of the Worlds using the meGUI ...but this time its not working... am I doing somthing wrong guys ?? pls Help me...
Doom9
16th January 2006, 08:06
When i press preview...there is nothing in it...just a thin black stripe...Open the script in a media player.. it will show you the error. It seems you forgot about point 5 in the reporting guidelines (good job otherwise):
If encoding/muxing doesn't start at all check your sources (e.g. open AviSynth script in a media player and VirtualDub, play the soundtrack in a media player, try playing the files to be muxed, etc.)
foxyshadis
16th January 2006, 09:12
Was the loss of the bitrate calc in x264 conditional intentional, or an accident? Because it's the best and I'd hate to lose it there.
berrinam
16th January 2006, 09:27
Was the loss of the bitrate calc in x264 conditional intentional, or an accident? Because it's the best and I'd hate to lose it there.
Is this due to the following bug?
MeGUI-x264 has no menus
Description: See http://forum.doom9.org/showthread.php?p=768048#post768048
Status: Not yet solved
In the Audio Encoding section setting a encoding profile then switching to Audio Radio button 2 will set the same profile. Changing the profile will then also change it for radio button 1.This is intentional.
In the MP4 muxer Audio section setting a name then switching to radio button 2 will keep the same name. Changing the name will then also change it for radio button 1.
This happens in 2.3.2024 as well.
This was fixed in 0.2.3.2026. Just wait for a new release
Avish
16th January 2006, 09:31
Open the script in a media player.. it will show you the error. It seems you forgot about point 5 in the reporting guidelines (good job otherwise):
No I didnt forgot about it...Here is the error MPC showed :
TFM: d2v file is not a d2v file or is of unsupported format!
(M:\DVDs\Indiana Jones & The Last Crusade\Indi_3.avs, line 3)
I thought that it's not mentionable enough...coz when i deleted the line 3 in script, it showed me the preview perfectly (ofcourse without deinterlacing) ;)
so the error must be in the TIVTC thing...which I cant figure out...
And yes, all the source files are playing perfectly (the soundtrack & the files to be muxed, etc)
Doom9
16th January 2006, 10:13
I thought that it's not mentionable enough...coz when i deleted the line 3 in script, it showed me the preview perfectly (ofcourse without deinterlacing)since you have the error in playback, obviously it's also the problem in encoding ;) So in turn, this is an AviSynth script problem, nothing that would relate to MeGUI or x264. I have no idea why decomb is in the script but isn't used.. or perhaps my filter knowledge is just too limited (all the scripting problems just go to show why the ideal script only contains 3 lines)
Avish
16th January 2006, 10:20
since you have the error in playback, obviously it's also the problem in encoding ;) So in turn, this is an AviSynth script problem, nothing that would relate to MeGUI or x264. I have no idea why decomb is in the script but isn't used.. or perhaps my filter knowledge is just too limited (all the scripting problems just go to show why the ideal script only contains 3 lines)
:confused: Then what should I do with this TIVTC thing which the meGUI automatically chooses after its deinterlacing analysis...whom should I ask about this ?? Pls guide me in the right direction ;)
berrinam
16th January 2006, 10:30
I implemented the source detection, and it automatically adds what you had to the script. The script generated for you seems in order, and it follows the instructions given in TIVTC's guide. This script works for me, so I'm not sure what's up. You should try making sure that (a) you made the d2v file with the latest version of DGIndex, and (b) you have the latest version of TIVTC.
If it still doesn't fix it, you can delete the d2v=whatever.d2v bit inside tfm(), but the guides recommend that parameter be set, so that's what I did.
EDIT: When I update to the most recent version of DGIndex, I get the same error as you. Time to do what I said immediately (whoops, didn't mean to stop there) above this paragraph: remove the d2v=whatever.d2v bit. I will also update MeGUI accordingly.
berrinam
16th January 2006, 10:54
Ok, I have updated the script generation. It now no longer adds the d2v=whatever.d2v bit inside tfm(). This is compatible with the newest version of DGIndex, but I'm not sure what happens with previous versions. The net result is that you should use DGIndex 1.4.6 or newer.
Obviously, the new binaries aren't up yet, but the change should be included in 0.2.3.2029, whenever it is released.
Avish
16th January 2006, 11:00
Ok, I have updated the script generation. It now no longer adds the d2v=whatever.d2v bit inside tfm(). This is compatible with the newest version of DGIndex, but I'm not sure what happens with previous versions. The net result is that you should use DGIndex 1.4.6 or newer.
Obviously, the new binaries aren't up yet, but the change should be included in 0.2.3.2029, whenever it is released.
:thanks: That was really fast... I'll try it out as u said & will report back immediately...
BTW Thanks for this great GUI...:) Its getting better & better...:)
Avish
16th January 2006, 12:57
If it still doesn't fix it, you can delete the d2v=whatever.d2v bit inside tfm(), but the guides recommend that parameter be set, so that's what I did.
EDIT: When I update to the most recent version of DGIndex, I get the same error as you. Time to do what I said immediately (whoops, didn't mean to stop there) above this paragraph: remove the d2v=whatever.d2v bit. I will also update MeGUI accordingly.
Removing the d2v bit from script worked just fine :) Thanks...
starkebn
16th January 2006, 13:51
In the Audio Encoding section setting a encoding profile then switching to Audio Radio button 2 will set the same profile. Changing the profile will then also change it for radio button 1.
This is intentional.
Why? If I want a 5.1 main track and a 2.0 directors commentary at a lower bitrate of encoding then I can't do that without preencoding the files and adding them in the muxer.
Doom9
16th January 2006, 13:53
was the audio profile bit ever changed? I thought I had initially written it so that the settings from making a profile selection would be applied only to the currently "active" audio stream. But it has been a really long while since I touched that part of the code (MeGUI is already 1 year old.. time just flies away)
starkebn
16th January 2006, 14:08
was the audio profile bit ever changed? I thought I had initially written it so that the settings from making a profile selection would be applied only to the currently "active" audio stream. But it has been a really long while since I touched that part of the code (MeGUI is already 1 year old.. time just flies away)
Well, I didn't attempt to encode as the profile name was always incorrect for one of the audio streams. I'm also pretty sure I checked the settings and they had changed as well.
berrinam
17th January 2006, 05:26
Using deinterlace detection on a 4:3 vob file, I got the following error: "unexpected value". Here is the log file:
This attachment still hasn't been approved. Can you upload it on http://rapidshare.de/ so that I can have a look at it please?
The Link
17th January 2006, 15:36
In 0.2.3.2031 I have following problems:
The Deinterlace Analyzer doesn't work anymore: "Can't open analysis log file "..." Make sure that decomb.dll is in your AviSynth plugins dir"
Decomb.dll is in my plugins directory.
Loading the prerendering job via avs script doesn't work though the avi plays fine (using ffdshow). That causes the following jobs to (silently) fail.
In the settings-->Other-->xvid encoder dropdown menu are two entries too much (double entries).
Dayvon
17th January 2006, 15:38
Hey guys! Trying your GUI for the first time. I've run into a problem trying to do a 2-pass enc job. Here's the log.
Next job job4 is a video job. encoder commandline:
--pass 2 --bitrate 1500 --stats "H:\DVD TEMP\The Island\DVD\VIDEO_TS\Island DGI.stats" --ref 2 --bframes 2 --b-pyramid --b-rdo --bime --weightb --filter -1,-1 --subme 6 --analyse p8x8,b8x8,i4x4,p4x4 --threads 2 --zones 1,186771,b=1/186772,195705,b=0.5 --progress --no-psnr --output "H:\DVD TEMP\The Island\DVD\VIDEO_TS\Island DGI.mp4" "H:\DVD TEMP\The Island\DVD\VIDEO_TS\Island DGI.avs"
successfully started encoding of job job4
job commandline: --pass 2 --bitrate 1500 --stats "H:\DVD TEMP\The Island\DVD\VIDEO_TS\Island DGI.stats" --ref 2 --bframes 2 --b-pyramid --b-rdo --bime --weightb --filter -1,-1 --subme 6 --analyse p8x8,b8x8,i4x4,p4x4 --threads 2 --zones 1,186771,b=1/186772,195705,b=0.5 --progress --no-psnr --output "H:\DVD TEMP\The Island\DVD\VIDEO_TS\Island DGI.mp4" "H:\DVD TEMP\The Island\DVD\VIDEO_TS\Island DGI.avs"
----------------------------------------------------------------------------------------------------------
Log for job job4
unknown option (
_____________________________________________________________
It says it starts but then doesn't even go. What am I doing wrong? I had set it up to do automatic 2pass, but I'm not sure what went wrong.
Doom9
17th January 2006, 15:58
@Dayvon: which x264 version are you using? I gave your commandline a try and it failed as well.. I then identified the offending option as --bime by process of elimination (calling x264 from the commandline with the commandline megui shows you, then eliminate option by option). Since bime was only added in revision 390 and my revision was older than that, it's not surprising that it didn't work.
then I downloaded the latest x264 and it worked as it should. So I'd suggest you try an up-to-date x264 version
Dayvon
17th January 2006, 16:16
Amazing... that was a fast help time. Thanks so much. Will check it out and let you know in a sec.
Edit: I'm gonna have to run 1st-pass again. Will let you know later today if this solves the issue. Thanks!!
Doom9
17th January 2006, 16:31
Edit: I'm gonna have to run 1st-pass again. Will let you know later today if this solves the issue. Thanks!!Why? bime is disabled anyway in the first pass.. so unless you change your settings there shouldn't be any need to run the first pass again.
handtruck
17th January 2006, 18:58
I just tried to use MeGui to do an dvd-xvid conversion (thought the post was more pertinent here, though), and the colors came out all wrong. The easiest way to describe it is that the earth in the universal logo is dark brown, not blue as it should be.
I don't know if it is a mencoder, megui, or xvid issue. I did a 2 pass, got the problem, and then a one pass and got the same problem. I don't think it's xvid because it still works perfectly in virtualdubmod. Also, I've done a few x264 conversions with megui and that worked fine as well.
Any suggestions?
Thanks for your help.
Doom9
17th January 2006, 21:01
Any suggestions?Which dgindex build are you using? This is a known issue with older dgindex builds..
handtruck
17th January 2006, 21:04
Which dgindex build are you using? This is a known issue with older dgindex builds..
I'm using 1.0.12, I suppose I'll update it and let you know what happens. I don't understand why the avs file looks fine in Virtualdub and Megui when I open it. I'll let you know if that fixes it.
Doom9
17th January 2006, 21:27
I don't understand why the avs file looks fine in Virtualdub and Megui when I open it.It's a colorspace issue, and the upgrade will fix it.. your release is rather old.. I recall using that and getting discolored video as well. If you search the old MeGUI threads you'll come across the same issue mentioned. And the software requirements (http://forum.doom9.org/showthread.php?t=96032) mention you need at least DGIndex 1.41. There are other things that won't work properly with older releases (like demuxing two specific audio tracks).
Dayvon
17th January 2006, 21:49
Why? bime is disabled anyway in the first pass.. so unless you change your settings there shouldn't be any need to run the first pass again.
I tried to run just the second pass, and it wouldn't do it. I think the .stats file was erased since an error was encountered (I have delete files on abort enabled). But either way, I'm in the middle of the 2nd-pass now, so things are looking good.
BTW, since I have the momentary attention of the Doom9 man himself, I just wanted to let you know that I can't really express how much your site has meant to me. Not just for DVD backups or your amazing codec comparisions (which are phenomenal), but for overall knowledge database and learning guides about video and coding, not to mention the awesome way that your site promotes our consumer rights. Just wanted you to know you got a great thing going and I will continue to support all that goes on here.
handtruck
17th January 2006, 23:04
@doom9: Thanks, the update of DGIndex did the trick.. Have to keep my software updated! Should have tried that first before coming here, but I guess that would have been too easy.
SBaT
18th January 2006, 01:37
I get an error screen when using Deinterlacing Analyse with message after progress bar has gone twice trough.
Unexpected value in file c:\filepath\ff_interlace.log
I'm using meGUI0.2.3.2024,DGIndex 1.4.6b5,TIVTCv1b7,decomb522
MeGUI shows in logfile DGIndex job successfull.
ff_interlace.log (http://www.bigupload.com/d=8D8298CD) if needed
handtruck
18th January 2006, 01:38
Thanks! I got a great encode using megui and x264.
The only problem is that is will only play in mplayer, and not MPC (I DO have ffdshow installed). Is it because I muxed it into an AVI file (using megui) with mp3 audio? Isn't mp3 acceptable in the mp4 container? (you can only use aac when muxing to mp4)
The error I get is "MPC could not render some of the pins..." and this box:
Stream 0
AVI Splitter
Media Type 0:
--------------------------
AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {10000005-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo {05589F80-C356-11CE-BF01-00AA0055595A}
bFixedSizeSamples: 0
bTemporalCompression: 1
lSampleSize: 1
cbFormat: 88
VIDEOINFOHEADER:
rcSource: (0,0)-(0,0)
rcTarget: (0,0)-(0,0)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 417083
BITMAPINFOHEADER:
biSize: 40
biWidth: 0
biHeight: 0
biPlanes: 1
biBitCount: 24
biCompression:
biSizeImage: 0
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0
Dayvon
18th January 2006, 01:47
Did you make the video in MP4 then convert it to AVI, or did you make it in AVI and convert to MP4? Whenever you make a video file with MeGUI, it either comes out MP4, AVI, or MKV, and we need to know which you made it in, and which format you're trying to play it in now to help you trouble shoot.
MP3 is allowed in MP4 container as is AAC.
handtruck
18th January 2006, 02:05
I actually initially made a raw .264 AVC file thinking that would be best, since the muxer does allow that input for avi's, but that seems to be the problem. I then simply muxed the .264 into .mp4 with no audio and THEN used that .mp4 in the MKV muxer with the mp3 file and all is well. I don't know if that is something that needs to be looked into, but .264 input with mp3 audio muxed in the megui muxer will not play in MPC.
berrinam
18th January 2006, 02:20
I get an error screen when using Deinterlacing Analyse with message after progress bar has gone twice trough.
Unexpected value in file c:\filepath\ff_interlace.log
I'm using meGUI0.2.3.2024,DGIndex 1.4.6b5,TIVTCv1b7,decomb522
MeGUI shows in logfile DGIndex job successfull.
ff_interlace.log (http://www.bigupload.com/d=8D8298CD) if needed
Aha! Got it! Let me guess: your locale specifies the comma as the decimal separator? This problem has been cropping up all over the place. I'll submit a fix soon.
berrinam
18th January 2006, 02:22
I'll submit a fix soon.Done!
Sephiros
18th January 2006, 08:12
Hello,
I have a problem with 2.3.2024: for some reason the avisynth generator wont take my .vob (even if it's supported by the filter of the dialog box) and .d2v file i load give me a DGindex reported 0 frame in this file. This is a fatal error i tried to create the d2v projet with another version of DGindex but it wont change anything.
One thing to note though, the .vob is only the second chapter of a DVD (did that for testing purposes)
I dont have time right now to rip an entire dvd and see if the problem keeps poping, but ill try.
Doom9
18th January 2006, 09:28
@Sephiros: is dgdecode.dll somewhere in your windows path or have you configured the path to dgindex in the settings? If not, that's your problem. What megui is trying to tell you is that it cannot read your d2v file, and that's normally due to a missing dgdecode, or an incompatible d2v/dgdecode.dll combo.
@handtruck: sounds like you're lacking some filters. Install haali and try again.
The Link
18th January 2006, 10:54
The Deinterlace Analyzer doesn't work anymore: "Can't open analysis log file "..." Make sure that decomb.dll is in your AviSynth plugins dir"
Decomb.dll is in my plugins directory.
fixed :)
Loading the prerendering job via avs script doesn't work though the avi plays fine (using ffdshow). That causes the following jobs to (silently) fail.
This was partly my fault because I didn't have ffvfw installed (just ffdshow) but with AviSource it still doesn't work. Changing it to DirectShowSource fixed this problem completely.
Doom9
18th January 2006, 10:59
but with AviSource it still doesn't work.Can you access the ffdshow vfw configuration (start vdub, go to the codec configuration, select ffdshow, then go to the decoder tab) and make sure huffyuv decoding is activated? By default, a lot of VfW decoding in ffdshow is deactivated.
The Link
18th January 2006, 11:04
Yes, that fixes it, thank you! Since I never used ffvfw I didn't know that the vfw decoder has to be configured separately.
dimzon
18th January 2006, 11:53
Bug @ bitrate calculator - can't handle video if duration is >= 7 hrs!
Doom9
18th January 2006, 12:43
can't handle video if duration is >= 7 hrs!Did you have a look at the source or the GUI in the GUI designer? This is by design. The maxvalue is set to 6 on the hours control. If you have a video that's longer than that.. I can live with it if you're going to use another application. But since this only happens like never, I'm not particularly concerned about that limitation. When an actual user comes along with a plausible scenario we'll see.. but before that, it makes no sense covering usecases that never happen.
dimzon
18th January 2006, 13:49
The maxvalue is set to 6 on the hours control.
Yes, I know!
If you have a video that's longer than that..
Really YES, I have 7hrs49min video! I have discovered this bug trying to encode it via meGUI.
I'm not particularly concerned about that limitation. When an actual user comes along with a plausible scenario we'll see.. but before that, it makes no sense covering usecases that never happen.
Let's just set maxvalue to int.MaxVal (why not)
Doom9
18th January 2006, 14:03
(why not)Actually, that would cause problems elsewhere in the calculator.. variables would overflow and thus crash the entire software. Imagine the length you're proposing, and a 20 mbit/s bitrate.. a high audio bitrate..
What the heck is your video? Who in his right mind is going to spend 8 hours watching a video? I'm sure it's just something you've been lazy to cut, admit it ;)
dimzon
18th January 2006, 14:32
Actually, that would cause problems elsewhere in the calculator.. variables would overflow and thus crash the entire software.
Seems lilke we need decimal computations ;)
SBaT
18th January 2006, 14:55
@berrinam
Thankyou for the updates noticed them also on the dev thread.
One question left. Where can I find 0.2.3.2033, or are I'm just too hasty and they show up at sourceforge at some point? Just eager to try out new version :)
max-holz
18th January 2006, 16:33
I have queued this job:
Starting job job1-1 at 15.42.25
Job is a video job. encoder commandline:
--pass 1 --bitrate 685 --stats
"C:\Scambio\Elaborazione Video\Peter\Peter.stats"
--bframes 3 --b-pyramid --filter -2,-1 --subme 1
--analyse none --me dia --threads 2 --progress
--no-psnr --output NUL
"C:\Scambio\Elaborazione Video\Peter\Peter.avs"
successfully started encoding
I always use the option --threads 2 and I have noticed that the pause button in the Queue tab does not suspend any threads. The pause button in this case suspends only the progress bar and the advancement of the enconding's percentage but not the encoding itself.
Doom9
18th January 2006, 17:33
I have noticed that the pause button in the Queue tab does not suspend any threads. The pause button in this case suspends only the progress bar and the advancement of the enconding's percentage but not the encoding itself.This is not quite correct. The thing is that x264.exe keeps on running for a while, while the line processing is suspended.. you don't get any status updates anymore because the processing is effectively suspended. After some 1xx frames, x264 will then stop as well, but not before that. The other codecs are not affected by this and I have no other way to suspend an encoder than to stop reading its outputs, other than to starve the application for CPU time (which would involve making MeGUI eat 100% cpu time.. not a good strategy).
One question left. Where can I find 0.2.3.2033, or are I'm just too hasty and they show up at sourceforge at some point? Just eager to try out new versionIt's already in the CVS but the thing with the releases is it takes time.. hence I asked for some help in the news so that we have somebody else making releases while all developers just focus on the code instead.
max-holz
18th January 2006, 17:50
This is not quite correct. The thing is that x264.exe keeps on running for a while, while the line processing is suspended.. you don't get any status updates anymore because the processing is effectively suspended. After some 1xx frames, x264 will then stop as well, but not before that. The other codecs are not affected by this and I have no other way to suspend an encoder than to stop reading its outputs, other than to starve the application for CPU time (which would involve making MeGUI eat 100% cpu time.. not a good strategy).
It's already in the CVS but the thing with the releases is it takes time.. hence I asked for some help in the news so that we have somebody else making releases while all developers just focus on the code instead.
???
Just a test
1) start the encoding
2) press the pause button at 0.3% of percentage of the encoding
3) after 10 minutes x264 process still eating 50% of CPU's time (P4 3.4 with dual channel memory 1 GB)
3) resume the encoding
4) the percentage of the encoding jumps to 3,4%
Sorry Doom9, for me the pause button doesn't function!
Doom9
18th January 2006, 18:25
well.. I just can't reproduce that on either of my machines (an X2 and a regular P4 without any HT).. it stops shortly after being told to stop.
3) after 10 minutes x264 process still eating 50% of CPU's timeNow that makes no sense.. either it would be 100% (or 99%), or something over 50% in case of two cores.
Even if I set 2 threads on my P4, it still pauses.. it takes a while, perhaps 30 seconds (and it encoded a good 300 frames in the meantime), but then it does what it's been told to.
max-holz
18th January 2006, 18:36
or something over 50% in case of two cores
That's right, after 10 minutes this is the situation, dual channel memory is like two cores. Perhaps I didn't explain well the issue. I have done a test with 1 thread, same situation.
I'am not sure but perhaps the ManualResetEvent isn't the best choice; I have thinked about the Semaphore class.
Ciao
max-holz
18th January 2006, 18:53
I have found this sample:
using System;
using System.Threading;
using System.Timers;
using System.Runtime.InteropServices;
// Sample application to demonstrate CPU imbalance on
Hyper-Threading enabled processors namespace cpuimbalance
{
public class ParameterBlock
{
public uint id;
public uint threadOption;
public uint loops;
public ManualResetEvent ev;
}
sealed public class SampleApp
{
static ParameterBlock[] blocks;
static uint numberOfThreads;
static uint threadOption;
// VTune API which supports VTPause and VTResume data collection feature.
// VTune is started in pause data collection mode until we are ready to begin
// event sampling.
[DllImport("vtuneapi.dll")]
static extern void VTResume();
public static void ThreadProcess(object parameterBlock)
{
ParameterBlock x = parameterBlock as ParameterBlock;
uint sum = 0;
uint i = 0;
// Wait to be signal before entering infinite loop.
x.ev.WaitOne();
// Simple loop to keep thread busy.
while (true)
{
// Add OS kernel call which provides the OS with an opportunity to
// context-switch this thread sooner than it may otherwise.
if (threadOption == 1) x.ev.WaitOne();
sum = sum + i*i;
i += 1;
x.loops += 1;
}
}
static void Main(string[] args)
{
if (args.Length != 2)
Console.WriteLine ("Invalid argument: [number of threads] [thread option]");
numberOfThreads = uint.Parse(args[0]);
threadOption = uint.Parse(args[1]);
blocks = new ParameterBlock[numberOfThreads];
blocks[0] = new ParameterBlock();
blocks[0].id = 0;
blocks[0].threadOption = threadOption;
blocks[0].ev = new ManualResetEvent(false);
for (uint i = 1; i < numberOfThreads ; i++)
{
blocks[i] = new ParameterBlock();
blocks[i].id = i;
blocks[i].threadOption = threadOption;
blocks[i].ev = new ManualResetEvent(false);
// Queue up worker threads.
ThreadPool.QueueUserWorkItem (new WaitCallback(ThreadProcess), blocks[i]);
}
// Signal threads to begin.
for (uint i = 0; i < numberOfThreads; i++)
blocks[i].ev.Set();
// Signal VTune Performance Analyzer to begin collecting data
VTResume();
// Using main thread as a worker thread. Begin processing
ThreadProcess (blocks[numberOfThreads - 1]);
// Should never get here since the threads running in infinite loop by design!
// Exit controlled by VTune when it terminates this process after data collect.
// Alternatively, user can kill the process through Cntrl-C.
}
}
}
I presume that the problem is that MEGui doesn't cycling for checking the number of threads and so doesn't dispatch the ManualResetEvent to all threads.
Also found this article: http://www.yoda.arachsys.com/csharp/multithreading.html
Ciao
Doom9
18th January 2006, 19:09
I'am not sure but perhaps the ManualResetEvent isn't the best choice; I have thinked about the Semaphore class.So you know C#.. excellent.. then why don't you put a breakpoint in the readStdOut and readStdErr methods, press pause, and see what happens.
max-holz
18th January 2006, 19:29
So you know C#.. excellent.. then why don't you put a breakpoint in the readStdOut and readStdErr methods, press pause, and see what happens.
I will do a debug tonight when I will be at home.
At later
max-holz
18th January 2006, 22:33
I have done the debug Doom9.
This is the 2 pass 1° pass same settings as described in my above post.
In Form1.cs App performs
private void pauseButton_Click(object sender, System.EventArgs e)
{
if (!this.paused) // we're encoding
{
paused = true;
string error;
if (vEnc != null) // currently encoding video
vEnc.pause(out error);
then in Video Encoder.cs
public virtual bool pause(out string error)
{
error = null;
return encoder.pause(out error);
}
then in CommandlineVideoEncoder.cs
public override bool pause(out string error)
{
error = null;
if (mre.Reset())
return true;
else
{
error = "Could not reset mutex. pause failed";
return false;
}
}
No error is returned, the application seems to have performed correctly the ManualResetEvent mre.Reset(), the problem is that event doesn't affect x264.exe encoding. The code doesn't pass from AviSynthProcessor.cs or in any other point of CommandlineVideoEncoder.cs especially protected void readStdOut() and protected void readStdErr() as you said to me.
Ciao
AMED
18th January 2006, 23:05
I'm not sure if this is a feature request or a bug, but here goes
when using the Avisynth script creator, i load in a .d2v file that has a aspect ratio of 4:3. the output resolution vaules in the "resolution crop" section stays at 640x272. shouldn't this value be the correct ratio when the .d2v file is loaded?
4:3 = 640x480
16:9 = 640x352
or maybe a good idea to set the "suggest resolution" to be on for 4:3,16:9 and 1:1 and off for custom?
please move this post if it is in the wrong place
Doom9
18th January 2006, 23:12
i load in a .d2v file that has a aspect ratio of 4:3. the output resolution vaules in the "resolution crop" section stays at 640x272.Yup.. that's the default value.. you need to enable "suggest resolution" for it to make a proper suggestion.. if you don't, then I assume you know your resizing and will make the proper choice. Just because I could make it change to 640x480 doesn't mean the user will make the right choice.. either you know it and the defaults don't matter, or you don't in which case you enable "suggest resolution"
the problem is that event doesn't affect x264.exe encoding. Since it does what it's supposed to and you're the only one so far to report this problem, I have to assume the error is machine related..
max-holz
18th January 2006, 23:15
Since it does what it's supposed to and you're the only one so far to report this problem, I have to assume the error is machine related..
I think not!!!
Sharktooth
18th January 2006, 23:18
@berrinam
Thankyou for the updates noticed them also on the dev thread.
One question left. Where can I find 0.2.3.2033, or are I'm just too hasty and they show up at sourceforge at some point? Just eager to try out new version :)
2033 bins are up on SF. Sources are here: http://files.x264.nl/?dir=./Sharktooth/megui/Sources
Doom9
18th January 2006, 23:28
I think not!!!you need to prove that.. otherwise I consider it an insult since I wrote and tested that code.
max-holz
18th January 2006, 23:34
you need to prove that.. otherwise I consider it an insult since I wrote and tested that code.
If the thread code doesn't fuction o with hyperthreading CPU is not a machine problem but a bug. For your notice also the Stop button is inoperative only the Abort button does the right job.
AMED
18th January 2006, 23:58
here is a audio extension bug i just stumbled across,
how to reproduce
on the input tab, set the audio portion to MP3 and set the Video output type to MKV
open up the dgindex, load in a vob, and choose "select audio streams to demux" and select any language, but leave track 2 empty, check both check boxes at the bottom of the dgindex window and click queue
goto the queue tab and click start and wait for the avisynth script creator to open, don't change anything in this window and click save
on the megui window, go back to the input tab and look at the extension of the audio output file, it will be called *.mp4
Doom9
19th January 2006, 09:02
For your notice also the Stop button is inoperative only the Abort button does the right job.You are once again mistaken. Stop stops the queue.. the current job will still be encoded. Hm.. I thought I was surrounded by VirtualDub loving people.. I blatantly copied much of the queue functionality from VDub.. it has the exact same feature working the exact same way. Stopping encoding in mit-stream is a dangerous and deadly operation.. hence it's called something dangerous: abort, and it asks you if you are really sure you want to do that.
If the thread code doesn't fuction o with hyperthreading CPU is not a machine problem but a bug.So you got that cheap piece of an smp excuse? Is the CPU usage always 50% when encoding or does it change when you press pause or thereafter? And just to make this very clear: I have a real SMP system and it works there.. Can you switch off HT and try again? And you've already verified that the code works.. how can you possibly call it a bug then.. there's not more you can do from within .NET.. there's no control over the actual encoding process.. if for some reason encoding goes on even if stdout and stderr are blocked on a HT system, that would still be an x264 problem if not a hardware problem (I've come across enough applications that don't even work properly with HT)
on the megui window, go back to the input tab and look at the extension of the audio output file, it will be called *.mp4That's by design because AAC is the default output. Is the codec dropdown still set to MP3?
AMED
19th January 2006, 09:28
That's by design because AAC is the default output. Is the codec dropdown still set to MP3?yeah, the dropdown still says MP3, you need to change the drop down from MP3 to something else and then back again and the extension will change to .mp3
http://img10.imageshack.us/img10/29/pic011pn.png
after fixing the extension of the audio file and i use the autoencode button, i get this error
http://img30.imageshack.us/img30/3264/pic029ps.png
it doesn't seem to do anything because all the files show in the queue tab as they should and encoding of the video, audio, muxing and playback works fine.
Gehenna
19th January 2006, 12:21
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
19th January 2006, 13:23
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
19th January 2006, 13:28
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
19th January 2006, 14:35
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
19th January 2006, 16:25
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
19th January 2006, 21:47
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
19th January 2006, 21:49
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
20th January 2006, 10:24
@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
20th January 2006, 15:07
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
20th January 2006, 15:13
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
20th January 2006, 17:53
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
20th January 2006, 20:07
@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
20th January 2006, 20:57
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
20th January 2006, 21:41
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
20th January 2006, 22:34
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
20th January 2006, 22:39
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
20th January 2006, 22:50
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
21st January 2006, 03:20
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
21st January 2006, 16:21
A bug I reported here (http://forum.doom9.org/showthread.php?p=772455#post772455).
Richard Berg
21st January 2006, 16:44
@Doom9 - here is a patch to fix the two bugs we discussed. Please review.
http://richardberg.net/bin/temp/filechecking-bugfixes.rar
Doom9
21st January 2006, 16:51
@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
21st January 2006, 17:19
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
21st January 2006, 17:22
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
21st January 2006, 17:24
ToArray() is in the patch :)
Doom9
21st January 2006, 17:29
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
21st January 2006, 17:31
Sounds good. A rough check can't hurt, so long as you can override it.
ChronoCross
21st January 2006, 19:34
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
21st January 2006, 22:32
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
21st January 2006, 23:08
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
21st January 2006, 23:14
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
22nd January 2006, 04:33
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
22nd January 2006, 05:35
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
22nd January 2006, 08:39
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
22nd January 2006, 09:35
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
22nd January 2006, 10:19
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
22nd January 2006, 11:08
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
22nd January 2006, 14:01
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
22nd January 2006, 17:36
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
22nd January 2006, 19:54
Bug: The small arrows for the "Birate Variance" don't increase/decrease the values well... unless I'm wrong?
- Dan
puffpio
22nd January 2006, 20:49
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
23rd January 2006, 00:28
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
23rd January 2006, 01:40
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
23rd January 2006, 02:04
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
23rd January 2006, 09:26
does ffmpeg support snow?
dimzon
23rd January 2006, 09:40
does ffmpeg support snow?
ffmpeg -formats
produce
...
DEV snow
...
puffpio
23rd January 2006, 10:53
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
23rd January 2006, 11:17
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
23rd January 2006, 12:06
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
23rd January 2006, 12:44
@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
23rd January 2006, 15:38
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..
vBulletin® v3.8.5, Copyright ©2000-2012, Jelsoft Enterprises Ltd.