Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
25th July 2013, 11:43 | #3361 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,823
|
Quote:
The way I understand it, when --bluray-compat is used, the default for --weightp is 1, so why does checking the Blu-ray compatibility option add --weightp 2 to the command line? Selecting the target device as Blu-ray doesn't. I assume it's wrong, as I ran a test encode and according to MediaInfo the setting for --weightp was 1 even with the Blu-ray compatibility option checked, so MeGUI adding --weightp 2 to the command line when it's checked doesn't seem to have any effect. When the Blu-ray compatibility option is checked, the open GOP setting can be selected/deselected, but it appears do to nothing, and while --open-gop is supported by the Blu-ray spec, and it's probably a good idea to use it when encoding for Blu-ray, it's not compulsory so there's probably no reason why MeGUI should force it's use. I'm still trying to get my head around these settings, but does using --bluray-compat in the command line also effectively add --aud and/or --nal-hrd as well? When selecting Blu-ray as the target device, the "Use Access Delimiters" option is checked and can't be unchecked, but should the Blu-ray compatibility option do the same thing on it's own? Currently, while it allows "use access delimiters" to be checked and unchecked, doing so appears to make no difference to the command line. If the Blu-ray compatibility option is checked (no target device selected), MeGUI adds the following warning to the log file: "NAL HRD parameters require VBV parameters" Manually adding VBV parameters gets rid of the warning but changing the HRD Info setting to "None" does not. I assume --bluray-compat doesn't enforce all the necessary settings for a fully Blu-ray compliant encode (although I've not found a definitive list as to which settings are effected), hence selecting Blu-ray as the target device in MeGUI adds extra parameters to the command line, but I think checking the Blu-ray compatibility option in MeGUI's encoder setup should do nothing more than add --bluray-compat to the command line. If checking it is going to also change other options relating to Blu-ray compatibility then it probably should change all the required options, or it should change none and leave that up to selecting Blu-ray as the target device. Last edited by hello_hello; 25th July 2013 at 12:00. |
|
26th July 2013, 10:11 | #3363 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,823
|
That site is down at the moment, but are you referring to the settings it uses when selecting Blu-ray/AVCHD as the target playback device?
If so, what it adds to the command line is understandable, but the main point of my previous post was that when no target playback device is selected and the Blu-ray Compatibility option is checked in the x264 configuration, it does more than simply add --bluray-compat to the command line, and maybe a couple of things is shouldn't. Is that be design? With no target playback device selected and the Blu-ray Compatibility option checked: --weightp 2 is added to the command line ( I think --bluray-compat restricts weightp to 1, so --weightp 2 has no effect). --open-gop is added to the command line even though open gop is not checked in the x264 configuration and it can't be removed, yet I think open gop is supported but not compulsory for Blu-ray (the same applies to selecting Bluray as the target device). I've done a little more research and understand a more about what --bluray-compat does in terms of setting/limiting other x264 parameters (assuming the list here is accurate), but the way MeGUI does things doesn't seem to be consistent across all x264 settings. For example if --bluray-compat restricts --bframes to 3, why does MeGUI let me change --bframes to more than 3 when the Blu-ray compatibility option is checked, yet it won't let me change the min gop size parameter because that's already set by --bluray-compat? When Blu-ray is selected as the target playback device the behaviour changes compared to using the Blu-ray compatibility option on it's own..... to the point where MeGUI adds --bframes 3 to the command line when a slower x264 speed preset is used, yet doing so is probably redundant. In my opinion there should be command line and GUI consistency between selecting Blu-ray as the target playback device and checking the Blu-ray Compatibility option on it's own. Maybe it'd be an idea for the encoder configuration to make it more obvious when one x264 setting is effected by another. For example when Blu-ray is selected as the target playback device, the "Use Access Unit Delimiters" checkbox could change colour to show why it's automatically checked and can't be unchecked. Of course if checking the Blu-ray compatibility option on it's own does the same thing, the same should apply to keep it consistent. Currently it can be checked/unchecked, but doing so has no effect. |
26th July 2013, 11:57 | #3364 | Link |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
Here's a list with things --bluray-compat does (lines 741-755):
http://git.videolan.org/gitweb.cgi?p...1280a1;hb=HEAD These should include all things you can set through other parameters, but note that there are some things --bluray-compat does that can not be enabled by any combination of the other settings as an alternative. Since --bluray-compat does not check all things demanded by the spec, it can indeed make sense for a GUI to do more checks itself. Your suggestions do make sense as well, though I'd consider most of them cosmetic. Use the following URL in case x264bluray.com is down: https://sites.google.com/site/x264bluray/ Last edited by sneaker_ger; 26th July 2013 at 13:08. |
26th July 2013, 12:39 | #3365 | Link | |
Guest
Posts: n/a
|
Quote:
|
|
26th July 2013, 12:55 | #3366 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
|
I am certain that this option has been explained verbosely before; the pity is that you won't find it if you don't know specific unique sentences used there, there are too many posts with many of the simple options mentioned which this "hack" forces or limits. The MeWiki on x264 Settings is a little lazy.
__ P.S.: From the source view in encoder/encoder.c Code:
739 if( h->param.b_bluray_compat ) 740 { 741 h->param.i_bframe_pyramid = X264_MIN( X264_B_PYRAMID_STRICT, h->param.i_bframe_pyramid ); 742 h->param.i_bframe = X264_MIN( h->param.i_bframe, 3 ); 743 h->param.b_aud = 1; 744 h->param.i_nal_hrd = X264_MAX( h->param.i_nal_hrd, X264_NAL_HRD_VBR ); 745 h->param.i_slice_max_size = 0; 746 h->param.i_slice_max_mbs = 0; 747 h->param.b_intra_refresh = 0; 748 h->param.i_frame_reference = X264_MIN( h->param.i_frame_reference, 6 ); 749 h->param.i_dpb_size = X264_MIN( h->param.i_dpb_size, 6 ); 750 /* Don't use I-frames, because Blu-ray treats them the same as IDR. */ 751 h->param.i_keyint_min = 1; 752 /* Due to the proliferation of broken players that don't handle dupes properly. */ 753 h->param.analyse.i_weighted_pred = X264_MIN( h->param.analyse.i_weighted_pred, X264_WEIGHTP_SIMPLE ); 754 if( h->param.b_fake_interlaced ) 755 h->param.b_pic_struct = 1; 756 } Last edited by LigH; 26th July 2013 at 13:05. |
26th July 2013, 19:15 | #3367 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,823
|
Quote:
Yeah, but the option is under the x264 video encoder configuration so I think it's reasonable to assume it only applies to x264 encoding. |
|
26th July 2013, 23:47 | #3368 | Link |
Registered User
Join Date: Jan 2009
Posts: 5
|
I've come across a problem in the recent dev builds 2357+
Using One Click Mode with a profile with the setting "Keep Input Resolution (disable Crop & Resize)" The generated Avisynth script does not include global MeGUI_darx or global MeGUI_dary This results in both the h.264 SAR being wrong and the MKV container AR being set to 3:2. The container AR is easy enough to change with MMG, but the only thing I've found to fix the h.264 AR is using a build of FFMPEG, but that introduces artifacts. The problem is not present in the stable core (2356) John |
27th July 2013, 04:50 | #3369 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,823
|
Same here. I also tried not using the keep input resolution option, but checking the anamorphic option instead, and the output still didn't have the correct aspect ratio. It seems the aspect ratio is being detected correctly when opening the video but it's not being used for encoding.
|
27th July 2013, 10:20 | #3370 | Link | |
Registered User
Join Date: Oct 2007
Posts: 385
|
Quote:
Mine looks like this: Import("path\x.avs") #deinterlace #crop #resize #denoise This doesn't change anything in the original full avs. I tried it now, original avs has TFM(order=-1).TDecimate().Spline36Resize(720,404) resulted 264/mkv is: Width : 720 pixels Height : 404 pixels Display aspect ratio : 16:9 Last edited by mini-moose; 27th July 2013 at 10:25. |
|
27th July 2013, 13:52 | #3371 | Link |
Registered User
Join Date: Nov 2009
Posts: 2,405
|
Thanks for the reports. I found the problem and have a partial fix but no tiome currently to finish and test it. It may take hours or weeks till I have that time.
EDIT: Test build http://megui.org/test/MeGUI.zip Last edited by Zathor; 27th July 2013 at 14:13. |
30th July 2013, 18:08 | #3379 | Link | |
Swallowed in the Sea
Join Date: Oct 2002
Location: Aix-en-Provence, France
Posts: 5,191
|
Quote:
Yes, Avisynth 2.6.0 should be used instead. |
|
30th July 2013, 18:55 | #3380 | Link | ||
Registered User
Join Date: Aug 2009
Posts: 463
|
Quote:
Quote:
|
||
Thread Tools | Search this Thread |
Display Modes | |
|
|