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.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 Encoder GUIs

Reply
 
Thread Tools Search this Thread Display Modes
Old 1st November 2018, 19:08   #6481  |  Link
Zetti
Registered User
 
Join Date: Dec 2015
Posts: 306
@LeMoi

x264 r2935
Zetti is offline   Reply With Quote
Old 2nd November 2018, 10:03   #6482  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
Quote:
Originally Posted by AVspace View Post
I still don't quite get though why when i leave it to unrestricted it's not determining that i don't need such high settings and adjusting on it's own. It's using all 16 ref frames of the very slow preset on stuff that i can't imagine needs that. Even if i'm encoding like a 436p DVD very low quality file.
It can't really work any other way. You've picked a speed preset that uses 16 ref frames. If you don't specify a profile/level, x264 will try to pick a level that allows 16 ref frames, but the level is also based on resolution and frame rate (and maybe other criteria).
If you specify a faster speed preset, x264 may choose a lower level if it complies with the number of ref frames for the faster speed preset (and the resolution and frame rate etc).

When you specify a level and a speed preset, the level wins, so for the very slow preset and level 4.1 (for example), you might find x264 limits the number of reference frames, and limits them more for higher resolutions. If you specify the number of ref frames in the command line (ie --ref 5), that's what'll be used regardless of the specified level or speed preset.

Quote:
As per your explanation would i then be better simply dropping to the slower preset while leaving the level unrestricted where it gives around 8-9 ref frames in the preset, or would it prudent to stick with very slow/unrestricted and then to manually lower the amount ref frames on my own to say around 8-9. Based on your description these seem like the better options than trying to do it through the levels. I just didn't want to mess around with too much stuff so i was thinking maybe levels might be the safer bet but it doesn't sound like it. I'm looking to keep as much of the image quality as i can so very slow might be preferable if i just lower the ref frame number a bit to pick up efficiency, 9 ref frames vs 16 ref frames can be a lot of time saved when i might not (i'm guessing/assuming) need all those ref frames in a lot of the encodes. If i need all those 16 ref frames on very slow as a constant within the preset then i might just consider dropping to slower, or possibly leaning more toward x265.
If you open MeGUI's x264 encoder configuration and "show advanced settings" is checked, when you select a speed preset or tuning or target playback device, MeGUI changes the advanced settings in the GUI to their new default values, so you can switch to the other tabs to see what they'll be. For the x264 defaults, it'll show 3 ref frames in the GUI. For the slow speed preset it changes to 5. The animation tuning increases the number of ref frames (amongst other things).

I don't think any settings are changed just be selecting a level, as whether they should be changed or how much they need to be changed depends on the resolution and frame rate, so it'd be x264 making the adjustments to be complaint with any specified level. MeGUI's encoder configuration has no way of knowing what the resolution or frame rate will be anyway.

So yeah, if you want to reduce the number of ref frames either pick a level and let x264 adjust it, or if you don't care about level compliance, specify a particular number of ref frames yourself.

MeGUI only adds something to the command line when it differs from the defaults for a particular speed preset or tuning (unless you select a target playback device that requires restricted settings). That means if you select the "slower" speed preset (for example) which defaults to 8 ref frames, and you want to specify (force) 8 ref frames regardless of the selected level, you'd have to manually add it to the custom command line section.

If you were to add --ref 8 to the custom command line section, the number of ref frames specified in the encoder configuration under "Frame Type" would be ignored by MeGUI (changing the number of ref frames in the GUI would do nothing) as options in the custom command line section take precedence.

The only thing x264 doesn't automatically enforce when you specify a level (as far as I know) are the level compliant VBV settings. That's why, when you select Level 4.2 (for example), MeGUI automatically adds "--vbv-bufsize 78125 --vbv-maxrate 62500" to the x264 command line.

Selecting the maximum level your playback device supports is probably a good idea. Level 4.1 (or higher) support is fairly standard these days. That way you'll have a complaint encode regardless of the speed preset. If you want to reduce the number of ref frames for a given encode, you can always specify that too.

Last edited by hello_hello; 2nd November 2018 at 10:47.
hello_hello is offline   Reply With Quote
Old 2nd November 2018, 23:50   #6483  |  Link
LouieChuckyMerry
Registered User
 
LouieChuckyMerry's Avatar
 
Join Date: Feb 2014
Posts: 355
Quote:
Originally Posted by LeMoi View Post
What is the latest x264 version compatible version MeGUI 2855, and where could I find it? I'm still using avs4x26x, and MeGUI 2855 crashed yesterday, I had to reinstall this version but I can't find a compatible version of x264 to my encodes.
Happy Friday! I still use Version 2855 because, for whatever reason (I'm not knowledgeable enough to understand exactly why ), any version after that doesn't work with my setups. If you turn off developmental server updates in MeGUI and update manually, then you can update everything except "MeGUI" and "x264" (be sure to untick "MeGUI" or you'll update from Version 2855; "x264" will try to update but you'll just get an error, so it's simpler to untick that, too). To manually update the x264 version, download the latest version (here's a good place), then rename it "x264.exe" (without the quotes) and use it to replace the current version in "Tools\x264". At least this works for me ;-) .
LouieChuckyMerry is offline   Reply With Quote
Old 3rd November 2018, 00:53   #6484  |  Link
LeMoi
Registered User
 
Join Date: Sep 2004
Location: France
Posts: 367
Thanks for the tip, i never managed to get back to 2855, every time I launch a job, it says I can't because I have a too old version of x264, and it only allows me to download latest build, not 2935.. Even if I manually replace the .exe, MeGUI doesn't recognize the version, it still thinks I have 2638 instead of 2935, I don't know how to tell him I changed the version...
LeMoi is offline   Reply With Quote
Old 3rd November 2018, 09:56   #6485  |  Link
j8ee
Registered User
 
j8ee's Avatar
 
Join Date: Aug 2002
Location: Sweden
Posts: 65
When loading one One-Click job after another continuously, MeGUi sometimes freezes up and becomes unresponsive, with all other windows - two worker windows with jobs running in parallell, and one one-click window - also frozen and unresponsive. This has happened when there is say 10 to 30 encoding jobs, which means 100-200 separate jobs in queue. One video encoding job will be running in the background, one ffmpeg and one x265 process, but when the video encoding process is finished, no new jobs in the queue are started. When that video encoding is done, I can hover the mouse over the worker and one-click windows on the taskbar, and close them one by one by the small preview window that pop up from the task bar. When all of those windows are closed, MeGui jumps into action again continuing with the queue as nothing has happened, and that could be a day after the video encoding process stopped.

Nothing of this can be seen in the log, no error messages or anything out of the ordinary at the point this happens.

I'm unsure if the freeze has happened with the one-click window only open, empty - maybe. But it has happened when pressing the queue butting trying to add another one-click job, and it has only happened when there are two worker windows/processes already up.

Using version 2888 development server.

edit: Made a bug report at sourceforge - https://sourceforge.net/p/megui/bugs/935/

Last edited by j8ee; 4th November 2018 at 19:06.
j8ee is offline   Reply With Quote
Old 3rd November 2018, 21:05   #6486  |  Link
LouieChuckyMerry
Registered User
 
LouieChuckyMerry's Avatar
 
Join Date: Feb 2014
Posts: 355
Quote:
Originally Posted by LeMoi View Post
Thanks for the tip, i never managed to get back to 2855, every time I launch a job, it says I can't because I have a too old version of x264, and it only allows me to download latest build, not 2935.. Even if I manually replace the .exe, MeGUI doesn't recognize the version, it still thinks I have 2638 instead of 2935, I don't know how to tell him I changed the version...
I don't know much, but perhaps all the playing around with your MeGUI has it confused . Have you tried a portable version of MeGUI 2855, just as a test?
LouieChuckyMerry is offline   Reply With Quote
Old 4th November 2018, 04:21   #6487  |  Link
AVspace
Registered User
 
Join Date: Oct 2018
Posts: 19
Quote:
Originally Posted by hello_hello View Post
It can't really work any other way. You've picked a speed preset that uses 16 ref frames. If you don't specify a profile/level, x264 will try to pick a level that allows 16 ref frames, but the level is also based on resolution and frame rate (and maybe other criteria).
If you specify a faster speed preset, x264 may choose a lower level if it complies with the number of ref frames for the faster speed preset (and the resolution and frame rate etc).

When you specify a level and a speed preset, the level wins, so for the very slow preset and level 4.1 (for example), you might find x264 limits the number of reference frames, and limits them more for higher resolutions. If you specify the number of ref frames in the command line (ie --ref 5), that's what'll be used regardless of the specified level or speed preset.



If you open MeGUI's x264 encoder configuration and "show advanced settings" is checked, when you select a speed preset or tuning or target playback device, MeGUI changes the advanced settings in the GUI to their new default values, so you can switch to the other tabs to see what they'll be. For the x264 defaults, it'll show 3 ref frames in the GUI. For the slow speed preset it changes to 5. The animation tuning increases the number of ref frames (amongst other things).

I don't think any settings are changed just be selecting a level, as whether they should be changed or how much they need to be changed depends on the resolution and frame rate, so it'd be x264 making the adjustments to be complaint with any specified level. MeGUI's encoder configuration has no way of knowing what the resolution or frame rate will be anyway.

So yeah, if you want to reduce the number of ref frames either pick a level and let x264 adjust it, or if you don't care about level compliance, specify a particular number of ref frames yourself.

MeGUI only adds something to the command line when it differs from the defaults for a particular speed preset or tuning (unless you select a target playback device that requires restricted settings). That means if you select the "slower" speed preset (for example) which defaults to 8 ref frames, and you want to specify (force) 8 ref frames regardless of the selected level, you'd have to manually add it to the custom command line section.

If you were to add --ref 8 to the custom command line section, the number of ref frames specified in the encoder configuration under "Frame Type" would be ignored by MeGUI (changing the number of ref frames in the GUI would do nothing) as options in the custom command line section take precedence.

The only thing x264 doesn't automatically enforce when you specify a level (as far as I know) are the level compliant VBV settings. That's why, when you select Level 4.2 (for example), MeGUI automatically adds "--vbv-bufsize 78125 --vbv-maxrate 62500" to the x264 command line.

Selecting the maximum level your playback device supports is probably a good idea. Level 4.1 (or higher) support is fairly standard these days. That way you'll have a complaint encode regardless of the speed preset. If you want to reduce the number of ref frames for a given encode, you can always specify that too.
Thanks for the help. I think i have a better understanding of it now after the replies.

The only reason i was changing it to level 4.2 was because i wanted all the benefits of very slow but relative to a lower setting basis like i don't feel like i need 16 ref frames but i might need other things very slow provides in it's preset and was attempting to manually limit the encode from going passed a certain threshold. I've seen a lot of other encode settings end up in the 4.1 and 4.2 range which is why i was focusing on that level range because that's about around the settings i'm using.

I see now that none of the various encoders automatically does this like i thought it would. I thought it automatically detected the source and adjusted settings in a different way. It's not a MeGui thing it's just the way it works.


Is it typically okay to take the very slow preset and apply it and then to manually add my own ref frames to the preset profile? Essentially what i want to do as my goal is have the benefit of the high motion estimate settings for example "multi-hexagon" subme10 and then i want to combine that with more realistic ref/bframes like 9 ref frames and 9 bframes or something like this.

Would that be a decent approach? What i want to know is if it's not a good idea to change something like this from the preset. Meaning it's usually better to change the preset rather than to change a few settings. Maybe it's at 16 ref frames for a good reason and changing it messes things up, that's what i'm trying avoid. I'm looking to take the best preset i can go with and lower just a few things like ref frames to pick up the speed efficiency to get a mix of high settings and efficiency.

Last edited by AVspace; 5th November 2018 at 01:13.
AVspace is offline   Reply With Quote
Old 4th November 2018, 15:12   #6488  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
Quote:
Originally Posted by AVspace View Post
Is it typically okay to take the very slow preset and apply it and then to manually add my own ref frames to the preset profile? Essentially what i want to do as my goal is have the benefit of the high motion estimate settings for example "multi-hexagon" subme10 and then i want to combine that with more realistic ref/bframes like 9 ref frames and 9 bframes or something like this.
Yes. I sometimes do it from the opposite perspective. ie starting with the Slow or Slower preset and then selecting slower motion estimation settings etc.

Quote:
Originally Posted by AVspace View Post
Would that be a decent approach? What i want to know is if it's not a good idea to change something like this from the preset. Meaning it's usually better to change the preset rather than to change a few settings. Maybe it's at 16 ref frames for a good reason and changing it messes things up, that's what i'm trying avoid. I'm looking to take the best preset i can go with and lower just a few things like ref frames to pick up the speed efficiency to get a mix of high settings and efficiency.
The x264 wiki suggests the point of rapidly diminishing returns is reached at around 5 ref frames.
https://en.wikibooks.org/wiki/MeGUI/x264_Settings#ref

You can check to see how many ref frames x264 actually used when you encoded with --ref 16 (if you still have MeGUI's log files), or you'll find the info under x264's "Standard Error Stream" in MeGUI's Log tab after encoding.

This is from the log of a SD encode using the Slow preset (5 ref frames) and Level 4.1 (L0 being past ref frames and L1 being future ref frames). The way I understand it, for the example below, 96.6% of P frames used 3 ref frames or less.

---[Information] [24/01/18 7:04:12 AM] x264 [info]: ref P L0: 66.8% 12.9% 13.9% 2.7% 3.2% 0.5% 0.0%
---[Information] [24/01/18 7:04:12 AM] x264 [info]: ref B L0: 92.5% 5.7% 1.3% 0.5%
---[Information] [24/01/18 7:04:12 AM] x264 [info]: ref B L1: 98.3% 1.7%

Towards the end of this page there's an explanation as to why x264 shows 7 ref frame percentages for P frames in the example above, even though the Slow speed preset only uses --ref 5.

"The last two are the virtual duplicates produced by the way x264 implements weightp. The decoder of the produced stream won't see them; they don't take DPB (decoded picture buffer) space."

-

Last edited by hello_hello; 4th November 2018 at 15:32.
hello_hello is offline   Reply With Quote
Old 5th November 2018, 00:21   #6489  |  Link
LeMoi
Registered User
 
Join Date: Sep 2004
Location: France
Posts: 367
Is it normal that with built 2888, as soon as I click on "Queue", job automatically starts? Either encode of file indexing... And I can't find anything in the settings to prevent that
LeMoi is offline   Reply With Quote
Old 5th November 2018, 01:26   #6490  |  Link
AVspace
Registered User
 
Join Date: Oct 2018
Posts: 19
Quote:
Originally Posted by hello_hello View Post
Yes. I sometimes do it from the opposite perspective. ie starting with the Slow or Slower preset and then selecting slower motion estimation settings etc.



The x264 wiki suggests the point of rapidly diminishing returns is reached at around 5 ref frames.
https://en.wikibooks.org/wiki/MeGUI/x264_Settings#ref

You can check to see how many ref frames x264 actually used when you encoded with --ref 16 (if you still have MeGUI's log files), or you'll find the info under x264's "Standard Error Stream" in MeGUI's Log tab after encoding.

This is from the log of a SD encode using the Slow preset (5 ref frames) and Level 4.1 (L0 being past ref frames and L1 being future ref frames). The way I understand it, for the example below, 96.6% of P frames used 3 ref frames or less.

---[Information] [24/01/18 7:04:12 AM] x264 [info]: ref P L0: 66.8% 12.9% 13.9% 2.7% 3.2% 0.5% 0.0%
---[Information] [24/01/18 7:04:12 AM] x264 [info]: ref B L0: 92.5% 5.7% 1.3% 0.5%
---[Information] [24/01/18 7:04:12 AM] x264 [info]: ref B L1: 98.3% 1.7%

Towards the end of this page there's an explanation as to why x264 shows 7 ref frame percentages for P frames in the example above, even though the Slow speed preset only uses --ref 5.

"The last two are the virtual duplicates produced by the way x264 implements weightp. The decoder of the produced stream won't see them; they don't take DPB (decoded picture buffer) space."

-
I don't know all the technical details behind it, all i know is when i left it at it's default setting of very slow and 16 ref frames it takes way longer than when it's less ref frames. Media info of the file says that it's using 16 ref frames and gives a 5.1 profile listing.

What you said about diminishing returns is how i understood it which is why i was thinking i don't need that high ref frames. I've never used that many ref frames before but i haven't used that high of settings either, i was usually always at the 3-6 range. I'm doing specific tasks now where i'm trying to keep the image quality of another picture and so i figure i need really high motion estimation and some of the other higher settings which is why i'm going for "very slow".

I started doing encodes changing it down to using 6 ref frames and it cut the time down by a lot and the results seem okay to me so far.

Alright, i think i finally have a basis to work from now i just needed to be sure i could change the ref frames manually from the preset without it messing something up as my last thing. I'll work from these settings with x264 and then slow preset on x265. Thanks for the help, hello_hello and LigH

Last edited by AVspace; 5th November 2018 at 01:31.
AVspace is offline   Reply With Quote
Old 5th November 2018, 08:32   #6491  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
@LeMoi: Try the "Settings" entry in the new "Workers" menu.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 7th November 2018, 09:13   #6492  |  Link
LeMoi
Registered User
 
Join Date: Sep 2004
Location: France
Posts: 367
Quote:
Originally Posted by LigH View Post
@LeMoi: Try the "Settings" entry in the new "Workers" menu.
Thanks, I didn't see that new menu
LeMoi is offline   Reply With Quote
Old 11th November 2018, 15:47   #6493  |  Link
dissory
Registered User
 
Join Date: Mar 2017
Posts: 51
@Zathor

There is a bug when transcoding DTS-HD or TrueHD audio (maybe others as well) in a mkv to another format using One-Click. It extracts the core stream and transcodes that instead of extracting and using the lossless audio stream.
dissory is offline   Reply With Quote
Old 11th November 2018, 19:02   #6494  |  Link
AOmundson
Registered User
 
Join Date: Dec 2017
Posts: 15
avs [error]: not supported pixel type: YUV420P10

Hey, I'm trying to encode from a 10-bit source, but every time I do I get this error. I haven't ever encountered this error before when encoding from 10-bit video, and am wondering if anyone has any tips on how to solve it.
AOmundson is offline   Reply With Quote
Old 11th November 2018, 19:12   #6495  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,565
Post the complete MeGUI log. What revision are you using? I think high-bitdepth support wasn't added until fairly recently with revision 2876. The high-bitdepth stuff needs avs+ (portable included in MeGUI) and filters need to support it as well.
sneaker_ger is offline   Reply With Quote
Old 11th November 2018, 21:09   #6496  |  Link
AOmundson
Registered User
 
Join Date: Dec 2017
Posts: 15
Quote:
Originally Posted by sneaker_ger View Post
Post the complete MeGUI log. What revision are you using? I think high-bitdepth support wasn't added until fairly recently with revision 2876. The high-bitdepth stuff needs avs+ (portable included in MeGUI) and filters need to support it as well.
Code:
-[Information] Log for job1 (video, Test.mkv.avs -> Test_Video.264)
--[Information] [11/11/2018 2:03:51 PM] Started handling job
--[Information] [11/11/2018 2:03:51 PM] Preprocessing
-[NoImage] global MeGUI_darx = 16
-[NoImage] global MeGUI_dary = 9
-[NoImage] LoadPlugin("C:\Program Files\MeGUI\tools\lsmash\LSMASHSource.dll")
-[NoImage] LoadPlugin("C:\Program Files\MeGUI\tools\avs\plugins\ConvertStacked.dll")
-[NoImage] LWLibavVideoSource("D:\Test.mkv.lwi", format="YUV420P10")
-[NoImage] ConvertFromDoubleWidth(bits=10)
-[NoImage] #Not doing anything because the source is progressive
-[NoImage] #crop
-[NoImage] #resize
-[NoImage] #denoise
--[Information] [11/11/2018 2:03:51 PM] AviSynth input script
--[Information] [11/11/2018 2:03:52 PM] resolution: 1920x1080
--[Information] [11/11/2018 2:03:52 PM] frame rate: 24000/1001
--[Information] [11/11/2018 2:03:52 PM] frames: 34093
--[Information] [11/11/2018 2:03:52 PM] length: 00:23:41.962
--[Information] [11/11/2018 2:03:52 PM] aspect ratio (avs): 16:9 (1.778)
--[Information] [11/11/2018 2:03:52 PM] color space: YUV420P10
--[Information] [11/11/2018 2:03:52 PM] custom command line: --aq-mode 3
--[Information] [11/11/2018 2:03:52 PM] Job command line: "C:\Program Files\MeGUI\tools\x264\x264.exe" --output-depth 10 --preset placebo --tune animation --crf 14 --deblock
0:0 --keyint 240 --bframes 8 --qpmax 69 --aq-strength 0.8 --merange 32 --me umh --psy-rd 0.90:0.10 --qpfile "D:\u1jndvvs.e1q\Test.mkv.qpf" --aq-mode 3 --sar 1:1 --frames 34093 -
output "D\u1jndvvs.e1q\Test_Video.264" "D:\u1jndvvs.e1q\Test.mkv.avs" 
--[Information] [11/11/2018 2:03:52 PM] Process started
--[Information] [11/11/2018 2:03:52 PM] Standard output stream
--[Information] [11/11/2018 2:03:52 PM] Standard error stream
---[Error] [11/11/2018 2:03:53 PM] avs [error]: not supported pixel type: YUV420P10
---[Error] [11/11/2018 2:03:53 PM] x264 [error]: could not open input file `D:\u1jndvvs.e1q\Test.mkv.avs'
--[Error] [11/11/2018 2:03:53 PM] Process exits with error: 0xFFFFFFFF (-1)
--[Information] [11/11/2018 2:03:53 PM] Job completed
I'm using a fresh version of 2876 x64 with all default plugins enabled, as I started encountering this error last night and thought perhaps a fresh download could fix it. It's possible it being the x64 version could be the issue, but considering I've had no trouble encoding 10-bit before with the x64 version I doubt it. Could it be that one of mods in the previous version broke, and it needs to be downloaded as well? Though honestly it's been such a long time since I downloaded any I've forgotten which mods I actually had installed.

Last edited by AOmundson; 11th November 2018 at 21:14.
AOmundson is offline   Reply With Quote
Old 11th November 2018, 22:30   #6497  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,565
I'm not really familiar with MeGUI x64. But I see the problem is that it's trying to let x264 open the 10 bit AviSynth script directly. That is not supported. As a workaround you can add the following line to the end of your script:
Code:
ConvertBits(16)
sneaker_ger is offline   Reply With Quote
Old 11th November 2018, 22:57   #6498  |  Link
AOmundson
Registered User
 
Join Date: Dec 2017
Posts: 15
Fixed, thanks!
AOmundson is offline   Reply With Quote
Old 12th November 2018, 13:00   #6499  |  Link
Zetti
Registered User
 
Join Date: Dec 2015
Posts: 306
FFmpeg v4.1 is released.
Zetti is offline   Reply With Quote
Old 12th November 2018, 13:53   #6500  |  Link
Betsy25
Registered User
 
Join Date: Sep 2008
Location: Holland, Belgium
Posts: 330
With every DVD I rip, Megui is always crashing upon analyzing the source for interlacing. Stable or Development version, doesn't matter. What has become of this once great tool ?
Betsy25 is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 15:12.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.