MeGUI: General Questions and Troubleshooting Thread

[foxyshadis]

Mewiki updated with the new secret knock you have to give, press a couple buttons, set the custom matrix to the hidden keyword, open a portal to the fifth dimension, etc...

The last of which is expanding the window from the lower-right corner to uncover it. Apparently the main window needs to enforce a minimum size somehow, I wonder if the property for that works with scalable fonts.

[Tacio]

Ok, thanks, I found it. In input window in audio options I chosen ND AAC with MP4 extension, but after I pressed AutoEncode button extension changed to m4a. Is it normal?

[mroz]

Did you check the automatic threads option in megui's settings?
OK, I've unchecked that & xvid is now using one less thread than whatever I configure it with in the xvid dialogue, which is fine.

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?

[Sharktooth]

Can not find queue button for audio encoding with 1021 version of MeGUI
Next release (0.2.6.1024) will have the fix.

[mdjaved]

I'm not sure if itz me but it seems therez a problem with the latest megui ... i got this error msg after it updated to the latest development version.

[kurt]

jap, got also an error after updating today:

http://i21.tinypic.com/2zz2lhz.png

[foxyshadis]

No point in approving the attachment, since it's the same error. :p

The job list updater didn't fire properly, you have to manually remove your old jobs, or put them elsewhere for the time being.

[kurt]

The job list updater didn't fire properly, you have to manually remove your old jobs, or put them elsewhere for the time being.
ah, thanks for the hint :)

[mdjaved]

i backed up the jobs and restarted megui and updated to 1023. After that i placed the jobs back in the same folder and restarted megui, the error still pops up. Which means if there are any jobs in the folder, it refuses to start. Can any1 fix this?

[ditche]

Can not find queue button for audio encoding with 1021 version of MeGUI
Extend the window. :)

[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 :stupid:

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=798476&group_id=156112&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]

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]

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]

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

[LigH]

Addition to reply #238 (http://forum.doom9.org/showpost.php?p=836633&postcount=238):

A user in the german doom9/Gleitz board reported a crash of the MeGUI (http://forum.gleitz.info/showthread.php?t=35710) 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 (http://sourceforge.net/tracker/index.php?func=detail&aid=1811644&group_id=156112&atid=798476).

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

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.

http://img168.imagevenue.com/loc978/th_43562_MediaInfo_122_978lo.jpg (http://img168.imagevenue.com/img.php?image=43562_MediaInfo_122_978lo.jpg)

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]

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.php?func=detail&aid=1811955&group_id=156112&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...

[ChrisW77]

Why is MeGUI's muxing, for MP4 x264 video, aac audio, sooo buggy ?

For instance, just tried this

Starting job job1 at 16:49:59
Starting preprocessing of job...
Preprocessing finished!
encoder commandline:
-add "H:\dvb-t\c4newsvideo.mp4" -add "H:\dvb-t\c4newsaudio.mp4:lang=eng" -tmp J:\dvb-t-muxed -new "J:\dvb-t-muxed\c4news.mp4"
successfully started encoding
Processing ended at 16:50:00
----------------------

Log for job job1

Error - 2 input names specified, please check usage

----------------------
End of log for job1



Starting job job1 at 16:50:43
Starting preprocessing of job...
Preprocessing finished!
encoder commandline:
-add "H:\dvb-t\c4newsvideo.mp4" -add "H:\dvb-t\c4newsaudio.mp4:lang=eng" -tmp G:\ -new "G:\c4news.mp4"
successfully started encoding
Processing ended at 16:51:02

Why did the first one keep failing with
"Error - 2 input names specified, please check usage"

What the heck kind of error is that ?
Yet, the second attempt, using the exact same files, yet this time I've written them to a smaller fat32 drive, worked fine. Why ?

And, why is it that, if I dot my filenames, it always fails ?
And, if I mux to the same drive/partition, it always fails, why ?

These bugs are really annoying, in what seems like a great program, aside from a slightly poorly designed gui.

Any other programs out there that can mux AAC and x264 into MP4 ? Is avidemux, any good ?

[mroz]

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)

Agreed, but I'm only an end user ;)

I also use Jukka Aho's info on aspect ratios, but have given up trying to convince others - I mentioned it to Kurtnoise a few times in respect of the presets in Yamb, but I obviously wasn't convincing.

/snip

But that's a separate issue to...

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.

...What seems to be a newish bug (I'm fairly sure this used to work, but icbw).

Even if you ignore any mistakes Megui makes in preset dars for dvd content, dar signalling in the avs currently doesn't seem to take into account cropping, which should be handled automatically.

As I see it, whenever the script is changed by the user or some internal function, if this could affect aspect ratio the signalling should be updated.

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

I don't know the code either, but when I first saw dar signalling I wondered why they were passing dar around; par seems to be more fundamental & isn't changed by cropping. To me sar & par seem to be the most easily manipulated base values with dar being the derived value.

[mroz]

Any other programs out there that can mux AAC and x264 into MP4 ? Is avidemux, any good ?

Yamb (http://yamb.unite-video.com/). It's yet another mp4box gui. Or you can always read up on the commandline syntax to mp4box & invoke it directly.

[mroz]

2.6.1024 with dg just updated to 1.50b6.

Not sure if this should be reported as a bug, as occassionally I find dgindex (all versions) gets the audio delay wrong & I can never be sure if this is down to a bug, a shortcoming or bad source data; also I've never found a transcoding app which doesn't sometimes make these kind of errors.

That said, with dgindex the problem is usually that it'll report 0 delay when in fact some non zero value is needed.

I've just done a transcode from an ntsc dvd & it reported a delay of -464ms. Watching the result I find a sync problem indicating there should have actually been 0 delay.

Posting here to see if this is common & therefore indicative of a bug.

[check]

For non-megui problems report to the relevant author(s), in this case neuron2.

[Kurtnoise]

I mentioned it to Kurtnoise a few times in respect of the presets in Yamb, but I obviously wasn't convincing.
really ? where did you mentioned that ? Anyway, Yamb contains only PAR presets not DAR and I certainly wouldn't add this feature in the next releases because it should be included more in the encoding step rather than in the mux one.


About delay issue, I need to test myself with some materials first before to comment this.

[Kurtnoise]

Why is MeGUI's muxing, for MP4 x264 video, aac audio, sooo buggy ?
Obviously, you didn't run the last development build...

And, why is it that, if I dot my filenames, it always fails ?
why guys would you dot your filenames ??? MP4Box cares about dots in filename. So, uses a normal way to name your file. That's the best thing you can do first...

[ChrisW77]

Obviously, you didn't run the last development build...

Well, obviously. Or so it would seem. ME's web update sees nothing, is there a development binary anywhere ?

why guys would you dot your filenames ??? MP4Box cares about dots in filename. So, uses a normal way to name your file. That's the best thing you can do first...

Looks neater, and every other program out there copes with dots, so why not mp4box ?

Channel 4 News October 12th 2007.mp4

Channel.4.News.October.12th.2007.mp4

Channel_4_News_October_12th_2007.mp4

To me, personally, the dotted name looks much neater. While the spaces (when there are many many files in a directory) looks lost, while the underscore one looks like it came from a torrent site. It's just a personal thing.
But even then, if I took out the dots, the first filename is still too long and gives me the error in my first post. Just silly.

[Maccara]

Agreed, but I'm only an end user ;)

I also use Jukka Aho's info on aspect ratios, but have given up trying to convince others - I mentioned it to Kurtnoise a few times in respect of the presets in Yamb, but I obviously wasn't convincing.


I have to admit, I haven't tried yamb myself, but I think Kurtnoise addressed that situation.

My point in this only is, that if software claims "ITU" is used, then values pertaining to ITU standards should really be used.

It is of course a completely different issue, if the source material actually followed ITU (i.e. in DVD case, correct active picture frame of 702x in case of PAL 720x576), but that is a moot point as long as user can freely choose differently, if he knows better (for example, if source material did infact use "Generic PAR").


But that's a separate issue to...


Definitely agree - and not even really relevant (I just wanted to point out, that they were not ITU values - in fact, I couldn't immediately figure out from where those values had been gotten from and that's why I think there may simply be rounding error/spelling mistake there).


Even if you ignore any mistakes Megui makes in preset dars for dvd content, dar signalling in the avs currently doesn't seem to take into account cropping, which should be handled automatically.

As I see it, whenever the script is changed by the user or some internal function, if this could affect aspect ratio the signalling should be updated.


THIS is the real bug here, and should be fixed before stable version is published.


I don't know the code either, but when I first saw dar signalling I wondered why they were passing dar around; par seems to be more fundamental & isn't changed by cropping. To me sar & par seem to be the most easily manipulated base values with dar being the derived value.


With this, I have to agree. Although, I have to admit I haven't thought of this too deeply yet (if there actually is a difference in ease of handling, if done properly in either case).

However, I think this would be a "fundamental change" in a sense that maybe this shouldn't be implemented until stable status is achieved on current codebase. Instead just fix the current signalling bug (so it gets updated on cropping) and just assume the source is un-cropped dvd (as it does now).

If I have the time to look into this a bit more, I'll start a discussion on this in the development thread pondering on the pros & cons and if it actually should be implemented like this.

And I guess, I shouldn't except others to implement something like this just because I would think it would be better, and have to offer to actually do something about it myself in that case. (well, it would be nice to give something back too, instead of just always benefiting from others' work for free :))

[mroz]

For non-megui problems report to the relevant author(s), in this case neuron2.

Sorry, should do. Any idea where best to send such reports?

Mentioned it here as I thought I recalled someone asking if the newer dg was reliable enough to be included in Megui.

[mroz]

really ? where did you mentioned that ?

Sorry, can't find it. I thought it was on these forums a year or so ago. It involved a brief exchange on a forum, I'm pretty sure; actually, it could have been by mail, just before I joined this forum.

Anyway, Yamb contains only PAR presets not DAR and I certainly wouldn't add this feature in the next releases because it should be included more in the encoding step rather than in the mux one.

Sorry again, I wasn't clear enough. I was merely referring to your choice of par presets for pal & ntsc 4:3 & 16:9. Yours differ (last time I checked) slightly from those given by Jukka Aho.

[berrinam]

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)I have done most of the AR stuff with very little documentation about the standards, and I don't remember where I got the above quoted numbers from. It looks like the ITU4x3 value should be 1.36752 but, by typo, the '5' got dropped. However, as this is indeed wrong, I've added a bug report: http://sourceforge.net/tracker/index.php?func=detail&aid=1812842&group_id=156112&atid=798476

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.For DVD sources, the ITU16x9 and ITU4x3 aspect ratios will be chosen. For other sources, square pixels are assumed, as the AVS creator isn't currently configured to read in AR signalling from other input files. This is definitely a limitation, and should be addressed in the future: http://sourceforge.net/tracker/index.php?func=detail&aid=1812844&group_id=156112&atid=798479

Then in ToSar method:

decimal ratio = ar * (decimal)vres / (decimal)hres;
return new Sar(ratio);
I'm not sure why you've quoted this; it seems correct to me.

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...
I'm not sure of terminology. By PAR you mean pixel aspect ratio? I assume so, but in MeGUI we call that SAR (Sample aspect ratio) so as to avoid confusion with Picture aspect ratio (which we call DAR, Display aspect ratio, in MeGUI).

Anyway, I see no reason why SAR is more consistent than DAR. Of course, when you know your film's resolution, they are essentially equivalent since you can convert between them. But SAR and DAR are complementary for the simple reason that when you resize, the DAR stays the same but the SAR might not, and when you crop, the SAR stays the same but the DAR might not. In this case, I do not see one as more consistent than the other, and it is not possible to forget about DAR because you need it for resizing.

However, I argue that DAR is a more intuitive and more fundamental concept than SAR. Consider that DAR refers to the shape of the video whereas SAR refers to the shape of the individual pixels. If someone with very little knowledge of video sees a film with the wrong aspect ratio, they will think, "the shape of this video is wrong" and not "the shape of the pixels is wrong" for the simple reason that they may not have heard of pixels.

Because of a number of reasons like this in MeGUI, DAR is exposed and not SAR. However, it makes little difference to almost all the code since most of the code just involves passing the information along and not actually processing it. And where it does matter, they SAR and DAR have pretty much equal standing: cropping needs SAR, resizing needs DAR, x264 uses SAR, xvid_encraw uses DAR.

Anyway, thanks for the useful post about MeGUI's AR problems.

[mroz]

ME's web update sees nothing, is there a development binary anywhere ?

Options > Settings > Extra config > Auto update > configure Servers > choose development from the drop down menu

[berrinam]

THIS is the real bug here, and should be fixed before stable version is published.Already fixed, in rev255.

[mroz]

Berrinam: I think we've taken SAR to be the apsect ratio of the display using pixel counts & PAR to be the physical aspect ratio of a single pixel (thus DAR = PAR*SAR).

Searching the web suggests the definitions of DAR & PAR are well established, but that for SAR isn't - sometimes it means PAR, as you use, & sometimes DAR/PAR.

What term do you use for DAR/PAR?

Regarding which of DAR & PAR is the more fundamental, you're of course right that there's a symmetry between them & that modifying the video by cropping/scaling will each affect one of those quantities.

It's also not terribly important which you treat as the derived quantity as long as the arithmetic is precise, however I'd still be inclined to go with DAR as the derived value as ime (quite limited), one tends to work with a small set of possible PARS all of which can be represented precisely as the ratio of two four digit integers. I think in practice if you wish to store DAR precisely you'd need more. Not important, just a personal choice.

[mroz]

Obviously, you didn't run the last development build...


why guys would you dot your filenames ??? MP4Box cares about dots in filename. So, uses a normal way to name your file. That's the best thing you can do first...

Ah, thanks, that explains a few errors I had recently. I ended up muxing from the command line which worked, but no doubt only as I probably renamed the files in
between.

I tend to process files using the names the sources have, until I come to archive the results, so sometimes encounter naming schemes I'd not personally choose.

Out of interest, why does mp4box care? What does it do with the names? OTTOMH I can't see a requirement that would necessarily mean it couldn't cleanly handle odd filenames. This smells like a shortcoming verging on a bug.

[ChrisW77]

Options > Settings > Extra config > Auto update > configure Servers > choose development from the drop down menu

Thanks, mroz

[Maccara]

Thanks, berrinam, for addressing this.


For DVD sources, the ITU16x9 and ITU4x3 aspect ratios will be chosen. For other sources, square pixels are assumed, as the AVS creator isn't currently configured to read in AR signalling from other input files. This is definitely a limitation, and should be addressed in the future: http://sourceforge.net/tracker/index.php?func=detail&aid=1812844&group_id=156112&atid=798479


This is fair enough - DVD usually is a good assumption.


I'm not sure why you've quoted this; it seems correct to me.


Sorry, I probably didn't address this well. The code is correct, but the issue is when we use that, we do not have _real_ ar (f.e. after cropping), which is fundamental for that formula to give correct results.

Sorry, I'm assuming here a little because I do not see DAR changing after cropping (as it should), but I haven't checked this properly from the code yet.

(Edit: This seems fixed in SVN already, sorry, didn't notice your other message until now)


I'm not sure of terminology. By PAR you mean pixel aspect ratio? I assume so, but in MeGUI we call that SAR (Sample aspect ratio) so as to avoid confusion with Picture aspect ratio (which we call DAR, Display aspect ratio, in MeGUI).


Yes, by PAR I mean pixel aspect ratio and by DAR display aspect ratio. With this definition I have understood SAR is equivalent to PAR, no? (hopefully _I_ haven't made a fundamental error here ;))


Anyway, I see no reason why SAR is more consistent than DAR. Of course, when you know your film's resolution, they are essentially equivalent since you can convert between them. But SAR and DAR are complementary for the simple reason that when you resize, the DAR stays the same but the SAR might not, and when you crop, the SAR stays the same but the DAR might not. In this case, I do not see one as more consistent than the other, and it is not possible to forget about DAR because you need it for resizing.


It all depends, what information we have available internally. Admittedly, I haven't looked at the code enough yet to have a clear opinion if indeed using par/sar would be simpler than dar. Of course assuming any of these are used correctly in the first place. :)


However, I argue that DAR is a more intuitive and more fundamental concept than SAR. Consider that DAR refers to the shape of the video whereas SAR refers to the shape of the individual pixels. If someone with very little knowledge of video sees a film with the wrong aspect ratio, they will think, "the shape of this video is wrong" and not "the shape of the pixels is wrong" for the simple reason that they may not have heard of pixels.


I think here our points of view will differ a little. Definitely, for the user, DAR is more intuitive, unless they've spent enough time pondering about the whole matter.

To me, PAR is "everything" - it will define everything else. Once I know what the PAR of the source is, I can derive every other value simply from that fact. This, I have to admit, undoubtedly will somewhat cloud my view in this.

However, I might have been thinking a bit ahead of myself here (with current limitations intact). For example, if I feed an already cropped (not resized) AVI to megui, DAR is defined by the resolution & PAR. This, of course, is not very relevant, if we always assume we get full-resolution sources only and can rely on DAR - or if we can get correct DAR/PAR automatically from the source we can derive correct values anyway.

(I may need to revise above paragraph, as it maybe didn't come out very clear - English is not my native language.)


Because of a number of reasons like this in MeGUI, DAR is exposed and not SAR. However, it makes little difference to almost all the code since most of the code just involves passing the information along and not actually processing it. And where it does matter, they SAR and DAR have pretty much equal standing: cropping needs SAR, resizing needs DAR, x264 uses SAR, xvid_encraw uses DAR.


Until I have time to look more deeply in the code, I have no choice but to agree here. :) At least I think the reasoning behind this is ok - just have to figure out if it is also implemented correctly (or if some bugs still remain). ;)


Anyway, thanks for the useful post about MeGUI's AR problems.

Thank you very much for clarifying the thinking behind this. At least makes me at more ease, knowing there shouldn't be any fundamental flaw with the whole processing and should work out fine for the purpose once the final bugs are squashed.

[Maccara]

Already fixed, in rev255.

Sorry, didn't notice this. Indeed, in SVN it seems fixed. Have to test it at some point.

[trooper11]

First of all, thanks for putting together this great program, Im going to be using it quite a bit, so its a huge help.


My system is running Vista Ultimate and I have the following versions of apps:

MeGui 0.2.5.1007 (latest stable version I could find)
AviSynth 2.5.7

Now, the problem Im having is when I go to the AviSynth Script Creator. Whenever I try to add a video source (Ive tried .mkv and .avi files) MeGui crashes (there is no particular error message, just that it stops responding and Vista has to shut it down)


Is there anything else I need to install in order for this to work, or is this a bug with Vista? I even tried installing the in development MeGui version 0.2.6.1024 but I get the same crash.

Any help would be appreciated.