MeGUI: bug reports and feature requests

[Guest]

It crashes MEGUI when I enqueue a script using DGMultiDecodeNV.dll. It opens the preview fine but then crashes when I enqueue a job. This is the problem I have always had.

If you have an Nvidia card I'd be happy to give you a license so you can figure out why Megui crashes.

[foxace]

Originally Posted by neuron2

It crashes MEGUI when I enqueue a script using DGMultiDecodeNV.dll. It opens the preview fine but then crashes when I enqueue a job. This is the problem I have always had.

If you have an Nvidia card I'd be happy to give you a license so you can figure out why Megui crashes.

same for me when I click on queue megui crash and the nvidia resizer don't work the resolution becomes very small

[Zathor]

Originally Posted by neuron2

If you have an Nvidia card I'd be happy to give you a license so you can figure out why Megui crashes.

That would be so great! Thank you very much. Sent you a PM.

Hopefully I can reproduce the crashes, it's easy to solve and the CUVIDServer is not necessary anymore.

I have removed the link in my previous posting because of the existing problems.

I had a look at this a while ago when i was having the same problem. Worked out it was a timing issue between the different threads. When you click Enqueue it opens the script at least 3 times and i guess that on some occasions it wasn't able to dispose of the old one before opening it again.

I ended up putting a Thread.Sleep(50) inside the AVSReader class just after it opens the script and that fixed my problem. Bit of a hack i know, but since it was only for me i didn't care. You might be able to come up with a better solution.

[stax76]

There might as well be a bug on the native side since I have a report DGMultiSource with resize arguments crashing StaxRip which doesn't do anything special other than a few simple VFW calls. Such a bug might not cause issues in a native application but only in managed applications. Some people notice a script running in a native application and don't in a managed application and conclude there is a bug in the managed application but it might as well be a bug in the native component. Often the CLR detects when a native component tries to corrupt managed memory, sometimes the complete managed exception handling fails.

I ended up putting a Thread.Sleep(50) inside the AVSReader class just after it opens the script and that fixed my problem. Bit of a hack i know, but since it was only for me i didn't care. You might be able to come up with a better solution.

Maybe some simple thread synchronization.

[Zathor]

Thanks to neuron2 I have now a license and I am able to reproduce the problem.

Originally Posted by olex99

I had a look at this a while ago when i was having the same problem. Worked out it was a timing issue between the different threads. When you click Enqueue it opens the script at least 3 times and i guess that on some occasions it wasn't able to dispose of the old one before opening it again.

You really do not want to know how many times the avs file is opened...

I ended up putting a Thread.Sleep(50) inside the AVSReader class just after it opens the script and that fixed my problem. Bit of a hack i know, but since it was only for me i didn't care. You might be able to come up with a better solution.

Tried this "hack", too, but I had no luck. Even with very high values and explicit dispose of the opened avs the program crashed without error handling in places where a error handling should catch it. Also I was not able to attach the CLR to the process. DGMultiSource errors out with cuCtxCreate() failed

It's too late now to check this further. Will have a look at it tomorrow.

[BuckMaster]

I want to thank you Zathor for all you do and time spend for Megui.I read this tread from the start, Megui is an app who worth more and you are one of the people who can prove that.
Cheers bro!

[medp7060]

Agreed. It seems that MeGUI is one of the best x264 GUI out there, but its develpment is not as avtive as before. Hope it is not another GKnot.

[JoeH]

Thanks to Kagain and Quantum for their work on v1 and v2 of the profiles. I have done some more work on the Bluray profiles, and am attaching the results.

NOTE: These profiles will ONLY work with the new version of MeGUI that Zathor has not yet released which has the checkboxes for the --aud and --nal-hrd options.

Here is a list of the changes I made and why:

1. Increased Bitrate on 2 pass to 8000 - Typical usage for a DVD9. The setting of 700 is not realistic for Bluray compatible devices.
2. Turned on Turbo on 2 pass - Default option, should always be used except in cases of extreme need.
3. --keyint 24 --min-keyint 2 - Required by Bluray specifications according the x264 Wiki
4. Moved everything I could off the "Custom command line" - It is not necessary to put everything that shouldn't change on the "Custom command line". It is enough that it appear in the command line. Anything that simply appears in the command line will take preference over the X264 "preset" and "tune" option. Because of this, the only thing I included was --bframe 3, as this is the default and thus does not naturally appear.
5. Selected the --nal-hrd and --aud checkboxes which Zathor added (Thanks Zathor!)
6. Slightly modified the CRF values - I changed "Very High Quality" to 15.0, which is what is recommended in the x264 official documentation as giving extremely high quality. I adjusted the values of Balanced and High Quality to step gradually up to the value of 23.0 in Standard.
7. Removed the difference between 1080p and 720p - X264 does nothing to resize the video. So, there is no need to have different profiles for 1080p and 720p. Therefore, I eliminated the redundancy and kept only 1 set of Bluray profiles, which should be used both for 1080p and 720p.

I think that's about it. If those changes seem good to you, please delete the v2 Bluray profiles and include these ones. Thanks!

Here is a link to download them: Bluray_profiles_v3.zip

P.S. - If you want to install these manually, just unzip them into the profiles directory. Just keep in mind you will need the update which Zathor posted but then took off.

[quantum5uicid3]

1. i assumed people would use the bitrate calculator
2. yeah, i agree, should probably be left on
3. oops
4. the slider and tune will change the commandline beyond just specifying the --tune and --preset is the problem. i think forcing the options in custom commandline is the better idea, because this makes maintaining compatibility for anyone completely dependent on the presets dummy proof(for lack of a better way to put it)
5. ok
6. i would imagine crf 15 would exceed the size of the original source in some cases. in other words, i think it's excessive. since this is a very subjective, i'd like to hear more opinions. maybe a "transparent" preset?
7. the difference is the maximum number of reference frames supported.

[Zathor]

Thank you very much, JoeH!

Originally Posted by JoeH

3. --keyint 24 --min-keyint 2 - Required by Bluray specifications according the x264 Wiki

I have read somewhere that --min-keyint 1 is recommended if targeting bluray. But I can't find the source now.

I'm in the process of bringing a new build online (without the DGindexer changes at the moment). I have changed the version to 1058 so that it can be updated with the new update server.

[nakTT]

Can't wait to give 1058 a try. Thanks Zathor.

[shon3i]

Originally Posted by Zathor

I have read somewhere that --min-keyint 1 is recommended if targeting bluray. But I can't find the source now.

Both --min-keyint 1 and --min-keyint 2 are ok, --min-keyint 2 is preffered if stream after encoding goes to authoring application such as sonic scenarist. max --keyint depend of maximum bitrate and fps.

Originally Posted by JoeH

Removed the difference between 1080p and 720p - X264 does nothing to resize the video. So, there is no need to have different profiles for 1080p and 720p. Therefore, I eliminated the redundancy and kept only 1 set of Bluray profiles, which should be used both for 1080p and 720p.

Originally Posted by quantum5uicid3

7. the difference is the maximum number of reference frames supported.

6 vs 4 for 720p anyway will not incrase quality that much. I recomend to not use more than 4 ref's in any case.

[Guest]

Originally Posted by Zathor

You really do not want to know how many times the avs file is opened...

DGMultiSource errors out with cuCtxCreate() failed

It's crucial to know that, because the GPU card's memory limits the number of simultaneous script instantiations. So, please tell us exactly how many times the script is opened, when and if they are closed, how they are closed (are they "really" closed, i.e., DGMultiDecode's destructor is called, or some funniness is used such that they are not really closed until Megui exits), etc.

[quantum5uicid3]

Originally Posted by JoeH

Thanks to Kagain and Quantum for their work on v1 and v2 of the profiles. I have done some more work on the Bluray profiles, and am attaching the results.

NOTE: These profiles will ONLY work with the new version of MeGUI that Zathor has not yet released which has the checkboxes for the --aud and --nal-hrd options.

Here is a list of the changes I made and why:

1. Increased Bitrate on 2 pass to 8000 - Typical usage for a DVD9. The setting of 700 is not realistic for Bluray compatible devices.
2. Turned on Turbo on 2 pass - Default option, should always be used except in cases of extreme need.
3. --keyint 24 --min-keyint 2 - Required by Bluray specifications according the x264 Wiki
4. Moved everything I could off the "Custom command line" - It is not necessary to put everything that shouldn't change on the "Custom command line". It is enough that it appear in the command line. Anything that simply appears in the command line will take preference over the X264 "preset" and "tune" option. Because of this, the only thing I included was --bframe 3, as this is the default and thus does not naturally appear.
5. Selected the --nal-hrd and --aud checkboxes which Zathor added (Thanks Zathor!)
6. Slightly modified the CRF values - I changed "Very High Quality" to 15.0, which is what is recommended in the x264 official documentation as giving extremely high quality. I adjusted the values of Balanced and High Quality to step gradually up to the value of 23.0 in Standard.
7. Removed the difference between 1080p and 720p - X264 does nothing to resize the video. So, there is no need to have different profiles for 1080p and 720p. Therefore, I eliminated the redundancy and kept only 1 set of Bluray profiles, which should be used both for 1080p and 720p.

I think that's about it. If those changes seem good to you, please delete the v2 Bluray profiles and include these ones. Thanks!

Here is a link to download them: Bluray_profiles_v3.zip

P.S. - If you want to install these manually, just unzip them into the profiles directory. Just keep in mind you will need the update which Zathor posted but then took off.

ok thanks to JoeH, ive made the changes to presets according to suggested points 1,2,3,7.

zathor we need your thoughts on point 4

[Guest]

OK, more data on the DG tools problem...

I found a missing close of the CUDA context in DGMultiDecode.dll. So please get the fixed one by redownloading 2.0.0 beta 6. It doesn't fix the Megui crashing but it may cure the cuCtxCreate() failure.

I traced my code and I see Megui doing this:

[open avs]
create DGMultiDecode instance (for preview)
[I close the preview]
destroy instance
[I enqueue the job]
create
destroy
create
destroy
create
destroy
CRASH!

So it should be working with my fix above but it is still crashing.

Also, it doesn't crash with the CUVID server, although I thought I saw that previously.

[Zathor]

- [x264ConfigurationPanel] updated the input handling 
- [AudioEncodingComponent] + [MeGUISettings] added audio format saving
- [MainForm] changed the unexptected error handler. The details will be only written to the log
- [ProfileConfigurationWindow] icon added
- [ProfileConfigurationWindow] every closing of the form will check if there has been something changed
- [x264ConfigurationPanel] added nal-hrd and aud checkbox (required for bluray; patched x264 is required for nal-hrd)
- [ContextHelp.xml] added and changed a few entries
- update MediaInfo library and its wrapper to the latest release (0.7.25)

In order to have a stable release the build 1058 is now online. Point the update server to http://www.constructd.com/megui/ and the new version will be applied.

Originally Posted by neuron2

It's crucial to know that, because the GPU card's memory limits the number of simultaneous script instantiations. So, please tell us exactly how many times the script is opened, when and if they are closed, how they are closed (are they "really" closed, i.e., DGMultiDecode's destructor is called, or some funniness is used such that they are not really closed until Megui exits), etc.

After 1058 is out I will continue the work at this front. Sadly it's not easy to answer your question because of the structure the avs are opened/called. Give me a little bit time

Originally Posted by JoeH

4. Moved everything I could off the "Custom command line" - It is not necessary to put everything that shouldn't change on the "Custom command line". It is enough that it appear in the command line. Anything that simply appears in the command line will take preference over the X264 "preset" and "tune" option. Because of this, the only thing I included was --bframe 3, as this is the default and thus does not naturally appear.

Changing the preset or tune slider will change things a user selected in other areas. That's the way it works now. So if a user wants to have higher speed/quality and moves the slider, some values which are required for device compatibility may be overwritten. For example the reference frames will increase up to 16 and many devices support only 3. I'm still unsure how to change the behavior. At the moment I recommend to put all device values into the custom command line. Device values = values which are required for device compatibility and which may change due to preset/tune changes.

[JoeH]

Originally Posted by Zathor

Changing the preset or tune slider will change things a user selected in other areas. That's the way it works now. So if a user wants to have higher speed/quality and moves the slider, some values which are required for device compatibility may be overwritten. For example the reference frames will increase up to 16 and many devices support only 3. I'm still unsure how to change the behavior. At the moment I recommend to put all device values into the custom command line. Device values = values which are required for device compatibility and which may change due to preset/tune changes.

Quantum and Zathor,

Thanks for clearing that up. I don't understand why it works that way - do you know if it is a bug in X264 or is this specific to MeGUI?

I just ran the updater to v1058, but the presets did not import. The window came up asking if I wanted to import the presets, but it was totally empty.

[JoeH]

Originally Posted by quantum5uicid3

6. i would imagine crf 15 would exceed the size of the original source in some cases. in other words, i think it's excessive. since this is a very subjective, i'd like to hear more opinions. maybe a "transparent" preset?

At least for Bluray movies it still tends to be smaller than the original, at least in tests I've run. Obviously this wouldn't be for someone who wants to burn to a DVD9, but for those times you want to quickly export a video to actually burn on a Bluray-25 disk, it tends to give about the right size.

Of course, it's not big deal for me to just customize it - so either way is fine with me.

I think Sharktooth used the term "insane" in his profiles to refer to extremely high quality...

[Zathor]

Originally Posted by JoeH

Thanks for clearing that up. I don't understand why it works that way - do you know if it is a bug in X264 or is this specific to MeGUI?

It's a MeGUI related "problem". If you change an option it is not locked and it will be changed if the preset/tune changes.

That's the way x264 applies the parameters:
--preset
--tune
user settings (will override preset and tune settings)
--profile overrides all settings

Thats the way MeGUI applies the settings if you change a value:
megui profile setting
changed user setting
if changed --preset overrides all settings
if changed --tune overrides all settings
if changed --profile overrides all settings
custom command line overrides all settings

That's not good at all, but if you understand how it works it is possible to create stable profiles.

Originally Posted by neuron2

OK, more data on the DG tools problem...

I found a missing close of the CUDA context in DGMultiDecode.dll. So please get the fixed one by redownloading 2.0.0 beta 6. It doesn't fix the Megui crashing but it may cure the cuCtxCreate() failure.

I traced my code and I see Megui doing this:

[open avs]
create DGMultiDecode instance (for preview)
[I close the preview]
destroy instance
[I enqueue the job]
create
destroy
create
destroy
create
destroy
CRASH!

So it should be working with my fix above but it is still crashing.

Also, it doesn't crash with the CUVID server, although I thought I saw that previously.

Yes, the cuCtxCreate() is gone but it is still crashing... The good news is as soon as the job is in the queue it can be started without problems. But it's very hard to get it in the queue without crash.