PDA

View Full Version : MeGUI - x264/XviD/lavc/Snow encoder with MP4/MKV/AVI output & audio


Pages : 1 2 3 4 5 6 7 8 [9] 10 11 12 13

Kurtnoise
22nd February 2009, 20:30
I restarted MeGUI and now the first pass of encoding fails immediately with an error. Anyone else having any trouble?
yes...reported by several people already. :rolleyes:

If you want a fresh & correct x264 build, ping me...

QuadraQ
22nd February 2009, 20:39
Downloaded older 1113 version from here: http://skystrife.com/x264/x264.1113M.x86.exe

Renamed it to x264.exe and replaced the one in the C:\Program Files\MeGUI\Tools\x264\ directory ran the same queued jobs and they seem to be working fine. Won't know for sure until encoding finishes, but looks like there is an issue with version 1114 and MeGUI of some kind.

Blatman
23rd February 2009, 14:38
Thank you for the advice ! now it works :)

cengique
23rd February 2009, 17:55
Downloaded older 1113 version from here: http://skystrife.com/x264/x264.1113M.x86.exe

Renamed it to x264.exe and replaced the one in the C:\Program Files\MeGUI\Tools\x264\ directory ran the same queued jobs and they seem to be working fine. Won't know for sure until encoding finishes, but looks like there is an issue with version 1114 and MeGUI of some kind.

There's a simpler solution than downloading an older x264. MeGUI keeps a backup of the previous x264.exe in the same tools directory mentioned above. So you can just rename the current x264.exe to something like "x264-broken.exe" and then rename the backup file as "x264.exe". It worked for me.

No rush in providing a new x264 bundle :)

Sharktooth
24th February 2009, 03:10
https://forum.doom9.org/showthread.php?p=1253876#post1253876

Robby23
5th April 2009, 22:00
Hi Everyone,

I am trying to extract subtitles from a ts stream that was recorded from my Scientific Atlanta 8300HD via firewire. No other subtitle extracting program even finds subtitles in the stream except for in megui in "HD streams Extractor." The actual source is of whose line is it anyways which is in 480i. When I extract the subtitles the subtitles are really scrambled but some parts are in line just buggy. Could someone possibly point me in the direction of a tool capable of extracting the subtitles properly? Thanks!!

EDIT: added an example of the subtitles. You can see if you open it in subresync or something like that, that the subtitles are not formatted correctly

QuadraQ
5th April 2009, 23:21
Could someone possibly point me in the direction of a tool capable of extracting the subtitles properly? Thanks!!

You have probably already tried this but I use CCExtractor (http://ccextractor.sourceforge.net/) for my subtitles. It's never let me down yet, although I'm recording with Media Center on Vista, so I can't say if it will understand your stream or not.

Unrealbr
5th April 2009, 23:50
Does anyone knows if MeGUI is already compatible with the x264 64bit version on vista 64? If so, does it benefit in any way?

Robby23
6th April 2009, 00:55
You have probably already tried this but I use CCExtractor (http://ccextractor.sourceforge.net/) for my subtitles. It's never let me down yet, although I'm recording with Media Center on Vista, so I can't say if it will understand your stream or not.

Thank you so much. Would you happen to know how to cut subtitles with the cuts file that is saved in megui?

Ruriko
7th April 2009, 06:40
I just downloaded MeGUI but it doesn't have the option to put it to avi. How can I get this option?

QuadraQ
7th April 2009, 07:33
Thank you so much. Would you happen to know how to cut subtitles with the cuts file that is saved in megui?

I'm afraid not. I would suggest doing your cuts in another program before running it through meGUI. I found this to be easier in terms of workflow.

I use VideoReDo to cut my recordings, and then use CCExtractor to save the .srt file and load the results into meGUI for the encoding. I highly recommend VideoReDo for recorded material, since most programs don't handle errors in transmission, or audio sync issues as well as it does. Not a free program but well worth it.

Taurus
7th April 2009, 08:56
I just downloaded MeGUI but it doesn't have the option to put it to avi. How can I get this option?

And what's this?
http://666kb.com/i/b7vfz0eb3ugbkk3cy.png

Only Xvid and Snow in AVI/(MKV/RAWASP)
x264 = MP4/MKV/RAWAVC

Pretty simple :p

Sharktooth
7th April 2009, 17:31
I just downloaded MeGUI but it doesn't have the option to put it to avi. How can I get this option?
easy: you cant put h.264 in avi with megui and it will never let you do that even if it's theoretically possible. if you want to know why, :search:

rtjnyoface
8th April 2009, 07:08
Don't know if it's said often enough but the dedication and hard work put into this piece of work is simply amazing. Just wanted to post a quick thank you. Wasn't too sure of where to post it either. Anyways, thanks to you all.

Sharktooth
8th April 2009, 12:40
you're welcome and glad you like megui.

Flight16
10th April 2009, 06:12
Thank you so much. Would you happen to know how to cut subtitles with the cuts file that is saved in megui?

I wrote a script that will re-time and trim subtitles using an .avs with a series of Trim()s as the source. I believe there is also a Japanese executable that will do the job.

I've been working on automating .ts -> final mux with trims and subtitles. PM me and maybe we can share our knowledge. Or start a new thread someplace about .ts, subtitles, and demux / encode / mux chain.

Flight16
10th April 2009, 06:14
Are there any plans to add command line invocation to megui? I would love to call:

megui.exe -inaudio=vid.avs -invideo=vid.avs -preset=ipod, and ipod would point to a given video and a given audio profile, and it would encode and mux the entire thing.

If there aren't plans, how much time do you estimate it would take? Is megui designed in such a way that the change would be easy to make? If so, I could add the feature myself.

Kurtnoise
10th April 2009, 07:10
no plan for such things...It's a GUI you know that !

Flight16
10th April 2009, 08:56
no plan for such things...It's a GUI you know that !

Heh, yes. I realize it would be adding a command-line interface to a gui that is designed to wrap command-line utils. But megui provides such a nice queue, logging, and presets... it would be nice to at least have a

megui.exe --auto-queue --vidpreset="ipod" --audpreset="ipod" --muxpreset="mp4"

option that would add a file to the queue with an audio preset, video preset, and muxing preset.

Oh well. megui is still nice. :)

Ruriko
10th April 2009, 13:03
How do I add subs to my video?

Mtz
10th April 2009, 13:30
Press Ctrl+R and go to filters.

Regarding subtitles, can be added some settings to set the desired font? And maybe the position. I know this can be made using SSA subitles, but most used subtitles are SRT.

enjoy,
Mtz

Ruriko
11th April 2009, 07:01
I don't have the subtitle file. How can I extract the subtitle from the mkv?

Sharktooth
11th April 2009, 15:15
Press Ctrl+R and go to filters.

Regarding subtitles, can be added some settings to set the desired font? And maybe the position. I know this can be made using SSA subitles, but most used subtitles are SRT.

enjoy,
Mtz
Post your request in the feature request tracker on megui project page on sourceforge. thanx.

Sharktooth
11th April 2009, 15:17
I don't have the subtitle file. How can I extract the subtitle from the mkv?
using the forum search function.
you, know, there is also a newbie section...
btw, ill make your life easier. search for MKVToolnix and MKVExtract.

Eric B
14th April 2009, 14:09
After some months/years without encoding, I've updated MeGUI by using x264.
What is the proper thread for improvement ideas? I've seen the "feature request" topic is closed: It would be good to update the first message of this topic consequently!

So I have the following suggestions to enhance the performance a little bit.

1) Configuration / default use of workers: since the video encoders are multi threaded but the rest are mainly not, I've set all video tasks to "worker1" and all the rest to "worker2": it seems to me the best optimization. What do you think? It would be good to be able to do so automatically, i.e., when a multi core CPU is detected, having 2 workers per default, set all video tasks to the main worker, and all other tasks to a 2nd worker.

2) In a similar way, I have 2 physical HDD in my PC, and try to use them as far as I can. I make all tasks "cross" HDD, e.g. setting one as source and the other as destination, thus one disk is used to read, the other to write. We could imagine to have 2 folders to configure, and when one is used as source, the other is taken per default as destination (instead of the same folder which causes read&write in the same disk, and thus slowing down this disk).

3) back to the threading handling, what is the purpose of the "pause" button in the queue or worker window? It seems to have to functionality! I'd like to have a real pause which could pause the encoding process so that the CPU is not used anymore. Do the codec / x264 CLI support such a feature?

4) Tools/Chapter Creator: would it be possible to have a more comprehensive tool which takes the DVD source as input? I am currently using "Chapter Grabber" which is quite powerfull. I'll ask Emp3r0r if he could brings his "chapter grabber" to MeGUI...

Sharktooth
14th April 2009, 14:18
the feature requests (http://sourceforge.net/tracker/?atid=798479&group_id=156112&func=browse) tracker on the megui project page.

Eric B
14th April 2009, 20:12
the feature requests (http://sourceforge.net/tracker/?atid=798479&group_id=156112&func=browse) tracker on the megui project page.

ok, thanks. Doom9 should put this link in the first message of the topic...

Anyway, before putting new features, could you comment my suggestions, whether it makes sense or not...

Sharktooth
15th April 2009, 15:34
1) We dont know if (certain) encoders will be optimized for multiple cores/CPUs in the future. So, it's a hard choice.

2) you can already change your output dir. however, moving files temp files to a temp location (configurable by the user) could be an option

3) we all whish to have a real pause...

4) i like the idea

masken
17th April 2009, 11:30
I'd like to request a 1-click install solution for meGUI, with everything needed to encode provided with the installer, or through menus in the application.

It's simply too tiresome searching for 5-6 different apps, installa them, copy DLL files and messing with things to get it working.

Kurtnoise
17th April 2009, 14:05
There is an installer from SF website (https://sourceforge.net/projects/megui/)...

Sharktooth
17th April 2009, 16:40
I'd like to request a 1-click install solution for meGUI, with everything needed to encode provided with the installer, or through menus in the application.

It's simply too tiresome searching for 5-6 different apps, installa them, copy DLL files and messing with things to get it working.
this is not the place for feature requests.
however, megui depends on avisynth and directshow filters.
DS filters are usually needed also for playing back the source or encoded files while avisynth is the ONLY real megui dependency and if it doesnt find it on your system it offers to open a webpage so you can painlessly download it.

therealjoeblow
20th April 2009, 00:54
Hi,

I have my HTPC setup with the general display font custom sized to 150% instead of the default "Normal Size (96DPI)" so that it's more easily readable from a distance when displayed on a 50" plasma @ 1920x1080 pixels.

The MeGUI main interface doesn't like this though, most of it is OK, but some of the fields are 'squashed' and illegible and almost inaccessible because of this.

I was wondering if the interface could be made more "large font compatible/tolerant" if possible?

Many thanks!

samepaul
20th April 2009, 21:33
I was wonder if anyone uses this program. I'm surprised people do.
It spends more that 10 minutes (maybe more I had no patience to wait any longer and killed it in favor of shorter clip) in opening single mkv file .. and for what? Just for building AviSynth script with only "DirectShowSource"? You must be kidding.

Inspector.Gadget
20th April 2009, 22:35
samepaul, your system's directshow filters are obviously broken. This is no more MeGUI's fault than a hardware failure would be. Start over with Haali and ffdshow and clean out your Avisynth plugins folder and see if anything improves. Also post an image of the graph generated by graphedit or graphstudio to render the file, as this will allow everyone else to figure out which filter(s) don't work.

samepaul
21st April 2009, 00:57
I doubt it is obvious to you, but there is something much more obvious to me. There is bug in MeGUI. Or a behavior that looks to me as a bug.
Nothing broken in my "system's directshow filters". As proof of my word - I have no problems with the source video itself. MPC and Graphstudio open it in milliseconds.
Manually created AVIS plays good as well. Besides, I'm dealing with video encoding for years (even here I'm registered longer than you ;) ) and know how looks broken directshow system.
Moreover I performed a small debugging.
My guess is that once you open media file (via File-Open-Other Video files), MeGUI ignores the input file type and tries to treat it as AVIS script anyway.
This explains why I see in Filemonitor that MeGUI just linearly scans input file. And only after scanning whole file it brings "AviSynth script creator" dialog.

After searching on forum I found instruction on opening files like "go to Tools -> AviSynth script creator". Indeed this way it opens faster, though still takes long time to open 30GB BD remux stored in MKV. Mediaplayer opens manual AVIS much (i mean MUCH) faster.
But even after reaching this AVIS creator, one move of slider in Preview window brings MeGUI again to coma of file scanning. I guess this is already side-effect of DirectShowSource without "fps". As for me it is bug as well. Don't see real reason for configuring cropping and resize via AviSynth. There is button "preview in player" - use it! Configure cropping, resizing in interactive mode via DirectShow. Then preview created script in player.

Inspector.Gadget
21st April 2009, 02:32
So it isn't actually a bug, you're just irritated that an Avisynth-based application needs to make use of Avisynth :rolleyes:

Sharktooth
21st April 2009, 02:55
@samepaul: you dont like a software? dont use it. no one is forcing you to use megui. plus, the sources are available (megui is an opensource software), so if you think you're so smart, you know what to do. otherwise, dont waste your and our time.

samepaul
21st April 2009, 04:38
Inspector.Gadget No, it's actually you don't read what I've written. Some people need to read twice before they begin to understand, so maybe you should give another try. Or just ignore me. Anyway you haven't said anything useful till now and I doubt you will.

Sharktooth It's not question who is smart and who isn't. If you paid attention I don't judge here anybody and especially authors of megui. I encountered bug (unnecessary file scanning) and suggested performance improvement (use directx directly instead of avisynth frameserving which is proven to be slow and have seeking problem). Take it in account or not - it's authors call. I don't really care as you correctly noted I use another software. Namely MediaCoder. It's not perfect (otherwise I wouldn't bother with MeGUI) but still fits better my needs.
As for taking a part in development... I'm C programmer and don't really like .NET :)

Patrick Bateman
21st April 2009, 07:09
I keep getting this error message when I try to load an index file into the Avisynth script creator. I never had any problem before but every index file I have gives me this now, including ones I just created and ones that I've used before with no problem. The only thing I can think of that changed was the 4/20 updates. Can anyone help me with this? Note; I use the NV/CUDA indexing programs from Neuron. -- I get the message whether the CUVID server is running or not.

http://img16.imageshack.us/img16/2758/errorkwn.png

Kurtnoise
21st April 2009, 08:29
you're running on windows 7 ? where is located CUVIDServer.exe on your system ?

Patrick Bateman
21st April 2009, 09:11
you're running on windows 7 ? where is located CUVIDServer.exe on your system ?

Indeed I am on windows 7. CUVIDServer is in a folder on my desktop, where it always has been. But as I said, I get the message whether I am running it or not, so that can't be the problem. Normally if I forgot to run it, I'd get an error saying 'CUVIDServer is not running'.

Kurtnoise
21st April 2009, 09:20
Actually, megui checkes in your DGxxxNV folder to find CUVIDServer exec. Isn't there ? If not, I suggest you to put in this folder and that should be fine...

I added this function to avoid the error message like above.

Patrick Bateman
21st April 2009, 09:51
Actually, megui checkes in your DGxxxNV folder to find CUVIDServer exec. Isn't there ? If not, I suggest you to put in this folder and that should be fine...

I added this function to avoid the error message like above.

Yep. I never bothered directing Megui to where I keep my indexers. I ran the programs independently. Directing it to them fixed it. -- I see it also executes CUVIDServer if it isn't running now.

Well, thanks a lot!

Sharktooth
21st April 2009, 13:46
Sharktooth It's not question who is smart and who isn't. If you paid attention I don't judge here anybody and especially authors of megui. I encountered bug (unnecessary file scanning) and suggested performance improvement (use directx directly instead of avisynth frameserving which is proven to be slow and have seeking problem). Take it in account or not - it's authors call. I don't really care as you correctly noted I use another software. Namely MediaCoder. It's not perfect (otherwise I wouldn't bother with MeGUI) but still fits better my needs.
As for taking a part in development... I'm C programmer and don't really like .NET :)
avisynth is necessary for it's powerfull scripting and filters.
also, directshow is not as accurate as avisynth since it depends on video drivers that are usually broken (most of the times the problem is wrong colorscale conversions). it also has seeking problems, depending on the decoder and it is not frame accurate...

Chumbo
21st April 2009, 17:02
May I ask for a "wish list" item please? When the update module updates the components and asks to restart, it resets the UI after the restart. Any chance this can be "fixed" so the UI stays as it was, i.e., size and position after the updates? Thank you.

Kurtnoise
21st April 2009, 17:33
yeah...already posted as feature request.

Chumbo
21st April 2009, 19:03
yeah...already posted as feature request.
Great. Sorry for the repost as I didn't find it when I searched initially, which surprised me. Thank you.

Yoshiyuki Blade
24th April 2009, 08:23
Ok, I've scrolled through the last couple months' worth of posts to see if anyone reported an issue I have, but I don't see anything about it. I hope I didn't overlook it.

With a fresh install of MeGUI from the latest build, and after fully updating everything, I went ahead and modified the x264 scratchpad to my own liking. Upon closing the program, I run into an error. I can't remember what it says off the top of my head, but it has something to do with a file already existing. Anyway, when I re-open MeGUI, all of the profiles are gone with just the scratchpads left. Force reinstalling the profiles fixes the issue though.

I'm on Vista 64-bit if that helps. I've been able to reproduce this issue on different computers with Vista, so it seems consistent and predictable. Apologies in advance that I couldn't give any more specific details.

Sharktooth
24th April 2009, 13:52
the exact error is actually an important part of your report...

Neillithan
24th April 2009, 14:38
This has probably been suggested before but I'm going to request it because I feel as though it would make a nice addition to MeGUI.

Can FLAC be added to MeGUI?

The Reason: I like to use MeGUI to make a lossless conversion of some of my videos (for archiving purposes) and to do this, I have to follow these steps:

1. encode the video as H.264 Lossless in MeGUI
2. use MediaCoder to convert the audio of the video to FLAC
3. use MKV Toolnix to mux the .264 and FLAC as .MKV

That's 3 steps and 3 different programs to do something really useful.

If MeGUI supported FLAC I could do all of that in 1 single step without the need for additional programs.

Please add FLAC support to MeGUI?

Thanks,
-Neil

Inspector.Gadget
24th April 2009, 14:51
FLAC support is already in the HD Streams Extractor for lossless audio from Blu-ray. When else would you need it, other than with a lossless audio input source? PCM Stereo is (in my experience) rare enough in DVDs that firing up foobar2000 to do the compression isn't an inconvenience. Plus, in that scenario, more often than not you're splitting by chapter from a music DVD and probably want to tag the split files anyway...

Neillithan
25th April 2009, 05:12
FLAC support is already in the HD Streams Extractor for lossless audio from Blu-ray. When else would you need it, other than with a lossless audio input source? PCM Stereo is (in my experience) rare enough in DVDs that firing up foobar2000 to do the compression isn't an inconvenience. Plus, in that scenario, more often than not you're splitting by chapter from a music DVD and probably want to tag the split files anyway...

Archiving purposes. I think it should be included because it can be. I use MeGUI to encode videos I make, I don't use it to encode Blu Ray movies. What I mean to say is, just because I don't use FLAC for the exact purpose you mentioned doesn't mean I shouldn't use it for any other purposes. FLAC would compliment MeGUI especially if I could choose it from the drop down list of audio encoders.

I hope the inclusion of a codec is not based solely on "how" it can be used, but rather "if" it can be used.

-Neil

Yoshiyuki Blade
25th April 2009, 12:01
the exact error is actually an important part of your report...

K, I managed to reproduce the error message again. I can't pinpoint the exact cause of this issue, but it definitely has something to do with modifying a profile sometime after a fresh MeGUI install (and after completely updating everything). It doesn't always occur immediately after the first modification from what I've seen.

http://img.photobucket.com/albums/v208/YoshiyukiBlade/meguierror.jpg

Inspector.Gadget
25th April 2009, 14:56
I hope the inclusion of a codec is not based solely on "how" it can be used, but rather "if" it can be used.

Using FLAC for anything but lossless source audio is stupid, and MeGUI already makes FLAC available for the vast majority of lossless sources.

Kurtnoise
25th April 2009, 19:40
no...it's a relevant feature request to ask to add a lossless audio codec.

DexterLab23
28th April 2009, 09:21
I want to be enlighten about something in MeGUI.
From where I can put/set in MeGUI the Audio Delay that is shown in the file:
"*Stream Information.txt" ? I found two possible places:

1. When I launch MeGUI in the main menu, down, right to the "Extension: MP4-ACC" is written "Delay".
2. Or when I mux together the video and audio stream, in Tools -> Muxer -> MP4 Muxer, is written at the Audio 1 tab, "Delay".

3. From where I can set now the Audio Delay ? Or I must set both (1 and 2, see above) ?
4. Or I must set only one option (1 and 2, see above) ?

Best regards.

P.S. I want a fast answer.
P.P.S. If Sharktooth could answer will be great.

Kurtnoise
28th April 2009, 11:38
It's better to put audio delay when you transcode your audio streams...

DexterLab23
28th April 2009, 12:05
Please be more explicit, I dont understand you. Do you mean when I transcode with DGIndex 1.5.4 ? Also you did not answered on any my questions. Please help with some clear advice.

nurbs
28th April 2009, 12:18
DGIndex doesn't transcode the audio (or video), it just extracts them. When you load one of the extracted audio files on the input tab in megui you can see that that the audio delay value from the filename is automatically entered in the delay box, so you shouldn't have to do anything manually. The encoded file will also automatically be renamed to idicate that the delay has been corrected. The new delay value in the encoded file will be 0ms. After the delay is corrected during encoding you obviously don't have any more delay when you mux the files, and so you don't have to enter it again.

Balthazar2k4
28th April 2009, 14:59
I've done numerous encodes using H264 & MPEG-2 as source material on Windows 7 without a problem, but I am really stumped on VC-1. When I switch back to Vista x64 it runs fine, but 7 x64 just won't let me do it. What did Microsoft change in the WMV9 codec support for Win7? I suspect my problem stems from the fact that FFDshow will not load in Win7, but I would love to find a workaround. I really like Win7 and am tired of switching back and forth. I have spent hours combing the net for answers to this dilemna (RipBot264, HDConverToX, etc. also fail to work). Any help would be deeply appreciated....

RunningSkittle
28th April 2009, 18:37
... I suspect my problem stems from the fact that FFDshow will not load in Win7...

FFDshow works just fine in windows 7 x64.

Here it is decoding 1920x1080 VC1:
http://deep.phpwebhosting.com/~mactownkrisp/computer/ffdshow-windows7.png

Balthazar2k4
28th April 2009, 20:37
FFDshow works just fine in windows 7 x64.

Here it is decoding 1920x1080 VC1:
http://deep.phpwebhosting.com/~mactownkrisp/computer/ffdshow-windows7.png

Have you experienced any problems converting VC-1 material with either MeGUI, RipBot264, or HDConverToX? I can't get any of them to do it and yet they all work fine under Vista x64...

Could it be a Haali Media Splitter problem?

RunningSkittle
28th April 2009, 22:53
directshowsource works

Balthazar2k4
29th April 2009, 00:10
directshowsource works

I can't figure out the problem to save my life. I installed a fresh copy of Win7 x64 build 7100. I turned off UAC. I installed ffdshow build 2913, haali media splitter, and AviSynth 2.5.8. I opened RipBot264 as an admin and proceeded to demux an m2ts containing VC-1. At the end of the demux, MPC pops up and tells me the graph filter has timed out. This happens with every VC-1 title I have tried. Anything else works great....

When I try and playback video via MPC Home Cinema, ffdshow does not show in the system tray and does not show it is doing anyting in the info & cpu dialog box under video decoder configuration.

I have tried setting ffdshow VC-1 to WMV9 and libavcodec and neither work.

HELP! This is driving me mad....

Balthazar2k4
29th April 2009, 00:55
Also, when I try and load the extracted stream into MeGUI, I receive the following error:

AviSynth Script Error
DirectShowSource: Timeout waiting for graph to start.

I just can't get ffdshow to play nice. I have even tried the x64 version, but predictably that did not work either.

DexterLab23
29th April 2009, 19:46
Help me understand something:
I ripped a serial, and have a file: "VTS_01_1 T80 1_0ch 192Kbps DELAY -8ms.ac3"
megui puts automatically the delay: "-8"
and inside the "VTS_01 - Stream Information.txt" file is written "Delay: -88ms"
Which is to be believed ? Which one to put inside megui ? -8 or -88 ?

P.S. You guys didn't answered my previous question.

nurbs
29th April 2009, 20:17
a) Kurtnoise answered your previous post and I wrote a little longer explaination, you just didn't bother to read it.
b) You believe the -8ms, because that's what dgindex says.

onesloth
29th April 2009, 22:51
...but I am really stumped on VC-1.
Do you have an NVidia card? DGVC1DecNV should work.

DexterLab23
30th April 2009, 09:57
Thank you Kurtnoise, nurbs.

I understand it. I will try and post here if the audio is out of sync or not.

I am sorry, you are right, next time I will read more carefully.

:thanks:

DexterLab23
30th April 2009, 11:26
It's MeGUI also available for linux ?

deets
30th April 2009, 12:12
add Device Types to the Adaptive & Manual Muxers. Now, we can force either iPod, iPhone, ISMA or PSP output when we select MP4 Muxer.

what difference does this make if you do or dont select PSP as the device type?

Sharktooth
30th April 2009, 14:09
@DexterLab23: nope, or at least, not yet.

@deets: the difference is the file wont play on that device if the option is not selected.

DexterLab23
30th April 2009, 14:28
a) Kurtnoise answered your previous post and I wrote a little longer explaination, you just didn't bother to read it.
b) You believe the -8ms, because that's what dgindex says.

b) was wrong option/value, the true/corect value was -88

@Sharktooth, Please put two options in megui where can it read the audio delay.

A. In the "*Stream Information.txt", correct.
B. In the name of the audio that is created during after DGIndex processed audio file name, ex. "VTS_01_1 T80 1_0ch 192Kbps DELAY -8ms.ac3"

Also I should mention that the clip was a short one, 00:07:08, but I think if the audio was wrong (-88 ms), it should be completely desynced.

turbojet
1st May 2009, 13:33
Any chance of an option to not make .backup files when updating?

Out of curiousity are they ever used by the program anyhow?

Kurtnoise
1st May 2009, 16:09
no...this is not used. There is a bug or something like that because such files must be deleted.


@DexterLab23: then, extract your audio stream with DVDDecrypter instead...

Ryu77
3rd May 2009, 09:35
Recently dgavcindex was added to the MeGUI tools folder... However, the version used is 1.0.1. I am wondering is there any reason why the newer 1.0.9 version isn't used?

I actually copied the newer version and .dll into the appropriate folders and eventually MeGUI updated back the older version.

Sharktooth
3rd May 2009, 14:18
i already said ill update it as soon as i get home

Ryu77
4th May 2009, 09:52
i already said ill update it as soon as i get home

Was this directed at my post? If it was, I can't see when did you state (in the last 3 days) anything to do with updating dgavcindex?

Sharktooth
4th May 2009, 15:03
yes, it was directed to you... http://forum.doom9.org/showthread.php?p=1279853#post1279853
and no, im still not at home.

avdw
4th May 2009, 15:11
yes, it was directed to you... http://forum.doom9.org/showthread.php?p=1279853#post1279853
and no, im still not at home.

If you get home, will you take your medications first ?

Sharktooth
4th May 2009, 20:21
"as soon as i get home" means it will be one of the first things i will do when i get home...

Ryu77
4th May 2009, 23:17
yes, it was directed to you... http://forum.doom9.org/showthread.php?p=1279853#post1279853
and no, im still not at home.

It's on a completely different thread... How the hell am I supposed to know that you already had this discussion with somebody else?

And yes, I could have searched through the forums (wasting far more time than the 5 seconds it would have taken you to answer it) but my question was a simple one and your answer should have been a polite one. I believe that this is the appropriate thread anyway, as it was something related to MeGUI updating not DGAVCDec itself.

By the way, that's one long trip home...

Sharktooth
5th May 2009, 03:56
sorry, i didnt mean to be rude.
it's just i'm too much stressed...

Keiyakusha
5th May 2009, 16:24
Little bug report.
If I start MeGui -> open x264 configuration dialog -> set Const. Quality 0.1 and then switch to Const. Quantizer, I get this error:
http://www.petaimg.com/u335/39305.05.png

UPD: the same when I click on Lossless checkbox instead of swithing to Const. Quantizer.

Ramir Gonzales
5th May 2009, 17:08
Little bug report.
If I start MeGui -> open x264 configuration dialog -> set Const. Quality 0.1 and then switch to Const. Quantizer, I get this error:

UPD: the same when I click on Lossless checkbox instead of swithing to Const. Quantizer.

That's not MeGUI's fault, you have a crap computer, probably crap memory !

Kurtnoise
5th May 2009, 17:51
That's not MeGUI's fault, you have a crap computer, probably crap memory !
47 posts of uselessness...You're on the right way, dude. Keep going.


@Keiyakusha: I'll look at it...thanks for the bugreport.

sebus
5th May 2009, 19:17
That's not MeGUI's fault, you have a crap computer, probably crap memory !

And your manners are left behind the door, right?

wolfbane5
7th May 2009, 02:55
I have created a custom x264 profile (2-Pass) in MeGUI. However, I would like pass 1 to be slightly different than pass 2, but every time I make changes to pass 1, save it, then fix pass 2, pass 1 gets overwritten and becomes identical to pass 2. Anyway to fix this?

nurbs
7th May 2009, 05:33
If you don't want to use the same settings for both passes or turbo you have to create a seperate profile for each of the passes.

wolfbane5
7th May 2009, 07:50
Alright, I created 2 profiles, one for each pass. I'm assuming you have to overwrite the --output NUL statement for pass 1, so that you actually have an output, which you have to set up as your input for the 2nd pass?

You'd think there'd be an easier way to have different settings for each pass...hopefully the MeGUI developers will design a way to do this in a later revision.

J_Darnley
7th May 2009, 10:41
You don't need to store the output of pass 1. The input of pass 2 is the same as it was for pass 1. It is the stats file which stores the information needed for pass 2.

wolfbane5
7th May 2009, 15:10
You don't need to store the output of pass 1. The input of pass 2 is the same as it was for pass 1. It is the stats file which stores the information needed for pass 2.

Ok so then I can set up pass 1 with the .avs input I have and not care about the output (job 1). Then I can setup pass 2 with the same .avs input, but this time i'll get an output and it'll automatically use the .stats file created from pass 1? Also, can I queue pass 1 and pass 2 at the same time, or do I have to wait for pass 1 to complete, before I can setup & run pass 2?

xandercage
10th May 2009, 19:20
I m using bitrate calculator in megui, bud when i try encode VC-1 stream in m2ts file i becomme always larger outfile xvid in avi container.

buzzqw
11th May 2009, 07:16
m2ts has an overhead of 7% (near) of total size , while avi/mkv is something like 24 bytes for frames

BHH

xandercage
11th May 2009, 09:59
So if it s VC-1 stream i must calculate like this formula
Total size 1400MB - 7%MB (98MB), so total size in megui must be cca 1302MB?

If it s h264 or AVC stream in mkv or m2ts the calculated file size is ok in output file xvid, avi.

I have trouble only with VC-1 streams.

Sharktooth
12th May 2009, 01:27
m2ts has simply a huge overhead and since bitrate calc still doesnt support m2ts you should take that 7% into account.

userix
14th May 2009, 06:06
Weird issue: Using the same versions of MEGUI and identical x264 profiles on two different computer, I get different qualities from the same vobs I am trying to encode. AVS scripts and D2V were created in the same exact manner on the different PCs. But my old Dell 1.5ghz 1GB ram Radeon 9500 does a cleaner, better looking encode than my Q6600 2GB ram 8800gts, although the Q6600 finishes much faster than the Dell. I am a newb at encoding, so I have no clue why the quality varies between my two comps.

wolfbane5
14th May 2009, 07:37
Weird issue: Using the same versions of MEGUI and identical x264 profiles on two different computer, I get different qualities from the same vobs I am trying to encode. AVS scripts and D2V were created in the same exact manner on the different PCs. But my old Dell 1.5ghz 1GB ram Radeon 9500 does a cleaner, better looking encode than my Q6600 2GB ram 8800gts, although the Q6600 finishes much faster than the Dell. I am a newb at encoding, so I have no clue why the quality varies between my two comps.

Are you sure you're using the same x264 profiles? One small change like --partitions none and --partitions all can make a huge difference in quality and encoding time.

Taurus
14th May 2009, 08:40
Weird issue: Using the same versions of MEGUI and identical x264 profiles on two different computer, I get different qualities from the same vobs I am trying to encode. AVS scripts and D2V were created in the same exact manner on the different PCs. But my old Dell 1.5ghz 1GB ram Radeon 9500 does a cleaner, better looking encode than my Q6600 2GB ram 8800gts, although the Q6600 finishes much faster than the Dell. I am a newb at encoding, so I have no clue why the quality varies between my two comps.
So you use the same decoder for the encoding
and the same decoder for playback on both machines?
Which decoder for playback; deblocking en/disabled?
Same bitrate, same filesizes of your encoded files?
To much variables to guess without log files and avisynth scripts....:D

Kurtnoise
14th May 2009, 08:46
In addition, I'd say compare both encodes on the same machine...

turbojet
14th May 2009, 21:32
Thanks for the .backup fix, tools directory went from 174 MB to 96 MB.

I have another suggestion which is checking reference frames against the level to prevent illegal files like avc level checker is intended to do but it's inaccurate which is discussed here (http://forum.doom9.org/showthread.php?t=146930).
But instead of avc level checker could it check within x264 config like it already does with vbv?
Also if vbv is left empty but a level is defined can it set the vbv maxrate and buffer to the maximum allowed for the level?

Sharktooth
14th May 2009, 22:12
VBV should NEVER be set until the user chooses to set it. megui will warn you if you set the buffers too high.
the inaccuracy is there to "protect" from b-pyramid problems.

turbojet
14th May 2009, 22:42
VBV should NEVER be set until the user chooses to set it. megui will warn you if you set the buffers too high.
the inaccuracy is there to "protect" from b-pyramid problems.

Why should vbv never be set until the user chooses?

If you take a 90 minute high action movie, set it to L4.1 and encode for BD25 output without any vbv you are likely to exceed the maximum bitrate and it will skip at times. Same can be said for DVD9 target but to a lesser extent.

What b-pyramid issue are you talking about?

1920x1080 24fps up to --ref 4 with and without b-pyramid is allowed in L4.x
According to AVC Level Checker 1920x1080 24fps L4 max is --ref 3 without b-pyramid or --ref 2 with b-pyramid.

1280x720 24fps up to --ref 9 with and without b-pyramid is allowed in L4.x
According to AVC Level Checker 1280x720 24fps L4 max is --ref 8 without b-pyramid or --ref 7 with b-pyramid.

Sharktooth
14th May 2009, 22:55
coz you dont want restrictions on ratecontrol if you dont need them. they would harm final quality.
b-pyramid problems are playback problems on hardware devices (DPB violations). if you add b-pyramid you should lower the refs by 1 to ensure compatibility. AFAIK that's a x264 problem.
btw, regarding the level checking in the config, it's not manageable since megui doesnt know about input file properties during the encoder configuration.

turbojet
15th May 2009, 00:22
coz you dont want restrictions on ratecontrol if you dont need them. they would harm final quality.

Very debatable on if it may hurt quality if it's within reason L4.0 would allow 50 mbps for less than a second, 25 mbps for more than a second, L4.1 would allow 135 mbps for less than a second, 62.5 mbps for more than a second.

If someone is setting level aren't they using it for a specific device that requires these types of level restrictions?
What I suggest wouldn't affect anything if you aren't setting level or vbv is already compliant.

b-pyramid problems are playback problems on hardware devices (DPB violations). if you add b-pyramid you should lower the refs by 1 to ensure compatibility. AFAIK that's a x264 problem.

This used to be the case but it was changed months ago so b-pyramid doesn't affect DPB.

btw, regarding the level checking in the config, it's not manageable since megui doesnt know about input file properties during the encoder configuration.

It could just as easily get this info on input like avc level checker does currently. What I'm suggesting is putting avc level checker functionality in the x264 config and getting rid of the level checker function.

Sharktooth
15th May 2009, 01:04
it's not debatable. setting VBV params forces the ratecontrol to behave in a different way and setting a level means setting a flag in a bitstream. if you want to specify VBV limits you can always do it.
about b-pyramid and DPB stuff, it was changed but it's still not perfect and still causes problems. as you can read on the megui presets thread:... Removed b-pyramid from all DXVA group presets... this time it is FOREVER until x264 gets properly patched.
x264 is still broken (http://forum.doom9.org/showthread.php?p=1180816#post1180816) in that way.
so, dont argue with me about b-pyramid... i will never consider it a reliable option... it's not even so usefull... i prefer one more b-frame or even one more ref instead...
It could just as easily get this info on input like avc level checker does currently. What I'm suggesting is putting avc level checker functionality in the x264 config and getting rid of the level checker function.nope, since you can set up the presets without loading an input file. avc level checker is what the name says, a "checker". it doesnt "set" anything except enforcing limits if and only if certain options are set out of specified level limits.

turbojet
15th May 2009, 01:46
it's not debatable. setting VBV params forces the ratecontrol to behave in a different way and setting a level means setting a flag in a bitstream. if you want to specify VBV limits you can always do it.

Ya it is a little different output. But again why would someone set a level if they wanted the level to be broken?

about b-pyramid and DPB stuff, it was changed but it's still not perfect and still causes problems. as you can read on the megui presets thread:
x264 is still broken (http://forum.doom9.org/showthread.php?p=1180816#post1180816) in that way.
so, dont argue with me about b-pyramid... i will never consider it a reliable option... it's not even so usefull... i prefer one more b-frame or even one more ref instead...

All I can say is BD players that used to fail max reference frames + b-pyramid now play them just fine. Presets or usefulness have nothing to do with this discussion.

nope, since you can set up the presets without loading an input file. avc level checker is what the name says, a "checker". it doesnt "set" anything except enforcing limits if and only if certain options are set out of specified level limits.

Then it warns the output will be non-compliant to the level set and tells the user to change level or whatever setting breaks it.

Sharktooth
15th May 2009, 01:58
Ya it is a little different output. But again why would someone set a level if they wanted the level to be broken?
Coz some devices/softwares check for the level flag but are capable of decoding higher bitrates than those specified in the level (some cellphones for example...).
All I can say is BD players that used to fail max reference frames + b-pyramid now play them just fine. Presets or usefulness have nothing to do with this discussion.
The reason i pointed you to that thread was to prove x264 has not been fixed and your statement:
This used to be the case but it was changed months ago so b-pyramid doesn't affect DPB.
was wrong
Then it warns the output will be non-compliant to the level set and tells the user to change level or whatever setting breaks it.
yes. also, VBV parameters are checked against the level during the preset configuration.

userix
15th May 2009, 07:12
Thanks for your replies. :)

I apologize for not being specific in my initial post. The file I am encoding is from one of my anime DVDs. It's not that the whole encode is crappier, only the beginning of the episode, which starts with a static scene, and then cuts to another static scene. On the Q6600 encodes, those 2 static scenes seem blockier (noisier) when compared to the old Dell encode. The rest of the encode, including future static scenes, seem fine afterwards. What gets me is why are the aforementioned static scenes encoded on my Q6600 blockier than those of my old Dell encode?

I have attached screenshots taken using MPC of the two static scenes I am talking about. The noise in the first scene is subtle, but you can clearly see the difference between the 2nd static scene. Of course, when watching it in full screen, the differences stand out much more.

In addition, when I encode the video using 2-pass xvid encoder with same bitrate on the Q6600, the 2 static scenes are the same quality as the Dell encode. It seems only when I use x264 encoder on my Q6600, I get crappier results. Boggles the mind.

Are you sure you're using the same x264 profiles? One small change like --partitions none and --partitions all can make a huge difference in quality and encoding time.

I'm pretty sure. I downloaded the same stable version to both computers, then proceeded to update it to the newest files available at the same time. Therefore, the profiles I downloaded through the update module are the same. I double check the command line arguments being fed and they are identical on both machines.

So you use the same decoder for the encoding
and the same decoder for playback on both machines?
Which decoder for playback; deblocking en/disabled?
Same bitrate, same filesizes of your encoded files?
To much variables to guess without log files and avisynth scripts....:D

I haven't looked at the logs specifically, but I figure if I create the d2v and avs script files in the same exact manner on both machines, I should get the same results, right? Bitrates are set the same for both comps. The size of the video encodes aren't exactly the same, but it's only off by 200k-300k. I have CCCP codec pack installed on both comps and use MPC to playback the files. I am not sure what you mean by using the decoder for encoding. MEGUI uses the x264.exe file it gets from the update, which is located in the MEGUI tools folder.

In addition, I'd say compare both encodes on the same machine...

I can rule out the decoding issue for playback, because I took the old Dell encoded file and played it on my Q6600 and it looks great, just like on my Dell. I played the Q6600 encoded video on the Q6600 and the old dell and it looks the same: blockier static screens at the beginning of the video.

turbojet
15th May 2009, 17:09
Coz some devices/softwares check for the level flag but are capable of decoding higher bitrates than those specified in the level (some cellphones for example...).

First time I've heard of this but I'm not familiar with cell phones. Can they decode any bitrate that's consistent over a second?
If not do you know how much higher bitrate they can decode?
Also if not leaving blank vbv may produce a skipping/unplayable output and the current situation of allowing up to vbv max doesn't help the matter. Looking at megui presets all of the cellphone profiles seem to follow level standards.

The reason i pointed you to that thread was to prove x264 has not been fixed and your statement:

was wrong

I'm pretty sure the fix was after November which is when that was posted. At least I remember checking a few BD players in January 2009 against --ref 4 --b-pyramid at 1920x1080 and they weren't playing, now the same players are playing the same 2 options with current x264 builds.

While b-pyramid may or may not be fixed how it should be, it doesn't seem to hinder playback anymore which is what the DPB formula only concern is.

yes. also, VBV parameters are checked against the level during the preset configuration.

VBV can never exceed the level because of how the x264 settings enforces the max rate so the check will never see a bad vbv setting or am I missing something?

Sharktooth
15th May 2009, 17:28
it depends on the device chipset or the software. for example, some media players/decoder want level 4.1 streams or they wont use DXVA. however they're capable of decoding streams with different limits from the L4.1...
the megui presets for cellphones and PDAs come as standard presets at levels 1.0, 1.1, 1.2 and 1.3. but it's not a secret there are cellphones that support level 1.x at much higher bitrate limits.
about the DPB, it was never fixed. the discussion ended with that thread and, if you read it, there is a chance the encode will be played back... but you can NEVER be sure since x264 continues to violate the DPB.
the VBV retrictions are FIXED by profile/level. they do not depend on res or fps, so they are checked when you create the preset. if you specify an invalid VBV rate for the specified profile/level, megui will warn you. i cant see a reason to change that behaviour.

turbojet
15th May 2009, 17:43
it depends on the device chipset or the software. for example, some media players/decoder want level 4.1 streams or they wont use DXVA. however they're capable of decoding streams with different limits from the L4.1...

Can you give some examples?


the megui presets for cellphones and PDAs come as standard presets at levels 1.0, 1.1, 1.2 and 1.3. but it's not a secret there are cellphones that support level 1.x at much higher bitrate limits.

Can you give some examples?

about the DPB, it was never fixed. the discussion ended with that thread and, if you read it, there is a chance the encode will be played back... but you can NEVER be sure since x264 continues to violate the DPB.

Everything on that thread pre dates my broken and playable tests.

the VBV retrictions are FIXED by profile/level. they do not depend on res or fps, so they are checked when you create the preset. if you specify an invalid VBV rate for the specified profile/level, megui will warn you. i cant see a reason to change that behaviour.

Are fixed by preset? yes. Fixed by level? Not currently, but my suggestion is VBV and references stay in compliance to the level set.

Sharktooth
15th May 2009, 18:17
the only DXVA decoder that can handle levels OVER 4.1 is MPC-HC AVC decoder. other decoders require Level 4.1 (just the flag on the bitstream!!!).
Some nokia phones and other phones (cant remember the models) have enough CPU power to decode AVC at levels higher than 1 or 1.x but are limited to those levels. you can safely encode at bitrate higher than level 1 or 1.x and the phone is perfectly able to play back the encode.
Again, x264 still violates the DPB. there is no entry in the changelog that says it was fixed. HENCE IT'S STILL BROKEN.
VBV restrictions are fixed by level/profile: http://en.wikipedia.org/wiki/H.264#Levels
That said, the discussion is over. You're speaking of something you dont even understand and i have no time to waste.

turbojet
15th May 2009, 18:30
When level is set in megui the vbv is not touched thus level does not fix vbv!
But ok I guess there still will not be a gui that has full range of settings and ensures the file will be within spec.
The threads and posts concerning this problem will continue to flood this forum.
Granted it shouldn't be gui's responsibility to fix x264's caveats but most people seem to think it should be.

Sharktooth
15th May 2009, 19:51
As i said, AVC Level checker is just a CHECKER. it wont change any parameters you set except for the fact that it wont permit the user to specify a level and non coherent parameters/options.
By that purpouse it will warn you when you select it, plus another check is run when you set up the preset... and if something is not coherent it will switch level to unrestricted/autoguess. THIS WONT CHANGE coz it is the only LOGIC thing to do.
Also there is only 1 person that rised this (not a-)problem and that person is you. So, by logic, im correct in stating your conclusion are illogical.
MeGUI is not an one click solution software. Users MUST KNOW what they're doing and looking for a table on wikipedia is not even so hard... expecially when it's the first hit when you type "AVC Levels" on google...

turbojet
15th May 2009, 20:19
I never suggested changing VBV to not autoguess when it's set higher then the level refers to, this will produce a compliant file however there are many situations where x264 and megui won't output a compliant file.

I'm not sure you understand what I'm suggesting which is to ensure that when level is used the file complies to that level. Currently the only thing it does is restrict vbv which is a start. The inaccurate avc level checker is pretty much hidden and a lot of megui users don't even know it exists.

The problem is every few days there's another post on this forum about a file not playing on their device m mainly due to too many references and resolution but vbv also comes up at times. I thought of a solution to all but the resolution problem and this is it. If someone has a better solution I'm all ears.

If/when megui outputs AVCHD/BD these issues will get even more and more popular and they'll directly point to MeGUI wouldn't you like to prevent these posts?

Profiles help but there's always people who are going to change things on a whim, some guide told them, etc. There is one common thing between H.264 encoders and H.264 devices and that's level, an encoder that complies to it is much more user-friendly then one that doesn't.

Kurtnoise
16th May 2009, 05:42
put a feature request on SF, we'll see what can we do for megui 1.0...;)

Sharktooth
16th May 2009, 14:51
I never suggested changing VBV to not autoguess when it's set higher then the level refers to, this will produce a compliant file however there are many situations where x264 and megui won't output a compliant file.
that depends on the user. if a user wants to set a level but doesnt want to put limits on the bitrate why should we add that restriction?
the user should also get informed on what he's doing. megui is not a software for the first idiot that thinks encoding is just a matter of some random mouse clicks.

I'm not sure you understand what I'm suggesting which is to ensure that when level is used the file complies to that level. Currently the only thing it does is restrict vbv which is a start. The inaccurate avc level checker is pretty much hidden and a lot of megui users don't even know it exists.
avc level checker is not inaccurate. it's made around x264 and it wont change until x264 will be fixed (if it ever will...).

The problem is every few days there's another post on this forum about a file not playing on their device m mainly due to too many references and resolution but vbv also comes up at times. I thought of a solution to all but the resolution problem and this is it. If someone has a better solution I'm all ears.
ppl could RTFM... as i said, you must know what you're doing...

If/when megui outputs AVCHD/BD these issues will get even more and more popular and they'll directly point to MeGUI wouldn't you like to prevent these posts?
i dont see any problems. there are presets for AVC-HD/BD. You should either use them or RTFM...

Profiles help but there's always people who are going to change things on a whim, some guide told them, etc. There is one common thing between H.264 encoders and H.264 devices and that's level, an encoder that complies to it is much more user-friendly then one that doesn't.
we dont fix idiots... just our software that is NOT MADE TO BE IDIOT PROOF on purpouse.

turbojet
16th May 2009, 19:46
put a feature request on SF, we'll see what can we do for megui 1.0...;)

OK I'll do that

that depends on the user. if a user wants to set a level but doesnt want to put limits on the bitrate why should we add that restriction?
the user should also get informed on what he's doing. megui is not a software for the first idiot that thinks encoding is just a matter of some random mouse clicks.

Isn't one of the few restrictions of H.264 levels max bitrate?

avc level checker is not inaccurate. it's made around x264 and it wont change until x264 will be fixed (if it ever will...).

They give different results. x264 warns correctly, avc level checker does not.

ppl could RTFM... as i said, you must know what you're doing...


i dont see any problems. there are presets for AVC-HD/BD. You should either use them or RTFM...


we dont fix idiots... just our software that is NOT MADE TO BE IDIOT PROOF on purpouse.

All rants that solve absolutely nothing. I also see no where in help explaining the levels so this would be misleading.

Doom9
16th May 2009, 20:56
Since I wrote the checker, this argument sparked my interest.
You asked
They give different results. x264 warns correctly, avc level checker does not.and I'd say it's better to error on the side of caution, is it not? Encoding a 1080p file can take some time after all. The x264 devs tend to give GUI developers pointers when something changes.. so I wonder if megui is doing something wrong they haven't brought it up - perhaps the approach of rather being safe than sorry also help them from bogus error reports.

Isn't one of the few restrictions of H.264 levels max bitrate?Not directly.. it really depends on the resolution and framerate of the source - and that's why I wrote the checker as a tool accessible in the main form (where you load sources), and not within a codec configuration (a user may not have loaded the source or may change it.. thus making the whole idea of saving presets unworkable). And, I still don't see a way to make this any better.. you can only really enforce levels properly if you completely change the workflow - megui wasn't built around enforcing a certain workflow.. it started out with what's still there and then got the auto encoder and finally the one click encoder - properly enforcing levels only works if you go about it in a whole different way (the one click workflow).. so if you want a mandatory or optional checker, that's where you'd need to put it.. and definitely not in the codec configuration.

Clicking around in the latest version a bit I noted that selecting a level no longer enforces the constraints that can be enforced.. I guess you can have a different opinion on that, but my approach with enforcing meant you lose flexibility so it appears the current developers opted for flexibility in that case - and it's really an either or decision.. you cannot have both. Given megui's history I understand why the choice went into the current direction - non experienced users can use the premade presets and the tools to facilitate encoding whereas all options are open to the advanced users who know what they're doing. I suppose you could have a setting "I know what I'm doing" and only allow people to change codec configurations, write scripts and the likes when that's checked, but it's a lot of work trying to force people who don't know better to not hurt themselves.

turbojet
16th May 2009, 21:13
Since I wrote the checker, this argument sparked my interest.
You asked
and I'd say it's better to error on the side of caution, is it not? Encoding a 1080p file can take some time after all. The x264 devs tend to give GUI developers pointers when something changes.. so I wonder if megui is doing something wrong they haven't brought it up - perhaps the approach of rather being safe than sorry also help them from bogus error reports.

Safe side sure but I would side with accuracy on a proven formula then to go below it which avc level checker does. The only safe thing I could understand is lowering ref by 1 if b-pyramid but some others and I have proven that b-pyramid does not affect the DPB anymore but simply playing max refs+b-pyramid in BD players. There is nothing obvious in x264 changelog to represent this however. The MeGUI wiki agrees with me on ref and b-pyramid.

Not directly.. it really depends on the resolution and framerate of the source - and that's why I wrote the checker as a tool accessible in the main form (where you load sources), and not within a codec configuration (a user may not have loaded the source or may change it.. thus making the whole idea of saving presets unworkable). And, I still don't see a way to make this any better.. you can only really enforce levels properly if you completely change the workflow - megui wasn't built around enforcing a certain workflow.. it started out with what's still there and then got the auto encoder and finally the one click encoder - properly enforcing levels only works if you go about it in a whole different way (the one click workflow).. so if you want a mandatory or optional checker, that's where you'd need to put it.. and definitely not in the codec configuration.

Clicking around in the latest version a bit I noted that selecting a level no longer enforces the constraints that can be enforced.. I guess you can have a different opinion on that, but my approach with enforcing meant you lose flexibility so it appears the current developers opted for flexibility in that case - and it's really an either or decision.. you cannot have both. Given megui's history I understand why the choice went into the current direction - non experienced users can use the premade presets and the tools to facilitate encoding whereas all options are open to the advanced users who know what they're doing. I suppose you could have a setting "I know what I'm doing" and only allow people to change codec configurations, write scripts and the likes when that's checked, but it's a lot of work trying to force people who don't know better to not hurt themselves.

All but these 2 things I brought up are already enforced by profile@level. Check different profiles, exceed max vbv of the level. I see no reason not to extend it to enforce all profile@level now that the formula for figuring it out is well known after months and months of research and testing.

The real problem with telling people to research themselves is the information available is very contradictory.

Sharktooth
17th May 2009, 14:41
you still dont understand x264 breaks the DPB...
so, as a matter of fact, it reports correct info about levels but the resulting stream may be unplayable on some hardware devices.
megui corrects that behaviour lowering some limits to ensure x264 will NOT break the DPB.
so whatever you can say, that wont change since it works. also you didnt prove anything about b-pyramind and DPB. As i said there is no changelog entry in x264 development that points that issue was fixed. hence it is still broken. period.

also you still dont want to UNDERSTAND (and that's your problem, not ours) that the megui workflow doesnt permit to do what you want... and remember megui is a gui for advanced users, not for newbies, so it's pretty normal the megui users should know what they're doing.

Doom9
17th May 2009, 15:11
You seem to mistake the AVC level checker for a generic AVC level checker - which it is not. Given that x264 isn't really respecting AVC levels, megui's checker is a best effort attempt by both x264 and megui developers to help people create streams which are compliant - but there are no guarantees that they really will be compliant since x264 isn't level aware and the developers have repeatedly and over years refused to change that.

The formulas used by megui come directly from the megui developers - and they are outlined here (http://forum.doom9.org/showthread.php?p=730001#post730001). Regardless of how many players you'll find that have no trouble playing streams that have as much reference frames as the actual specs allow - that's no indication that those streams are really compliant. It's not just encoders that may not respect specs, decoders can have the same issues as there's certainly one decoder out there that does require full compliance and it will fail utterly and then the user will blame the megui developers for the failure. Specs are nice and all but anybody who has ever implemented a specification written by a third party is well aware that specs are one thing and the real world is quite another - and you need to develop for the real world. It doesn't help you if you can insist on the fact that you are doing everything right when your software doesn't work the way people expect it - if you rely on some other component that sees things differently and they won't adapt it or only some undetermined time in the future, you simply have no choice but to relax constraints on your own end where you're in control.

But if it really bothers you so, download the megui source code, open up AVCLevels.cs, comment out lines 128 - 133 and recompile (there's a batch file for you to do that in the root of the source.. it used to work with just the .net runtime 2.0 installed so you don't even need to install an SDK or IDE to do that) and voila.. the level checker now calculates ref frames according to spec, and not according to what the x264 devs think you should to be on the safe side when using levels.

And as for my second point, it took me but one reply to understand sharktooth's frustration with you.. I gave you a perfectly valid explanation why your idea doesn't work.. and you completely ignore it. My take of that behavior is that you think you know better anyway - but in that case what you should do is write your own GUI.. or create a fork of megui which implements just the workflows where your ideas to work. We can talk again about whether it makes sense to do levels according to specs when you've been on the receiving end of "bug reports" yourself for a couple of months ;)

Dark Shikari
17th May 2009, 15:26
You seem to mistake the AVC level checker for a generic AVC level checker - which it is not. Given that x264 isn't really respecting AVC levels, megui's checker is a best effort attempt by both x264 and megui developers to help people create streams which are compliant - but there are no guarantees that they really will be compliant since x264 isn't level aware and the developers have repeatedly and over years refused to change that.Have you been under a rock for the past three years or something?

Doom9
17th May 2009, 15:28
Actually, yes, I have in a manner of speaking ... you might have noted the lack of commits during that time;)

Would you be so kind then to give an updated to the situation over akupenguin's post I linked to in my post just before this one... sort of a "rock shock"?

Kurtnoise
17th May 2009, 18:23
from set.c ...:D

int x264_validate_levels( x264_t *h, int verbose )
{
int ret = 0;
int mbs = h->sps->i_mb_width * h->sps->i_mb_height;
int dpb = mbs * 384 * h->sps->i_num_ref_frames;
int cbp_factor = h->sps->i_profile_idc==PROFILE_HIGH ? 5 : 4;

const x264_level_t *l = x264_levels;
while( l->level_idc != 0 && l->level_idc != h->param.i_level_idc )
l++;

if( l->frame_size < mbs
|| l->frame_size*8 < h->sps->i_mb_width * h->sps->i_mb_width
|| l->frame_size*8 < h->sps->i_mb_height * h->sps->i_mb_height )
ERROR( "frame MB size (%dx%d) > level limit (%d)\n",
h->sps->i_mb_width, h->sps->i_mb_height, l->frame_size );
if( dpb > l->dpb )
ERROR( "DPB size (%d frames, %d bytes) > level limit (%d frames, %d bytes)\n",
h->sps->i_num_ref_frames, dpb, (int)(l->dpb / (384*mbs)), l->dpb );

#define CHECK( name, limit, val ) \
if( (val) > (limit) ) \
ERROR( name " (%d) > level limit (%d)\n", (int)(val), (limit) );

CHECK( "VBV bitrate", (l->bitrate * cbp_factor) / 4, h->param.rc.i_vbv_max_bitrate );
CHECK( "VBV buffer", (l->cpb * cbp_factor) / 4, h->param.rc.i_vbv_buffer_size );
CHECK( "MV range", l->mv_range, h->param.analyse.i_mv_range );
CHECK( "interlaced", !l->frame_only, h->param.b_interlaced );

if( h->param.i_fps_den > 0 )
CHECK( "MB rate", l->mbps, (int64_t)mbs * h->param.i_fps_num / h->param.i_fps_den );

/* TODO check the rest of the limits */
return ret;
}

Disturbance
17th May 2009, 21:00
G'day, lately I've been having a problem with megui, when ever i use multiple workers at once, ie 2 workers, they get to about 0.8% and then megui just closes, no error dialogue it just closes down, in my scripts i have all my plugins loaded in script, i use the latest avisynth 2.5.8, and once it actually came up with an error and im my events viewer it spits this out at me

Faulting application megui.exe, version 0.3.1.1035, faulting module msvcr80.dll, version 8.0.50727.1433, fault address 0x000173d0.

anyone have any idea what could be the problem

Dark Shikari
17th May 2009, 21:06
Actually, yes, I have in a manner of speaking ... you might have noted the lack of commits during that time;)

Would you be so kind then to give an updated to the situation over akupenguin's post I linked to in my post just before this one... sort of a "rock shock"?x264 will yell loudly about all violations of significant level limits.

turbojet
17th May 2009, 22:18
AVC level checker's formula is inaccurate for the way x264 works today. Come to think of it, it really did take years to figure out the correct formula. Those years of work don't even really play a role in today's encoding because only one thing has any mention of it, x264, all it does is warn you and expects the user to figure out the error.

MeGUI enforces some parts of levels but ignores some others, I consider this incomplete and suggest to complete it for the better of the program. Others think it's intentional and not all parts of the level should have to be followed and the common excuse seems to be you need to be an advanced user or use profiles. The way I see it for the majority of people who aren't 'advanced', ensuring levels gives the user a lot more freedom while still ensuring playback while one change in a profile can break playback.

x264 gives an accurate yell but if megui can't hear it does it make a sound?

Kurtnoise
18th May 2009, 00:04
what I told you ?...now, pass the 2nd. Period. :rolleyes:

magic144
18th May 2009, 00:41
hey guys,
just came across an issue with MeGUI last week

when using the AutoEncode feature, I ended up with an .mkv that was larger (by 2MB) than the chosen target size (8152 MB, DVD-9)

am I right in assuming that MeGUI IS NOT taking into account the size of the subtitle stream when calculating bitrate?

this is the first time this has ever happened, but I tried playing around with the standalone bitrate calculator tool and it seems to confirm my assumption

I have more recently been using BDSup2Sub to make VobSub idx/sub pairs which are obviously significantly larger than .srt text files, so whereas before the .srt files would have had little or no impact on target size, this is not necessarily true with VobSub

anyway, in a nutshell, if my assumption is correct (?), will MeGUI incorporate a bitrate adjustment to take into account the size of the subtitles in its AutoEncode calculations?

thanks for such a brilliant tool!

m

Sharktooth
18th May 2009, 01:15
AVC level checker's formula is inaccurate for the way x264 works today. Come to think of it, it really did take years to figure out the correct formula. Those years of work don't even really play a role in today's encoding because only one thing has any mention of it, x264, all it does is warn you and expects the user to figure out the error.

MeGUI enforces some parts of levels but ignores some others, I consider this incomplete and suggest to complete it for the better of the program. Others think it's intentional and not all parts of the level should have to be followed and the common excuse seems to be you need to be an advanced user or use profiles. The way I see it for the majority of people who aren't 'advanced', ensuring levels gives the user a lot more freedom while still ensuring playback while one change in a profile can break playback.

x264 gives an accurate yell but if megui can't hear it does it make a sound?
you still dont want to UNDERSTAND... read again what i wrote... x264 will break the DPB in some situations. the megui level checker ensures that wont happen.
now, if you still dont want to understand, i will ignore further posts from you.

hey guys,
just came across an issue with MeGUI last week

when using the AutoEncode feature, I ended up with an .mkv that was larger (by 2MB) than the chosen target size (8152 MB, DVD-9)

am I right in assuming that MeGUI IS NOT taking into account the size of the subtitle stream when calculating bitrate?

this is the first time this has ever happened, but I tried playing around with the standalone bitrate calculator tool and it seems to confirm my assumption

I have more recently been using BDSup2Sub to make VobSub idx/sub pairs which are obviously significantly larger than .srt text files, so whereas before the .srt files would have had little or no impact on target size, this is not necessarily true with VobSub

anyway, in a nutshell, if my assumption is correct (?), will MeGUI incorporate a bitrate adjustment to take into account the size of the subtitles in its AutoEncode calculations?
post a feature request in the megui feature requests tracker on sourceforge.
G'day, lately I've been having a problem with megui, when ever i use multiple workers at once, ie 2 workers, they get to about 0.8% and then megui just closes, no error dialogue it just closes down, in my scripts i have all my plugins loaded in script, i use the latest avisynth 2.5.8, and once it actually came up with an error and im my events viewer it spits this out at me

Faulting application megui.exe, version 0.3.1.1035, faulting module msvcr80.dll, version 8.0.50727.1433, fault address 0x000173d0.

anyone have any idea what could be the problem
be more specific. what jobs you assigned to the workers?

turbojet
18th May 2009, 07:31
you still dont want to UNDERSTAND... read again what i wrote... x264 will break the DPB in some situations. the megui level checker ensures that wont happen.
now, if you still dont want to understand, i will ignore further posts from you.

You never said x264 will break DPB until now but you said may which I took as you weren't sure. But since you now know it will please give x264 settings and device(s) that are affected by this broken DPB with the current build so the community can test it and possibly fix it.

Also please don't go linking to posts back in November, we've already been through that and x264 b-pyramid behavior has changed since. I don't know why it's undocumented or if it's mentioned in some other way in the changelog but the real test is checking on hardware which some people have already done, myself included. I was tipped off by this post (http://forum.doom9.org/showthread.php?p=1277785#post1277785) and rather than say it's not in changelog so I don't believe it I went and tested and he was correct as is the megui wiki.

Disturbance
18th May 2009, 07:52
be more specific. what jobs you assigned to the workers?

when i encode something i use a automated 2 pass, but i also add an analysis pass as well, and i assign the sets of 3 to a worker, so say for example i have 2 videos i want to encode, i load the avs, Queue analysis pass, and then the enqueue button, go to the "queue" tab and set the 3 created jobs to a single worker, then i repeat the process for the other video, set those 3 created jobs to another worker, then i hit "start" and then the 2 workers start the analysis pass gets to %0.7 then megui with no error window or anything just completely closes,

i am at a loss as to why it does this

AkumaX
18th May 2009, 07:56
I have a couple questions from the last couple builds from the Core;

Is there a specific reason why Device target was added? Does specifying a device do anything special rather than keeping it normal? (please elaborate whether it makes a difference for iPod Touch/iPhone/PSP encoding)

I recently tried an encode for my iPod Touch. I selected the Device-Iphone profile, with a resolution of 640x360. However, after the encode (whether selecting normal or iphone for the device target), it plays back at an AR of 20:13 - it's playing back @ 640x416 on my iPod, VLC, QuickTime, and MPC-HD (w/ K-Lite). Any reasons why?

Thanks!

edit: forget question#2, I just restarted MeGUI and it encoded fine now. Weird...

Sharktooth
18th May 2009, 13:23
You never said x264 will break DPB until now but you said may which I took as you weren't sure. But since you now know it will please give x264 settings and device(s) that are affected by this broken DPB with the current build so the community can test it and possibly fix it.
Coz it MAY break the DPB. that means it will not sistematically do that but WILL do in some occasions.
Breaking the DPB means it will produce a non compliant stream and i dont give a sh!t what devices wont play that coz what i care is it will be non compliant to the standard.

Also please don't go linking to posts back in November, we've already been through that and x264 b-pyramid behavior has changed since. I don't know why it's undocumented or if it's mentioned in some other way in the changelog but the real test is checking on hardware which some people have already done, myself included. I was tipped off by this post (http://forum.doom9.org/showthread.php?p=1277785#post1277785) and rather than say it's not in changelog so I don't believe it I went and tested and he was correct as is the megui wiki.
ppl may say whatever they want... so if they lie you will believe lies? no entry in the changelog means it hasnt been fixed.
sagekilla maybe refers to the fact the situation has been improved (coz before november x264 was wildly braking the DPB) but it's still buggy.
also note how Dark_Shikari, a x264 dev, posted here during our discussion BUT didnt say i was wrong.
why dont you ask him instead of pissing me off?
also you may continue to speak forever but things wont change until x264 will be fixed. what you will get, instead, is a very high probability to get insulted to death for being such a retarded.

Sharktooth
18th May 2009, 13:28
when i encode something i use a automated 2 pass, but i also add an analysis pass as well, and i assign the sets of 3 to a worker, so say for example i have 2 videos i want to encode, i load the avs, Queue analysis pass, and then the enqueue button, go to the "queue" tab and set the 3 created jobs to a single worker, then i repeat the process for the other video, set those 3 created jobs to another worker, then i hit "start" and then the 2 workers start the analysis pass gets to %0.7 then megui with no error window or anything just completely closes,

i am at a loss as to why it does this
do you know what the analysis pass does?
your problem is probably due to avisynth going out of memory.

Sharktooth
18th May 2009, 13:30
I have a couple questions from the last couple builds from the Core;

Is there a specific reason why Device target was added? Does specifying a device do anything special rather than keeping it normal? (please elaborate whether it makes a difference for iPod Touch/iPhone/PSP encoding)

I recently tried an encode for my iPod Touch. I selected the Device-Iphone profile, with a resolution of 640x360. However, after the encode (whether selecting normal or iphone for the device target), it plays back at an AR of 20:13 - it's playing back @ 640x416 on my iPod, VLC, QuickTime, and MPC-HD (w/ K-Lite). Any reasons why?

Thanks!

edit: forget question#2, I just restarted MeGUI and it encoded fine now. Weird...
some devices require some special muxing.
apple stuff has common settings, while PSP is different.
both apple (ipods/iphones... etc) and PSP wont accept normally muxed files.

magic144
18th May 2009, 15:35
post a feature request in the megui feature requests tracker on sourceforge.

ok done, thanks!

AkumaX
18th May 2009, 19:26
some devices require some special muxing.
apple stuff has common settings, while PSP is different.
both apple (ipods/iphones... etc) and PSP wont accept normally muxed files.

really? that's strange... because then i don't understand how i'm able to encode for ipod touch/psp if these muxing profiles for specific devices weren't set before. it's always worked *shrug*

Disturbance
18th May 2009, 20:13
your problem is probably due to avisynth going out of memory.

well i dont see how i have 4gb of ram, and i always had encoded multiple videos at a time, just all of a sudden stopped working like that, and can only encode 1 at a time now

turbojet
18th May 2009, 20:56
Coz it MAY break the DPB. that means it will not sistematically do that but WILL do in some occasions.
Breaking the DPB means it will produce a non compliant stream and i dont give a sh!t what devices wont play that coz what i care is it will be non compliant to the standard.

DPB only matters for hardware devices. I care about compliant encodes as well which is why I brought up this suggestion. Currently megui can roam way outside of compliance to the level set.

ppl may say whatever they want... so if they lie you will believe lies? no entry in the changelog means it hasnt been fixed.
sagekilla maybe refers to the fact the situation has been improved (coz before november x264 was wildly braking the DPB) but it's still buggy.
also note how Dark_Shikari, a x264 dev, posted here during our discussion BUT didnt say i was wrong.
why dont you ask him instead of pissing me off?
also you may continue to speak forever but things wont change until x264 will be fixed. what you will get, instead, is a very high probability to get insulted to death for being such a retarded.

There's a big difference between seeing something written and actually experiencing it. Please correct me if I'm wrong but you seem to be basing everything you write off of what you read and not by experience. I don't believe everything I see, in fact I really don't believe there are any hardware devices that used to handle b-pyramid + (max-ref - 1) that don't handle b-pyramid + max-ref with current x264 builds all BD players tested so far handle it and it's by far the majority of the market. I'd encourage people to prove me wrong and I won't get angry about it at all. I've never seen an x264 dev claim that b-pyramid hasn't changed recently and this information is starting to spread.

I agree with you that x264 is the real culprit in all of this and should be responsible to output compliant streams. I already suggested it to them and if you know anything about how they stand on hardware compatibility they've always taken it as a laughing matter, at least the ones on Doom9 and that hasn't changed, Instead they delegate the responsibility to frontends. So here I am suggesting it to one of the more popular frontends that already has some things enforced and still seems to be worked on.

There's no reason to get angry and there's no reason to resort to insults. The only thing that gets me is you claim things over and over again but it's tough to take them seriously when they are so bland, please be more specific about your claims.

Doom9
18th May 2009, 22:07
That last post suddenly rang a bell (http://forum.doom9.org/showthread.php?t=145612&page=2)... suddenly, I see the futility of this discussion all the more clearly.

turbojet
18th May 2009, 23:09
That last post suddenly rang a bell (http://forum.doom9.org/showthread.php?t=145612&page=2)... suddenly, I see the futility of this discussion all the more clearly.

You are going way off topic here but I brought up completely valid points in that discussion, all of which are still true. m2ts has much more compatibility then mkv, m2ts allows lossless subs mkv doesn't, very few(none?) commercial software supports mkv while m2ts is widely supported. I also had experience with popcorn hour and tvix 6500 long before that discussion and it's true that some mkv's won't play correctly while the same audio/video/subs muxed to m2ts plays fine and its reproducable. It's yet TBD if mkv will still be widely talked about in 2011 but I never said it will or won't just that I bet it wouldn't.

Anyhow it's pretty clear that some megui devs want levels to stay non-compliant and they want to keep avc level checker as contradictory to even megui help files (wiki). They'll even start personal attacks to try to prove their point, not good support imo.

I guess my only hope is one of the dev's will actually see why this is important like MPEG1/2 encoders, XviD and DivX did long ago and were very open minded on the matter.

I'm done with this discussion and will just start ignoring every post that comes in regarding broken playback because levels are completely ignored.

Disturbance
19th May 2009, 00:49
well then would u be able to try help with the problem i am having? :D

Sharktooth
19th May 2009, 02:56
well i dont see how i have 4gb of ram, and i always had encoded multiple videos at a time, just all of a sudden stopped working like that, and can only encode 1 at a time now
on windows a 32 bit process cant allocate 4 gigz of ram. when hitting 2 gigz it goes nuts.
simplify your avisynth script.

@turbojet: your points are not valid at all and you still dont want to understand you're wrong. plain and simple. go polluting another place.
from now on i will sistematically ignore all your posts.

Disturbance
19th May 2009, 03:42
sharktooth i dont see how i use the same general scripts and then all of a sudden stops wanting to do it

Sharktooth
19th May 2009, 03:56
trying costs nothing.
the error happens on a dll which is made by microsoft so we cant really debug it...

Clumpco
20th May 2009, 10:51
Has anybody had any problems with update 0.3.1.1037?
Just updated and started an encode, got this immediately:
-[NoImage] Error starting job
--[NoImage] Exception message: starting encoder failed with error 'Process has exited'
--[NoImage] Stacktrace: MeGUI.core.gui.JobWorker.startEncoding(TaggedJob job)
--[NoImage] Inner exception: null

[EDIT] - Rolled back x264.exe to 1148 and normal service was resumed.

Yoshiyuki Blade
20th May 2009, 15:10
Has anybody had any problems with update 0.3.1.1037?
Just updated and started an encode, got this immediately:
-[NoImage] Error starting job
--[NoImage] Exception message: starting encoder failed with error 'Process has exited'
--[NoImage] Stacktrace: MeGUI.core.gui.JobWorker.startEncoding(TaggedJob job)
--[NoImage] Inner exception: null

[EDIT] - Rolled back x264.exe to 1148 and normal service was resumed.

I've had an error with that too, I suppose I should roll back and give it a shot as well.

EDIT: It seems the build from Skystrife is borked somehow. I tried the one from techouse (http://forum.doom9.org/showthread.php?p=1287751#post1287751) and it works fine.

alc0re
21st May 2009, 01:47
some devices require some special muxing.
apple stuff has common settings, while PSP is different.
both apple (ipods/iphones... etc) and PSP wont accept normally muxed files.

Could you elaborate a little on this? I have been using MeGUI for about 6 months now (well before the device type option in the muxer, or at least well before I noticed it.)

I have been using a slightly modified version of the device - iphone profile for transcoding, and I have just muxed using the mp4 muxer. I sync the videos to my ipod touch and it has always worked just fine. I just muxed a few with device type = standard and they work fine. What are the benefits of using device type = iphone if device type = standard plays fine on the iphone?

EDIT : Could it have something to do with that fact that I never use the megui muxer to mux chapter files into my mp4 files? I usually mux audio+video to mp4 with megui, then I take that and mux the chapter information to that file with mp4creator. If that's one reason to select device type = iphone, are there other reasons?

EDIT 2 : Just tested muxing audio + video + chapters file to mp4 with MeGUI with option device type = iphone, and the chapters don't work (even after changing the extension to .m4v like what I have to do after using mp4creator to have chapters work.)

Sharktooth
21st May 2009, 03:11
alc0re: :search:

alc0re
21st May 2009, 04:54
@Sharktooth

I did search...I'm not an idiot. But all that I found regarding the question I posted were the release notes simply stating the feature was added to be able to force those different muxing types. My question is not as simple as what does it do...I'm asking what specifically the differences are between the standard device type for muxing and the iphone, since they both work on an iphone/ipod touch.

You took the time to answer the poster before the same question without putting in a :search:, you could just as easily responded to my question that is basically a continuation of the previous poster's question.

EDIT : I've also checked the documentation of mp4box.exe and all it said was that -ipod switch rewrites the file for ipod support...still not very clear on any advantages of using the -ipod switch in mp4box when ipod's with newest firmware can play regular muxed files just fine...would love to know if there were any benefits to using -ipod

Kurtnoise
21st May 2009, 07:13
may be interesting if you want to have subtitles...

alc0re
21st May 2009, 15:29
Last time I did research, iphone/ipod touch didn't support subtitles (that weren't burned into the movie.) When I use the slightly modified version of mp4creator to add chapters to my m4v files, they show up in mediainfo as timed text...but the ipod uses them as chapter markers. So I'm not sure if you could have chapters that used the timed text format as well as subs. I've searched around and I can't find anything saying there's real support for subs for iphone/ipod touch.

GB
21st May 2009, 15:55
I recently instaled Win7 x64 build 7127. When I encode the same material like I did before in Vista x64 ( h264 in ts to x264 in mkv), the speed in the 1st pass is slower with 40-45%. In the 2nd pass the speed is only slowed by maximum 10%. I can't find an explanation for it. I am encoding using "2pass unrestricted fast" preset.

Kurtnoise
21st May 2009, 22:45
Last time I did research, iphone/ipod touch didn't support subtitles (that weren't burned into the movie.) When I use the slightly modified version of mp4creator to add chapters to my m4v files, they show up in mediainfo as timed text...but the ipod uses them as chapter markers. So I'm not sure if you could have chapters that used the timed text format as well as subs. I've searched around and I can't find anything saying there's real support for subs for iphone/ipod touch.
Just give it a try...

I recently instaled Win7 x64 build 7127. When I encode the same material like I did before in Vista x64 ( h264 in ts to x264 in mkv), the speed in the 1st pass is slower with 40-45%. In the 2nd pass the speed is only slowed by maximum 10%. I can't find an explanation for it. I am encoding using "2pass unrestricted fast" preset.
using an OS not finished for regular stuff is insane...

therealjoeblow
21st May 2009, 23:31
When recompressing some of my existing H264 encodes, can someone please recommend the correct setting for FFDShow's H264 deblocking options in the Codec's page when using it as the decoder with DirectShowSource? Should either or both of the "skip deblocking when safe" or "skip deblocking always" be enabled or disabled?

Otherwise, I have the other settings all at default (eg, postprocessing, resize, sharpen, levels, overlay, etc. are all OFF/disabled.)

Also, on the Output & RGB Conversion tabs, should I make any changes or just leave those at default?

Many thanks
The REAL Joe

GB
22nd May 2009, 21:45
using an OS not finished for regular stuff is insane...
Pointless answer. If I was a regular user wanting to do basic "regular stuff", I wouldn't have instaled a beta OS.
On-topic: I tryed using some lower quality settings for x264 than the ones I usually use, and the fps was did not got higher than 10-11 in the first pass. However in the second pass, the fps is like before, no drops in it.

Kurtnoise
23rd May 2009, 06:47
Meaningless question I would say. Why you're posting in this thread then ? you think it's related to megui ? if yes, prove it otherwise create a new thread...

Taddeusz
28th May 2009, 21:32
MeGUI in combination with Avisynth and the CoreAVC decoder don't seem to play well together. I can get previews and everything just fine. When it comes time to transcode the video if I click on the progress window MeGUI stops responding. Once x264 is finished MeGUI comes back to life, at least on shorter videos. This doesn't seem to happen with any other dx filter. Just with CoreAVC. Any ideas?

daWsOn_s
28th May 2009, 23:23
delete

alc0re
28th May 2009, 23:57
MeGUI in combination with Avisynth and the CoreAVC decoder don't seem to play well together. I can get previews and everything just fine. When it comes time to transcode the video if I click on the progress window MeGUI stops responding. Once x264 is finished MeGUI comes back to life, at least on shorter videos. This doesn't seem to happen with any other dx filter. Just with CoreAVC. Any ideas?


They all worked just fine on my computer. I was using CoreAVC, MeGUI and Avisynth all just fine on both windows xp with sp2 and with sp3.

Although that was a few months ago when I was still using DirectShowSource for both h.264 and vc1 sources.

My recommendations are to make sure CoreAVC, MeGUI and Avisynth are all updated to newest available.

If that doesn't work I really don't recommend using DirectShowSource anyways. You should be indexing the h264 file with DGAVCDec from neuron2.net. If the source is VC1 though, you have to 1) have an nvidia video card that support CUDA and 2) you have to be a contributer on the website neuron2.net to be able to use the VC1 decoder/indexing programs. At least the h264 one is free.

Hope that helps

alcOre

Adub
29th May 2009, 23:00
DSS2 from Haali's splitter package is also a nice alternative when partnered with FFDShow-Tryouts. I use this all the time, as it's frame accurate and multi-threaded, since DGAVCDec is not multi-threaded.

alc0re
30th May 2009, 02:29
Oh...I didn't know there was another solution that was frame accurate....

Decodes VC1 also?


I'm not that worried about the decoder being multi-threaded since as far as I know, the decoding is hardly ever the bottleneck (as least with me dealing mostly with HD content.)

alcOre

mencius
30th May 2009, 21:23
I can't convert AAC to MP3. The error says "DirectShowSource: Could not open as video or audio." I am using latest version. I think I have done this before with no problem.

Inspector.Gadget
30th May 2009, 21:37
mencius, you need an AAC decoder. Install latest ffdshow-tryouts (if you haven't already) and make sure AAC decoding is enabled in the audio config.

mencius
30th May 2009, 22:27
Thanks Inspector.Gadget. I already had ffdshow installed. I tried installing the latest version and checked everything (avisynth serving and plugins, etc) and set it to decode aac. But still doesn't work in Megui.

Inspector.Gadget
30th May 2009, 23:28
Do you have an MP4 splitter installed? (File may not be "raw" AAC).

mencius
31st May 2009, 02:16
Yes I have Haali Media Splitter installed. I reinstalled it but still no go.

Sharktooth
31st May 2009, 02:19
if your avs doesnt play in a directshow media player, megui cant encode it.
fix your directshow filter chain until the avs script plays back in a DS media player.

mencius
31st May 2009, 03:26
Okay thanks, it works now. I installed "AAC parser filter for DirectShow".

therealjoeblow
2nd June 2009, 18:36
When recompressing some of my existing H264 encodes, can someone please recommend the correct setting for FFDShow's H264 deblocking options in the Codec's page when using it as the decoder with DirectShowSource? Should either or both of the "skip deblocking when safe" or "skip deblocking always" be enabled or disabled?

Otherwise, I have the other settings all at default (eg, postprocessing, resize, sharpen, levels, overlay, etc. are all OFF/disabled.)

Also, on the Output & RGB Conversion tabs, should I make any changes or just leave those at default?

Many thanks
The REAL Joe

I posted the above question a while back, but didn't see any response, so I figured I'd try asking again.

Could someone who has some good experience or knowledge please recommend the appropriate settings to use for FFDShow's Deblocking option; and for Output Colorspace when used as a decoder with DirectShowSource? I'm assuming that using the wrong settings for those options would affect the quality of the encode to some extent?

Many thanks!

Sharktooth
3rd June 2009, 01:09
ask in the appropriate place.

therealjoeblow
3rd June 2009, 14:46
ask in the appropriate place.

Well, I know there are several different places where I could have asked, but really, what's inappropriate about here? Is there noone here who uses MeGUI as a frontend with ffdshow/directshowsource and have any advice to offer? There's all sorts of talk here about different ways to get the source video (and audio, as _you_ recently contributed to) into the encode process. I don't see anything inappropriate in asking for some advice from people who use a specific tool regularly.

And while I'm at it, if you were going to take the time to post a reply, if you thought I asked in the wrong place, could you not have maybe suggested what the appropriate place would be, rather than just post a snide, useless comment. Seriously, that was quite rude Sharktooth.

alc0re
3rd June 2009, 16:36
@therealjoeblow

I can't answer the question you have about the settings to use (see my pm that I sent you)

But, I would suggest not using DirectShowSource for re-encoding your existing h.264 encodes. Head over to neuron2.net. Go to the section titled Mine, and download DGAVCDec AVC/H.264 Decoder and Frame Server. Trying using that to index your raw h264 file and then using that tool to decode frame accurate video to avisynth. Works just like DGMPGDec. Its a better solution than using DirectShowSource.

alcOre

poisondeathray
3rd June 2009, 16:43
I posted the above question a while back, but didn't see any response, so I figured I'd try asking again.

Could someone who has some good experience or knowledge please recommend the appropriate settings to use for FFDShow's Deblocking option; and for Output Colorspace when used as a decoder with DirectShowSource? I'm assuming that using the wrong settings for those options would affect the quality of the encode to some extent?

Many thanks!

Leave everything as default (everything unchecked), if you change the settings, the output file will not match the input file (unless that's what you want to do). If you have any filters activated in ffdshow, they will pass through to the encode if you are using DirectShowSource() and ffdshow as the decoder (usually unwanted)

If you need to do a colorspace conversion, you can specify that in your script. Most sources (DVD, blu-ray) will be YV12 anyway, so you don't need to do anything. Avoid unecessary colorspace conversions, because they are lossy.

simms
9th June 2009, 19:32
Hi i wasnt sure where to post this but this seemed to most logical place at the moment. if its in the wrong place i do apologise. And please can someone notify me if it gets moved or such.

The problem i am posting about is a virus being downloaded with the MeGui updates. It is of the malware type and today is not the first time i found it. I found this previously but thought myself to have landed unlcuky. So after removing the previous completely and taking all neccisary precautions i re-installed MeGui from a fresh DL of the latest build and did the usual update to aquire the rest of the tools to go with the application. Then ran a virus check once again to be sure (AdAware) Againthis has come up with a virri is the DL'd files. And quite a serious one at that.

Here is the details -


C:\Program Files\megui\tools\eac3to\HookSurcode.dll
C:\Program Files\megui\update_cache\eac3to-316.zip:HookSurcode.dll

Win32BackDoor.Hupigon
also known as
Win32BackDoor.Graybird


As you can imagine i am finding this quite shocking as have used MeGui for quite some time and swear by the app.
If someone could please clear up whats happening here i would be most grateful. The virus is quite serious and i wish to continue using MeGui....

Thankyou for anyones time and look forward to reply's.

Inspector.Gadget
9th June 2009, 19:33
eac3to and its libraries do not contain viruses. That is a false positive. Check the eac3to thread for details.

buzzqw
9th June 2009, 19:35
just 2 words: "False Positive"

hooksurcode is a dll by eac3to use for commanding Surcode DTS Encoder.

It's safe software. You can check on eac3to thread. There are many antivirus that flag it as virus. BUT IS ALWAYS A FLASE POSITIVE.

you can report to your antivirus

BHH

Taurus
9th June 2009, 20:28
@simms
Trash your stupid VBA32 Virus Scanner - it's a false alarm.
Next time before insulting a honest source, upload the suspicious file to http://www.virustotal.com and see for yourself!

simms
10th June 2009, 01:37
@ Inspector Gadget, buzzqw

Thankyou for your reply's it is appreciated. I was hoping it was something like this but thought i would ask.

@ Taurus

From the look of my post did it seem i was trying to insult anything....? I came asking a question as anyone would under those circumstances, and got reply's to what i asked which is fair enough.
Using online scanners which if you checked dont always keep there db's up to date as they should do, to get more false readings would have done no one any good. It is better to just ask at the source and see if anyone else has had the issue or if its just a mistake.

Thankyou for your replys.

simms

delanejenkins
11th June 2009, 04:21
Is there any way to do a 2pass encode and use constant quality for the first pass instead of avg bitrate?

Sharktooth
11th June 2009, 13:34
yes, doing it manually. i mean, set you your own presets with NO automated 2 or 3 passes.

delanejenkins
11th June 2009, 19:10
Thanks sharktooth. So I should just run a CQ encode with minimal settings like that of a turbo pass then plug that resulting avg bitrate into a 1 pass abr?

Am I oversimplifying it or is this correct? I'm just not sure what info is passed in the .stats files from the first pass of a 2pass encode

Sharktooth
12th June 2009, 13:38
nope. 1st pass using CRF (ensure the stats are saved, if not, manually add the --stats ".stats" option in the custom commandline options field) and regular 2nd pass using the avg bitrate from the first pass.

delanejenkins
12th June 2009, 14:29
Ok thanks Sharktooth. Any chance there may ever be an automated 2pass with Crf?

Sharktooth
12th June 2009, 16:45
i think not since CRF bitrate is unpredictable.

delanejenkins
12th June 2009, 17:23
Yeah I'm sure it's not a commonly used method. The only reason I need to use it is because I want to get the optimal bitrate but still have to stay dxva compliant and use vbv

nurbs
12th June 2009, 21:56
You can have that with only one pass. x264 will write vbv violations in the log and quality should only be worse in 1pass + vbv if you encode close to the limits. You could always create a log and only do a second pass if problems show up.
It also depends on what you want to do. If for instance you encode 720p at level 4.1 you'll basically never run into problems at sane crf values.

delanejenkins
13th June 2009, 00:46
Nurbs, I usually do my sd to 3.1 and do all my bluray to 720p at level 4.1, all at crf 18. I actually was wondering if I would even need to worry about any bitrate spikes beyond those levels.

delanejenkins
13th June 2009, 03:39
Sharktooth, tried to get megui to save the .stats file by adding the --stats ".stats" into the custom command line and cannot get it to save a stats file. What am I doing wrong?

Sharktooth
13th June 2009, 12:15
also add "--pass 1"

delanejenkins
13th June 2009, 16:52
Sharktooth, I added the "--pass 1" command and I am now getting a stats file but when I try to run my second pass I just get an error. Am i doing something wrong? I keep the same file loaded up and switch my preset to 2pass 2nd pass and enqueue.

Sharktooth
14th June 2009, 02:50
what error?

delanejenkins
14th June 2009, 04:43
Under the queue tab, it immediately shows up as error and nothing is encoded

Sharktooth
14th June 2009, 14:17
well there is a Log tab for a reason... ;)

delanejenkins
15th June 2009, 04:23
[Error] Log
-[Information] Versions
--[NoImage] MeGUI Version : 0.3.1.1041
--[NoImage] OS : Windows XP Home Edition x86 SP3 (5.1.196608.2600)
--[NoImage] Framework used : 2.0 SP1 (2.0.50727.3082)
-[Information] Hardware
--[NoImage] CPU : AMD Phenom(tm) II X4 920 Processor
-[Error] Log for job9 (video, Test.avs -> Test.mkv)
--[Information] [6/13/2009 10:49:08 AM] Started handling job
--[Information] [6/13/2009 10:49:08 AM] Preprocessing
--[NoImage] Job commandline: "C:\Video Tools\megui\tools\x264\x264.exe" --pass 2 --bitrate 2800 --stats "G:\Video Workbench\DVD\Test.stats" --level 3.1 --ref 5 --mixed-refs --bframes 3 --b-adapt 2 --weightb --direct auto --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 14000 --vbv-maxrate 17500 --me umh --threads auto --thread-input --sar 638:525 --progress --no-psnr --no-ssim --output "G:\Video Workbench\DVD\Test.mkv" "G:\Video Workbench\DVD\Test.avs"
--[Information] [6/13/2009 10:49:08 AM] Encoding started
--[Error] An error occurred: x264 [error]: ratecontrol_init: can't open stats file
--[Error] An error occurred: x264 [error]: x264_encoder_open failed
--[NoImage] Standard output stream
--[NoImage] Standard error stream
---[NoImage] avis [info]: 720x352 @ 23.98 fps (5297 frames)
---[NoImage] x264 [info]: using SAR=638/525
---[NoImage] x264 [info]: using cpu capabilities: MMX2 SSE2Fast FastShuffle SSEMisalign LZCNT
--[Information] [6/13/2009 10:49:09 AM] Job completed
-[Information] Log for job13 (video, Test.avs -> Test.mkv)
--[Information] [6/13/2009 11:47:42 AM] Started handling job
--[Information] [6/13/2009 11:47:44 AM] Preprocessing
--[NoImage] Job commandline: "C:\Video Tools\megui\tools\x264\x264.exe" --crf 18 --bframes 3 --b-adapt 2 --weightb --subme 2 --partitions none --threads auto --thread-input --sar 638:525 --progress --no-psnr --no-ssim --output "G:\Video Workbench\DVD\Test.mkv" "G:\Video Workbench\DVD\Test.avs" --pass 1 --stats "G:\Video Workbench\Megui\test.stats"
--[Information] [6/13/2009 11:47:44 AM] Encoding started
--[NoImage] Standard output stream
--[NoImage] Standard error stream
---[NoImage] avis [info]: 720x352 @ 23.98 fps (5297 frames)
---[NoImage] x264 [info]: using SAR=638/525
---[NoImage] x264 [info]: using cpu capabilities: MMX2 SSE2Fast FastShuffle SSEMisalign LZCNT
---[NoImage] x264 [info]: profile Main, level 3.0
---[NoImage]
---[NoImage] x264 [info]: slice I:120 Avg QP:13.09 size: 34265
---[NoImage] x264 [info]: slice P:1834 Avg QP:14.95 size: 20939
---[NoImage] x264 [info]: slice B:3343 Avg QP:17.04 size: 10332
---[NoImage] x264 [info]: consecutive B-frames: 2.6% 14.7% 57.4% 25.3%
---[NoImage] x264 [info]: mb I I16..4: 34.4% 0.0% 65.6%
---[NoImage] x264 [info]: mb P I16..4: 50.4% 0.0% 0.0% P16..4: 49.1% 0.0% 0.0% 0.0% 0.0% skip: 0.5%
---[NoImage] x264 [info]: mb B I16..4: 31.9% 0.0% 0.0% B16..8: 34.1% 0.0% 0.0% direct:23.6% skip:10.4% L0:23.2% L1:33.7% BI:43.1%
---[NoImage] x264 [info]: coded y,uvDC,uvAC intra:93.5% 77.4% 43.6% inter:52.5% 40.3% 1.7%
---[NoImage] x264 [info]: kb/s:2790.1
---[NoImage] encoded 5297 frames, 66.08 fps, 2790.27 kb/s
--[Information] Final statistics
---[NoImage] Constant Quality Mode: Quality 18 computed...
---[NoImage] Video Bitrate Obtained (approximate): 2793 kbit/s
--[Information] [6/13/2009 11:49:05 AM] Postprocessing
---[Information] Deleting intermediate files
--[Information] [6/13/2009 11:49:05 AM] Job completed

doveman
15th June 2009, 11:15
First, thanks for a great tool. The only thing that bugs me is that the output filenames are all lower case, both for XviD and x264 encoding. Is there anything that can be done to preserve the case from the input filenames?

tebasuna51
15th June 2009, 11:42
@delanejenkins
If pass2 is executed before pass1 and with diferent stats filename:

--pass 2 --stats "G:\Video Workbench\DVD\Test.stats"
--pass 1 --stats "G:\Video Workbench\Megui\test.stats"

the pass2 never found the stats file:
--[Error] An error occurred: x264 [error]: ratecontrol_init: can't open stats file

patelsiraj1
15th June 2009, 12:41
Hi all..

Can we have feature of Autoresize in MeGUI like Automkv and AutoGK.

Sharktooth
15th June 2009, 12:56
feature requests -> HERE (http://sourceforge.net/tracker/?atid=798479&group_id=156112&func=browse)

delanejenkins
16th June 2009, 05:47
Ok finally figured out what i was doing wrong. I had to manually enter the name for "name.stats" in the custom command line for the first pass to match the name of my output file. Working like a charm now. Thanks for the help guys

deets
16th June 2009, 19:50
would it be possible to add an option to use the 64 bit version of x264?

currently i can use ripbot264 but it doesnt support dga files and hardware deinterlacing, but megui does, but lacks the 64 bit option :)

Akatsuker
17th June 2009, 02:12
Two simple and fast ones for you (I've been searching but found nothing):

First - Quoting, meWIKI:

1st/2nd/3rd pass:' If you want more control over your pass settings, you can set every pass up individually. You will have to set up every pass you want this way, MeGUI will not detect or setup missing passes.

Logfile: When encoding a first pass, the video encoder will run through the movie and write statistics about it to a log file for use in subsequent passes. With this option, you can specify the location of the pass if you want to. The default location is in the output directory. For LMP4/XviD this option is on the last page, for x264/Snow it is on the first.

The thing is, I did an automated 2 pass, but in the second job (2nd pass), i've got an error ("unsupported format(DIB)" thing). Found this (http://forum.doom9.org/archive/index.php/t-107549.html) and I'll give a try putting "converttoYV12()" on the script.

But, like I said, it was a 2pass automated, and the 1st job (analysing and generating a .stats file) worked fine. I want to do just the 2nd pass, using the "2 pass - 2nd pass" on the x264 config menu.

On the quotes, it says "write statistics about it to a log file for use in subsequent passes". Okay. But how x264 will know what the .stats file it should be using on this 2nd pass? The option there is for writing some new stats file, even when I try this option (on "Logfile"). :confused:

Second - Just opened my stats file, I see that it records and uses the resolution info (it's a 720p video). Can anybody please just confirm that, if I want to do two encodes of the same script (except for the resolution: script 1 is 720p, but script 2 is, for example, 480p), I couldn't use the same .stats for both?

Sorry if that's too dumb... Like I said, I've been searching for the answers. Thanks. ^^'

Ruriko
19th June 2009, 05:05
How do I add a picture at the begining of the video for 10 seconds?

Sharktooth
19th June 2009, 12:55
@deets: it does but you cant simply replace x264 with x264 64bit... you need to "flag" megui as a 64bit app, replace avisynth, filters and all the needed decoders with 64 bits ones, etc...

@akatsuker: 1st, you can either use automated 2 pass or 2-pass 1st pass and then 2-pass 2nd pass. do yourself a favour and dont mix... 2nd, the answer is no.

@Ruriko: the answer is: thru avisynth. you should ask in the avisynth forum.

badbob001
8th July 2009, 23:10
In MeGUI (0.3.1.1046), I run AVS Script Creator, select a Video Input, and the video is displayed in a new window. It plays fine. BUT if in MeGUI I click [Preview AVS Script] or check [x] Apply Auto Preview, the video turns solid green.

If I go ahead and encode the video, the result is still green. What is wrong?

The input is mjpeg avi. I have AVisynth 2.5.8 installed.

Inspector.Gadget
8th July 2009, 23:14
You may have a broken MJPEG decoder. Try using ffdshow-tryouts instead.

rtjnyoface
13th July 2009, 09:10
I really just wanted to stop in really quick and let all the individuals working on MeGUI thank you. I can't imagine the time and effort put into the project. Once again, thanks.

:thanks:

Yoshiyuki Blade
13th July 2009, 19:01
I really just wanted to stop in really quick and let all the individuals working on MeGUI thank you. I can't imagine the time and effort put into the project. Once again, thanks.

:thanks:

Indeed. They've been keeping on top of things with constant updates, and adjusting to the changing times as necessary. Major thanks to the MeGUI devs!

I just noticed one of the latest updates, when you go to x264 options and hit the "Load Defaults" button, youll get a virtually clean command line, with the bare essentials (program/output/input commands). Only --partitions p8x8,b8x8,i4x4,i8x8 and --thread-input are visible now.

By the way, is --partitions p8x8,b8x8,i4x4,i8x8 necessary to be visible despite being the default?

Sharktooth
13th July 2009, 19:37
nope... however it will "disappear" soon... ;)
it's just one of those "redundant" options i was referring to in the MeGUI dev thread.

Yoshiyuki Blade
13th July 2009, 19:53
nope... however it will "disappear" soon... ;)
it's just one of those "redundant" options i was referring to in the MeGUI dev thread.

Awesome! I should lurk around in that thread to see what's up.

arch_angel16
19th July 2009, 23:04
Got something of an issue:

My hdtv died, and I can't afford to replace it, so my media center is now an old large projection tv and an xbox with xbmc. Since xbox can't really take x264 all that well, I'm re-encoding all my stuff to high bitrate divx. Thus far, MeGUI's been awesome for this, but I'm running into an issue:

Some of my files have aspect ratio that don't match their height and width, (ie a 16:9 video with a 704x480 resolution) and MeGUI reads the file as having an AR of 1.467. Now, what's funny is that media player classic opens the video at 16:9/1.778 just fine.

when making the avisynth script, I manually set the AR to 1.778, checked auto preview and resize. the values in the resize field automatically changed to 704x400 (good) and it seemed good to go. I saved the script, and auto-encoded the file.

...the autoencode worked at something like 300fps (first indication something was wrong) and the output file size was only a few megabytes. This is off of a 24 minute long, 350mb original file.

I'm re-doing the job so I can save & output the log entry (my next post).

Anyways, anyone have experience with this?

Inspector.Gadget
19th July 2009, 23:19
Post your AVS Script, arch_angel16.

arch_angel16
19th July 2009, 23:22
My avs script:

DirectShowSource("E:\anime\test\test.mkv", fps=23.976, audio=false, convertfps=true)
#deinterlace
#crop
LanczosResize(704,400) # Lanczos (Sharp)
#denoise

My xvid config:

program -i "input" -pass2 ".stats" -bitrate 1300 -kboost 100 -clow 15 -overhead 0 -turbo -max_key_interval 250 -nopacked -vhqmode 4 -qpel -closed_gop -lumimasking -imin 1 -pmin 1 -bvhq -bquant_ratio 162 -bquant_offset 0 -bmin 1 -threads 2 -o "output"

And my full log after encode complete:

[Information] Log
-[Information] Versions
--[NoImage] MeGUI Version : 0.3.1.1051
--[NoImage] OS : Windows Vista Ultimate Edition x86 SP1 (6.0.65536.6001)
--[NoImage] Framework used : 2.0 SP1 (2.0.50727.1434)
-[Information] Hardware
--[NoImage] CPU : Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz
-[Information] AutoEncode job generation log
-[Information] AutoEncode job generation log
--[NoImage] Split Size : null
--[Information] Eliminating duplicate filenames
---[NoImage] Video output file: E:\anime\test\test.mkv
---[NoImage] File already exists. New video output filename: E:\anime\test\test_0.mkv
---[NoImage] Muxed output file: E:\anime\test\test-muxed.mkv
---[NoImage] Encodable audio stream 0: E:\anime\test\test.ac3
-[Information] Log for job1 (audio, test.mkv -> test.ac3)
--[Information] [7/19/2009 6:23:36 PM] Started handling job
--[Information] [7/19/2009 6:23:36 PM] Preprocessing
--[NoImage] Avisynth script
---[NoImage] DirectShowSource("E:\anime\test\test.mkv", video=false)
---[NoImage] EnsureVBRMP3Sync()
---[NoImage] Normalize()
---[NoImage] return last
--[NoImage] Commandline used: -readtoeof 1 -b 384 - "{0}"
--[Information] [7/19/2009 6:23:36 PM] Encoding started
--[Information] [7/19/2009 6:23:36 PM] Encode thread started
--[Information] [7/19/2009 6:23:36 PM] Avisynth script environment opened
--[Information] [7/19/2009 6:23:37 PM] Script loaded
--[Information] Output Decoder
---[NoImage] Channels: 2
---[NoImage] Bits per sample: 16
---[NoImage] Sample rate: 48000
--[NoImage] Commandline: C:\Program Files\megui\tools\aften\aften.exe -readtoeof 1 -b 384 - "E:\anime\test\test.ac3"
--[Information] [7/19/2009 6:23:37 PM] Encoder process started
--[NoImage] Output from encoder via stderr
---[NoImage] Aften: A/52 audio encoder
---[NoImage] Version SVN
---[NoImage] (c) 2006-2007 Justin Ruggles, Prakash Punnoor, et al.
---[NoImage] input format: Microsoft WAVE Signed 16-bit little-endian 48000 Hz stereo
---[NoImage] output format: 48000 Hz stereo (2/0)
---[NoImage] SIMD usage: MMX SSE SSE2 SSE3
---[NoImage] Threads: 2
---[NoImage] progress: 100% | q: 359.0 | bw: 60.0 | bitrate: 384.0 kbps
--[Information] [7/19/2009 6:24:18 PM] Postprocessing
---[Information] Deleting intermediate files
--[Information] [7/19/2009 6:24:19 PM] Job completed
-[Information] Log for job2 (video, test.avs -> )
--[Information] [7/19/2009 6:24:19 PM] Started handling job
--[Information] [7/19/2009 6:24:19 PM] Preprocessing
--[NoImage] Job commandline: "C:\Program Files\megui\tools\xvid_encraw\xvid_encraw.exe" -i "E:\anime\test\test.avs" -pass1 "E:\anime\test\test_0.stats" -bitrate 1300 -kboost 100 -clow 15 -overhead 0 -turbo -max_key_interval 250 -nopacked -vhqmode 4 -qpel -closed_gop -lumimasking -imin 1 -pmin 1 -bvhq -bquant_ratio 162 -bquant_offset 0 -bmin 1 -par 1:1 -threads 2
--[Information] [7/19/2009 6:24:19 PM] Encoding started
--[NoImage] Standard output stream
---[NoImage] xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003
---[NoImage] Tot: enctime(ms) =138404.00, length(bytes) = 2441803
---[NoImage] Avg: enctime(ms) = 3.79, fps = 264.02, length(bytes) = 66
---[NoImage] I frames: 147 frames, size = 3077/ 452319, quants = 2 / 2.00 / 2
---[NoImage] P frames: 12131 frames, size = 146/ 1771126, quants = 2 / 2.00 / 2
---[NoImage] B frames: 24262 frames, size = 9/ 218358, quants = 3 / 3.00 / 3
--[NoImage] Standard error stream
---[NoImage] Trying to retrieve width and height from input header
---[NoImage] xvid [info]: Avisynth detected
---[NoImage] xvid [info]: Input colorspace is YUYV or YUY2
---[NoImage] xvid [info]: Input is 704 x 400, 23.976fps (2500000/104271), starting from frame 0
---[NoImage] xvid [info]: Number of frames to encode: 36540, Bitrate = 1300kbps
---[NoImage] xvid [info]: xvidcore build version: xvid-1.2.2
---[NoImage] xvid [info]: Bitstream version: 1.2.2
---[NoImage] xvid [info]: Detected CPU flags: ASM MMX MMXEXT SSE SSE2 TSC
---[NoImage] xvid [info]: Detected cpus = 2, threads requested = 1, threads in use = 1
---[NoImage] xvid [info]: Threaded input reading active
--[Information] [7/19/2009 6:26:48 PM] Postprocessing
---[Information] Deleting intermediate files
--[Information] [7/19/2009 6:26:48 PM] Job completed
-[Information] Log for job3 (video, test.avs -> test_0.mkv)
--[Information] [7/19/2009 6:26:48 PM] Started handling job
--[Information] [7/19/2009 6:26:48 PM] Preprocessing
--[NoImage] Job commandline: "C:\Program Files\megui\tools\xvid_encraw\xvid_encraw.exe" -i "E:\anime\test\test.avs" -pass2 "E:\anime\test\test_0.stats" -bitrate 1300 -kboost 100 -clow 15 -overhead 0 -max_key_interval 250 -nopacked -vhqmode 4 -qpel -closed_gop -lumimasking -imin 1 -pmin 1 -bvhq -bquant_ratio 162 -bquant_offset 0 -bmin 1 -par 1:1 -threads 2 -mkv "E:\anime\test\test_0.mkv"
--[Information] [7/19/2009 6:26:48 PM] Encoding started
--[NoImage] Standard output stream
---[NoImage] xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003
---[NoImage] Tot: enctime(ms) =140853.00, length(bytes) = 2442097
---[NoImage] Avg: enctime(ms) = 3.85, fps = 259.43, length(bytes) = 66
---[NoImage] I frames: 147 frames, size = 3079/ 452613, quants = 1 / 1.00 / 1
---[NoImage] P frames: 12131 frames, size = 146/ 1771126, quants = 1 / 1.00 / 1
---[NoImage] B frames: 24262 frames, size = 9/ 218358, quants = 1 / 1.00 / 1
--[NoImage] Standard error stream
---[NoImage] Trying to retrieve width and height from input header
---[NoImage] xvid [info]: Avisynth detected
---[NoImage] xvid [info]: Input colorspace is YUYV or YUY2
---[NoImage] xvid [info]: Input is 704 x 400, 23.976fps (2500000/104271), starting from frame 0
---[NoImage] xvid [info]: Number of frames to encode: 36540, Bitrate = 1300kbps
---[NoImage] xvid [info]: xvidcore build version: xvid-1.2.2
---[NoImage] xvid [info]: Bitstream version: 1.2.2
---[NoImage] xvid [info]: Detected CPU flags: ASM MMX MMXEXT SSE SSE2 TSC
---[NoImage] xvid [info]: Detected cpus = 2, threads requested = 1, threads in use = 1
---[NoImage] xvid [info]: Threaded input reading active
--[Information] Final statistics
---[NoImage] Video Bitrate Desired: 1300 kbit/s
---[NoImage] Video Bitrate Obtained (approximate): 15 kbit/s
--[Information] [7/19/2009 6:29:17 PM] Postprocessing
---[Information] Deleting intermediate files
----[Information] [7/19/2009 6:29:17 PM] Successfully deleted E:\anime\test\test_0.stats
--[Information] [7/19/2009 6:29:17 PM] Job completed
-[Information] Log for job4 (mux, test_0.mkv -> test-muxed.mkv)
--[Information] [7/19/2009 6:29:17 PM] Started handling job
--[Information] [7/19/2009 6:29:17 PM] Preprocessing
--[NoImage] Job commandline: "C:\Program Files\megui\tools\mkvmerge\mkvmerge.exe" -o "E:\anime\test\test-muxed.mkv" --engage keep_bitstream_ar_info --default-duration 1:24000/1001fps -d 1 -A -S "E:\anime\test\test_0.mkv" -a 0 -D -S "E:\anime\test\test.ac3" --no-clusters-in-meta-seek
--[Information] [7/19/2009 6:29:17 PM] Muxing started
--[NoImage] Standard output stream
---[NoImage] mkvmerge v2.9.7 ('Tenderness') built on Jul 1 2009 18:43:35
---[NoImage] 'E:\anime\test\test_0.mkv': Using the Matroska demultiplexer.
---[NoImage] 'E:\anime\test\test.ac3': Using the AC3 demultiplexer.
---[NoImage] 'E:\anime\test\test_0.mkv' track 1: Using the MPEG-4 part 2 video output module.
---[NoImage] 'E:\anime\test\test.ac3' track 0: Using the AC3 output module.
---[NoImage] The file 'E:\anime\test\test-muxed.mkv' has been opened for writing.
---[NoImage] The cue entries (the index) are being written...
---[NoImage] Muxing took 4 seconds.
--[NoImage] Standard error stream
--[Information] [7/19/2009 6:29:22 PM] Postprocessing
---[Information] Deleting intermediate files
----[Information] [7/19/2009 6:29:22 PM] Successfully deleted E:\anime\test\test_0.mkv
----[Information] [7/19/2009 6:29:22 PM] Successfully deleted E:\anime\test\test.ac3
--[Information] [7/19/2009 6:29:22 PM] Job completed

arch_angel16
20th July 2009, 00:56
Can anyone tell me what's happening?

badbob001
20th July 2009, 15:22
Got something of an issue:

My hdtv died, and I can't afford to replace it, so my media center is now an old large projection tv and an xbox with xbmc. Since xbox can't really take x264 all that well, I'm re-encoding all my stuff to high bitrate divx.

I too have been trying to find the right settings for megui to encode into x264 for the original xbox. I tried the settings from here: http://xbmc.org/wiki/index.php?title=HOW-TO_Encode_H.264_Videos_Compatible_With_XBMC_For_Xbox

But to get good quality for high motion vids, you need to enable some x264 settings that are really cpu-heavy. But in the process, I discovered the following:

Xbmc has two players: mplayer by default and dvdplayer. Dvdplayer plays x264 much more smoothly under 100% cpu conditions. Try it out before you re-encode all your 480p x264 content. Use the 'play using...' menu option to pick the player to play a vid. To make it permanent, set dvdplayer to be the default with advancesettings.xml. Note that dvdplayer uses a lot more ram than mplayer so it'll freeze if you don't have enough memory. I had to lower my xbox from 1080i to 720p and uses smaller thumbnails in my skin to get enough ram for all movies. It's probably possible to everything at 1080i when using a very minimal skin.

arch_angel16
22nd July 2009, 23:06
I'm not recoding 480p h264, I'm recoding 720p and 1080p content downwards to 720x400 xvid with 1300k/s bitrate. it's working pretty well, except in the rare situation of a bad encode or an encode where the height / width doesn't 1:1 match the aspect ratio.

badbob001
25th July 2009, 22:07
In MeGUI (0.3.1.1046), I run AVS Script Creator, select a Video Input, and the video is displayed in a new window. It plays fine. BUT if in MeGUI I click [Preview AVS Script] or check [x] Apply Auto Preview, the video turns solid green.

If I go ahead and encode the video, the result is still green. What is wrong?

The input is mjpeg avi. I have AVisynth 2.5.8 installed.

I got it. I installed MeGUI on another PC and it worked fine. So I used InstalledCodec (http://www.nirsoft.net/utils/installed_codec.html) to list my codecs to compare and I started disabling any codec that wasn't on the working PC. The culprit was m3jpeg32.dll from Morgan Multimedia.

mallb
11th August 2009, 02:10
A small cosmetic issue on video preview window.

Screen resolution: 1920x1200, DPI scale: 120


10148

popper
11th August 2009, 22:41
i receaved this error after a current clean install and using x264_dp_ Standalone-PS3-Xbox360_Fast.xml as the output.

[NoImage] Standard error stream: C:\Program Files\megui\tools\x264\x264.exe: unrecognised option `--no-mbtree'

am i to assume the included presets have not been updated to the newer x264 cli options yet ?, if so, how do i fix it being new to this GUI.

or is it, given `--no-mbtree' is one of the newer options, that the included x264 is running behind the preset updates,and is an older one in the auto update, so just manually replace it with a newer version, if so which one, or perhaps you will be providing the required auto update soon.

----------------------------
ohh,looking at the MeGUI change log it seems option two (the currently supplyed older Jeebs 1183 patched x264) is the problem.

i wonder if there are also other external tools (mencoder and ffmpeg/libx264) that have been updated to the newest x264 options recently and so are also in need of new MeGUI updates inclusion?

DS's latest http://mirror05.x264.nl/Dark/x264_mbtree13.exe testing 0.69.1195+2 5ed78fa isnt compiled for Mp4 output apparently (works for mkv, but that containers no good for direct 360 streaming use) so im not sure what the latest version is to use here or which D9 thread to find it posted...

"0.3.1.1053
- (kurtnoise) [x264 Config] * add presets/tunings/mb-tree/rc-lookahead/no-psy options. Requires x264 revision 1206 or higher.

* redesign config panel in 4 tabs (Main, the default one + Frame-type + Rate-Control + Analysis + Misc)

* clean up the code for better reading. "

scottws
12th August 2009, 07:15
i receaved this error after a current clean install and using x264_dp_ Standalone-PS3-Xbox360_Fast.xml as the output.

[NoImage] Standard error stream: C:\Program Files\megui\tools\x264\x264.exe: unrecognised option `--no-mbtree'

am i to assume the included presets have not been updated to the newer x264 cli options yet ?, if so, how do i fix it being new to this GUI.

or is it, given `--no-mbtree' is one of the newer options, that the included x264 is running behind the preset updates,and is an older one in the auto update, so just manually replace it with a newer version, if so which one, or perhaps you will be providing the required auto update soon.

----------------------------
ohh,looking at the MeGUI change log it seems option two (the currently supplyed older Jeebs 1183 patched x264) is the problem.

i wonder if there are also other external tools (mencoder and ffmpeg/libx264) that have been updated to the newest x264 options recently and so are also in need of new MeGUI updates inclusion?

DS's latest http://mirror05.x264.nl/Dark/x264_mbtree13.exe testing 0.69.1195+2 5ed78fa isnt compiled for Mp4 output apparently (works for mkv, but that containers no good for direct 360 streaming use) so im not sure what the latest version is to use here or which D9 thread to find it posted...

"0.3.1.1053
- (kurtnoise) [x264 Config] * add presets/tunings/mb-tree/rc-lookahead/no-psy options. Requires x264 revision 1206 or higher.

* redesign config panel in 4 tabs (Main, the default one + Frame-type + Rate-Control + Analysis + Misc)

* clean up the code for better reading. "


I'm having the same problem. I've tried several presets and they all end up with...

--[NoImage] Standard error stream: C:\Program Files (x86)\megui\tools\x264\x264.exe: unrecognised option `--no-mbtree'

As of 1:00am EDT on 8/12/09, I am using MeGUI with all available updates on Windows 7 Ultimate x64 RC. The latest x264 build available at this time according to MeGUI is Jeeb's 1183 x264.

I downloaded Jarod's 1206 x264 (x64) from here (http://x264.nl/) and replaced the copy in the megui folder. This did not work; there was an error in the MeGUI log stating that x264 could not open the AVS file. I replaced that copy with Jarod's 1206 x264 (x86) from the same link and so far this seems to be working in the sense that the encoding job is actually running now.

nurbs
12th August 2009, 07:28
Sharktooth is currently unavailable, so the files in autoupdade are a bit out of date and a x64 version of x264 obviously can't work directly with a 32bit version of avisynth.

scottws
12th August 2009, 07:30
Sharktooth is currently unavailable, so the files in autoupdade are a bit out of date and a x64 version of x264 obviously can't work directly with a 32bit version of avisynth.

Sorry, it wasn't obvious to me. I just use the stuff. I don't know the details of their inner-workings.

Undead Sega
25th August 2009, 19:00
so in order to keep the x64 version of x264 and to have it work is to install the 64bit version of AviSynth?

kypec
26th August 2009, 06:32
so in order to keep the x64 version of x264 and to have it work is to install the 64bit version of AviSynth?
:search: and you'll find how to use 64-bit x264 with 32-bit Avisynth (http://forum.doom9.org/showthread.php?t=144140)

Undead Sega
26th August 2009, 19:00
well ive done what scottws has done, by replacing the x64 x264 with a x86 x264, and that hasnt solved my problem either, instead i get:

C:\Program Files (x86)\megui\tools\x264\x264.exe: unknown option -- nal-hrd--output

why is this now? :(

nurbs
26th August 2009, 19:04
For starters it should be --nal-hrd --output What version of megui are you using?

Also you must make sure that the x264 version you are using is compiled with the nal-hrd patch. (when the command line is fixed)

Undead Sega
26th August 2009, 22:10
sorry for my technical mistake there on my previous post, however i am using the latest version onf MeGUI with all the latest updates, but as i said i replaced x264 with the x86 version of it. Not to forget to mention, that i am running all this on Windows 7 x64.

nurbs
26th August 2009, 22:22
The question is if the version of x264 you downloaded was compiled with the nal-hrd patch. If you have an unpatched version, for instance the one from x264.nl or one of the unpatched builds the people on this forum provide, then --nal-hrd will of course not be recognized.
You can download an up do date patched build here http://forum.doom9.org/showthread.php?p=1318350#post1318350

Undead Sega
27th August 2009, 00:12
can i get a patched 64bit x264?? would that sort everything out potentially if one exists? :D

Undead Sega
27th August 2009, 00:53
okay, i am abit confused now, ive downloaded this one:

x264 r1232 32bit
download ; release notes
built on Aug 25 2009, gcc: 4.3.4 20090220 (prerelease) (x32.generic.Komisar)
fprofiled, -march=i686

and replaced it in the tools folder of MeGUI and i still get the same thing, did i do something wrong? :(

LigH
27th August 2009, 06:57
If the reason for this error was that two options got glued together, and are still connected without a space in between, then it doesn't matter which build you are trying, this double-option will never get recognised, a space in between is required to separate them.

Undead Sega
27th August 2009, 09:43
but i was given:

-- nal-hrd--output

i took this off the log.

bluebebe
28th August 2009, 15:30
hi, what happened with megui? no updates since ~ 4 weeks?

Taurus
28th August 2009, 15:45
hi, what happened with megui? no updates since ~ 4 weeks?
11 posts above - see the answer.
Sharktooth, the maintainer of MeGui is temporary(I hope) out of reach.
I hope he's doing fine.

nurbs
28th August 2009, 15:48
Also the development version has been updated a couple of times since the last stable release.

Undead Sega
29th August 2009, 18:20
but i was given:

-- nal-hrd--output

i took this off the log.

anyone at all? i dont know what to do, as this is what i get, as the stream error. i desperately need to start encoding with MeGUI :(

Undead Sega
1st September 2009, 14:24
anyone at all may i ask? :(

OAKside
4th September 2009, 00:57
I think MeGUI's LAME MP3 VBR quality scale is backwards. Although I don't come across the "10-100" quality scale
very often (the 0-9 scale is more common) so I could be wrong. Can anyone verify this?

megui 100 = V9 (correct 100 = V0)
megui 90 = V8 (correct 90 = V1)
...
megui 20 = V1 (correct 20 = V8)
megui 10 = V0 (correct 10 = V9)

Inspector.Gadget
4th September 2009, 01:05
Numerically, yes. A VBR quality of 100 is likely equal to -V 0 --vbr-new. But that's more intuitive for most people, and the reason for the additional digit of precision is because LAME now supports command like -V 5.5

Edit: incorrect

OAKside
4th September 2009, 02:52
A VBR quality of 100 is likely equal to -V 0 --vbr-new.MeGUI's VBR quality of 100 equates to -V 9 (not -V 0), and so on all the way down the scale (10 equates to -V 0), opposite of LAME documentation.
I un/installed MeGUI, re-encoded and checked the logs because I couldn't believe it. Do you think this oddity in MeGUI is intentional?

Inspector.Gadget
4th September 2009, 02:58
Looks like they follow the LAME standard with the decimal point shifted once to the right. Odd, and somewhat counterintuitive...

OAKside
4th September 2009, 03:42
Looks like they follow the LAME standard with the decimal point shifted once to the right. Odd, and somewhat counterintuitive...That still wouldn't quite be right. (-V 10.0 should then equate to 100, but it's off at 90?) Since using the scale backwards works perfectly, someone must be using it backwards?! :p

Ruriko
5th September 2009, 11:51
I got this error unrecognised option `--rc-lookahead'
how to fix this?

nurbs
5th September 2009, 18:02
You can fix it by using an up to date version of x264.

tomos
6th September 2009, 10:44
updated everything in megui and i still get that error. megui says i have ver 0.3.1.1051

XhmikosR
6th September 2009, 11:25
The update server is not being updated. You can try putting in MeGUI's settings kurtnoise's update server (http://kurtnoise.free.fr/MeGUI/). So you can use latest x264 from http://x264.nl/, and latest dev MeGUI from SF.net (http://sourceforge.net/projects/megui/files/). If you need a patched x264 build then take a look at this (http://forum.doom9.org/showthread.php?t=130364&page=114) topic.

tomos
6th September 2009, 13:50
ta, will give that a shot :)