View Full Version : MeGUI: bug reports and feature requests
JoeH
11th December 2009, 08:06
It seems to be not my day :) So I need to ask a few questions:
1) main screen = main configuration screen of the profile or the main screen?
speed = x264 preset and preset = profile?
3) so we have basic rulesets for the devices? great!
More or less this is the way I would want it to be, but everybody keep the feedback flowing!
Sorry for the term confusion. Yes, I was referring to
"Main screen" of MeGUI, NOT of the profile
speed = X264 preset
Preset = MeGUI profile
So, I think we are in agreement.
Adub
11th December 2009, 08:58
Seems to be a small bug when entering in values by hand into the x264 settings dialog window. It basically goes haywire and is very difficult to compensate for.
Also, when scrolling down from 1000 kbps, it jumps to 9999 and then starts to decrease.
Zathor
11th December 2009, 11:02
Seems to be a small bug when entering in values by hand into the x264 settings dialog window. It basically goes haywire and is very difficult to compensate for.
Also, when scrolling down from 1000 kbps, it jumps to 9999 and then starts to decrease.
Thanks for the problem report. I will have a look at it. Do you have the problem with all sliders?
Sorry for this noob question. What is --nal-hrd ?
http://mewiki.project357.com/wiki/X264_Settings#nal-hrd
Add NAL HRD parameters to the output stream; used for HD-DVD and Blu-ray compliancy. Depends on vbv-bufsize and vbv-maxrate to be set to be active.
quantum5uicid3
11th December 2009, 15:52
not sure if auto update wasn't working because version didn't change or what, but jeeb's 1373 patched is up now.
nakTT
11th December 2009, 15:54
not sure if auto update wasn't working because version didn't change or what, but jeeb's 1373 patched is up now.
Thank god. I have been waiting for it.
:thanks:
Edited: I get this error.
Finished parsing update file...
There is 1 file that can be updated.
Updating x264. File 1/1.
Update completed.
0 file was completed successfully
1 file had problem.
nakTT
11th December 2009, 15:56
http://mewiki.project357.com/wiki/X264_Settings#nal-hrd
Thanks for the info. No wonder I never encounter issue with 1369, because I did not use that particular feature.
:thanks:
rack04
11th December 2009, 15:58
In the new x264 profiles I is possible to break Blu-ray compliance using the tunes. For example, --tune animation increases bframes to 5 while blu-ray specifications say the limit is 3. If you know what settings you need for compliance I would add those to the custom command line so you're not relying on the defaults.
Kagain
11th December 2009, 17:05
In the new x264 profiles I is possible to break Blu-ray compliance
You're right about that.
Deleted the animation profiles.
Added reference frames and b frames to the command line so now the tune animation can be used instead.
http://www.mediafire.com/?znoqzwm2kdf
Thanks
quantum5uicid3
11th December 2009, 17:13
if i understand the presets and tuning correctly. specifying individual options in the command line does overwrite the tunings, but does not overwrite the presets. i didn't think about this before, so i think we're gonna need more gui changes. someone correct me if i'm wrong.
the update server should be good now, i think it was having trouble parsing the name of the patch for some reason. the hyphen maybe?
nakTT
11th December 2009, 17:16
the update server should be good now, i think it was having trouble parsing the name of the patch for some reason. the hyphen maybe?
After I keep on trying, it just succeeded in the end. I don't know what is the problem but it is okay now. Many thanks for providing us the update server.
:thanks:
quantum5uicid3
11th December 2009, 17:20
ive been messing with it for a while now, i verified it wasn't working here either. i was confused why, i'm pretty sure it was the hyphen in the patch name though :)
quantum5uicid3
11th December 2009, 17:25
so no confusion
nakTT
11th December 2009, 17:28
ive been messing with it for a while now, i verified it wasn't working here either. i was confused why, i'm pretty sure it was the hyphen in the patch name though :)
I don't know why and I can't really help as I'm not a programmer. But I'm very glad it is working now. Thanks again.
:thanks:
quantum5uicid3
11th December 2009, 17:46
Presets will be used as follows:
--preset name
and apply before all other options. In other words, they override the x264 defaults, which, with the default changes (http://forum.doom9.org/showthread.php?t=148148), will be:
--subme 7 --bframes 3 --weightb --8x8dct --ref 3 --mixed-refs --trellis 1 --crf 23 --threads auto
As such, all options that you set will act on top of the preset you choose, regardless of the option order.
ultrafast:
--ref 1 --scenecut 0 --nf --no-cabac --bframes 0 --partitions none --no-8x8dct --me dia --subme 0 --aq-mode 0
veryfast:
--partitions i8x8,i4x4 --subme 1 --me dia --ref 1 --trellis 0
fast:
--mixed-refs 0 --ref 2 --subme 5
medium:
<defaults>
slow:
--me umh --subme 8 --ref 5 --b-adapt 2 --direct auto
slower:
--me umh --subme 9 --ref 8 --b-adapt 2 --direct auto --partitions all --trellis 2
placebo:
--me tesa --subme 9 --merange 24 --ref 16 --b-adapt 2 --direct auto --partitions all --no-fast-pskip --trellis 2 --bframes 16
For all encodes, regardless of preset or not, using --pass 1 will automatically trigger "turbo" settings, which are as follows and override all commandline options:
--trellis 0 --no-8x8dct --partitions none --me dia --ref 1 --subme MIN(2, previous subme)
This can be disabled using --slow-firstpass.
For all encodes, if you don't set your own --ref option and instead use the default or a preset, x264 will automatically lower --ref if the --level you set conflicts with it. If you set --ref explicitly, it will not override what you set.
Profiles will be used as follows:
--profile name
The options will be baseline, main, and high, which do what you think they do. Note that these override all other options no matter what, with two exceptions.. Because interlaced and lossless coding are options with very explicit meanings, the encoder will terminate with an error if you attempt to use them with an incompatible profile.
Tunings will be used as follows:
--tune name
The options will be "film" and "animation", and will tweak AQ strength, psy-rd/trellis strength, deblock, refs, and so forth:
film:
--deblock -1:-1 --psy-rd 1.0:0.15
animation:
--ref (previousref==1?1:MIN(previousref*2,16)) --deblock 1:1 --psy-rd 0.4:0 --aq-strength 0.6 --bframes 5
All of this is subject to change before final release, and suggestions are welcome.
If you don't use any of the new presets, the only changes for you will be the new defaults, and the automatic fast first pass.
maybe someone can understnad this better, i just kept setting all my options manually, so never bothered to understand this. does "explicitly" setting options override the --tune and --preset or not?
rack04
11th December 2009, 18:18
maybe someone can understnad this better, i just kept setting all my options manually, so never bothered to understand this. does "explicitly" setting options override the --tune and --preset or not?
yes it will override both.
quantum5uicid3
11th December 2009, 18:25
ok cool thanks. im doing new ones now, it's so tedious :)
foxace
11th December 2009, 18:58
Hello and thank you for your excellent work.
Is it possible to make megui compatible with
the new version of "DG NV tools 2.0.0 "
The server "CUVIDServer .exe" does not launch properly, the function resize nvidia not working well.
:thanks:
quantum5uicid3
11th December 2009, 19:03
does anyone know? DXVA can now play anything as long as it's h264 compliant, right?
and AVCHD compliant is the same as bluray compliant?
i made some device presets with quality settings ranging from crf 18.5 to 23 in increments of 1.5 and a 2pass. you still need to set the tune option depending on the source and adjust the preset slider for speed adjustments.
quantum5uicid3
11th December 2009, 19:32
Hello and thank you for your excellent work.
Is it possible to make megui compatible with
the new version of "DG NV tools 2.0.0 "
The server "CUVIDServer .exe" does not launch properly, the function resize nvidia not working well.
:thanks:
someone buy zathor a gtx 295 and dgnv and i'm sure he'd be inclined :)
foxace
11th December 2009, 20:03
someone buy zathor a gtx 295 and dgnv and i'm sure he'd be inclined :)
ok. I send a letter to Father Christmas we'll see if he answers.:p
Kagain
11th December 2009, 23:29
you still need to set the tune option depending on the source and adjust the preset slider for speed adjustments.
The problem with making device profiles and still use the preset slider for speed adjustments is that the reference frames will not be adjuster accordingly.
i.e if --ref 4 is set in the commandline and you want a faster profile, the # of reference frames will not be decreased if you use the slider. But that might not matter too much.
quantum5uicid3
11th December 2009, 23:47
i know it's not absolutely perfect, but playing with it, ultra fast still goes pretty damn fast.
quantum5uicid3
12th December 2009, 00:20
zathor,
the following fields throw an error when trying to delete them to type in a new value, functionally everything is good, it's purely aesthetic.
Maximum GOP Size
Minimum GOP Size
Number of Reference Frames
VBV Buffer Size
VBV Maximum Bitrate
there's also problems deleting the crf and typing in a new value. if i delete it and want 23 for instance, i have to type 3-2.
Zathor
12th December 2009, 01:51
the following fields throw an error when trying to delete them to type in a new value, functionally everything is good, it's purely aesthetic. [...] there's also problems deleting the crf and typing in a new value. if i delete it and want 23 for instance, i have to type 3-2.
Thanks and fixed (as soon as I upload the next build)
I noticed how megui passes a parameter to neroencaac.exe that creates a fake chapters in the mp4/m4a container. If this could be fixed so it doesn't create fake chapters,it'd help muxing mp4 and uploading to youtube without using mp4box as a cli.
From the nero aac encoder help:
Note that multiple input files can be specified, they will be encoded together into a single output file with chapter marks indicating source file divisions.
So the problem seems to be a feature which works as designed. I assume a chapter will be created every time a stream is passed to neroaacencoder from stdin.
nakTT
12th December 2009, 02:07
zathor,
the following fields throw an error when trying to delete them to type in a new value, functionally everything is good, it's purely aesthetic.
Maximum GOP Size
Minimum GOP Size
Number of Reference Frames
VBV Buffer Size
VBV Maximum Bitrate
there's also problems deleting the crf and typing in a new value. if i delete it and want 23 for instance, i have to type 3-2.
The same issue happen when you want to type bitrate for "automated 2pass".
Zathor
12th December 2009, 02:38
The same issue happen when you want to type bitrate for "automated 2pass".
I have checked all input handler in the configuration window. All of them should be ok now.
Can you do this for audio file format as well?
This has been added, too. But the new build is still not available and because of other changes it may take one or two days before this build is available.
nakTT
12th December 2009, 02:50
Glad to hear that. Thanks man.
:thanks:
Evil Ash
12th December 2009, 15:36
Hi, this is my 1st post and I'm sorry its to report a bug. MeGUI is adding "--sar 1:1" at the end of the command line overriding any custom I add, its a PAL DVD so I'm adding "--sar 64:45" to the custom command line, everything looks fine in the profile, eg."program --crf 21.5 --thread-input --sar 64:45 --output "output" "input" ", I hit encode and heres an edited log so you can see what I mean.
--[NoImage] Job commandline: "x264.exe" --crf 21.5 --thread-input --sar 64:45 --sar 1:1 --output "E:\MKVs\vinny.mkv" "E:\MKVs\vinny.avs"
---[NoImage] avs [info]: 708x548 @ 25.00 fps (171658 frames)
---[NoImage] x264 [info]: using SAR=1/1I'm using the newest installer(thanks quantum5uicid3) fully updated and WinXp-SP3.
Zathor
12th December 2009, 15:44
Hi, this is my 1st post and I'm sorry its to report a bug. MeGUI is adding "--sar 1:1" at the end of the command line overriding any custom I add, its a PAL DVD so I'm adding "--sar 64:45" to the custom command line, everything looks fine in the profile, eg."program --crf 21.5 --thread-input --sar 64:45 --output "output" "input" ", I hit encode and heres an edited log so you can see what I mean.
Welcome to the forum!
And thanks for the problem report. I have fixed the error and a custom sar will overwrite the automatically generated one. But I can still not upload the build because of ongoing other changes.
Zathor
12th December 2009, 18:45
- [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
- removed DGM and DGVC1 Indexer, removed CUVIDServer start
- added DGIndexNV and DGMultiSource support
This is an unstable build only for testing purposes because of the DGIndexer changes. I cannot test it myself (no license) so someone else needs to test it. As soon as the feedback is positive I will merge all three DGIndexer. At the moment all three indexer may not function properly. So do not use it in a productive environment!
If you want to test it, download the build, install as usual, edit the DGIndexNV path in the settings and copy the DGMultiDecodeNV.dll to the megui\tools\avisynth_plugin folder.
Unstable development build!
Link removed
Guest
12th December 2009, 21:02
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
12th December 2009, 23:48
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
12th December 2009, 23:52
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.
olex99
13th December 2009, 00:41
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
13th December 2009, 01:08
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
13th December 2009, 01:31
Thanks to neuron2 I have now a license and I am able to reproduce the problem.
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
13th December 2009, 08:06
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!:D
medp7060
13th December 2009, 09:59
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
13th December 2009, 13:09
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 (http://www.mediafire.com/?zejiwmyeu0e)
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
13th December 2009, 14:12
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
13th December 2009, 14:20
Thank you very much, 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
13th December 2009, 14:31
Can't wait to give 1058 a try. Thanks Zathor.
:thanks:
shon3i
13th December 2009, 14:33
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.
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.
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
13th December 2009, 15:06
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
13th December 2009, 15:10
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 (http://www.mediafire.com/?zejiwmyeu0e)
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
13th December 2009, 15:38
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
13th December 2009, 15:39
- [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.
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 :rolleyes:
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
13th December 2009, 16:13
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
13th December 2009, 16:27
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...:p
Zathor
13th December 2009, 16:27
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.
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.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.