MeGUI: General Questions and Troubleshooting Thread

[mroz]

Originally Posted by mroz

[xvid thread count]

I've now set it to 12 which gives me around 90% cpu usage 1st pass & 95% 2nd pass; diminishing returns after that.

Are there any serious quality issues with a high thread number & xvid? How about stability?

Lastly, for the devs, why does Megui (when configured to auto set the thread count) request as many threads as there are cores? Any good reason?

Hmm

For the record, 4 threads does seem near optimal for a quad core. I stupidly only looked at cpu usage, not encoding rates.

It is true that cpu usage is sub optimal & that this can be increased with more threads, but this actually degrades xvid encoding performance

It seems xvid isn't able to make good use of a quad core. Shame.

[mroz]

How does Megui handle audio delay, specifically when encoding using Nero Digital AAC? Does it get encoded into the audio or only specified at the mux stage?

Aiui many decoders ignore mp4 audio delay, hence my concern. If it is a mux operation, the only alternative atm seems to be to use Belight, which will apply any delay & pregain before running the encode itself.

Edit: asking as I just queued up an encode with a delay of -100ms & observed no logging of any pre encode step (nor is the encode itself capable of handling a delay, going by the cmdline used & nero's cmdline help info).

[Doom9]

Why do you need a step if the audio decoder is able to handle delay just fine? If you load a queued audio job you'll see your delay (assuming the delay is part of the filename.. that's what megui uses to deduce audio delays)

[ACrowley]

Are the Progress Window/ Time Calculation Bugs fixed now with 0.2.6.1 1023 Build ?

- Remaining Time Value jumps around , no stable Value as like as with older Versions

- After 24h Elapsed Time restes to zero fixed

EDIT:
No, now i see its not fix

Cant be so hard to fix these Bugs ?!

[Sharktooth]

there are more important bugs to be fixed... (look here: http://sourceforge.net/tracker/?atid...12&func=browse)

[DeathAngelBR]

Megui server no workie. What's going on? I've been trying to update for hours.

edit: update werks.

Next: megui cpu usage is at 100% after loading an avs file and locks up. any ideas?

[Sharktooth]

does the avs play in MPC or WMP?

[mroz]

Originally Posted by Doom9

Why do you need a step if the audio decoder is able to handle delay just fine? If you load a queued audio job you'll see your delay (assuming the delay is part of the filename.. that's what megui uses to deduce audio delays)

[Disclaimer: I'm not trying to teach granny to suck eggs, just making sure I'm understood...]

Edit: reread your post & realised /I've/ probably misunderstood - see (*) below.

Suppose I need to introduce a negative delay on an audio track. I can either chop the front off the audio stream just before it gets encoded, or I can attach the delay information to the file.

I assume now that Megui is doing the latter?

I don't know the details of how this info is encoded - ie whether it becomes part of the stream or is stored somewhere else in the container's header, but that's not too important.

What does matter is how widely respected that information is by decoders. Can you comment on this?

mp4box allows one to configure a delay for an audio stream in an mp4 container. I assume that if Megui needed to apply a delay, it would use that mechanism?

Last time I played with that - probably a year or more ago - I found all the splitters/decoders on my test box were ignoring the delay info. In fact that migt be one of the reasons I first investigated Belight, as it happens (so maybe more than a year back).

Even if that's not a problem, what about decoders in standalones.

Also what of the other supported container formats, mkv & avi? I didn't even realise avi allowed an audio stream to have an associated delay.

Cutting/extending the stream itself just seems so much safer.

Of course it's quite possible I'm entirely wrong & my assumptions are based on outdated information & errors. Please do put me straight.

One last thought. If it isn't needed, why does Belight modify the stream itself rather than just tag on the delay info?


(*) ...Or are you actually saying that the decoder that feeds the audio encode will itself apply the delay? Doesn't that depend on what the decoder is? How is the decoder given that info - just through the filename? Sorry, very tired atm.

[Kurtnoise]

1/ with MeGUI, audio delay is applied during the preprocessing (via avisynth) before the encoding process.

2/ about delays and containers, you should try the last haali splitter.

3/ BeLight doesn't modify the stream itself. BeSweet introduces some padding as soon as you've mentioned a delay.

[mroz]

Originally Posted by Kurtnoise13

1/ with MeGUI, audio delay is applied during the preprocessing (via avisynth) before the encoding process.

I hadn't noticed avisynth being involved in audio processing within Megui.

/Runs a small test & checks log

Oh, hold on. No input file in the command line to neroAacEnc.exe & the ignorelength switch which help mentions is related to input over stdin...

So does MeGUI use an avisynth script internally to introduce delay & pipe its output straight to the encoder?

That's warmly reassuring which makes me think I need to get out more. Cheers

2/ about delays and containers, you should try the last haali splitter.

3/ BeLight doesn't modify the stream itself. BeSweet introduces some padding as soon as you've mentioned a delay.

Thanks for the info & correction. Much appreciated.

[Kurtnoise]

Originally Posted by mroz

So does MeGUI use an avisynth script internally to introduce delay & pipe its output straight to the encoder?

yes...

[LigH]

Addition to reply #238:

A user in the german doom9/Gleitz board reported a crash of the MeGUI trying to convert a video using custom audio settings, but not creating an "Audio Preset" before starting the conversion.

You should either make it inevitable to use or make a preset if you really can't make MeGUI work without one, or find at least a workaround to avoid a crash down to a stack trace. A minor reason should not result in a major failure.

[Sharktooth]

@Ligh: thanks for reporting it, but please use the MeGUI Bugtracker so we dont forget to look into that. Thanks.

[LigH]

Done.

[The_Rebel]

Newb here.

Is there a quick way to downsample the video track in MKV's in megui? (with keeping the attachments; audio/subs)

[Darkness008]

Originally Posted by foxyshadis

In that case I'd guess it's directshow that's causing the problem - check ac3filter, or ffdshow's mixer, or whatever the default decoder is. (You should be able to get to it by playing the track in MPC, and looking in play->filters).

I made a snap of the mediainfo from my file.



As I said VLC won't play it 5.1 it's just stereo here. On another file the 5.1 is OK.

[Maccara]

Aspect ratios in 0.2.6.1024, how are they determined/calculated?? And what should I use?

I noticed, that when I feed avis, for example, (captures from vhs etc) I can't select if pal/ntsc is in use etc. Didn't yet check what happens if I rip a dvd and try with that.

Also, I don't think the aspect ratios used are correct anyway (ITU), unless something more is done when feeding the info forward... (and that's why I'm asking, in case my own calculations are handled some other way I think they're)

Example:

I'm using values from http://www.iki.fi/znark/video/conversion/ which should be accurate (linked from analogue capture guide too).

PAL cropped resolution 672x560, selected ITU (4:3) megui_darx: 1709 megui_dary: 1250 (exactly 1.3672) whereas if I manually calculate using ITU PAL PAR 128/117, it should be 256/195 (1.3128).

Just to make sure, I got the un-cropped avi (720/576) and checked what the DAR is calculated by ITU (PAR 128/117, 13.5MHz, 52us, PAR 128/117) and it is 160/117 (1.36752).

Megui still gives the same value as above, before and after cropping. So is the value used by megui not DAR then? Are some additional calculations done besides what's in the avisynth script? (should be)

Besides, I checked that 1.3672, and to me, it isn't exactly any standard DAR (ITU, DVD or "generic", PAL or NTSC; closest I see is NTSC dvd at 1.3674 or 1.3673, depending on rounding).

Is it possible megui uses wrong values (rounding error? dropped the "5" from 1.36752?) or something else? Takes cropping into account, when calculating dar values (as we know, par isn't affected by cropping only)?

If megui just calculates differently or does some additional modifications to the values in avisynth script when signalling x264 about SAR which actually results in correct values used, please explain what else I need to take into account in my own calculations.

[Sharktooth]

Options->Settings->Acceptable Aspect Error (%)
set it accordingly to your prefs (as a reference i usually have it set to 1%)

[Maccara]

Originally Posted by Sharktooth

Tools->Settings->Acceptable Aspect Error (%)
set it accordingly to your prefs (as a reference i usually have it set to 1%)

Thank you, I had it in 5%, but changed to 1%. However, that does not affect anything - I still get exactly the same "wrong" values (wrong to me, but megui might be doing some additional calculations besides those values, which I'm not aware of and would like to get a clarification on).

I might add, that I'm NOT doing any resizing, only cropping.

Also, I haven't checked the end results yet (encoding will take some time, machine busy atm) but I had at least some encodes, where the sar/dar was not correct in the final file where I had trusted megui to set them correctly during encode (and only did cropping, no resize).

I'm just anal in the matter that I need to know how a software achieves its results, in case it happens incorrectly (like many capture drivers which do not adhere to any known specs).

Edit: Btw, that option was in Options->Settings in this version. Maybe you didn't notice the version I'm using. I "think" aspect used to work differently in earlier versions (I do not have the older version on-hand to check) and that is one of the reasons I'm asking this.

Edit2: Oh, just noticed I'm not the only one who thinks something may be amiss (note to self: need to start checking the bugtracker too ): http://sourceforge.net/tracker/index...12&atid=798476

[Maccara]

Ok, now I see where this is coming from...

DAR.cs:

public static readonly Dar ITU16x9 = new Dar(1.823M);
public static readonly Dar ITU4x3 = new Dar(1.3672M);
public static readonly Dar A1x1 = new Dar(1M);

First of all, ITU4x3 is wrong - not PAL DVD (1.36752) or NTSC DVD (1.36738). (and really, I think there should be separate values for pal/ntsc anyway)

Second, those are close only when DVD is the source, but I guess that's an ok assumption, as long as real DAR is chosen by the user.

Then in ToSar method:

decimal ratio = ar * (decimal)vres / (decimal)hres;
return new Sar(ratio);

And all nice explanation, that _real_ dar should be used in calculation etc, but I can't see anywhere that the _real_ dar is set after cropping etc, or that we would be assuming the source _was_ originally a DVD of 720x576/480 resolution and base our calculations on that. And then when we're preparing an encode, we simply read megui_darx&y from the avisynth script and base our calc of sar on that.

So, as it currently works, user should enter the _real_ dar (if already cropped), and if he's cropping in avisynth script creator, he should then calculate it again himself.

So, I think there really is a bug.

This is the first time I've looked at megui sources, so I'm not sure if that would be an easy fix (and what way it should be fixed in the first place), and I'm really pressed for work so I'm not sure if I could post a patch in bugtracker for that one anytime soon... Maybe it even would be better to use PAR values internally altogether (as they're more consistent) and forget about DAR? No idea how much work that would be...