MeGUI Bug-Report Thread

[dimzon]

Originally Posted by Doom9

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]

@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]

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]

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 version

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.

[max-holz]

Originally Posted by Doom9

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]

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 time

Now 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]

Originally Posted by Doom9

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]

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]

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]

Originally Posted by Doom9

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]

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]

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]

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]

Originally Posted by Doom9

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]

Originally Posted by SBaT

@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]

I think not!!!

you need to prove that.. otherwise I consider it an insult since I wrote and tested that code.

[max-holz]

Originally Posted by Doom9

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]

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]

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 *.mp4

That's by design because AAC is the default output. Is the codec dropdown still set to MP3?

[AMED]

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



after fixing the extension of the audio file and i use the autoencode button, i get this error



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.