MeGUI: bug reports and feature requests [Archive] - Page 17

help_me!

15th February 2010, 15:28

Forget it guys!!

This was the problem:

Maybe you have the same problem I did. Check these posts: http://forum.doom9.org/showthread.php?p=1371125#post1371125

:thanks::thanks::thanks:

edit I feel stupid for wasting your time! I will be more careful from now and on! Thanks to all who helped me.

mikey1984

15th February 2010, 21:16

Any of u guys have problem with megui adding "work tasks" to que twice?

I mean, when i add two x264 passes to ques, 1st then 2nd, then i go to que view, and both jobs are added twice, 1st,2nd,1st,2nd....

Kinda bizzare, and i noticed it happening after last core update to 3.3.5... anyone else with such problem?

EDIT:
After some looking around, i noticed, that while using bitrate calculator and applying its calculations to already pre-saved x264 profiles, it automaticaly changes my "2 pass 1st pass" and "2pass 2nd pass" x264 modes in those presets into "Automated 2 pass", thus it gets added "twice" to work que.

Any way to fix this issue? Seems like there is some problem within bitrate calc.

Fr4nz

15th February 2010, 22:53

Hi Zathor,

in case you didn't knew this: syntax for --nal-hrd parameter has been changed in latest revisions. See here (http://forum.doom9.org/showpost.php?p=1374503&postcount=85).

Zathor

15th February 2010, 23:01

After some looking around, i noticed, that while using bitrate calculator and applying its calculations to already pre-saved x264 profiles, it automaticaly changes my "2 pass 1st pass" and "2pass 2nd pass" x264 modes in those presets into "Automated 2 pass", thus it gets added "twice" to work que.
Thanks, the change in 0.3.3.5 has been too agressive. I will fix it with the next dev (which is likely the stable) build.

Hi Zathor,

in case you didn't knew this: syntax for --nal-hrd parameter has been changed in latest revisions. See here (http://forum.doom9.org/showpost.php?p=1374503&postcount=85).

Ok, I will change it in one of the next builds. I think I will push out a stable build first still with x264 1376 and change the nal-hrd handling with the first dev build.

Lyle_JP

16th February 2010, 08:57

I don't suppose you'd be willing to push out the x264.nl or techouse r1376. The Jeeb's and Komisar builds never play well with my equipment. I can't be the only one.

help_me!

16th February 2010, 11:13

FYI this clip: http://www.massmirror.com/4931a8e5af68704161fde207bae78fb7.html crashes x264_64 from the very first moment of encoding.

Tried the x264 build from both stable and dev. servers.

I eventually encoded it from CLI with a x264.nl 32bit build. As it was the only video that failed from the 30 or so clips I encoded successfully yesterday night, I didn't bother researching the cause. Perhaps a vfw4x264 issue? I uploaded it in case anyone wants to experiment with it.

edit From the very few tests I did, I don't think that settings matter at all but I tried CRF only encodes..

Zathor

16th February 2010, 11:15

I don't suppose you'd be willing to push out the x264.nl or techouse r1376. The Jeeb's and Komisar builds never play well with my equipment. I can't be the only one.

The problem is that the x264.nl build has no nal-hrd support and therefore a patched one has to be used. This will change sometime in the future as soon as the support for nal-hrd will be implemented in the default x264 builds.

Fr4nz

16th February 2010, 11:19

The problem is that the x264.nl build has no nal-hrd support and therefore a patched one has to be used. This will change sometime in the future as soon as the support for nal-hrd will be implemented in the default x264 builds.

After some testing, latest Komisar patched build seems to work well Zathor (keeping in mind that NAL-HRD parameter has a different syntax!), so you could include it in development version of MeGUI without problems...

SacredCultivator

16th February 2010, 20:37

MuLTiTaSK

16th February 2010, 20:52

I guess I should have asked this a while back as I've been doing it manually in the past.

When there are updates for the x264 builds, when updating, does that only update the 32-bit version? Or does it also update the 64-bit, as I know the 64-bit doesn't always get updated at the same time as the 32-bit.

So just thought I would ask, even though I generally manually dl the 64-bit.

no need to update manually unless you want to use a special build both 32-bit and 64-bit builds always get updated together just use the ones included and save yourself the trouble plus you never know what x264 switches might change;)
avs4x264.exe
vfw4x264.exe
x264.exe
x264_64.exe

SacredCultivator

16th February 2010, 21:03

@MuLTiTaSK: Ahh, thanks for the response, again, I just wasn't sure, so I always did it manually just to be 100% sure that I had the latest 64-bit build. But now that you mention it updates both, shall leave it up to that, thanks.

Hiritsuki

17th February 2010, 06:24

I think this problem is megui dev server update new a method for x64 suport
I'd useing Windows7 x64 and mgui update dev server no problem
x86 maybe wrong in this way

quantum5uicid3

17th February 2010, 12:32

[ReX]

18th February 2010, 06:15

There's a new version of AVI-Mux GUI, 1.17.8.3.

Contains fixes for a couple of problems: reading certain DTS files, reading certain AAC files, settings dialog was cropped when the system font size was larger than normal, should not require compatibility mode setting on Vista and Windows 7 anymore. It's partially migrated from C-string functions to STL. This is NOT PROPERLY TESTED, I just want to release it, otherwise I'd never get it out. Maybe you want to test...

http://www.alexander-noe.com/video/amg/AVI-Mux_GUI-1.17.8.3.zip

ninja_racoon

18th February 2010, 15:38

can I use x264 64bit and avisynth 32bit using megui?

HeadlessCow

18th February 2010, 16:03

It does that automatically, ninja_racoon.

rapscallion

18th February 2010, 23:20

heres new preset with bluray and avchd updated for new hrd switch. i added a "max compatibility (Dxva)" with level 4.1 and vbv 40000 too. if it don't work with all cards support avc acceleration plz post.
http://www.mediafire.com/?zeyydehngrm

What is the "new" hrd sw ? The "vbr" following hrd has no (-), but is that it?

Also, the post referenced above by @Fr4nz indicates x264 build 1442 for the new sw.
The current dev build is 1400 , so we should not use the new presets yet, right ?.

quantum5uicid3

19th February 2010, 05:02

that's it :)

yeah, im using komisar1442. it should be the standard going forward.

ninja_racoon

20th February 2010, 06:19

How do I turnoff the subtitles getting hardsubbed in megui?

Barough

20th February 2010, 12:36

New MediaInfo released, v0.7.2.8

http://mediainfo.sourceforge.net/en/Download/Windows

poisondeathray

20th February 2010, 15:57

How do I turnoff the subtitles getting hardsubbed in megui?

Takeout textsub() line in the avs script

or

Remove soft subs from the source

Zathor

20th February 2010, 18:52

0.3.3.6
- update MediaInfo library and its wrapper to the latest release (0.7.28)
- [UpdateWindow] moved the MediaInfo files to a separate download package
- [Calculator] encoding mode will only be changed if profile encoding mode is const. quality or const. quantizer. Bug #2952574
- [dgiReader] enhanced error handling
- [SourceDetector] enhanced error handling in analyseFF. Bug #2810830
- [Calculator] settings can only be applied if bitrate > 0. Bug #2812840
- [AviSynthWindow] enabling clever anamorphic encoding applies immediately the selected settings. Bug #2827053

EDIT:
If someone wants to test the newer x264 builds you can replace the x264.exe and x264_64.exe with newer builds. If using nal-hrd you have to add e.g. --nal-hrd vbr to the custom command line.

Zathor

20th February 2010, 21:52

0.3.3.7
- [JobControl] error handling added. Bug #2279852
- [x264Encoder] corrected scenecut handling. Bug #2942446
- [LogItem] error handling added. Bug #2947565 + #2925500

himan2001

21st February 2010, 07:25

eac3to (auto-update) is still on 0 Bytes, maybee wrong or invalid zip compression on update-server.

Zathor

21st February 2010, 09:35

eac3to (auto-update) is still on 0 Bytes, maybee wrong or invalid zip compression on update-server.
Thanks, the wrong file name has been fixed.

hajj_3

22nd February 2010, 16:18

regarding:

http://i45.tinypic.com/35bi0x5.jpg

You can choose not to use a built-in de-interlacer, but disabling the checkbox would be better, as for the resizer you have to choose 1 unfortunately even when you select nvidia's resizer, this causes the video not to encode and gives you the following error:

http://i50.tinypic.com/fjlts5.jpg

Please disable the dropdown box for the resizer and don't add any info to the .avs script when we select nvidia's resizer.

Thanks zathor :)

Zathor

23rd February 2010, 19:53

0.3.4.1
- [x264Encoder] added support for new nal-hrd (requires x264 revision 1442 or higher)

rapscallion

23rd February 2010, 19:59

Zathor, what exactly is the benefit of the "new" nal-hrd sw?

hajj_3

23rd February 2010, 20:03

nice to see x264 1442 support, hope you can fix the stuff 3 posts up from this post.

Zathor

23rd February 2010, 20:09

Zathor, what exactly is the benefit of the "new" nal-hrd sw?

The syntax of x264 for nal-hrd has changed. --nal-hrd has been the old switch and this is the new one:
--nal-hrd <string> Signal HRD information (needed e.g. for Blu-Ray compliance)
- vbr, cbr. (requires vbv-bufsize; cbr-hrd not allowed in .mp4)

nice to see x264 1442 support, hope you can fix the stuff 3 posts up from this post.
Hopefully :)

kool

23rd February 2010, 20:51

Hi,
I have tried to analyse Blu-Ray source for test purpose throw megui with dgindexnv, it toke very long almost after 30min i haven't got any result.

rack04

23rd February 2010, 20:57

Hi,
I have tried to analyse Blu-Ray source for test purpose throw megui with dgindexnv, it toke very long almost after 30min i haven't got any result.

Try closing the preview window before analyzing.

kool

24th February 2010, 01:31

That way it works fine, what would be the reasone when it is not working when the preview window is on? and one more strenge thing what I've come across is, when I crop and chose the nvidia resizer the resolution shewed up 1920x552 instead of 1920x816, the script come out after analysing as below
LoadPlugin("C:\Program Files (x86)\megui\tools\dgindexnv\DGDecodeNV.dll")
DGSource("C:\Users\kool\Desktop\test\test.dgi",fieldop=0, resize_w=1920, resize_h=816)
#deinterlace
crop( 0, 132, 0, -132)

#resize
#denoise
and AvsP preview http://i48.tinypic.com/9a0l1f.png

Inspector.Gadget

24th February 2010, 01:44

In that script, you're resizing before cropping. If you want to use the NV resizer, you must also use the NV crop rather than the Avisynth crop for any pre-resize cropping tasks.

hajj_3

24th February 2010, 11:36

p.s please add the following size to the bitrate calculator: 746mb (1/6 dvdr)

x264 build 1462 is out now btw, nice changelog too:)

Nightshiver

24th February 2010, 18:53

Is it that hard for you to just set the bitrate yourself? The calc has even numbers, and 746 is just a weird size and besides that, it's just to simple to increase the bit rate yourself to get that size.

SledgeHammer_999

24th February 2010, 20:20

A regression from 0.3.3.5:
In the calculator user-defined file sizes aren't saved after closing the calculator.(either by apply or cancel).

Feature request:
After each update remember user-defined file sizes and don't delete them.

rapscallion

24th February 2010, 22:47

Zathor

24th February 2010, 23:55

0.3.4.2
- [AviSynthProfileConfigPanel] if clever anamorphic encoding is enabled the dropdown box will be also enabled
- [AviSynthWindow] openning a file also triggers the clever anamorphic encoding event. Bug #2957647
- [UpdateWindow] set file changed time of extracted files
- [UpdateWindow] files which need a reboot will also be backuped if selected
- update ICSharpCode.SharpZipLib.dll

XhmikosR

24th February 2010, 23:59

Zathor, please update the SVN; that's why it exists. Thanks.

Zathor

25th February 2010, 00:03

Speaking of the calculator....I still find that it's on the high side for m2ts container in both dvd5 and dvd9 sizes.
So, I've been able to adjust accordingly. However I'm at a loss for bd25 size. Suggestions welcome.

The m2ts calculation is experimental. I'm open for any suggestions to improve this part.

Feature request:
After each update remember user-defined file sizes and don't delete them.

Please post all feature requests also to the sourceforge page. Otherwise they may get lost.

Zathor

25th February 2010, 00:43

Zathor, please update the SVN; that's why it exists. Thanks.

Most of the time I update the SVN a few minutes before or a few minutes after I publish a new version. This time I had a few other things to do between these tasks. Because I am the only active developer at the moment I do it as fast and in the order and way I am able to do it - there is no other developer waiting to incorporate my code. It would be a good thing if there would be one.

If the source code is not committed a few days after a new build has been published you can remind my and I will apologize for my laziness. Please do not push me a few minutes after an update.

By the way - SVN should be up to date in all relevant parts now.

XhmikosR

25th February 2010, 01:22

Most of the time I update the SVN a few minutes before or a few minutes after I publish a new version. This time I had a few other things to do between these tasks. Because I am the only active developer at the moment I do it as fast and in the order and way I am able to do it - there is no other developer waiting to incorporate my code. It would be a good thing if there would be one.

If the source code is not committed a few days after a new build has been published you can remind my and I will apologize for my laziness. Please do not push me a few minutes after an update.

By the way - SVN should be up to date in all relevant parts now.
I know you are the only developer and I appreciate all the hard work you are doing. Don't get me wrong but sometimes you didn't commit your changes for days, although you had released a new version on the server. That's why I thought you would do the same. The SVN exists for a reason and this has nothing to do with the fact that you are the only dev. At least this is how I see it.
I just compile the latest meGUI for testing purposes and most of the times I find that a new build exists without the changes in the source code being published. Anyway, I hope you get my thinking, I didn't want to sound like I don't appreciate your work.

Lyle_JP

25th February 2010, 07:47

With b-pyramid normal now on as default (r1462 and higher), we now need a GUI switch for explicitly turning b-pyramid off.

jeremy33

25th February 2010, 12:55

I have a probleme. I encode a movie in x264 in mp4 container but when I want to mux it with mkvtoolnix 3.20 there is just a few minute of movie in my mkv.

sorry for my bad english

Inspector.Gadget

25th February 2010, 14:20

jeremy33, read the last few pages of the mkvtoolnix thread, where i believe a similar problem was reported and perhaps resolved.

quantum5uicid3

26th February 2010, 00:51

i haven't tested extensively, but i've hit 4.35-4.36GB everytime i've selected DVD5. files were a 640kbps AC3 and a raw h264 stream muxed to m2ts with tsmuxer.

himan2001

27th February 2010, 05:54

There is a Uint64 Overflow Error in The Bitratecalculator.

I try to calculate audio & video for a stream that is 21 hours in length. When i select the 1rst Audio i get uint64 Overflow Error. At the Moment it is not possible to calculate a stream for 24h length with Audio (mp3 or ac3). 24h are typical for Security video/cam for exsample.

This must be calculated with external calculator for the moment.

rkalwaitis

27th February 2010, 18:40

I have downloaded this build from scratch. Everything seems to go fine except I can not create a dv2 file. It starts to make the file but hangs. The log does not give an error as I end the abort the process myself. I am obviously missing something simple but can not figure it out. I ran the dv2 creator from the folder not using Megui and had the same problem.