MeGUI - x264/XviD/lavc/Snow encoder with MP4/MKV/AVI output & audio [Archive] - Page 49

Atavarius

12th February 2010, 10:53

To be honest, I don't think your attitude is helping the situation here either...

It is important that discussions about technical issues remain technical. If you start attacking each other (this goes for both of you), nothing will get done.

Agreed DS, and apologies to all. His tone just really got under my skin.

Neil,

Honestly, I would like to help, and I am sure many in the community here are willing. You've laid out what you want in a profile, so put a few together and post them here. People can go over them and critique and you can distribute them at your leisure. If you want help in building them, then layout to us that devices you are shooting for and what encoding methods (well I guess your preference for 2 pass has been established:p) you want to use.

Neillithan

12th February 2010, 11:06

Agreed DS, and apologies to all. His tone just really got under my skin.

Neil,

Honestly, I would like to help, and I am sure many in the community here are willing. You've laid out what you want in a profile, so put a few together and post them here. People can go over them and critique and you can distribute them at your leisure. If you want help in building them, then layout to us that devices you are shooting for and what encoding methods (well I guess your preference for 2 pass has been established:p) you want to use.

I can only tell you what I would like to see for presets. More than a year ago, I would use the Unrestricted presets, which were formerly named simply "x264 2-pass extreme" or something to that nature. In an effort to avoid creating L5.1 AVC videos, I started using the DXVA presets. In the latest update of MeGUI, the DXVA presets have been renamed (or changed) to Unrestricted (DXVA).

I have not yet researched what makes the new DXVA presets "Unrestricted", but in an effort to retain consistency across all platforms, I started using and suggesting the PS3-Xbox360 preset.

Also, to further complicate things, there are new AVCHD presets. I don't know much about AVCHD other than a video encoded and formatted as a Blu Ray structure can be burned to DVDs and played in most Blu Ray players.

Whether or not that makes them incompatible with the Xbox360, or other hardware media streamers, I don't know... but in an effort to choose the least harmless preset, it is becoming annoying to rediscover the presets every 6 months and at the same time, it is a growing concern for me and the people I teach how to use MeGUI. They tend to come back to me with questions regarding the presets, which is already a very annoying topic.

I assumed the DXVA presets were the golden ones that work on anything, but now that they have been renamed to "Unrestricted", I'm not so sure anymore.

So in addition to teaching the fundamentals of bitrates and multiple pass encodings, I have to teach something totally irrelevant like x264 presets.

I consider myself acquainted to video encoding and MeGUI based on a few years of experience with different programs and trial and error. I possess no means to create my own presets, nor do I WANT to, which I have stated more than once now.

-Neil

Atavarius

12th February 2010, 11:37

I don't think you're ever going to really get a profile that will work 100% on every decoder out there. Especially since some of the hardware decoders get pretty touchy on what setting can be used.

From a quick glance at the 2-pass DXVA profile, you can simply change the AVC level to whatever level you wish and it will no longer be unrestricted. From there you just need to enter whatever bitrate you calculated and you should be fine. If you want more specific you will have to tailor a profile to your specific decoder.

Neillithan

13th February 2010, 04:36

After some experimentation, I can say that Constant Quality has confirmed all of my suspicions.

I used a 21second 1080p 30fps video (No Audio) captured from Unreal Tournament 3, which has lots of motion, so its compressibility should be very difficult.

Using the "Unrestricted (DXVA) Insane" Preset, it created an 82MB file. Average bitrate: 31,000

Using the "Unrestricted (DXVA) Balanced" Preset, it created a 42MB file. Average bitrate: 17,000

Using the "Unrestricted (DXVA) Standard" preset, it created a 35MB file. Average bitrate: 14,000

Each of these files exceeds a 10,000 bitrate, which allow me to explain why this is bad.

Unless your computer meets 1 or more of these 3 requirements, it will have difficulty playing this video.

1. At least a dual core CPU
2. GPU acceleration for video decoding of AVC videos.
3. A super fast software decoder like CoreAVC

Why is this bad? Because by being lazy and using Constant quality, the filesizes are MUCH larger than a 2-pass encoding with a specified bitrate less than 10,000 and they are much more difficult to decode due to the high bitrates.

By imposing Constant Quality on most presets, you are making non tech savvy users to MeGUI create videos that are 1. Much larger than they need to be and 2. Much more CPU intensive to decode, given the source material.

By using 2-pass and learning how bitrate influences filesize and decoding requirements, you leave nothing up to chance. This is the way MeGUI used to work. 2-pass was the default selection.

On top of that, the bitrate calculator can give you a really good idea of what the resulting filesize will be, and it offers to implant the bitrate into your video preset.

To make matters worse, when selecting a preset that defaults to constant quality, if you attempt to use the bitrate calculator to implant a bitrate, rather than select 2-pass as the default mode, it selects ABR, which is something I have never seen MeGUI do!

I cannot begin to express how faulty MeGUI has become.

-Neil

Dark Shikari

13th February 2010, 05:01

...CPU intensiveness depends on the maximum bitrate, not the average. If you want to attempt to avoid situations where videos have overly intensive segments, you need to have VBV on by default as well.

This of course will create situations in which some difficult portions of videos need a lot more bitrate than the maximum, will look bad, and people will complain about them.

There's no such thing as a free lunch.

nurbs

13th February 2010, 10:27

Why is this bad? Because by being lazy and using Constant quality, the filesizes are MUCH larger than a 2-pass encoding with a specified bitrate less than 10,000 and they are much more difficult to decode due to the high bitrates.

By imposing Constant Quality on most presets, you are making non tech savvy users to MeGUI create videos that are 1. Much larger than they need to be and 2. Much more CPU intensive to decode, given the source material.

You got a high bitrate because it is 1080p video game footage. That's not exactly easy to encode. If you had used another clip the resulting bitrate might have come out as 5 Mbps and then your 10 Mbps clip would be 1. Much larger than it needs to be and 2. Much more CPU intensive to decode, given the source material. I doubt that you can determine the compressibility of the clip just by looking at the source material.

To make matters worse, when selecting a preset that defaults to constant quality, if you attempt to use the bitrate calculator to implant a bitrate, rather than select 2-pass as the default mode, it selects ABR, which is something I have never seen MeGUI do!

I cannot begin to express how faulty MeGUI has become.

You could begin by filing a bug report (http://sourceforge.net/tracker/?group_id=156112&atid=798476), which you haven't bothered doing yet.

It's the same with the profiles. Instead of just complaining you could make your own. Maybe you can post them somewhere on the forum so the people you teach and the 5000 people the situation annoys according to you get something out of it.

Neillithan

13th February 2010, 10:32

I created profiles with my limited knowledge. I basically used the DXVA Unrestricted 2-pass preset as a starting point. I changed it from "autoguess" to "High". I created profiles for each individual preset (medium, slow, slower etc...). I named them in a way so that they appear in numerical order in the "Encoder Settings" dropdown menu.

Here they are.

http://www.filefront.com/15571911/Neil%27s%20x264%20dxva%202-pass%20profiles.zip

I understand what the new profiles and preset slider are designed to do. They're designed to simplify the "Encoder Settings" dropdown menu, but that is not ideal in my opinion. The dropdown menu shows an "at a glance" view of the individual profiles". If the "Encoder Settings" dropdown had individual presets for the different speeds, I wouldn't be forced to use the "Config" to adjust the speed or complexity of the profile.

It would be better if there were 2 dropdown menus so that a "basic" set of profiles are selectable using the "Medium" preset as default. The second dropdown menu would allow you to choose a second list of profiles that change the preset to whatever speed you prefer (Medium, slow, slower etc...).

That may complicate things, but if you consider the current way profiles work, it's really bad. If you try to configure a profile to change the preset to whatever speed you want, it bugs you to save the preset. Maybe I don't want to save the preset just so I can choose a different speed, which is why I suggest the "multiple dropdown lists" idea.

Also, as another suggestion, it might be worth it to change some terminology in the GUI. Instead of "presets", why not consider "speed" or "complexity". Speed more closely resembles the naming scheme for "Slow", "Slower"... "Complexity" is more accurate (in my opinion). The word "preset" is too ambiguous. You could also just insert the word "Speed" before the word "Preset": Speed Presets.

-Neil

Neillithan

13th February 2010, 10:47

You got a high bitrate because it is 1080p video game footage. That's not exactly easy to encode. If you had used another clip the resulting bitrate might have come out as 5 Mbps and then your 10 Mbps clip would be 1. Much larger than it needs to be and 2. Much more CPU intensive to decode, given the source material. I doubt that you can determine the compressibility of the clip just by looking at the source material.

Yes, I am well aware that the video footage I used was extremely difficult to encode. That's why I used it as an example. Whether it's a high action packed scene of a movie, or a video of Unreal Tournament, the probability of getting an extremely high bitrate outweighs the benefits of using constant quality. I remember watching a video that was created in Vegas that used a film grain effect. More than likely, using Constant Quality on any video that has a manual film grain effect like that would produce a high bitrate video.

The very unsubtle point I'm making is, Constant Quality is not ideal for most situations, whereas 2-pass most certainly is and should be the default method, as it has been for most of MeGUI's existence.

You could begin by filing a bug report (http://sourceforge.net/tracker/?group_id=156112&atid=798476), which you haven't bothered doing yet.

It's the same with the profiles. Instead of just complaining you could make your own. Maybe you can post them somewhere on the forum so the people you teach and the 5000 people the situation annoys according to you get something out of it.

Done.

nurbs

13th February 2010, 11:27

I basically used the DXVA Unrestricted 2-pass preset as a starting point. I changed it from "autoguess" to "High". I created profiles for each individual preset (medium, slow, slower etc...).
If you only have medium and slower presets setting the profile to high doesn't change anything, because these presets create high profile output anyway. Even if they didn't why would you want to indicate a higher profile than the stream was encoded at? If you want to ensure higher compatibility to old DXVA hardware and standalone hardware players you should set the level to 4.1 and add the necessary VBV parameters if you haven't done that already.
Instead of "presets", why not consider "speed" or "complexity".
Because the command line parameter is --preset and changing the GUI label to something different would likely be confusing instead of helpful.
Whether it's a high action packed scene of a movie, or a video of Unreal Tournament, the probability of getting an extremely high bitrate outweighs the benefits of using constant quality. I remember watching a video that was created in Vegas that used a film grain effect. More than likely, using Constant Quality on any video that has a manual film grain effect like that would produce a high bitrate video.
Well, yes, getting an extremely high bitrate can be a result of constant quality depending on the source. That's the point of using CRF after all. The video gets as much bitrate as is needs without the user having to worry about it.
If you want a lower bitrate for a grainy video while keeping most of the details your best bet is some avisynth filters (MCTemporalDenoise, MVDegrain, ect.) to get rid of at least part of the grain before encoding. If you are okay with a less accurate representation of the source in general you can encode everything including other clips without grain at a higher CRF value and save some space.
The very non subtle point I'm making is, Constant Quality is not ideal for most situations, whereas 2-pass most certainly is and should be the default method, as it has been for most of MeGUI's existence.
For the average user 2-pass is ideal in exactly one situation, when you have space constraints e.g. a DVD. If you use hardware decoders or you have a slow CPU your best chance is constraining the encode to Profile@Level+VBV and you can do that with CRF as well as 2-pass. At the same time you don't have to do any extra setup. With 2-pass you still have to pick a bitrate. If you have space constraints you have no choice anyway. If you don't you can't really know if you are wasting bits or starving the encode without a compressibility test.

quantum5uicid3

13th February 2010, 13:51

we need like a 12 step program for life without the sharktooth profiles or something

stax76

13th February 2010, 14:12

The defaults in x264 are very good, StaxRip uses them 1:1, constant quality mode is the default in x264 and in StaxRip it's the default since years even before x264 existed, it's the only mode I use and recommend since years. Thinking 2pass mode is more efficient then constant quality mode is one of the most common misconceptions and because of this StaxRip has a help button right besides the Mode option explaining the difference:

Generally there are two popular encoding modes, quality based and 2pass. 2pass mode allows to specify a bit rate and file size, quality mode doesn't, it works with a rate factor and requires only a single pass. Other terms for quality mode are constant quality or CRF mode in x264.

Slow and dark sources compress better then colorful sources with a lot action so a short, slow and dark movie requires a smaller file size then a long, colorful source with a lot action and movement.

Quality mode works with a rate factor that gives comparable quality regardless of how well a movie compresses so it's not using a constant bit rate but adjusts the bit rate dynamically. So while the same rate factor can be applied to every movie to achieve a constant quality this is not possible with 2pass mode because every movie requires a different bit rate. Quality mode is much easier to use then 2pass mode which requires a longer encoding time due to 2 passes and a compressibility check to be performed to determine a reasonable image and file size which also requires more expertise.

It's a common misconception that 2pass mode is more efficient than quality mode. The only benefit of 2pass mode is hitting a exact file size. Encoding in quality mode using a single pass will result in equal quality compared to a 2pass encode assuming the file size is identical of course.

Quality mode is ideal for hard drive storage and 2pass mode is ideal for size restricted mediums like CD's and DVD's. If you are still not sure which mode to use then it's probably better to use quality mode.

So yes, of course it's true that 2pass requires more effort and experience.

Users should really not rely on profiles made by a GUI but try to understand x264 directly and build their own profiles. Since presets and tunings were introduced there aren't many excuses any longer that this is difficult, maybe because of devices but devices can be integrated in the GUI in a similar way presets and tunings are integrated in x264, that is much better than having device options only in profiles, also devices will be integrated in x264 since ease of use is a primary design goal for x264.

MeGUI is designed for experienced users and don't take care of newbies, this has been stated by various MeGUI developers in the past, this causes newbies a lot of problems, instead of complaining they either need to learn or use a application designed for them.

quantum5uicid3

13th February 2010, 15:27

i guess ill add:

as ive said before

maybe im wrong, but im yet to be corrected, dxva in itself is not restricted. specific decoders, maybe all atis still?, and older nvidia video cards have limitations @4.1. a $80 low profile 9600gt and mpc-hc does not. --level 4.1 should be sufficient if unrestricted is cause u problems. ( it is on my 8400gs) ive asked for the current state of dxva from the ati side of the fence but never heard anything. basically my view was that the 9600gt's are pretty shitty at this point in the world of video. if they can handle it, then i think it would be silly to keep encoding vids to conform to programmer's laziness and a decision to do so would be more specific then a general rule.

im the douchebag(heh) that made the presets stepping on the shoulders of sharktooth, kurtnoise, the x264 dev peeps, and all the other smart people here in about 10minutes using kurtnoise's device settings spreadsheet specifically. i never asked for any credit for them or deemed them as a seamless transition from sharktooth's. im far from an expert compared to others around here and realize they are far from perfect and others are encouraged to recreate them or make specific suggested fixes(adding "speed" in front of preset probably isn't going to happen though)(i think "slow" and "fast" etc. denote speed in the presets clearly enough) :)

the only documentation i wrote and will write:

the megui profiles now are just device settings. i chose imho a logical constant quality crf range going from 17-23 in increments of 1.5 and a 2pass. users must change --preset(amount of time dedicated to encode) and --tune(type of source) to their needs still. with the maturity of crf 2pass is only needed to hit a certain file size. certain options ensuring device compatibility are forced in the "custom commandline" field. this prevents user error and allows the preset to be changed while maintaining required options.

Neillithan

13th February 2010, 22:24

@nurbs

It does seem like a good idea to limit the profile and VBV if there are hardware constraints. The new presets in MeGUI default to the Medium preset mode, unless the preset is for a specific device... which is good because Medium doesn't create too complex of an encode for the non tech savvy user.

However, some people might be tempted to choose some of the slower presets, which most of the time will botch things from device compatibility and computer performance point of view. Choosing the "placebo" preset will most of the time create an L5.1 video unless you manually specify the Level and restrict the profile to High. Also, I'm well aware the Placebo preset is not going to do much compared to the slower preset. For instances like that, it would be more beneficial to use a profile (especially for the DXVA profiles) that restrict those couple of things.

To top it off, it would be interesting to have an intelligent VBV now that CRF is deemed the new default in MeGUI. Rather than leave the VBV at "0", perhaps there could be an option in MeGUI that automatically determines the VBV based on the source material. I've seen videos that have an average bitrate of 10,000 but have a peak bitrate of 70,000. That should never happen, no matter how short the segment in the video is. That is less likely to happen in a 2-pass encode even without VBV manually specified, which is why I suggest it. Now that I am aware of VBV, I will be using it a lot more. Obviously if my target bitrate is 10,000, I will want to specify a VBV between 20,000 to 30,000, right? It all depends what the user chooses for the bitrate.

@quantum5uicid3,
yes, the 4.1 restriction of older video cards has a lot to do with why I think the DXVA profiles should be restricted, or at the very least, offer a second set of Restricted DXVA profiles to avoid that issue. Not to mention, (to my knowledge) all hardware decoders like the PS3, Xbox 360, popcorn hour (you name it) do not support L5.0 or L5.1. As stated by Dark Shikari in past threads, they can't due to physical limitations. Even if you don't intend to watch your video on a hardware media streamer, that doesn't mean you should encourage the bad practice of creating Ultra high level videos. They only serve to pollute. I'm always downloading videos from Quakeunity.com and own-age.com in the MP4 or MKV container to find that the user created an L5.1 video. That probably was his own fault for not understanding the inner workings of AVC, but the blame can't be placed entirely on him, agreed?

It seems clear to me that you guys are going to stick with CRF, even though 2-pass has been commonplace in MeGUI for years now... I'm beating a dead horse at this point. The least you can do is take my suggestions under consideration and offer a set of profiles that work on a variety of devices, that do not break compatibility if you choose a preset higher than medium.

Thanks,
-Neil

nurbs

13th February 2010, 23:29

I've seen videos that have an average bitrate of 10,000 but have a peak bitrate of 70,000. That should never happen, no matter how short the segment in the video is. That is less likely to happen in a 2-pass encode even without VBV manually specified, which is why I suggest it. Now that I am aware of VBV, I will be using it a lot more. Obviously if my target bitrate is 10,000, I will want to specify a VBV between 20,000 to 30,000, right? It all depends what the user chooses for the bitrate.
VBV parameters don't depend on your target bitrate, they depend on the playback device. VBV maxrate is a function of profile and level that is supported, e.g. hp@4.1 has a maxrate of 62500 kb/s. x264 can't do anything unless both maxrate and buffer size are specified. The buffer size depends on the playback device. As a rule of thump people generally select the same buffer size as the maximum bitrate. One should probably keep in mind that blu-ray uses maxrate and bufsize that is lower than hp@4.1 if that is the target. It would be interesting to know if that matters for hardware compatibility, but I wouldn't think so.
Your 10 Mb/s average 70 Mb/s maximum scenario could still happen with hp@4.1 and blu-ray encodes (if I remember the blu-ray numbers correctly).
Furthermore 2-pass and CRF should have almost the same bitrate distribution given the same average bitrate so I doubt the peak would be much lower.

Not to mention, (to my knowledge) all hardware decoders like the PS3, Xbox 360, popcorn hour (you name it) do not support L5.0 or L5.1.
Actually it is sometimes 4.1 with more reference frames allowed. My 80€ WD TV (http://www.wdc.com/de/products/wdtv/) can allegedly decode 1080p with 16 refs and I guess it's not the only device using that particular decoder chip. I love that player. Handles vobsubs in 720p mkv perfectly Personally my encodes top out at hp@3.1 so I never really tested the limits.

In principle I agree that there should be a hardware profile that is limited to hp@4.1 for maximum compatibility. (If there isn't already. I don't know since I don't use the profiles.)

HeadlessCow

16th February 2010, 16:46

ive asked for the current state of dxva from the ati side of the fence but never heard anything.

ATI (at least the 3450 and 4670 I have) limits DXVA decodes to level 4.1. (might not care about the VBV settings, I never encode high enough bitrate for them to matter).

Lyle_JP

17th February 2010, 19:56

An excerpt from a conversation I had with a friend regarding MeGUI.

Was there a reason for this post other than to act like a dick? If you don't like MeGUI's direction you're certainly free to write your own GUI and post it here. That actually might be a useful post.

rudiev

18th February 2010, 13:24

rudiev

18th February 2010, 13:40

I updated to megui 0.3.3 and ran an megui update. But when I want to encode to x264 it uses vfw4x264.exe, and this doesn't work with my profile. How can I use the x264.exe which I used before with the old megui? I can't find it in the settings.

I updated the x264.exe from x264.nl, now version 1442, but it generated an error in megui, could not create process or something. Now I renamed the vfw4x264.exe to #vfw4x264.exe.org and renamed the x264.exe to vfw4x264.exe and it works all fine now.
Why does megui uses vfw4x264.exe? It's a small program so I think it calls x264.exe to do the encoding, but with the new x264.exe it doesn't work.

Zathor

18th February 2010, 14:50

I updated the x264.exe from x264.nl, now version 1442, but it generated an error in megui, could not create process or something. Now I renamed the vfw4x264.exe to #vfw4x264.exe.org and renamed the x264.exe to vfw4x264.exe and it works all fine now.
Why does megui uses vfw4x264.exe? It's a small program so I think it calls x264.exe to do the encoding, but with the new x264.exe it doesn't work.

Please post the error log and your system details. vfw4x264 is used as a wrapper for x64 x264.

rudiev

18th February 2010, 17:14

Please post the error log and your system details. vfw4x264 is used as a wrapper for x64 x264.

Strange, now it is working. also updated x264_64.exe with the latest one from x264.nl, now version 1416 for 64 bit.

The error log is:

[Warning] Log
-[Information] Versions
--[NoImage] MeGUI Version : 0.3.3.0
--[NoImage] OS : Windows Seven x64 (6.1.0.7600)
--[NoImage] Latest .Net Framework installed : 3.5 SP1 (3.5.30729.4926)
--[NoImage] Avisynth Version : 2.6.0.1
-[Information] Log for job1 (video, loadm2ts.avs -> )
--[Information] [18-2-2010 13:09:36] Started handling job
--[Information] [18-2-2010 13:09:36] Preprocessing
--[NoImage] Job commandline: "C:\Program Files (x86)\MeGUI\tools\x264\vfw4x264.exe" --profile high --level 4.1 --preset slow --tune film --pass 1 --bitrate 14400 --stats "G:\src\Heat.1995.BluRay.1080p.DTS.Remuxed.dxva-KNiCKER.stats" --slow-firstpass --thread-input --ref 8 --vbv-bufsize 50000 --vbv-maxrate 50000 --rc-lookahead 60 --subme 9 --partitions all --trellis 2 --no-dct-decimate --sar 1:1 --output NUL "G:\src\loadm2ts.avs"
--[Information] [18-2-2010 13:09:36] Encoding started
--[NoImage] Standard output stream
--[NoImage] Standard error stream: Error: Failed to create process <2>!
--[Information] [18-2-2010 13:09:37] Job completed
-[Warning] Log for job1 (video, loadm2ts.avs -> )

But now it's working, vfw4x264.exe is using the x264_64.exe. Maybe i gonna test how much the difference is using the 32 bit or 64 bit of x264.exe. Does someone maybe have some reference movie file to test?

rudiev

18th February 2010, 19:00

Ok, here the results of a little testing. I found a .m2ts file on an bluray. Here's the MediaInfo information:

General
ID : 0
Complete name : G:\src\00015.m2ts
Format : BDAV
Format/Info : Blu-ray Video
File size : 453 MiB
Duration : 5mn 50s
Overall bit rate : 10.8 Mbps
Maximum Overall bit rate : 48.0 Mbps

Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : VC-1
Format profile : AP@L3
Duration : 5mn 50s
Bit rate : 9 051 Kbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Resolution : 8 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.182
Stream size : 378 MiB (83%)

...

There were also three AC-3 audio codings and two subtitle stream, but I left those out of the MediaInfo because it has not value.

Used version x264.exe , downloaded from x264.nl
32 bit: x264 core:85 r1442 781d300
64 bit: x264 core:84 r1416 fcf70c2

Computer
Intel Quadcore Q9450 2,66GHz @ 3,2GHz
8 GB RAM
Using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cache64
MeGUI Version : 0.3.3.0
OS : Windows Seven x64 (6.1.0.7600) (Windows 2008 R2)
Latest .Net Framework installed : 3.5 SP1 (3.5.30729.4926)
Avisynth Version : 2.6.0.1

Command lines

--[NoImage] Job commandline: "C:\Program Files (x86)\MeGUI\tools\x264\vfw4x264.exe" --profile high --level 4.1 --preset slow --tune film --pass 1 --bitrate 14400 --stats "G:\src\test_xx-bit.stats" --slow-firstpass --thread-input --ref 4 --vbv-maxrate 50000 --sar 1:1 --output NUL "G:\src\test.avs"

--[NoImage] Job commandline: "C:\Program Files (x86)\MeGUI\tools\x264\vfw4x264.exe" --profile high --level 4.1 --preset slow --tune film --pass 2 --bitrate 14400 --stats "G:\src\test_xx-bit.stats" --thread-input --ref 4 --vbv-maxrate 50000 --sar 1:1 --output "G:\src\test_xx-bit.mkv" "G:\src\test.avs"

Encoding megui 0.3.3 with vfw4x264.exe using x264_64.exe

Time FPS
Job1 7:28 18,68 FPS
Job2 5:19 26,28 FPS

Encoding megui 0.3.3 with x264.exe 32 bit (renamed it to vfw4x264.exe)

Time FPS
Job1 7:46 18,01 FPS
Job2 5:37 24,97 FPS

Conclusion
There are little difference in encoding time using the 32 bit or 64 bit version of x264.exe. Job1 is 3,9% faster with 64 bit compare to 32 bit. Job2 is 5,3% faster with 64 bit compare to 32 bit.
The 64 bit could go even faster because the vfw4x264.exe process is consuming a little CPU power

karasu

19th February 2010, 15:21

Hello,

I'm trying to recompress a 4Go MKV using Megui. Here's my avs file :

DirectShowSource("H:\Movie.mkv", fps=23.976, audio=false, convertfps=true)

mergechroma(blur(1.3)) # Little Noise

loadplugin("C:\Program Files\AviSynth 2.5\plugins\FFT3DFilter\fft3dfilter.dll")
FFT3DFilter(bt=-1, sharpen=1.2)

In Megui, I load my avs file, the preview windows pops up and show me a proper frame of the movie.
I set up my x264 settings and enqueue it.
I have an error when I launch the encoding :

[Error] An error occurred: avs [error]: DirectShowSource: couldn't create filter graph:
[Error] An error occurred: x264 [error]: could not open input file `H:\Movie.avs'

I can play my avs file in MPC.

Can you help me?

TheProfosist

20th February 2010, 09:04

was wondering where i can request features since that thread is closed. i would like to request FLAC encoding support and save frames to file or to clipboard in the preview window

Inspector.Gadget

20th February 2010, 18:21

I'm trying to recompress a 4Go MKV using Megui.

What is a "4Go MKV", what's in it, and how did you make it?

Zathor

20th February 2010, 19:12

was wondering where i can request features since that thread is closed. i would like to request FLAC encoding support and save frames to file or to clipboard in the preview window

You can request new features here:
http://sourceforge.net/tracker/?group_id=156112&atid=798479

Flac support is already on the list.

karasu

22nd February 2010, 14:32

What is a "4Go MKV", what's in it, and how did you make it?

AVC1 1280x544 and AC3 audio

Inspector.Gadget

22nd February 2010, 14:59

OK, but that still doesn't tell us the sort of details relevant to figuring out why DSS isn't working. What program did you use to make the MKV container? What was the writing library? What did you use to encode the AVC stream and did you use any exotic options? Etc. My initial suspicion is that you don't have a system-wide (versus internal to MPC) DirectShow matroska splitter and/or H.264 decoder, but if that proves incorrect, then it's down to something weird with the file itself.

karasu

22nd February 2010, 17:59

MPC uses ffdshow libavcodec (cccp) with Haali Media Spliter. I did not create the source file.

I didnt understand why Megui is capable to show me the preview windows of my avs but crashes when starting the actual encoding process.
Megui work great when I rip my own dvds with d2v project files.

I have remuxed the mkv file with MMG v2.9.9 but always the same error.

Inspector.Gadget

22nd February 2010, 18:12

I did not create the source file.

Sorry, you're on your own, per the forum rules (http://forum.doom9.org/forum-rules.htm). If you'd like to clarify the origin of the material with a mod via private message and the mod clears it, then we can discuss the file.

xxxomxxx

28th February 2010, 09:19

hi all

how can i force MeGui to use more CPU - while encoding mine is running at 40% CPU & RAM?

thanks

karasu

1st March 2010, 15:07

how can i force MeGui to use more CPU - while encoding mine is running at 40% CPU & RAM?

can you paste here your avs file? (I suspect a non-multithreaded filter)

karasu

1st March 2010, 15:21

I have tried with a MKV file encoded myself (with megui) from a DVD I have bought. with the same avs file (with corrected filepath of course).
The avs file is playable in MPC with Haali Media Splitter and FFDSHOW.

Megui display properly the preview window when I load the avs file.

But I always get the same error when starting the queue.

Megui is up to date.

Robertus

6th March 2010, 20:20

with 0.3.4.0 when i open bitrate calculator and i set a size, when i close and reopen bitrate calculator , the size disappears... why!?

old version didn't have this problem... someone have a solution?

Ruriko

10th March 2010, 11:34

When I try to load any video in the AVS script creator megui just closes. Megui was working fine for the past 3months and now this happens!

ZEXEL

10th March 2010, 12:02

need function for next release MegUI:
# auto-delete .AVS + source file
hope it can be reality... :thanks:

blubberbirne

10th March 2010, 15:28

need function for next release MegUI:
# auto-delete .AVS + source file
hope it can be reality... :thanks:

hm, and what happens when your outfile is crap?

ZEXEL

17th March 2010, 08:23

hm, and what happens when your outfile is crap?
let it be...

Floatingshed

10th April 2010, 23:20

Can anyone please help. My XVID encodes will only play on a standalone player for 6 seconds if encoded with MeGUI (XVID Encraw) but they are fine using Virtualdub and XVID with the same settings! I've tried them on a friend's, entirely different player too, same result.
Does that ring any bells with anyone, please?

handsomejack

11th April 2010, 02:30

with 0.3.4.12 when i was encoding it showed error
Runtime error!
Program: C:\Program files\megui\tools\x264\x264.exe
abnormal program termination
I used 0.3.4.0,too; but no use. but when i use 0.3.1.1053, it's ok.

PS: Sorry for my bad english :p

LigH

19th April 2010, 08:39

@ Floatingshed:

Might be possible that the tools used by MeGUI (ffmpeg / mencoder) don't create optimal AVI containers (which might lack of some indexing), which could be fixed by remultiplexing them using e.g. AviMux-GUI or VirtualDub.

But without a detailed technical analysis it is impossible to answer your question - you did not even mention your used container (I can only guess it's AVI because most SAP won't be able to play anything else, and VirtualDub doesn't create anything else either).
__

@ handsomejack:

Different MeGUI versions might use different x264 revisions - which may require different command line options.

Furthermore you did not mention any system details, e.g. if you have a 64-bit Windows.
__

Details, details, details. ;)

Ryu77

21st April 2010, 15:50

I have noticed something strange as of recent...

I can not seem to change my x264 log file name or location through MeGUI anymore. When I click on the little button next to the log file absolutely nothing happens (MeGUI/Config/Misc/). The strange this is, if I press the button below the log file for the qp file, this seems to work fine.

Has anyone else experienced this? Is there a fix for it?

unknownsoldierX

21st April 2010, 19:58

What is the proper way to select audio input? Say if my source is an AVI with xvid and mp3. I use the script creator. Then, under audio input, I select the AVI. The resulting file does not have audio.

Do I have to demux a file before using MeGUI?

quantum5uicid3

21st April 2010, 20:27

@floatingshed

megui uses the most recent squid_80 build of xvid_encraw.exe for mkv output and xvidcore.dll 1.2.2. there arent known issues with the squid_80 build, but try using a more recent build. even downloading the 1.2.2 from this site will have an updated xvid_rawenc.exe. you will lose mkv output though.

http://www.xvidvideo.ru/xvid-video-codec/

edit: i guess it could be a problem with avimuxgui v1.17.8.3 too

@handsomejack
plz let autoupdate update everything unless you know what your doing.

@Ryu77
looks like a bug to me

@unknownsoldierX
yes megui can transcode the audio directly from a container. it sounds like your missing the steps of enqueuing and running the audio job seperately and muxing the newly created files together