MeGUI: bug reports and feature requests

[Zathor]

2255 [AVS Script Creator] resize is enabled by default in the profiles (only for new profiles)
[AVS Script Creator] suggest resolution is automatically pre-selected when doing a resize
[AVS Script Creator] DAR changes also triggers a recalc of the "Aspect Ratio Error"
[AVS Script Creator] avoid upsizing (if disallowed) when "Clever (TM) anamorphic encoding" is used
[AVS Script Creator] some minor cosmetics / changes
2254 [Update] fixed a crash if the proxy has been enabled without server address

[hello_hello]

When doing a non-anamorphic encode the target SAR is 1:1 (square pixel). Therefore the input video must be converted also to SAR 1:1 to get the aspect ratio error:
720x576 with an aspect ratio of 4:3 has a SAR of 16/15 which results in 768x576 in SAR 1:1. Therefore you have an slight error with 640x480.

Maybe I'm just being dense, unless there's rounding involved when doing the math which is causing a slight aspect error to be displayed, but even so 768x576 and 640x480 are both exactly 4:3.

(576/768)*640=480 or
(720/576)*(16/15)*480 = 640

However you do it, it comes out exact. StaxRip and the Yoda Resize Calculator both agree. MeGUI has always seemed to give slightly different results to other programs. Generally only by a couple of tenths of a percent I think, but I'm sure it always has. Many times I've opened a "strict" anamorphic encode and compared it to the original DVD and thought the aspect ratio was off by a pixel or two. I'd always assumed it's the way MPC-HC resizes, but now.....

There's another little oddity in the "trust what MeGUI is telling me" department. It seems to happen regularly when opening video containing square pixels (I haven't played with anything else much yet). For example I just opened a 640x480 AVI and enabled resizing but left it on 640x480. MeGUI displays a slight aspect error (it's only around 0.16% but it's there). The only way to correct it is to manually select the input aspect ratio (1.333) and then adjust the resizing or cropping. Once you return the the cropping back to zero or the resizing back to 640x480, MeGUI will then display a zero aspect error as it should.

I think maybe there's too much rounding happening when calculating the input aspect ratio although I'm not sure how it works. For me, opening a 704x384 AVI displays an input aspect ratio of 1.833, which is correct, but when enabling resizing it displays a 0.142% aspect error at 704x384. Changing the input display aspect ratio to 1.832 (which unless I'm going mad MeGUI actually did itself once) displays the same aspect error at 704x384. With an input aspect ratio of 1.834 the aspect error changes to 0%, but the problem is that's not the input aspect ratio MeGUI chooses when opening the file.
Once again too, changing the input aspect ratio has no effect on the aspect error being displayed until cropping or resizing has been adjusted.

Cheers.

Edit: I just saw your previous post. I see input aspect ratio changes now cause the aspect error to be recalculated.

[Zathor]

Maybe I'm just being dense, unless there's rounding involved when doing the math which is causing a slight aspect error to be displayed, but even so 768x576 and 640x480 are both exactly 4:3.
Yes, there was a rounding problem which resulted in 767x576 causing the error. If will upload a fix in the next minutes.


Many times I've opened a "strict" anamorphic encode and compared it to the original DVD and thought the aspect ratio was off by a pixel or two. I'd always assumed it's the way MPC-HC resizes, but now.....
This aspect error calc is completely new an has only the SAR calculation in common with the internal functions for anamorphic encodings. Of course they may be wrong as well - but in that case they are wrong for years. Nevertheless when you find a reproducable problem in that part I will have a look as well.

Please try 2256 and let me now if everything is fine.

[Overdrive80]

How its possible?? http://s9.postimage.org/j7xwecnkb/Captura.jpg (http://postimage.org/image/j7xwecnkb/)

Yoda calc and me, obtain the same result than is very different to showed by megui.

EDIT: Ok http://forum.doom9.org/showthread.php?t=22497

[Zathor]

MeGUI calculates it in this way:
AR Error = 1-((Input Width*Output Height)/(Output Width*Input Height)) (which is the same as in http://forum.doom9.org/showthread.php?p=130085#post130085)
Which is in this case:
AR Error = 1-((714*480)/(704*480))=1-(714/704)=-0,014204545454545=-1,4204545454545%

You and Yoda are calculating it:
AR Error = 1-((704*480)/(714*480))=1-(704/714)=0,0140056022408964=1,40056022408964%

Which one is correct?

You can say (with simplified values) that 100 is 33% larger than 75 - and 75 is 25% smaller than 100. So both are showing a correct aspect ratio error but the point of view is different. Staxrip for example is using the same as MeGUI. Which is the most common point of view? I can change it if required.

[Shevek]

Hi Zathor,

Here is the patch to use system proxy if a username is not supplied:

http://pastebin.com/yaEMEcUc

I have tested this here at work this morning and it works

Of course this may require a stable build release otherwise those who rely on it won't be able to get the revision which fixes it :D

[Zathor]

Thanks - does this also work when using a proxy without user name / password? Or do I need to include a new setting if no credentials, specified credentials or default credentials should be used?

[Shevek]

Thanks - does this also work when using a proxy without user name / password?

Ah, I'm not sure.

Perhaps we should have an additional checkbox "Use System Proxy"

Actually, thinking about it, the system credentials include the URI of the proxy so it needs to work differently anyway.

Should be:

Use Proxy?:-

Yes: - Use System Proxy?:-

Yes:- use CredentialCache.DefaultCredentials

No: prompt for url/port/uid/pwd

How easy is it to add a new flag to settings?

EDIT: I've found the MeGUISettings class - I'll have a play

[Shevek]

Is the Sourceforge repo not up to date for read only checkouts?

I am only seeing up to 2232 on 9th Dec and there have been many more commits since then...

[Zathor]

Perhaps we should have an additional checkbox "Use System Proxy"
Maybe a combobox with all the 4 settings (no proxy, system proxy, proxy with and without user/pwd)

But isn't there a way to remove this whole part in the settings and use the system proxy (= IE proxy) setting all the time?

[Zathor]

Is the Sourceforge repo not up to date for read only checkouts?

I am only seeing up to 2232 on 9th Dec and there have been many more commits since then...
Use https://megui.svn.sourceforge.net/svnroot/megui for gthe checkout. There has been a move to a new repository which I have missed.

[Shevek]

Maybe a combobox with all the 4 settings (no proxy, system proxy, proxy with and without user/pwd)

Good idea

But isn't there a way to remove this whole part in the settings and use the system proxy (= IE proxy) setting all the time?

Hmm, yes that's true. It's a .Net application so it will always have access to the IE settings, as both Chrome and Firefox do. I'll do some more testing on my work and home PCs and ensure that this will work in both situations.

Use https://megui.svn.sourceforge.net/svnroot/megui for gthe checkout. There has been a move to a new repository which I have missed.

Great, I now have the latest code, tx!

[Zathor]

Great, I now have the latest code, tx!
I have switched my productive repositories. From now on all my commits are in svn://svn.code.sf.net/p/megui/code

[Shevek]

Hi Zathor,

It will need to be the multiple options as there could be some users out there who use proxy servers which require a separate log in from their system account (i.e. windows clients on a network that uses a unix/linux proxy server)

Proposed solution:

Replace global setting "usehttpproxy" with an enum setting "HttpProxyMode":
public enum ProxyMode { None = 0, SystemProxy = 1, CustomProxy = 2, CustomProxyWithLogin = 3 }

On Settings form remove the checkbox and replace with drop down with options from the enum

None, SystemProxy = address/port/uid/pswd disabled
CustomProxy = address,port enabled, uid/pswd disabled
CustomProxyWithLogin = address/port/uid/pswd enabled

Logic in UpdateCacher.cs and UpdateWindow.cs updated to build proxy settings based on HttpProxyMode

How does that sound? I'll get on with coding this and provide a patch.

Let me know if you want anything tweaked.

[Zathor]

Sounds good. Looking forward to your patch!

[Shevek]

Having problems opening the Settings form :angry:

Could not find type 'MeGUI.core.gui.TargetSizeSCBox'. Please make sure that the assembly that contains this type is referenced. If this type is a part of your development project, make sure that the project has been successfully built using settings for your current platform or Any CPU.

Have you seen similar?

I'm using VS2010 on Windows 7 x64 (both fully patched)

[Zathor]

Switch to the x86 platform in VS. This happens also for me when x64 is enabled (and I do not know why).

[Shevek]

Ah, that's fixed it :D

[Overdrive80]

You can say (with simplified values) that 100 is 33% larger than 75 - and 75 is 25% smaller than 100. So both are showing a correct aspect ratio error but the point of view is different. Staxrip for example is using the same as MeGUI. Which is the most common point of view? I can change it if required.

Yeah, I noticed after for this reason, I edited the post with the link. Really I think that you method is more proper, only I want know that happens it.

Thanks

[Shevek]

Hi Zathor,

Here is the patch:

http://pastebin.com/BW9dmF9k

It should be applied in the trunk folder

It includes a new helper class core/util/HttpProxy.cs as the proxy is used in both core/gui/UpdateCacher.cs and core/gui/UpdateWindow.cs

[tebasuna51]

MeGUI calculates it in this way:
AR Error = 1-((Input Width*Output Height)/(Output Width*Input Height)) (which is the same as in http://forum.doom9.org/showthread.php?p=130085#post130085)
Which is in this case:
AR Error = 1-((714*480)/(704*480))=1-(714/704)=-0,014204545454545=-1,4204545454545%

You and Yoda are calculating it:
AR Error = 1-((704*480)/(714*480))=1-(704/714)=0,0140056022408964=1,40056022408964%

Which one is correct?
None, a few of maths:

A relative error is = Error/Exact_value

Or
(Approximated_value - Exact_value) / Exact_value = (Approximated_value / Exact_value) - 1

Here the AR Exact_value is 714/480 and the Approximated_value is 704/480 then

AR relative error = (704/714) - 1= -1,40056022408964%

1,40% less (-) than Exact_value.

EDIT: Suggested formula:
AR Error = ((Output Width*Input Height)/(Input Width*Output Height)) - 1

[bamsebo]

I have a problem with the latest release 2237. Queue processing seems to have changed. Normally I will queue files ready for indexing but process them one at a time by right clicking and "Send to Temporary Worker" Normally this will process only that job. With the latest, when doing that it seems to work as if I had clicked the "start" button and wants to process all other jobs in the queue.

Is there a way round that or will the old method return in a future release?

BTW its a great suite of programs, been using it for a while now, keep up the good work!

[Overdrive80]

None, a few of maths:

A relative error is = Error/Exact_value

Or
(Approximated_value - Exact_value) / Exact_value = (Approximated_value / Exact_value) - 1

Here the AR Exact_value is 714/480 and the Approximated_value is 704/480 then

AR relative error = (704/714) - 1= -1,40056022408964%

1,40% less (-) than Exact_value.

EDIT: Suggested formula:
AR Error = ((Output Width*Input Height)/(Input Width*Output Height)) - 1

Ok. I understand than:

Absolute_error = Approximated_value (Resize) - Exact_value (Crop)

Ok, then my algorthym was wrong by the order of the summands.

I agree with Tebasuna51, my mistake.

[Zathor]

Thanks, Tebasuna51 and Overdrive80. I changed the calculation - hopefully the last time ;)

Here is the patch:
http://pastebin.com/BW9dmF9k
Thank you very much!

I have a problem with the latest release 2237. Queue processing seems to have changed. Normally I will queue files ready for indexing but process them one at a time by right clicking and "Send to Temporary Worker" Normally this will process only that job. With the latest, when doing that it seems to work as if I had clicked the "start" button and wants to process all other jobs in the queue.
The "Temporary Worker" handling has once again changed in the latest development builds. Either switch to the development update server or wait for the next stable build.

[bamsebo]

The "Temporary Worker" handling has once again changed in the latest development builds. Either switch to the development update server or wait for the next stable build.

many thanks for that, its just inconvenient because of the way I work :) I'll wait for the next stable build! Barry

[invy]

Zathor: could you please respond to my previous post, please? d:

Also for whomever is/are the talented coding folks here.. I would like to request there be a way in OneClick mode so that it will automatically select the correct OneClick profile, based on the filename (partial match) of the file you selected, and add it to the queue.

So, it would go something like this:

1. First, obviously you would need to setup each string you want to match. Let's say you type in, 'banana', and next to it you select the OneClick profile it would use. We'll call it 'banana', too. Click a button to confirm and add it. (MeGUI would save this information to a settings file)

2. Next, the actual auto-loading in action! You would select a file, and drag it over to the auto load window. I drag over a file named, "AdventuresofBananaS01E05.mpg" (multiple file drag or a folder load would be convenient here).

3. It would acknowledge that you dropped a file in the window, and whether or it found a matching OC profile to use. Something like, "Found a match! Using 'banana' profile for 'AdventuresofBananaS01E05.mpg'..... Done!"

4. It will log it for each file you dragged over, or if you loaded a folder, for each supported filetype it found.

5. From here, you can delete any which one that you don't want, re-order them, check the "and Start" box, or click the 'Queue' button right next to it.

Wouldn't this be like the coolest, and more importantly, most convenient thing ever?

Because quite frankly I've grown tired of having to navigate through MeGUI's interface. Not that there is too much wrong with it - it's the best GUI around :p - But, it's just the fact that I have had things to encode, on just about a daily basis, and I simply cannot do it anymore.

I'm not the first one to request this, am I? I would really love a feature like this.

[TSoft]

"Wouldn't this be like the coolest, and more importantly, most convenient thing ever?"

I don't think so.

I think the most important thing (and here I am sure I am not the only one who asked for it) is the compressibility test XD

[bilditup1]

Request: the mp4 muxer actually does almost everything right in terms of getting things to work properly on iDevices. However, there's one thing left out - specifying a group for audio tracks, so that they don't play all at once. This is achievable by adding ":group=1" to the end of each audio track's command line section, and, additionally, ":disabled" to the end of each audio track *except* for the first one.

One nice feature is the autoconversion of chapters from ogg to xml formats when specifying iPhone or iPod output; I haven't found a separate tool that does this. But it would be nice to have an extra option, a checkbox, say, that allowed the chapters to be added in the original txt format as well as in the xml format, to foster the widest compatibility. Or maybe a radio button, one each for 'mux txt', 'convert to xml', 'use both', with an accompanying tooltip explanation.

It might be worth doing the same for srt (which are also autoconverted, though to my knowledge this is a feature of mp4box).

I would build this stuff myself if I knew what is necessary to compile it.

Thank you very much for listening, and thank you very much for making this indispensible tool!

[hello_hello]

I don't know if there's plans to do so but I still think the Resize section could be tweaked a little when using any of the anamorphic options which don't resize. As an example using a PAL 4:3 DVD.....

If I crop 4 pixels from one side using "resize to mod16" the width remains at 720 but turns red as it should. However it does the same using any of the other mod16 options which don't resize, and as the width turns red it implies resizing even though there isn't any. Doing the same thing while selecting "overcrop to mod16 " should ideally cause the resize width to automatically change to 704 etc in order for MeGUI to correctly display the output resize dimensions.

Also the way the resizing displayed is updated makes it inconsistent (even though in reality it doesn't apply). For example selecting "overcrop to mod16" before enabling cropping and then cropping 4 pixels from the side causes MeGUI to display 720x576 with the width background red, enabling "overcrop to mod16" after cropping causes it to display 720x592 with both width and height background red, and finally if you crop, enable "resize to mod16" and then switch to "overcrop to mod16", MeGUI displays 720x592 with the width given a red border on a white background while the height background turns red.

I realise in all the above examples MeGUI isn't actually resizing, but ideally it should display the correct output dimensions and if you change the desired mod after cropping and resizing, any changes MeGUI makes to under/over cropping should also be reflected in the output dimensions it displays.

I guess the aspect ratio/error discussion has continued over the last few days and the calculations have been changed again since 2256? If that's the case then the rest of this post is no doubt obsolete as I was just wanting to report 2256 still gets it slightly wrong. Only enough to be noticeable occasionally, but it still causes MeGUI to report an aspect error sometimes when in fact there should be none.
I tried tebasuna51's formula on the video's which were causing MeGUI to display an incorrect aspect error when resizing and it seems to be spot on, so I'll look forward to the next MeGUI release.

Thanks for all the hard work guys.

[Kurtnoise]

Request: the mp4 muxer actually does almost everything right in terms of getting things to work properly on iDevices. However, there's one thing left out - specifying a group for audio tracks, so that they don't play all at once. This is achievable by adding ":group=1" to the end of each audio track's command line section,
Yes, it's already on my local tree...forgot to commit this.

and, additionally, ":disabled" to the end of each audio track *except* for the first one.
Why ?

One nice feature is the autoconversion of chapters from ogg to xml formats when specifying iPhone or iPod output; I haven't found a separate tool that does this. But it would be nice to have an extra option, a checkbox, say, that allowed the chapters to be added in the original txt format as well as in the xml format, to foster the widest compatibility. Or maybe a radio button, one each for 'mux txt', 'convert to xml', 'use both', with an accompanying tooltip explanation.
mmh, ok...

It might be worth doing the same for srt (which are also autoconverted, though to my knowledge this is a feature of mp4box).
you mean srt to xml conversion ? Please, explain...

[Kurtnoise]

Also for whomever is/are the talented coding folks here.. I would like to request there be a way in OneClick mode so that it will automatically select the correct OneClick profile, based on the filename (partial match) of the file you selected, and add it to the queue.

So, it would go something like this:

1. First, obviously you would need to setup each string you want to match. Let's say you type in, 'banana', and next to it you select the OneClick profile it would use. We'll call it 'banana', too. Click a button to confirm and add it. (MeGUI would save this information to a settings file)

2. Next, the actual auto-loading in action! You would select a file, and drag it over to the auto load window. I drag over a file named, "AdventuresofBananaS01E05.mpg" (multiple file drag or a folder load would be convenient here).

3. It would acknowledge that you dropped a file in the window, and whether or it found a matching OC profile to use. Something like, "Found a match! Using 'banana' profile for 'AdventuresofBananaS01E05.mpg'..... Done!"

4. It will log it for each file you dragged over, or if you loaded a folder, for each supported filetype it found.

5. From here, you can delete any which one that you don't want, re-order them, check the "and Start" box, or click the 'Queue' button right next to it.

Wouldn't this be like the coolest, and more importantly, most convenient thing ever?

Because quite frankly I've grown tired of having to navigate through MeGUI's interface. Not that there is too much wrong with it - it's the best GUI around :p - But, it's just the fact that I have had things to encode, on just about a daily basis, and I simply cannot do it anymore.

Why not create your own profiles according to your input files name ?

[Zathor]

@Invy: Sorry, no time and interest in your two requests at the moment. Please add them to the feature request tracker so that they get not lost. Especially the first one will be added but I have no ETA.

Request: the mp4 muxer actually does almost everything right in terms of getting things to work properly on iDevices. However, there's one thing left out - specifying a group for audio tracks, so that they don't play all at once. This is achievable by adding ":group=1" to the end of each audio track's command line section, and, additionally, ":disabled" to the end of each audio track *except* for the first one.
Does this harm the compatibility of MP4 files with specific devices? I have no native MP4 devices to test. If no I will add it.

One nice feature is the autoconversion of chapters from ogg to xml formats when specifying iPhone or iPod output; I haven't found a separate tool that does this. But it would be nice to have an extra option, a checkbox, say, that allowed the chapters to be added in the original txt format as well as in the xml format, to foster the widest compatibility. Or maybe a radio button, one each for 'mux txt', 'convert to xml', 'use both', with an accompanying tooltip explanation.

Same question as above. Is it possible to add both formats wiohtout harming the compatibility? So is it possible to add "-add filename.xml:chap -chap filename.txt"?

I guess the aspect ratio/error discussion has continued over the last few days and the calculations have been changed again since 2256? If that's the case then the rest of this post is no doubt obsolete as I was just wanting to report 2256 still gets it slightly wrong. Only enough to be noticeable occasionally, but it still causes MeGUI to report an aspect error sometimes when in fact there should be none.
The changed calculation will not have an effect on your mentioned scenario where an error is reported when there is none. So please provide an example.

Regarding your other points I have to reproduce it later.

[Kurtnoise]

Hi Zathor,

HappY NeW YeaR...;)

Does this harm the compatibility of MP4 files with specific devices?
nope...this trick is used to switch audio tracks. I've an iphone to test this. No worry.

Same question as above. Is it possible to add both formats wiohtout harming the compatibility? So is it possible to add "-add filename.xml:chap -chap filename.txt"?
I don't think so...At least, Apple devices should not be read the track corresponding to the -chap filename.txt, only the first one. Incompatibility may arise with other players, not Apple devices...I'll check it out.

[Zathor]

Happy new year :) - and thanks!

Here is the patch:

http://pastebin.com/BW9dmF9k
Thanks again - it has been added a few minutes ago to the trunk.

[hello_hello]

The changed calculation will not have an effect on your mentioned scenario where an error is reported when there is none. So please provide an example.

My mistake, I think. I tried to reproduce it again but couldn't.
I "think" I may have done something silly at the time such as used DirectShow for decoding while leaving ffdshow's cropping filter enabled and because MeGUI doesn't display the input resolution I didn't notice it had change. Actually..... MeGUI displaying the input resolution as well as aspect ratio..... that'd be nice. ;)

But sorry, I guess I made a boo-boo.

[hello_hello]

I think the most important thing (and here I am sure I am not the only one who asked for it) is the compressibility test XD

Maybe it'd be too hard to implement for the usage it'd get given quality based, rather than file size based encoding seems to be more the norm these days. StaxRip can but I'm not sure if there's any other "currently maintained" GUIs which do.

AutoGK and StaxRip run their compression tests by adding a simple function to the script and it generally produces quite accurate results. You could add the same thing to the script MeGUI creates and then use it to run an encode, which effectively becomes the compression test.

SelectRangeEvery(300, 15)

The above is what AutoGK generally adds to the end of the script which means it encodes the first 15 frames out of every 300 which gives you 5% of the video. It always seems to encode 15 frames in a row but for shorter clips it changes the the range. ie SelectRangeEvery(150, 15) gives you a compression test over 10% of the video. For a five minute video AutoGK uses SelectRangeEvery(43, 15).
I ran one compression test with StaxRip and it used SelectRangeEvery(280, 14) but I guess the end result would be about the same.

For Xvid you'd run the compression test using a single pass encode and a constant quantizer of 2. For x264 I think it's just CRF18 (that seems to be what StaxRip uses). The above method will allow you to at least run a compression test using MeGUI, but given MeGUI won't do it for you, someone may be able to supply the formula for doing the math yourself
Maybe calculating the quality/file size/resolution from a compression test result might be a subject worthy of a new thread. I'd assume once you know the formula it can't be too hard.

[Kurtnoise]

No one use compressibility tests these days with codecs like x264...So, why bother ?

[bilditup1]

Request: the mp4 muxer actually does almost everything right in terms of getting things to work properly on iDevices. However, there's one thing left out - specifying a group for audio tracks, so that they don't play all at once. This is achievable by adding ":group=1" to the end of each audio track's command line section, and, additionally, ":disabled" to the end of each audio track *except* for the first one.

One nice feature is the autoconversion of chapters from ogg to xml formats when specifying iPhone or iPod output; I haven't found a separate tool that does this. But it would be nice to have an extra option, a checkbox, say, that allowed the chapters to be added in the original txt format as well as in the xml format, to foster the widest compatibility. Or maybe a radio button, one each for 'mux txt', 'convert to xml', 'use both', with an accompanying tooltip explanation.

It might be worth doing the same for srt (which are also autoconverted, though to my knowledge this is a feature of mp4box).

I would build this stuff myself if I knew what is necessary to compile it.

Thank you very much for listening, and thank you very much for making this indispensible tool!

I initially posted a feature request here:
https://sourceforge.net/p/megui/feature-requests/495/
and then submitted a patch:
https://sourceforge.net/p/megui/patches/65/

I eschewed modifying the gui in favor of a more practical approach, since SRT subs are converted in any event and never just muxed in - so creating a new device profile seemed silly just for the chapters. I patched the iOS stuff (described in detail at the patch link above) and changed the behavior of chapter adding to always add the ogg chapters, even when also adding xml chapters for iPod and iPhone. This does not break functionality for software that only uses either form of chapter. I'm not sure if this violates a standard (probably does) but it's the practical move and I believe the right one...

[bilditup1]

and, additionally, ":disabled" to the end of each audio track *except* for the first one.

Kurtnoise asked why this is necessary. In my testing I have found that if this is NOT done, then all audio tracks still play all at once, until the user goes and selects one audio track or the other (even if the UI says that the first track is selected). Now, sometimes this does NOT happen, and everything works fine. But the behavior is inconsistent, and adding :disabled has gotten rid of this problem every time I tried opening a file.

Adding the disabled flag both prevents this stupidity and has no detrimental effect in my other players (OpenELEC-xbmc-rpi; MPC-HC w/LAV or with internal filters on Win7 x64)

[Zathor]

If I crop 4 pixels from one side using "resize to mod16" the width remains at 720 but turns red as it should. However it does the same using any of the other mod16 options which don't resize, and as the width turns red it implies resizing even though there isn't any.Doing the same thing while selecting "overcrop to mod16 " should ideally cause the resize width to automatically change to 704 etc in order for MeGUI to correctly display the output resize dimensions.
Thx - fixed.

Also the way the resizing displayed is updated makes it inconsistent (even though in reality it doesn't apply). For example selecting "overcrop to mod16" before enabling cropping and then cropping 4 pixels from the side causes MeGUI to display 720x576 with the width background red, enabling "overcrop to mod16" after cropping causes it to display 720x592 with both width and height background red, and finally if you crop, enable "resize to mod16" and then switch to "overcrop to mod16", MeGUI displays 720x592 with the width given a red border on a white background while the height background turns red.
Also fixed.

The next build will have the "aspect ratio error" for anamorpic encodings enabled again. Both input and output are converted to square pixels and then compared. Interestingly not all settings have 0% AR error. If the expected behavior is that with "Clever anamorphic..." enabled it must always be 0% I will have a look at the reson.

[Zathor]

I initially posted a feature request here:
https://sourceforge.net/p/megui/feature-requests/495/
and then submitted a patch:
https://sourceforge.net/p/megui/patches/65/
Thanks for the patch - I am going to commit the audio/subtitle part but I will not implement the chapter part as I will wait for Kurtnoise because I cannot test anything here.

[Kurtnoise]

Hi,

I initially posted a feature request here:
https://sourceforge.net/p/megui/feature-requests/495/
and then submitted a patch:
https://sourceforge.net/p/megui/patches/65/

I'd say testing Device Type in Audio Part could be better (like Subtitles)...Something like :


Index: megui/trunk/packages/muxer/mp4box/MP4BoxMuxer.cs
===================================================================
--- megui/trunk/packages/muxer/mp4box/MP4BoxMuxer.cs (revision 2260)
+++ megui/trunk/packages/muxer/mp4box/MP4BoxMuxer.cs (working copy)
@@ -268,6 +268,7 @@
sb.Append(":name=" + settings.VideoName);
sb.Append("\"");
}
+ int trackCount = 0;
foreach (object o in settings.AudioStreams)
{
MuxStream stream = (MuxStream)o;
@@ -315,8 +316,13 @@
sb.Append(":name=" + stream.name);
if (stream.delay != 0)
sb.AppendFormat(":delay={0}", stream.delay);
+ if (settings.DeviceType == "iPod" || settings.DeviceType == "iPhone")
+ {
+ sb.Append(":group=1");
+ if (trackCount > 0)
+ sb.Append(":disabled");
+ }
sb.Append("\"");
+ trackCount++;
}
+ trackCount = 0;
foreach (object o in settings.SubtitleStreams)
{
MuxStream stream = (MuxStream)o;
@@ -335,8 +341,13 @@
if (!string.IsNullOrEmpty(stream.name))
sb.Append(":name=" + stream.name);
if (settings.DeviceType == "iPod" || settings.DeviceType == "iPhone")
+ {
sb.Append(":hdlr=sbtl:layout=-1:group=2");
+ if (trackCount > 0)
+ sb.Append(":disabled");
+ }
sb.Append("\"");
+ trackCount++;
}

otherwise, it looks ok to me. In addition, I would like to add also some checkings with Audio format (i.e AC3, not compatible with Apple Devices, etc)


I eschewed modifying the gui in favor of a more practical approach, since SRT subs are converted in any event and never just muxed in - so creating a new device profile seemed silly just for the chapters.
I frankly don't understand why you want to do with subtitles conversion...Could you explain with more details ?

[Zathor]

I'd say testing Device Type in Audio Part could be better (like Subtitles)...Something like
Sorry, I was too fast :( The audio part has already been commited but of course it can and should be changed again if necessary. I will now stop doing anything in the MP4 area.

Nevertheless:

2266 [Audio Encoder] added BassAudioSource() as decoder. Part II
2265 [MP4 Muxer] improved iOS compatibility when using multiple audio/subtitle tracks. Patch #65 by Eli Bildirici
2264 [Worker] a temporary worker will always be deleted after a job is finished (successful or not)
2263 [Audio] changed default value of the normalization to disabled
2262 [AVS Script Creator] show "Aspect Ratio Error" when doing an anamorphic encoding
some cosmetic sizing & cropping enhancements
2261 [Update] added system proxy. Patch by Shevek
2260 [AVS Script Creator] changed "point of view" of the aspect error calculation
2259 [Audio Encoder] added BassAudioSource() as decoder
default order: NicAudio, BassAudio, FFAudioSource, DirectShow
2258 [Job] improved aborting of Jobs

[bilditup1]

Hi,


I'd say testing Device Type in Audio Part could be better (like Subtitles)...Something like :


Index: megui/trunk/packages/muxer/mp4box/MP4BoxMuxer.cs
===================================================================
--- megui/trunk/packages/muxer/mp4box/MP4BoxMuxer.cs (revision 2260)
+++ megui/trunk/packages/muxer/mp4box/MP4BoxMuxer.cs (working copy)
@@ -268,6 +268,7 @@
sb.Append(":name=" + settings.VideoName);
sb.Append("\"");
}
+ int trackCount = 0;
foreach (object o in settings.AudioStreams)
{
MuxStream stream = (MuxStream)o;
@@ -315,8 +316,13 @@
sb.Append(":name=" + stream.name);
if (stream.delay != 0)
sb.AppendFormat(":delay={0}", stream.delay);
+ if (settings.DeviceType == "iPod" || settings.DeviceType == "iPhone")
+ {
+ sb.Append(":group=1");
+ if (trackCount > 0)
+ sb.Append(":disabled");
+ }
sb.Append("\"");
+ trackCount++;
}
+ trackCount = 0;
foreach (object o in settings.SubtitleStreams)
{
MuxStream stream = (MuxStream)o;
@@ -335,8 +341,13 @@
if (!string.IsNullOrEmpty(stream.name))
sb.Append(":name=" + stream.name);
if (settings.DeviceType == "iPod" || settings.DeviceType == "iPhone")
+ {
sb.Append(":hdlr=sbtl:layout=-1:group=2");
+ if (trackCount > 0)
+ sb.Append(":disabled");
+ }
sb.Append("\"");
+ trackCount++;
}

otherwise, it looks ok to me. In addition, I would like to add also some checkings with Audio format (i.e AC3, not compatible with Apple Devices, etc)



I frankly don't understand why you want to do with subtitles conversion...Could you explain with more details ?

Good idea re detecting ac3.
If you'd like to restrict the audio stuff I suggested to the iOS device profiles then I suppose that's fine; makes no difference to me. I guess if you're gonna be checking for ac3 anyway then you might as well keep things organized.
About the subtitles, it was based on A misunderstanding of how mp4box handles them...and I wasn't really talking about conversions. I thought that srt subs were mixed in to mp4 without any conversion unless the iOS device profiles were used. That's not what happens though. mp4box, in the process of musing, converts the files from srt to the t3xg subtitle format. So my idea to have multiple options, like I suggested for chapters, where the user would specify whether to mux srt, t3xg, or both, made no sense.

[bilditup1]

Oh cool, you guys accepted the patch! Ha. Much less fuss than the ruby people. They want a zillions and one tests. Thanks!

[hello_hello]

Well I hate to harp on the aspect error calculation, but...... (MeGUI 2266)

Take a PAL 4:3 DVD and work out the aspect ratio using 16/15.

(720/576)*(16/15)=1.33333333
So without cropping I resize that to 640x480 and MeGUI shows a zero aspect error which is correct.

Now lets crop 20 pixels from the width and 16 from the height.
(700/560)*(16/15)=1.33333333
Resize that to 640x480 and MeGUI displays a slight aspect error which it shouldn't.

I'm still not sure why MeGUI and Yoda consistently disagree by a small amount. As best as I can tell Yoda is getting it correct.

In the subject of aspect ratios..... now that the aspect error calculation has been enabled when using anamorphic encoding, why should MeGUI ever display anything but a zero aspect error? Even when using the encode non-mod16 method some combinations of cropping produce a slight aspect error, which I'd thought shouldn't happen if you're not resizing at all.

[Zathor]

Well I hate to harp on the aspect error calculation, but......
Thank you very much! Please continue with your feedback. If there are errors they must be fixed.


(720/576)*(16/15)=1.33333333
So without cropping I resize that to 640x480 and MeGUI shows a zero aspect error which is correct.
Now lets crop 20 pixels from the width and 16 from the height.
(700/560)*(16/15)=1.33333333
Resize that to 640x480 and MeGUI displays a slight aspect error which it shouldn't.
700/560 with SAR 16/15 are in square pixel 747/560 and have an DAR of 1,333928571. So the error is:
(560 * 640) / (747 * 480) - 1 = -0,0446229%
In my opinion this is correct. What do you think?
EDIT: There seems to be a rounding error. Searching...
EDIT2: Fixed - I am now using not an INT value anymore for the square pixel dimensions. So it is 746,6666666 / 560 = 1,33333 resulting in a 0% aspect ratio error.

... now that the aspect error calculation has been enabled when using anamorphic encoding, why should MeGUI ever display anything but a zero aspect error? Even when using the encode non-mod16 method some combinations of cropping produce a slight aspect error, which I'd thought shouldn't happen if you're not resizing at all.
That was my question some posts above as well. So should the new SAR setting of the AVS file always result in an aspect error of 0%? Or do we have such slight differences like in the example above?

[Zathor]

Please try 2267:

2267 [AVS Script Creator] improved accuracy of the "Aspect Ratio Error"
[AVS Script Creator] improved accuracy of the aspect ratio when using "Clever (TM) anamorphic encoding"
[AVS Script Creator] internal optimizations
[OneClick] implemented the AVS Script Creator changes

[AliveNoMore]

Here MeGUI goes into a loop: wants to update from 2266 to 2267, then wants to update to 2266 again, then to 2267, and so forth.

[Shevek]

Here MeGUI goes into a loop: wants to update from 2266 to 2267, then wants to update to 2266 again, then to 2267, and so forth.

Give it 30 mins for all the servers to sync to the same version and it will stop...