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

forum king

4th February 2010, 04:51

Thanks quantum matey :)
a few Q
.. i am thinking of usinf -2,-1 as deblocking , and subme 7 ( coz slider does stuff but i believe some tweaks are inevitable like the deblocking , bframes (10) , ref frames 8-10 , off course ME algorithm..
all the other settings i am leaving as they were in the earlier unrestricted 2 pass..

are these reasonable ?

help_me!

4th February 2010, 17:13

I don't understand how i can get 5 Reframes.
I configured this profile:

http://www.abload.de/thumb/3yddg.jpg (http://www.abload.de/image.php?img=3yddg.jpg) http://www.abload.de/thumb/19coj.jpg (http://www.abload.de/image.php?img=19coj.jpg) http://www.abload.de/thumb/4tgyk.jpg (http://www.abload.de/image.php?img=4tgyk.jpg) http://www.abload.de/thumb/2pckl.jpg (http://www.abload.de/image.php?img=2pckl.jpg) http://www.abload.de/thumb/5icb8.jpg (http://www.abload.de/image.php?img=5icb8.jpg)

with the follwoing result:

What must i change to get this?

I have the same problem. Anyone can help us? :)

poisondeathray

4th February 2010, 17:21

I don't understand how i can get 5 Reframes.

You entered 5 and got 5. (look at your 4th screenshot). What's the problem?

EDIT: Oh I See, there is a difference in mediainfo. It reports 4 at the top and 5 at the bottom for the encoding settings. Perhaps mediainfo is reading it incorrectly?

Format settings, ReFrames : 4 frames
Encoding settings : cabac=1 / ref=5

You have to use a stream analyzer like h264visa or streameye to be certain what it really is, mediainfo just reads the header and maybe incorrect

What does the log file say?

quantum5uicid3

4th February 2010, 17:46

one of the options lowers --ref by one. i forgot the details, b-pyramid perhaps. it's expected.

Fr4nz

5th February 2010, 13:23

I upgraded to the latest version of x264 last night and now It crashes anytime I try running a job. I reverted back to the previous version and it's working fine now.

Just thought i'd give everyone a heads up.

Same thing here: had to revert from 1416 to 1400. It seems that all 1416 builds are affected (not only the komisar build bundled with MeGUI);

Oh Zathor, I'd like to ask you also another thing: actually MeGUI tries to force you to use the "official" x264 build downloaded from MeGUI repository (if I use a custom build it always asks me to upgrade); it would be nice if we could use more easily customized builds, as the old versions of MeGUI let you do.

Ah, my specs:

Win7 64-bit;
Intel E6750 (but it crashes also on my other PC, an AMD quad-core);
2Gb of RAM;
etc.

Command-line used:
program --profile high --level 4.1 --preset slow --tune film --pass 2 --bitrate 3440
--stats ".stats" --thread-input --b-pyramid normal --slices 4 --vbv-bufsize 15000
--vbv-maxrate 15000 --aud --nal-hrd --threads 4 --output "output" "input"

Zathor

5th February 2010, 15:25

Oh Zathor, I'd like to ask you also another thing: actually MeGUI tries to force you to use the "official" x264 build downloaded from MeGUI repository (if I use a custom build it always asks me to upgrade); it would be nice if we could use more easily customized builds, as the old versions of MeGUI let you do.

If you want to have your own build you can disable the update check for this file and copy your files into the \tools\x264 directory.

And what kind of crash do you get? Is MeGUI crashing or x264 or... and what kind of error message do you get. Can you provide more details about your avs file and the source file? I would like to reproduce this problem.

Fr4nz

5th February 2010, 16:02

If you want to have your own build you can disable the update check for this file and copy your files into the \tools\x264 directory.

Yes I know this, but old version of MeGUI didn't bother for an update if it found a custom x264 build... :D

And what kind of crash do you get? Is MeGUI crashing or x264 or... and what kind of error message do you get. Can you provide more details about your avs file and the source file? I would like to reproduce this problem.

Apparently the culprit is x264; the behaviour is system dependent: on my Intel it doesn't crash, it simply freezes (and the CPU stays at 100%); on my father's AMD a message is returned (atm I don't remember it, I'm going to give you an update later when I can access it again), but when I close the window of that message, the x264 window remains open, so it also seems a lock-up at the end.

The avs file I'm using is this:

DirectShowSource("E:\work\Condiviso\INGLORIOUS\inglorious.mkv", fps=23.976, audio=false, convertfps=true)
BilinearResize(1280,720) # Bilinear (Soft)

In this case the source is an original Inglorius Bastards blu-ray disc, italian version, extracted with makemkv, but note that lockups occur with every movie I've tried. Another curious thing is that lockups occur always at frame 10290 during the first pass.

I've tried also to use an unpatched x264 build and exclude settings regarding blu-ray compliancy (NAL-HRD), but the problem persists.
The only solution is reverting back to x264 version 1400.

MrCommunistGen

6th February 2010, 00:52

I don't understand how i can get 5 Reframes.

I'm not entirely sure what ReFrames actually means in MediaInfo (I've been using it pretty much as long as it has existed) but it is not an actual measure of reference frames. For a lot of my older x264 based encodes it was way off. Back then I was using ref=3 and MediaInfo often shows ReFrames of 7 or more if I remember correctly... I'm not at home right now (to clarify: if I check my old encodes with the current version of MeGUI). With newer builds (or maybe my newer settings) the MediaInfo reported ReFrames has gotten closer to the actual number of references, but as you've found it does not always represent the actual value.

If you check your log after the encode you will see that x264 actually is using 5 reference frames (based on your command line).

-mcg

TheSane

7th February 2010, 09:48

I have the same problem. Anyone can help us? :)

So, i have the conclusion of the mysterious "bug".
I recoded the movie once more and disabled "b-Pyramid" and the correct reframe where used.
The only thing i don't tested yet, when i increase the reframe number with activated b-pyramid, if there is a decrease of one or the fall back to 4 reframes.

one of the options lowers --ref by one. i forgot the details, b-pyramid perhaps. it's expected.

You could be right, thanks for your hint.

I'm not entirely sure what ReFrames actually means in MediaInfo (I've been using it pretty much as long as it has existed) but it is not an actual measure of reference frames. For a lot of my older x264 based encodes it was way off. Back then I was using ref=3 and MediaInfo often shows ReFrames of 7 or more if I remember correctly... I'm not at home right now (to clarify: if I check my old encodes with the current version of MeGUI). With newer builds (or maybe my newer settings) the MediaInfo reported ReFrames has gotten closer to the actual number of references, but as you've found it does not always represent the actual value.

If you check your log after the encode you will see that x264 actually is using 5 reference frames (based on your command line).

-mcg

Can't approve your experience.

forum king

7th February 2010, 18:21

TDC.net

7th February 2010, 22:45

Having issues with the x264 build from the dev-server here.
The resulting video does not play correctly with ffdshow (skipping several frames, repeatable) and it cannot be muxed with MKVtoolnix.
I coded the file again with the new x264 build and again it failed.

Downgraded to x264 from stable server: File is 100% ok, muxes fine.

Any idea what's wrong with the dev-build?
Thanks

Dark Eiri

8th February 2010, 01:32

I'm having no issues with it. Working flawlessly with several encodes, muxed to MKV just fine.

forum king

8th February 2010, 04:27

hey folks please advise if you can , i ll be thankful folks :)
1.. on the first page of this thread zarhor says use 1056 build and install and update, which update server to use
Default or development ( its not mentioned )
2.. The newer builds have certainly raised the bar of encoder settings :D
i wanted to ask how much subme is enough if are encoding at low bit rates i mean 600 to 1000 , also how mant ref frames and bframes are sufficient ( i am concerned more about quality and less about speed but no doubt a balanced setting will be prefeered which is not very slow... )

3 .. i am unable to decide upon deblocking , sometimes 0.0 give very good results and sometimes it doesnt, i find edges horribly blurred..

regards

guys also .. after the last 2 updates i am seeing that the settings which used to give me decent quality are encoding lot of blocks and blurred edges despite good bitrate ( then before )
could some one suggest me how can i reverse all the chnges that have been made in last 2 updates ( the first had some files other than x264 build updated and the second has x264 and a few more ) after that i didnt update at all.. :(

Zathor

8th February 2010, 17:22

Yes I know this, but old version of MeGUI didn't bother for an update if it found a custom x264 build... :D
MeGUI has never ever checked the files. So it doesn't matter if you copy a custom build to the directoty as long as the file names are still present (x264.exe, x264_64.exe, vfw4x264.exe and avs4x264.exe).

The only solution is reverting back to x264 version 1400.
I have forced a downgrade at the development server now. I have still no problems but there have been several reports like yours.

1.. on the first page of this thread zarhor says use 1056 build and install and update, which update server to use
Default or development ( its not mentioned )
Use the server you like. The default / stable one should be more stable and with the development server you get the latest tools and builds.

guys also .. after the last 2 updates i am seeing that the settings which used to give me decent quality are encoding lot of blocks and blurred edges despite good bitrate ( then before )
It may be that the video is fine but your decoder can't play it properly. Try adding --weightp 0 to the custom command line.

aegisofrime

8th February 2010, 17:49

I'm not sure if this will help, but I have been using an AMD optimized 1416 version compiled by outlaw87 over at Doom10 without any problems. My encodes are TGMC'ed DVD videos...

Here's the link to grab the build, if you guys want to try it out.

http://doom10.org/index.php?topic=26.msg1265#msg1265

My settings are simply CRF 21 with Preset "Slower", tuning Film. Nothing else.

Fr4nz

8th February 2010, 21:53

I have forced a downgrade at the development server now. I have still no problems but there have been several reports like yours.

Okay. I wrote in the x264 subforum, let's see if someone can make some light on this issue.

mozzle

9th February 2010, 01:35

Okay. I wrote in the x264 subforum, let's see if someone can make some light on this issue.

Just for the record, I too had issues with x264 1416. My encode would go for about an hour and then x264 would crash. It did this twice in a row so I reverted to 1400 and things worked fine again.

quantum5uicid3

9th February 2010, 19:45

i also have no issues with 1416. what decoder and settings are you guys using?

Fr4nz

9th February 2010, 22:58

i also have no issues with 1416. what decoder and settings are you guys using?

I'm using the latest ffdshow tryouts as decoder and these are the "usual" settings I use under MeGUI:

program --profile high --level 4.1 --preset slow --tune film
--pass 2 --bitrate XXXX --stats ".stats" --thread-input
--b-pyramid normal --slices 4 --vbv-bufsize 15000 --vbv-maxrate
15000 --aud --nal-hrd --threads 4 --output "output" "input"

thedozer

11th February 2010, 18:47

rapscallion

12th February 2010, 21:03

see post # 767 above. Also the dev server will now downgrade to 1400, just click on the "update" option to see it.

Zathor

12th February 2010, 21:38

Also the dev server will not downgrade to 1400
I'm confused. The downgrade works for me. Maybe you have mixed up not and now?

rapscallion

12th February 2010, 22:25

Z...that's exactly what happenned.Post edited.

thedozer

12th February 2010, 22:32

I tried 1400 build and it does the same (skipping frames) but not as always, the best build I could find is 1376 which is in the stable update

help_me!

13th February 2010, 11:08

Zathor

13th February 2010, 13:02

I can confirm that:

Megui from development server produces videos that neither the DXVA decoder of MPC-HC nor FFDSHOW can decode properly.
Megui from stable server produces videos that play perfectly on both.

Most likely it's the newer x264 versions that are problematic.

So you have changed nothing beside the x264 build? Are the problems reproducable with 1400/1416? Please provide more information about your system (especially 32/64 bit), the source file, avs used and the megui log (command line for x264).

help_me!

13th February 2010, 15:22

So here's what I did for you:

Uninstalled Megui, and did a fresh install of 1056.
Updated to the latest core and tools from stable server.
Encoded a video (Unrestricted DXVA - Very High Quality, preset: slower)
It plays beautifully.

Updated the x264 (only) from the development server. (I have also tested to update the core and tools, the problem is exactly the same)
Encoded the same video with the same settings.
Upon playback MPC-HC DXVA crashes, MPC-HC with FFDSHOW decoding skips tons of frames.

Both of the videos are included in the following rar: http://www.massmirror.com/a32d8720450fe289baf163e6f8ac531b.html
The one with the underscore "_" is the problematic.

I'm using Windows 7 x64, a quad core, source file is a 291MB HFYU avi, script consists of opening the source with AviSource and converting to YV12 with ConvertToYV12.

Zathor

13th February 2010, 15:35

I'm using Windows 7 x64
x64 - so maybe vfw4x264.exe or x264_64.exe could be part of the problem. Please rename the file vfw4x264.exe and rename avs4x264.exe to vfw4x264.exe. Does the newly encoded file still crash? If yes, then rename x264_64.exe to something else and rename x264.exe to x264_64.exe. Does the new encode crash? Rename the original vfw4x264.exe back to vfw4x264.exe and try again. If it is still not working then delete/rename vfw4x264.exe and rename the original x264.exe back to x264.exe and try it again.

help_me!

13th February 2010, 15:51

Tried all of the combinations.. result is always a file that crashes upon playback.

thedozer

13th February 2010, 18:17

I'm having the same results as "help_me!" in a Win7 32bit system with a Core2Duo processor

I also encoded different types of video files like: AVI(Xvid), MP4(H264) and MKV, and I always have the same result which is skipping frames mostly at the beginning of the videos.

I only use FFDShow for decoding though.

mozzle

13th February 2010, 22:16

This x264 issue is bizarre. Some folks have no issues while others are experiencing crashes and still others are successfully encoding but with a bunch of skipped frames.

WTF?!?

Inspector.Gadget

13th February 2010, 22:26

No issues here with the x264 1400 downgrade on Vista x64 and muxed with mkvmerge / then using Haali -> MPC-HC internal DXVA decoder to play back resulting file.

horvathd

13th February 2010, 22:55

I made some testing around the x264 r1416 and the problem is with the builds by Komisar, not the x264 itself.

I don't know which versions were included into MeGUI (generic or core2, 32 or 64 bit). The main problem is that the generic 32 and 64 bit executables are the same, probably due mislabeling. They should be the the 64 version because they don't run on my PC. (The core2 32 and 64 bit version also don't run.)

I suggest grab an executable from the following topic http://doom10.org/index.php?topic=3.0 or build one yourself. I did the latter one, and left out the unused lavf and ffms input methods.

thedozer

13th February 2010, 23:28

@horvathd:
For my tests I used 1400 & 1416 builds from http://x264.nl and still the same problem with those skipped frames.

I should mention that I only mux into MKV, and skipped frames sometimes play normally after muxing the encoded video with audio using mkvmerge.

saint-francis

13th February 2010, 23:35

I must say that there are no problems on my end with the Dev build. I've been using it all the time too.

horvathd

13th February 2010, 23:42

@thedozer:
Then probably you should report this issue in this topic (http://forum.doom9.org/showthread.php?t=108571) to the developers.

quantum5uicid3

13th February 2010, 23:46

someone upload some clips

help_me!

14th February 2010, 02:45

horvathd

14th February 2010, 08:45

I did: http://forum.doom9.org/showthread.php?p=1373819#post1373819

The one with the _ (encoded with the x264 from the dev. server) doesn't play correctly.
The other one (encoded with the x264 from the stable server) plays without problems.

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

Poutnik

14th February 2010, 09:42

Vulnerability scan of Personal software inspector by Secunia.com claims that
mplayer.exe 0.x version in mencoder tool folder of MeGUI is not supported anymore.

( it means in general authors of such product either did not respond to several vulnerability notifications,
or they responded or actively announced the product version is not supported anymore )

Edit: It seems all revealed vulnerabilities for MP 0.x seems patched, but it need not to be checked anymore.
http://secunia.com/advisories/product/2129/?task=advisories

OTOH, with mplayer 1.x the situation is not better as far as several vulnerabilities are unpatched
Both of Highly Critical vulnerabilities of all 4 unpatched issues
seems related to media streaming, so in context of MeGUI they do not look like big issue.
http://secunia.com/advisories/product/2255/?task=advisories

Zathor

14th February 2010, 11:59

Honestly said I have no idea anymore regarding the x264 problem. Can someone with the problem please try to encode from the command line with the official build 1416 from x264.nl? (Use the command line from the MeGUI log - replace vfw2x264.exe with x264.exe in the command line if running on x64 and of course replace the file x264.exe with the one from x264.nl). If the problem can be reproduced this way with build 1416 and with build 1376 (from the stable server) it is gone I assume that the x264 build is the source of the problem.

help_me!

14th February 2010, 12:44

Using 32bit 1416 from x264.nl (not messing with vfw) and the same settings as previously produces a file that:
- the MPC-HC DXVA decoder doesn't crash this time but now has the same problem of skipping frames like the FFDSHOW decoder did (I've never tested 1416 before so maybe that's why there's slightly different behavior from 1400)
- FFDSHOW skips frames as previously with megui's dev. server x264 1400

Using 32bit 1376 from x264.nl:
- with MPC-HC DXVA decoder plays great!
- with FFDSHOW plays great!

quantum5uicid3

14th February 2010, 14:32

sorry didnt see them. can you upload a clip of the source plz

Fr4nz

14th February 2010, 16:59

Hi Zathor, I have good news!

With latest MeGUI development version (0.3.3.5 with all the components updated) I don't have anymore freezing problems with unpatched 264.nl 1416 64-bit build. I guess that something in MeGUI code was updated and solved this issue.

Now I'm gonna try Komisar 1416 NAL-HRD patched build in order to see if it also works with MeGUI...

UPDATE: Okay, the culprit seems to be Komisar's 1416 builds: they keep freezing; don't use them.

UPDATE2: Found that probably there's a bug in NAL-HRD patch; see here (http://forum.doom9.org/showpost.php?p=1374315&postcount=2988);

help_me!

14th February 2010, 18:58

sorry didnt see them. can you upload a clip of the source plz

http://www.megaupload.com/?d=D1T7FUXN

Here's a 4 second clip from the 10 second Huffyuv source. Size is a bit big as you can understand (120MB) but Megaupload should give you good speeds. :)

quantum5uicid3

15th February 2010, 11:29

http://www.megaupload.com/?d=D1T7FUXN

Here's a 4 second clip from the 10 second Huffyuv source. Size is a bit big as you can understand (120MB) but Megaupload should give you good speeds. :)

komisar 1416/hrd both 32 and 64 are working flawlessly on this too. plz post your settings, but i think a decoding chain issue is more likely though, like the haali media splitter prob horvathd pointed out.

addition:

i tried 32bit and 64bit outputting to mp4, mkv, and raw. all played back perfectly with both dxva and ffdshow...

Fr4nz

15th February 2010, 11:46

komisar 1416/hrd both 32 and 64 are working flawlessly on this too. plz post your settings, but i think a decoding chain issue is more likely though, like the haali media splitter prob horvathd pointed out.

addition:

i tried 32bit and 64bit outputting to mp4, mkv, and raw. all played back perfectly with both dxva and ffdshow...

Actually latest Komisar's NAL-HRD patched build is bugged (culprit is the NAL-HRD patch used). See here (http://forum.doom9.org/showpost.php?p=1374315&postcount=2988) and here (http://forum.doom9.org/showpost.php?p=1372665&postcount=769).

quantum5uicid3

15th February 2010, 11:59

what's the trigger? i'm enabling nalhrd on all encodes and yet to have an issue. is it a certain vbv?

Fr4nz

15th February 2010, 12:07

what's the trigger? i'm enabling nalhrd on all encodes and yet to have an issue. is it a certain vbv?

This is what I get when using avs2yuv (but it freezes also with MeGUI):

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Assertation failed!
Program: E:\dvd\avs2yuv\x264_x64.exe
File: encoder/set.c, Line 679
Expression: dpb_output_delay < pow( 2, sps->vui.nal_hrd_parameters.i_dpb_output_delay_length )
E:\work\Up.2009.1080p.avs:
1920x1080, 2500000/104271 fps, 138282 frames
Output error: wrote only 2676405 of 3110400 bytes

Fatal Error: The encoder has encountered an unexpected error!