MeGUI: bug reports and feature requests

[Zathor]

Just tell me which filter is better and I will change. And yes, it has to support the avs+ color spaces.

[sneaker_ger]

I'm surprised to read that as xy-vsfilter is the default renderer Aegisub uses. (libass is optional)
MeGUI is shipping pinterf's version, right? I don't think it has any less features than the one in Aegisub.

If there's a problem they should upload a sample. Maybe there is some unknown regression. (Or maybe just user error.)

[Zathor]

MeGUI is shipping pinterf's version, right? I don't think it has any less features than the one in Aegisub.
For Vista+, yes. Not for XP as it does not work there.

[hello_hello]

For Vista+, yes. Not for XP as it does not work there.

It does a bit. :)

For some reason MPC-HC has no trouble opening scripts with pinterf's vsfilter, or when pinterf's version is in the auto-loading folder, and the subtitles display as expected, but not so much for MeGUI or AvsPmod. I couldn't even begin to speculate why.

Zathor,

sorry I must have missed your earlier post, but to play with the new and improved Chapter Creator, should I download the test version of MeGUI you linked to in your post, or the current version on the development server?

Thanks.

[Zathor]

sorry I must have missed your earlier post, but to play with the new and improved Chapter Creator, should I download the test version of MeGUI you linked to in your post, or the current version on the development server?
The test link, please. The Chapter Creator stuff has not been merged yet and the test build includes some work in progress stuff. It will always be updated when the development build will be updated.

[hello_hello]

Zathor,

The Input/Output chapter timings displaying together in the GUI is nice addition, although as someone who's never satisfied, I now crave an additional column displaying the corresponding qp file keyframes too. :)

EDIT2: new version online. fpsin cannot be changed anymore if the input file has fps information.

I've done an about-face and my current position on locking the input/output is to not do either. :)

Regardless of the input type, when the input/output fps are the same, the chapter input/output timings should always remain unchanged, IMHO.
There's no reason for the input fps not to default to the fps of the input file, and the output fps could default to the frame rate of a preview when it's opened. The input/output fps should effectively be a numerator and denominator though. If the wrong frame rates are specified, I'd classify it as user error.

A preview script has a fixed number of frames and a specific frame rate and duration. The only sane assumption is neither will change, so you'd be opening chapters from the source to adjust the timings to match the script output duration, and selecting the original frame rate as input fps and the script frame rate as the output fps should take care of that. The keyframe numbers would be based on the input fps.

If the total frame count has changed compared to the source, when applying IVTC to an NTSC DVD for example, the preview frame rate would still be the output frame rate, but the input fps must be 23.976 even if the input IFO insists on 29.970fps.
If the input/output fps are both 23.976, the chapter timings won't change. The keyframe numbers would be calculated based on a 23.976 frame rate.

Lastly, the total frame count and duration for the script output could both be different to the source. Applying IVTC to an NTSC DVD and speeding it up to 25fps, for example. The input fps needs to be 23.976 no matter what the IFO says, and the output would be 25fps. The chapter timings would be adjusted according to the change in duration, and once again the corresponding keyframes numbers are calculated according to the 23.976 input fps.

So now I've thought about it again, I probably over-thought it a little before. Two rules should cover the common sense scenarios, with or without a preview.

Rule 1: If the input/output fps are the same, the chapter timings don't change, even if they don't match the source/output frame rate. The keyframe numbers are based on the input fps.

Rule 2: If the input/output fps are different, they become the numerator and denominator for chapter timings and stretch them accordingly, but they don't "stretch" the keyframe numbers. They're still based solely on the input fps.

Unless I've under-thought it this time, I think that covers it.

Cheers.

[LigH]

Regarding subtitles with Asian fonts in the VideoHelp thread:

Apparently there was an old MeGUI version with an old VSfilter version... :o

[imsrk48]

#bug
megui encoding is slowing when i used image2ass created .ass subs

please fix this problem

[Glarioo]

Cannot unselect/select "Starts new jobs in queue immediatly" no more ...16530
If I use One Click Encoder, then click on Queue, MeGUI immediately starts with Extracting Tracks.

[Zathor]

Please check "Workers\Settings" and disable it there

[imsrk48]

?????#bug
megui encoding is slowing when i used image2ass created .ass subs

please fix this problem

[Zathor]

?????

To match the number of your ? as your problem report is a bit... short:

1. What do you mean with "slowing"?
2. Have you tested it outside of MeGUI with the command line tools directly?
3. Have you tested it outside of MeGUI with other tools?
4. Do you have uploaded the MeGUI log?
5. Do you have uploaded sample files to reproduce it?

[Zetti]

MKVToolNix v28.0.0 is released.

[Glarioo]

Please check "Workers\Settings" and disable it there

:thanks:

[Zetti]

MKVToolNix v28.1.0 is released.

[Zathor]

MKVToolNix v28.1.0 is released.

Thanks, uploaded

[imsrk48]

Latest MeGui missing Contents Adding in Queue for Start Later.

Please Add That Option Back.

[Zetti]

MKVToolNix v28.2.0 is released.

[LigH]

I don't know what to think of this new URL: https://mkvtoolnix.download/ – okay, this TLD is valid now. I'll have to get used to that fact. :o

[Zathor]

Latest MeGui missing Contents Adding in Queue for Start Later.

Please Add That Option Back.

These options have been moved to Workers\Settings

[mt_video]

I guess the denoise filter in megui for minimal noise (Undot) and medium noise (FluxSmooth) are not usable for 10Bit color deep. I get color errors if I use them on 10Bit videos. I tested on 2 machines.
Would it be possible to replace the denoise filters with more versatile one?

Thanks for any effort.

[imsrk48]

thanksThese options have been moved to Workers\Settings

[AVspace]

I've been using MeGui more lately. (Preference: development mode)

One area i'm finding a little confusing is when it comes to the levels.

What i thought would happen is if i chose unrestricted/auto for the level that MeGUI would analyze the source and determine on it's own a setting that closely follows the source material. However, what seems to be happening is i'm always ending up with settings that equal to around the 5.1 level range based around a very slow setting no matter my source.

My question becomes do i always need these specific settings? Am i always going to benefit from having 16 ref frames? When prioritizing efficiency in theory could i choose a specific level range manually to sort of guide more of reasonable goal. Like if i'm working with source content that fits more around the 3.1-4.2 range is it safe to then manually select 4.2 rather than unrestricted? Am i going to see noticeable quality loss in doing this?

I'm wondering if using unrestricted in most scenarios is going overboard in the settings to what i would realistically need when prioritizing efficiency. The main noticeable change when switching from unrestricted appears to be lowering reference frames and changing max bitrate. With the lower profile my performance is increased by a lot and so when prioritizing efficiency above all else on paper and in theory it seems to be good approach but i'm not sure. I've looked at the wikipedia page showing the different levels/i've searched for information about it but i haven't been able to track down an answer to this specific question.

Here's an example when using a 4.2 profile rather than unrestricted with a very slow preset/High10. This encode took about 2 and a half hours. When set to unrestricted it was estimated to take closer to 4 hours. In terms of efficiency... a pretty big deal.

cabac=1 / ref=4 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=24 / lookahead_threads=4 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=23.1 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=62500 / vbv_bufsize=78125 / crf_max=0.0 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00

Is there anything here big that i'm losing that i would gain by using unrestricted other than higher ref frames? My goal being the prioritizing of efficiency and getting the most out of the "very slow" preset settings that i can in the process.

[LigH]

The value in the Profile@Level attribute is only important if you care about playback compatibility for devices which have a limited decoding speed or a limited reading speed from slow media. Playback on a fast PC with a powerful CPU, a quick harddisk, and a lot of RAM won't care much about level values. But a consumer player or even a mobile device has its limits, so you need to restrict bitrate distribution and encoding complexity to ensure that the result will play on these devices. You may need to know which Profile@Level a specific device is compatible to before you encode video for it.

If you don't restrict it, the encoder will guess probable values from the video resolution, frame rate, and other attributes of the encoding option set.

[AVspace]

The value in the Profile@Level attribute is only important if you care about playback compatibility for devices which have a limited decoding speed or a limited reading speed from slow media. Playback on a fast PC with a powerful CPU, a quick harddisk, and a lot of RAM won't care much about level values. But a consumer player or even a mobile device has its limits, so you need to restrict bitrate distribution and encoding complexity to ensure that the result will play on these devices. You may need to know which Profile@Level a specific device is compatible to before you encode video for it.

I get that part of it where levels are usually relevant to compatibility. I don't require any sort of compatibility though. I'm more concerned with efficiency.

The problem being when i leave the level on unrestricted it's always giving me result settings equal to that of in the 5.1 range which i'm theorizing might be inefficient to my goals. When manually selecting a level it does seem to affect the settings and performance as i described.

I'm only using the levels as a reference guide of sorts for the settings. Basically when manually selecting a level i'm wondering if i'm able to then guide the settings to a more efficient place than when it's left unrestricted because it doesn't seem to be doing that on it's own. Would i always need the full ref frames that unrestricted might give me despite the source for example/if the source has settings in the 3.1 profile range as another example and unrestricted is giving me result settings far beyond that.


If you don't restrict it, the encoder will guess probable values from the video resolution, frame rate, and other attributes of the encoding option set.

That's what i thought/expected but it doesn't appear to be doing this for whatever reason. Maybe because i'm using "High10" it's giving me higher settings i don't know. I can't see how i always need settings in the 5.1 level range when i work mostly with source material in the 3.1-4.1 range and below. On paper it appears quite inefficient the settings i'm being given within unrestricted.

[LigH]

Don't be alarmed too much. If you want to play it on a PC only, leave it unrestricted. The encoder just summarizes that Level 5.1 was sufficient for your video resolution, frame rate, estimated bit rate range, and selected complexity (e.g. speed "preset"). Surpassing Level 5.1 would require a much larger bit rate or insane complexity. BTW, preset "placebo" is not the "most efficient", rather a waste of time and energy. And to "need" all the reference frames you can get, you seem to have irregular video material, e.g. cartoons (learn about the tunings here, e.g. "tune animation").

[AVspace]

Don't be alarmed too much. If you want to play it on a PC only, leave it unrestricted. The encoder just summarizes that Level 5.1 was sufficient for your video resolution, frame rate, estimated bit rate range, and selected complexity (e.g. speed "preset"). Surpassing Level 5.1 would require a much larger bit rate or insane complexity. BTW, preset "placebo" is not the "most efficient", rather a waste of time and energy. And to "need" all the reference frames you can get, you seem to have irregular video material, e.g. cartoons (learn about the tunings here, e.g. "tune animation").

Again my concern isn't compatibility or anything like that.

My concern is when i manually select 4.2 level that my encode takes 2 and a half hours and when it's unrestricted it takes closer to 4 and half hours.

My theory being that when left unrestricted it's giving me too high settings (mainly in very high ref frames) to be efficient relative to my source material and goals leading me to the question is it then safe for me to manually restrict it to be theoretically more efficient without losing much in the quality area of things.

I typically use "very slow" only rarely use placebo when i'm okay with with long encode which is much faster when i manually choose the level. I'm using source material like say for example i ripped a DVD/Bluray movie and/or series episodes a long time ago with a CRF of like 16-18 and it already has a settings profile of like 3.1 to 4.1 and i'm now redoing the file with a lesser CRF in the 21-23 range. That's the type of source material i'm using. I'm not an expert but i wouldn't think i need settings that equate to a 5.1 level for this. When i manually select 4.2 the result seems pretty decent to my eyes but i can't be sure if if in doing so i'm losing something valuable within the process which is why i'd prefer unrestricted did this but it isn't, leading me to the question and/or potential problem at hand.

[LigH]

Of course: If you pre-select a lower level, then the encoder restricts itself to the limits of this level. This often means lower encoding complexity, ensuring less decoding efforts for weak decoder chips. This result will not be encoded as efficiently as an unrestricted one. The encoder uses e.g. a smaller range to look for similarities usable to spare bitrate and decrease quality loss. Still, the CRF method tries to guarantee an overall quality loss below a specific threshold (Constant Rate Factor), and that may mean using more bitrate when using less efforts to reduce it.

CRF 18 is usually "visually transparent" for most people, and CRF 21 will probably have "little but still not very annoying loss". Between unlimited and lower levels, the kind of loss may look different, but the overall amount will be similar (based on the rate factor calculation), despite a different resulting bitrate (an unrestricted encoder will search with more efforts to restrict the loss with less bitrate, a restricted encoder will give up earlier and invest more bitrate to achieve it).

[AVspace]

Of course: If you pre-select a lower level, then the encoder restricts itself to the limits of this level. This often means lower encoding complexity, ensuring less decoding efforts for weak decoder chips. This result will not be encoded as efficiently as an unrestricted one. The encoder uses e.g. a smaller range to look for similarities usable to spare bitrate and decrease quality loss. Still, the CRF method tries to guarantee an overall quality loss below a specific threshold (Constant Rate Factor), and that may mean using more bitrate when using less efforts to reduce it.

CRF 18 is usually "visually transparent" for most people, and CRF 21 will probably have "little but still not very annoying loss". Between unlimited and lower levels, the kind of loss may look different, but the overall amount will be similar (based on the rate factor calculation), despite a different resulting bitrate (an unrestricted encoder will search with more efforts to restrict the loss with less bitrate, a restricted encoder will give up earlier and invest more bitrate to achieve it).

Thanks for explaining.

I'm okay with some quality loss and i'm prioritizing speed and size efficiency for a sacrifice in quality. I use madvr/lavfilters at a fairly high setting which in my view makes up for the quality degradation within the encode. First priority for me needs to be speed/size efficiency. I find that in the 21-23 range the quality loss degradation is an acceptable result. I've done quite a bit of testing on what's acceptable for me. For example episodes in this setting will typically leave me with about 350-550mb for a 720p 43min episode which is what i'm looking for as a target result and it looks good enough to my eyes especially when madvr is applied.

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.

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.

[LeMoi]

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.

[Zetti]

@LeMoi

x264 r2935

[hello_hello]

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.

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.

[LouieChuckyMerry]

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 :o ), 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 (https://www.videohelp.com/software/x264-Encoder)), 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 ;-) .

[LeMoi]

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...

[j8ee]

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/

[LouieChuckyMerry]

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 :rolleyes: . Have you tried a portable version of MeGUI 2855, just as a test?

[AVspace]

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.

[hello_hello]

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.

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.

--- [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 (https://en.wikibooks.org/wiki/MeGUI/x264_Settings/x264_Stats_Output) 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.

[I]"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."

-

[LeMoi]

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

[AVspace]

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.

--- [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 (https://en.wikibooks.org/wiki/MeGUI/x264_Settings/x264_Stats_Output) 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.

[I]"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

[LigH]

@LeMoi: Try the "Settings" entry in the new "Workers" menu.

[LeMoi]

@LeMoi: Try the "Settings" entry in the new "Workers" menu.

Thanks, I didn't see that new menu :)

[dissory]

@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.

[AOmundson]

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.

[sneaker_ger]

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.

[AOmundson]

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.

-[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.

[sneaker_ger]

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:
ConvertBits(16)

[AOmundson]

Fixed, thanks!

[Zetti]

FFmpeg v4.1 is released.

[Betsy25]

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 ?:scared: