Log in

View Full Version : MeGUI: bug reports and feature requests


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 [25] 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147

MOS-Marauder
2nd July 2010, 14:13
When the Tools will be updated ? (for example DGTools NV is actually 2018....)

Chris

Edit: Weird.. right in that moment i wrote u did it *G*

Sharktooth
2nd July 2010, 14:47
It's also called mind-reading or telepathy ;)

Zathor
2nd July 2010, 17:54
0.3.5.1
- [FileIndexerWindow] changed caption. Feature request #3019279
- [AudioEncoderInterface] fixed crash if input wav file is locked. Bug #3021693
- [VideoUtil] + [DialogManager] CUVIDServer will be started if needed. Bug #3011113
- [x264ConfigurationPanel] changed preset defaults (requires x264 revision 1658 or higher)
- [x264ConfigurationPanel] added the missing update events to some settings
- [x264ConfigurationPanel] enhanced command line generating for main/baseline profile
- [FileIndexer] disabled MKV indexing with DGAVCDec. Bug #3024329
- [FileIndexer] DGIndexNV is only available if license.txt is found
- [MuxProvider] added support for SUP suptitles in MKV (requires MkvToolNix 4.1.0 or higher)
- [VideoCodecSettings] update custom command line if neccessary (e.g. --nal-hrd -> --nal-hrd vbr)

some fixes to profiles. ***for latest x264***
1. added "--open-gop coded" to bluray and avchd presets.
2. force disabled bframes and soft enabled CABAC for iphone profile.
3. force disabled b-pyramid and soft enabled CABAC for psp profile.
3. and removed redundency of setting vbv to 10000 when level 3 is already set. *correction*

Thanks, new profiles are online, too.

Shevek
2nd July 2010, 18:37
I'm trying to update to the latest x264 but it won't work:

Trying server: http://megui.org/auto/
Retrieving update file from server...
File downloaded successfully...
Loading update data...
Update data loaded successfully...
Finished parsing update file...
There is 1 file that can be updated.
Updating x264. File 1/1.
Update completed.
0 file was completed successfully
1 file had problem.

All the other updates worked OK (core, Tx264, dgindexnv, ffms)

Sharktooth
2nd July 2010, 18:50
i updated it without problems.
try clearing the update_cache folder and launch megui again.

Shevek
2nd July 2010, 19:29
i updated it without problems.
try clearing the update_cache folder and launch megui again.

Excellent! Thanks Sharktooth. I've updated to 1659 now.

Shevek
2nd July 2010, 19:33
Where is the correct place to make feature requests?

Zathor
2nd July 2010, 19:36
Where is the correct place to make feature requests?

If you want to discuss it first you can post here but afterwards the correct place is there:
http://sourceforge.net/tracker/?group_id=156112&atid=798479

tebasuna51
2nd July 2010, 19:39
Warning with MkvToolNix 4.1.0

2010-06-12 Moritz Bunkus
* mkvmerge: enhancement: mkvmerge uses header removal compression
by default for AC3, DTS, MP3, Dirac and MPEG-4 part 2 (XviD/DivX) tracks.

2010-06-25 Moritz Bunkus
* mmg: enhancement: The "compression" drop down box is enabled for
all track types. That way "no compression" can be forced for those
tracks mkvmerge uses "header removal" compression for.

Eac3to don't support tracks with "header removal compression" and HD Stream Extractor don't work with these tracks. Tested at least with dts tracks.

Sharktooth
2nd July 2010, 19:44
the problem is MeGUI is not the only too that uses MKVMerge...
so i guess we have to update eac3to in the next days. at least i hope...

Shevek
2nd July 2010, 19:59
If you want to discuss it first you can post here but afterwards the correct place is there:
http://sourceforge.net/tracker/?group_id=156112&atid=798479

Thanks Zathor.

Is it possible to add some default options for the HD Steams Extractor? (Similar to Configure AutoEncode defaults...)

e.g.


Option to default to VC1 or H264 for video stream instead of MKV
Option to automatically add -core to options for DTS Master or TrueHD audio streams
Option to automatically select all [language] streams (Audio and Subtitle)

mcwups1
3rd July 2010, 01:49
Good evening everyone.

I got a message for an update and all went well except the x264 update which gave me this message....

http://i142.photobucket.com/albums/r89/mcwups1/Capture.jpg

Now, first of all, I have Win7 x64, so why does it say x86? I really don't understand the difference. When I'm transcoding, it says x264x64.exe (I think) in the processes, and I know I put it in the folder in MeGui.

Anyway, does anyone have an idea what I need to do to fix this? Everytime I start MeGui, the update balloon pops up, and this happens.

Thanks in advance.

Shevek
3rd July 2010, 02:01
Good evening everyone.

I got a message for an update and all went well except the x264 update which gave me this message....

I posted about the same update problem a few hours ago, here's Sharktooth's reply which worked for me:

i updated it without problems.
try clearing the update_cache folder and launch megui again.

mcwups1
3rd July 2010, 02:06
I posted about the same update problem a few hours ago, here's Sharktooth's reply which worked for me:

Ah, okay. Thanks to BOTH of you then, because that worked like a charm.

Happy 4th to you all.

AMED
3rd July 2010, 23:08
MkvToolNix 4.1.1 is out

http://forum.doom9.org/showthread.php?p=1414216#post1414216

Sharktooth
4th July 2010, 03:46
MkvToolNix 4.1.1 is out

http://forum.doom9.org/showthread.php?p=1414216#post1414216
will update it tomorrow

MOS-Marauder
4th July 2010, 08:18
I have a small question.. Ive tried to encode an Xvid with MeGui. No matter what Resolution or Setting i give MeGui (4:3, 16:9, 1.8xxx) the final file will always have Custom Pixel Shape. Where can i set it that there is the correct in the Mpeg4 settings ?

In that case it was 640x320, a file from my cam after cropping.

PAR 1:1 =1
DAR 2:1 =2
Custom Pixel SHape 1:1=1

Where can i set these things ? In the AVS script Gen i set the AR to 16:9.... i need Square Pixel


Chris

Sharktooth
4th July 2010, 15:00
if you need square pixels dont check the anamorphic option (that means non-square pixels)

Capsbackup
4th July 2010, 21:30
i updated it without problems.
try clearing the update_cache folder and launch megui again.

I have tried this for both my XP and Win 7 installations, but neither will update x264. I get this:
Finished parsing update file...
There are 2 files that can be updated.
Updating x264. File 1/2.
Error: Could not unzip x264. Deleting file. Please run updater again...
Updating mkvmerge. File 2/2.

I can manually download x264, and place in the proper folder. However, I keep getting the update available notice for x264, which keeps displaying the same message!

Zathor
4th July 2010, 22:03
Please post the complete update log.

Capsbackup
4th July 2010, 22:14
Please post the complete update log.

Gladly. Can you tell me where to find the update log, since I did not know and just did a copy/paste within the update window where I saw the update failed. :confused:

EDIT:
Just cleared the update-cache of the failed zip of x264, rebooted, and tried updating again and this time it was successful! :)
I will try my XP Pro version next to see if I can update it too.

Repeated same steps for XP, and it now updated x264 too! All is well again.

WorBry
5th July 2010, 03:57
Have the same problem updating x264 1649 to 1659 (x86) from the developmental server - 1659 wont unzip. Clearing the update cache, rebooting and repeating update doesn't resolve it for me.

Edit: Tried again an hour later and it updated OK this time.

nakTT
5th July 2010, 06:40
Hi all,

I'm using spline64 for downsizing my resolution (is it better than lanczos?). The thing is the next time I want to use MeGUI again, the setting has been reverted back to lanczos (Sharp) from spline64 (sharp). Is there any way I can make the setting stick?

:thanks:

AMED
5th July 2010, 07:16
Hi all,

I'm using spline64 for downsizing my resolution (is it better than lanczos?). The thing is the next time I want to use MeGUI again, the setting has been reverted back to lanczos (Sharp) from spline64 (sharp). Is there any way I can make the setting stick?

:thanks:Make a Avisynth profile in Avisynth script creator.

MOS-Marauder
5th July 2010, 08:11
if you need square pixels dont check the anamorphic option (that means non-square pixels)

I didnt check it!!!

I simply loaded the DGI file.. cropped the file (640x288).

Input DAR was set to 16:9. Thats all i did there... And outcome again has CUSTOM PIXEL SHAPE in "About Mpeg4 Encoding" in Avinaptic.


In the Original Xvid COdec i can Choose Square Pixel... so why is there no Option in Megui for that?


Edit: I encoded the SAME AVS with the SAME SETTINGS now with VDub and outcome was as expected Square Pixels. NO Custom Shape. What can i do to change it in MeGui ?

Chris

nakTT
5th July 2010, 08:19
Make a Avisynth profile in Avisynth script creator.
Thanks. It worked like a charm.

:thanks:

Sharktooth
5th July 2010, 12:49
I didnt check it!!!

I simply loaded the DGI file.. cropped the file (640x288).

Input DAR was set to 16:9. Thats all i did there... And outcome again has CUSTOM PIXEL SHAPE in "About Mpeg4 Encoding" in Avinaptic.


In the Original Xvid COdec i can Choose Square Pixel... so why is there no Option in Megui for that?


Edit: I encoded the SAME AVS with the SAME SETTINGS now with VDub and outcome was as expected Square Pixels. NO Custom Shape. What can i do to change it in MeGui ?

Chris
if you didnt check anamorphic then it's square pixel. what reports avinaptic may vary due to the fact megui uses another interface for xvid... but still if the picture looks good (i mean the right proportions) then it is ok.
post a screenshot.

MOS-Marauder
5th July 2010, 12:55
SHot of the Picture or the Avinaptic output ?

Ive tested MeGui now ... also 720x576 uncropped 4:3 or 16:9 ... Every Encode results in Square Pixels in Avinatptic so there must be something not ok ....

From the Optics.. Imho both encodes look same (VDubmod+XVid / MeGui) but thats not the point iam aiming to... ;)


Output Avinaptic @ MeGUI:

Resolution: MEDIUM (640 x 288)
Width: multiple of 32 (GOOD)
Height: multiple of 32 (GOOD)
Average DRF quality: MEDIUM (3.738947)
Standard deviation quality: MEDIUM (1.242031)
Std. dev. weighted mean: MEDIUM (0.997095)

[ Video track ]

FourCC: xvid/XVID
Resolution: 640 x 288
Frame aspect ratio: 20:9 = 2.222222
Pixel aspect ratio: 1:1 = 1
Display aspect ratio: 20:9 = 2.222222
Framerate: 25 fps
Number of frames: 148568 (953)
Stream size: 639,134,959 bytes
Bitrate: 860.393838 kbps
Qf: 0.186717
Key frames: 1615 (0; 250; 500; 743; 993; ... 148372)
Null frames: 0
Min key int: 1
Max key int: 250
Avg key int: 91.992569
Delay: 0 ms

[ About MPEG4 encoding ]

User data: XviD0050
Packed bitstream: No
QPel: No
GMC: No
Interlaced: No
Aspect ratio: Custom pixel shape (1:1 = 1)
Quant type: H.263
Number of frames: 148568
Drop/delay frames: 0
Corrupted frames: 0


Same Video in Vdubmod+Xvid and all Settings same:


Resolution: MEDIUM (640 x 288)
Width: multiple of 32 (GOOD)
Height: multiple of 32 (GOOD)
Average DRF quality: MEDIUM (4.241983)
Standard deviation quality: MEDIUM (1.259045)
Std. dev. weighted mean: HIGH (0.650623)

[ Video track ]

FourCC: xvid/XVID
Resolution: 640 x 288
Frame aspect ratio: 20:9 = 2.222222
Pixel aspect ratio: 1:1 = 1
Display aspect ratio: 20:9 = 2.222222
Framerate: 25 fps
Number of frames: 148568
Stream size: 625,389,595 bytes
Bitrate: 841.890036 kbps
Qf: 0.182701
Key frames: 1579 (0; 300; 600; 743; 1043; ... 148472)
Null frames: 0
Min key int: 1
Max key int: 300
Avg key int: 94.089930
Delay: 0 ms

[ About MPEG4 encoding ]

User data: XviD0055
Packed bitstream: No
QPel: No
GMC: No
Interlaced: No
Aspect ratio: Square pixels
Quant type: H.263
Number of frames: 148568
Drop/delay frames: 0
Corrupted frames: 0







Chris

Sharktooth
5th July 2010, 13:03
screenshot of the source and encoded videos.
also what's the custom pixel shape reported by avinaptic?

MOS-Marauder
5th July 2010, 13:05
Here they are...

Dont wonder about the cropping at the Bottom.. Its beacuse this Movie has Hardcoded Subs.


http://www10.zippyshare.com/v/42271132/file.html

Ive done these with Avidemux .. Frame 4828.


Chris

btw.. my AVS:


LoadPlugin("C:\Program Files (x86)\megui-Dev\tools\dgindexnv\DGDecodeNV.dll")
DGSource("winter.dgi",fieldop=0)
#deinterlace
crop( 0, 70, 0, -32)

LanczosResize(640,288) # Lanczos (Sharp)
#denoise

Sharktooth
5th July 2010, 13:29
CUSTOM PIXEL SHAPE is just a flag set into the bitstream. pixel shape 1:1 IS square pixels.
as i said early, incoerencies in what avinapic reports may be due to the fact megui uses xvid_encraw interface instead of xvid VFW...
what matters is the pixel shape. 1:1 is square pixels. i dont know why avinaptic is reporting 1:1 as custom but still... it's 1:1 and so it is square.
infact megui and vdub produced pictures looks exactly the same.

MOS-Marauder
5th July 2010, 13:37
CUSTOM PIXEL SHAPE is just a flag set into the bitstream. pixel shape is 1:1 IS square pixels.
as i said early, incoerencies in what avinapic reports may be due to the fact megui uses xvid_encraw intefrace instead of xvid VFW...
what matters is the pixel shape. 1:1 is square pixels. i dont know why avinaptic is reporting 1:1 as custom but still... it's 1:1 and so it is square.
infact megui and vdub produced pictures looks exactly the same.

Yeh thats what i said.. looking same (allmost.. i guess that Enc with MeGui has more Details?).

So its more a Bug or bad "Tagging" in xvid_encraw ?

Standalone Players detect SQUARE and 1:1 differently...

Chris

Sharktooth
5th July 2010, 13:57
http://en.wikipedia.org/wiki/Pixel_aspect_ratio

look at the images... and you'll understand.

The aspect ratio of the pixels themselves is known as the Pixel Aspect Ratio (PAR) – for square pixels this is 1:1

as long as the PAR is 1:1 you get square pixels... no matter what.
so it's neither a bug or a bad tagging.
probably the bug is in avinaptic that reports a custom pixel shape even if the pixel shape is explicitly set to 1:1.

edit: if the bitstream doesnt have pixel shape signaled, it's usually assumed it is square. if the bitstream has 1:1 PAR signaled it IS square, no assumption required.
now, avinaptic seems to tell you that no-signaling is square pixels, while if pixel shape is signaled then avinaptic reports Custom even if it is set to 1:1.

MOS-Marauder
5th July 2010, 15:06
Jo i agree with u but some ppl still say mit must be written into the Bitstream. U know maybe some kind of Patcher ?

Btw i forgot... Welcome back ;)


Chris

Sharktooth
5th July 2010, 15:13
Jo i agree with u but some ppl still say mit must be written into the Bitstream. U know maybe some kind of Patcher ?

Btw i forgot... Welcome back ;)


Chris
Thanks.
Well, listen...
if the encoder doesnt specify the AR then it's usually assumed the encoding is made in square pixels... that's ok, coz even if the AR was missing you couldnt know.
however, if the AR is specified and it's 1:1 then we exactly know the encoding IS square pixel and we need no assumption and we know the AR isnt missing.
So, if avinaptic assumes 1:1 is a Custom AR, that's a limitation coz it only checks for the AR flag but doesnt check the actual AR values (even if it displays it).
A sane way of doing that would be checking the AR values and comparing them to common values so that 1:1 would be recognized as Square pixels coz it IS square pixels...

MOS-Marauder
5th July 2010, 15:32
Thanks.
Well, listen...
if the encoder doesnt specify the AR then it's usually assumed the encoding is made in square pixels... that's ok, coz even if the AR was missing you couldnt know.
however, if the AR is specified and it's 1:1 then we exactly know the encoding IS square pixel and we need no assumption and we know the AR isnt missing.
So, if avinaptic assumes 1:1 is a Custom AR, that's a limitation coz it only checks for the AR flag but doesnt check the actual AR values (even if it displays it).
A sane way of doing that would be checking the AR values and comparing them to common values so that 1:1 would be recognized as Square pixels coz it IS square pixels...

Yep i think so, too.. Anyway.. i found a Tool that patches the Headers ;)

"MPEG4Modifier"

So all is fine now ...

Chris

Sharktooth
5th July 2010, 15:57
you dont need to patch the header...

quantum5uicid3
5th July 2010, 16:54
i can't help but to bring it up again, because i don't think anyone commented on it. crf is a great feature, but sometimes it produces an unexpected result quality/bitrate above/below expectations. i find it's more practical to adjust the bitrate manually by just running a second pass at that point. i know i can just change the crf and renecode, but it's still kind of a guessing game how much of a +/- change to make.

basically im requesting an additional 1st pass mode in the advanced settings of the x264 configuration dialog. that uses ( --crf x --pass 1 --slow-firstpass ) , outputting both stats and video files.

I don't much like using my shitty batch file for encoding. :)

is there a disadvantage that i'm missing?

Sharktooth
5th July 2010, 17:03
yes. using CRF AND aiming for a bitrate.
you should chose one or the other.
however you dont need batch files since you can add custom commandline options to your CRF preset and specify --pass 1 --slow-firstpass and --stats ... and save it.
create a new preset with the same settings but in "2pass - 2nd-pass" mode with the new bitrate and let it go...

quantum5uicid3
5th July 2010, 17:26
I'm not needing any certain bitrate/filesize in particular, so most of the time i don't need two passes. just sometimes it gives an undesirable result, and it's often enough that I would just rather always wrtie stats with my crf encodes.

yeah i tried custom commandline but i couldn't figure out a way to take advantage of megui's automatic handling of the stats file name/location.

Sharktooth
5th July 2010, 17:44
assuming the source and the destination files are in the same folders there will be also the stats too.
just add --stats and the drive:\path\filename to the custom commandline options for both presets.
that will suffice to replace the megui stats handling.

quantum5uicid3
5th July 2010, 18:41
nvm, crf is infallible.

Sharktooth
6th July 2010, 16:33
im gradually adding newer x264 options such as the new Open GOP, NAL-HRD, infinite KeyInt etc.
that may break the ACTUAL presets, but if necessary i will publish updated ones together with the new megui version (still dev version)

Sharktooth
6th July 2010, 18:15
Megui dev version 0.3.5.2 BREAKS the x264 PRESETS.
Please BACKUP ALL YOUR x264 PRESETS BEFORE UPDATING.

Frogger13
6th July 2010, 22:24
You can find the installation instructions here:
http://forum.doom9.org/showthread.php?p=1390397#post1390397

Thanks for the Information, but I keep getting following error:

http://img267.imageshack.us/img267/4698/errorjl.jpg

AviSynth64 is installed and working. MeGUI64 is in the same path as MeGUI32. But also if I put the x64 files in a separate Directory, the error is the same.

Edit: Installed .NET Framework is incremental .NET Framework 3.5 (http://www.microsoft.com/downloads/details.aspx?FamilyId=333325fd-ae52-4e35-b531-508d977d32a6&displaylang=en) + hotfixesMeGUI x64 must be installed in a different directory than MeGUI x86. But this is not the source of the error. It seems that you need to install a Visual C++ x64 Redistributable Package (there are several ones and newer ones do not include the older packages)

Well I tried and installed VC++ Redist 2005, 2005 SP1, 2008, 2008 SP1 and 2010... But I still get the Same error... :confused:

System is Xp x64 and MeGUIx64 has its own directory now...

BTW I'm wondering why there are no x64 builds of the DLLs?! Am I missing something :confused::confused::confused:

FraGTaLiTy
6th July 2010, 22:36
Megui dev version 0.3.5.2 BREAKS the x264 PRESETS.
Please BACKUP ALL YOUR x264 PRESETS BEFORE UPDATING.

Is there a way to fix this? It won't let me re=add my presets.

doc_dvxm
7th July 2010, 00:19
I've updated it without backup and all x264 presets have been lost.....

Now I'am starting tests with new version with new self generated "Unrestricted (DXVA) Very High Profile" for x264.

OS: Win 7 32 Bit Ultimate.

Everythings look fine...

Sharktooth
7th July 2010, 01:03
Is there a way to fix this? It won't let me re=add my presets.
yes: http://forum.doom9.org/showthread.php?p=1415179#post1415179

Sharktooth
7th July 2010, 01:04
I've updated it without backup and all x264 presets have been lost.....

Now I'am starting tests with new version with new self generated "Unrestricted (DXVA) Very High Profile" for x264.

OS: Win 7 32 Bit Ultimate.

Everythings look fine...
same answer as above. megui automatically made a backup folder with your old presets.
read this post if you need your old presets: http://forum.doom9.org/showthread.php?p=1415179#post1415179

quantum5uicid3
7th July 2010, 10:30
sorry but imho the change in the profiles was a regression, why break them now? the same problem exists as before, device compatibility isn't maintained when changing the speed --preset and now there's going to be a hundred questions about why i lost my profiles.