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. |
2nd November 2018, 10:03 | #6482 | Link | ||
Registered User
Join Date: Mar 2011
Posts: 4,829
|
Quote:
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:
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. |
||
2nd November 2018, 23:50 | #6483 | Link | |
Registered User
Join Date: Feb 2014
Posts: 355
|
Quote:
|
|
3rd November 2018, 00:53 | #6484 | Link |
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...
|
3rd November 2018, 09:56 | #6485 | Link |
Registered User
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. |
3rd November 2018, 21:05 | #6486 | Link | |
Registered User
Join Date: Feb 2014
Posts: 355
|
Quote:
|
|
4th November 2018, 04:21 | #6487 | Link | |
Registered User
Join Date: Oct 2018
Posts: 19
|
Quote:
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. |
|
4th November 2018, 15:12 | #6488 | Link | ||
Registered User
Join Date: Mar 2011
Posts: 4,829
|
Quote:
Quote:
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. |
||
5th November 2018, 01:26 | #6490 | Link | |
Registered User
Join Date: Oct 2018
Posts: 19
|
Quote:
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. |
|
11th November 2018, 15:47 | #6493 | Link |
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. |
11th November 2018, 19:02 | #6494 | Link |
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.
|
11th November 2018, 19:12 | #6495 | Link |
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.
|
11th November 2018, 21:09 | #6496 | Link | |
Registered User
Join Date: Dec 2017
Posts: 15
|
Quote:
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 Last edited by AOmundson; 11th November 2018 at 21:14. |
|
11th November 2018, 22:30 | #6497 | Link |
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) |
Thread Tools | Search this Thread |
Display Modes | |
|
|