Log in

View Full Version : MeGUI x64


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

Sharktooth
27th July 2010, 15:18
Yah, I had installed ffdshow_rev3507_20100707_clsid_x64. I tried to use the command line but it always get error. I only want to use AVS Script Creator and meGUI but it gets that problem . I also put the DirectShowSource.dll to Avisynth plugin64 and meGUI tools>Avisynth plugin.
if you use the CLI and you get errors then it's not a megui problem.

Fr123
31st July 2010, 14:29
I have a problem (my os: Win7 Home Premium 64bit):

1. I installed AviSynth 2.5.8 32bit, then downloaded the AviSynth x64 files, put the files "avisynth.dll" and "DevIL.dll" in "windows/system32" directory, ran the batch installer "avisynth_intall.cmd".

2. I installed MeGui x64, let the program update all the files

3. When I try to load a .avs file into megui, megui reports an error: "AviSynth script error ; DirectShowSource: Renderfile, the filter graph manager won´t talk to me"

Anybody can help?

Zathor
31st July 2010, 14:55
DirectShowSource depends on the installed directshow filters. Please make sure that you have 64bit filters installed (and activated). Or you can use the file indexer in MeGUI.

Fr123
31st July 2010, 15:32
I solved the problem by installing K-Lite codec package 64-bit :-)

quantum5uicid3
3rd August 2010, 08:44
the only change to the default configuration of ffdshow-tryouts x64 is setting it to handle RAW video. a codec pack is not necessary.

it's been my understanding that using dgdecnv built in resize was a successful workaround to the resize bug. anyone know for sure if this is true, using dgdecnv or now x264 builtin resize filter?

Zathor
7th August 2010, 10:55
I think you correct about AviSynth threads staying open. I just did a quick check by opening a FFMS indexed mkv file in the avisynth creator. I then closing the AviSynth creator by clicking the Red X and then tried to delete the mkv file and i get this.

http://img18.imageshack.us/img18/4511/megui.png (http://img18.imageshack.us/i/megui.png/)

I checked the problem and can reproduce it only with FFMS. If I index the file with DGIndexNV the file is not locked. Therefore I assume that it is not a problem of MeGUI but a problem of the x64 FFMS plugin.

AMED
8th August 2010, 21:25
ahh ok, thanks for looking.

I'll just keep to my keep queuing jobs using FFMS untill MeGUI starts erroring out, restart MeGUI and continue queuing method :)

Next time i do a big run and get an error i'll post a screenshot and log.

gahz
9th August 2010, 02:52
hi guys quick question:

i think i have everything working correctly. followed the instructions in post #1 and i have gotten no errors so my question is:

i have run 2 jobs so far comparing both 32 and 64 bit megui to see what the diff is speed wise.

unfortunatly i dont see any diff. the fps is equal between the two. maybe i'm not doing something right?

script is simple dgindexnv default and i use dgindexnv64 for the 64 bit ver of megui.

*i just noticed that regardless of which version of megui i pull up they both call on x264_64.exe. the only diff being that the 32 bit version of megui also calls up vfw4x264.exe *32, while the 64 bit ver of megui does not. is this working as intended or have i messed something up bad?

Zathor
9th August 2010, 06:15
*i just noticed that regardless of which version of megui i pull up they both call on x264_64.exe. the only diff being that the 32 bit version of megui also calls up vfw4x264.exe *32, while the 64 bit ver of megui does not. is this working as intended[...]?

Yes, this is correct.

LeXXuz
10th August 2010, 16:15
Ran an encode yesterday with a fresh build x64 machine and was pretty impressed by the speed. Source was vc1 in matroska container and everything worked like a charm.

The last couple of hours I learned the hard way that dgavc does not work on x64 Avisynth. I already ripped GIGs of movie titles to hard disk as raw h264 stream to use with dgavc (as I used to with my old XP x86 sys). Is there any other way to index raw AVC streams? Or do I have to remux all my already ripped titles back into a container to use with FFMSIndex? Is FFMSindex a good method to use (at the moment?)

Guest
10th August 2010, 16:21
The last couple of hours I learned the hard way that dgavc does not work on x64 Avisynth. I already ripped GIGs of movie titles to hard disk as raw h264 stream to use with dgavc (as I used to with my old XP x86 sys). Is there any other way to index raw AVC streams? You can use DGDecNV 64-bit.

If you don't have an Nvidia card already, you can install a cheap 8400GS alongside your existing card.

Lyle_JP
10th August 2010, 16:57
The last couple of hours I learned the hard way that dgavc does not work on x64 Avisynth. I already ripped GIGs of movie titles to hard disk as raw h264 stream to use with dgavc (as I used to with my old XP x86 sys). Is there any other way to index raw AVC streams? Or do I have to remux all my already ripped titles back into a container to use with FFMSIndex? Is FFMSindex a good method to use (at the moment?)

You could use DirectShowSource, as long as you install the Win7 Codec Tweaker, ffdshow, and haali splitter.

LeXXuz
10th August 2010, 17:10
You can use DGDecNV 64-bit.

If you don't have an Nvidia card already, you can install a cheap 8400GS alongside your existing card.

HM. At the moment system uses onboard AMD IGP. To be frank when I ordered the parts I had no plans to switch to Win7 x64 but I read a couple of threads here including this one and thought I'll give it a try.^^

Probably stupid question, but are there any differences in quality between these indexing methods? Or is it first of all a matter of speed? To be honest, I don't understand the detail of this indexing process at all. Logic tells me that it could not affect quality until indexing is not meant in the matter of just finding desired information in the source file. Multiple ways lead to Rome, right?

I never thought about GPU indexing, but if it comes with a noticeable speed increase, why not. Is a 8400 fast enough for this task or would a more expensive card speed up things further more?

Guest
10th August 2010, 17:21
Probably stupid question, but are there any differences in quality between these indexing methods? Or is it first of all a matter of speed? To be honest, I don't understand the detail of this indexing process at all. Logic tells me that it could not affect quality until indexing is not meant in the matter of just finding desired information in the source file. Multiple ways lead to Rome, right? Not quite right. DG tools are designed from the ground up for frame accuracy. DSS2() and the others are not and run into issues in several common scenarios. For example, they might serve the correct frame's data, but it shows artifacts because the source filter has not injected the needed SPS/PPS. Or they can simply deliver the wrong frame's data because the timestamps are not perfectly monotonic. Or they get screwed up by trim() in your script. If you need assured accurate random frame access, then DG tools are the way to go. DISCLAIMER: I have an interest in the DG tools. But you can find similar assessments by others on the web.

I never thought about GPU indexing, but if it comes with a noticeable speed increase, why not. Is a 8400 fast enough for this task or would a more expensive card speed up things further more? The indexing is not done on the GPU. Decoding the video is done on the GPU. So the Avisynth source filter's workload is offloaded to the GPU. Indexing simply enables frame accuracy in the source filter.

For purely decoding, a fast CPU can beat the GPU (although Fermi is starting to challenge that wisdom). But in the vast majority of cases where Avisynth is used, the user is *transcoding* and the decoding rate is not the bottleneck, so offloading the decode to the GPU can give an overall performance gain to the transcoding operation by leaving more CPU bandwidth for the encoder.

The Fermi cards will outperform the 8400GS but are MUCH more expensive. The 8400GS has a VP3 engine and is very fast; it's the current sweet spot for price/performance. Refer to the DGDecNV Benchmarking thread for more details.

Gser
10th August 2010, 18:18
Btw if anyone is looking at an ati 4870 or 4970, they take two power inputs (same as a normal SLI/Crossfire configuration would). So if you want to add a second gfx card, you need a quad (or tri) gfx card config supporting power supply.

mariush
10th August 2010, 18:27
Not really, you can get adapters which convert a regular hard drive connector to the connectors video cards use. As long as the power supply has enough power to feed both cards (I'd say 650 watts and up) you're good.

LeXXuz
10th August 2010, 19:49
Not quite right. DG tools are designed from the ground up for frame accuracy. DSS2() and the others are not and run into issues in several common scenarios.

Thanks a lot for that explanation neuron2. That explains a lot of things I stumbled over in the past. :thanks:



But in the vast majority of cases where Avisynth is used, the user is *transcoding* and the decoding rate is not the bottleneck, so offloading the decode to the GPU can give an overall performance gain to the transcoding operation by leaving more CPU bandwidth for the encoder.

Okay, so for my purposes as a transcoding scenario the 8400GS is more than fast enough that I would not gain any more speed increase from a faster card, right?
Is there anything more I have to watch out for like memory size or bandwith (DDR2, DDR3) or can I just go and buy any 8400 GPU based card I find?

Guest
10th August 2010, 20:52
Any 8400GS will be OK. The more memory you have the more filter instances you can create.

Just get the best 8400 GS you can afford. Or if money is not an issue, get a Fermi. :)

Ezekeel
19th August 2010, 19:20
Hi there,

first of all: nice work on the x64 build!

But i have a problem: Whenever i start encoding a video with x264, sooner or later i get this error:

http://omploader.org/vNTl6Yw/meguix64error.png

if i "close the program" it disappears, but the fps drops from 80-90 fps to 12 fps (1st pass).

Any idea what that could be?

Sharktooth
19th August 2010, 19:50
encoder crashed. check your AVS script in your favourite directshow media player and see if it can be played (from the beginning to the end) without crashes.
also, check your system for stability, expecially if you overclocked the CPU, RAM or Videocard.
most ppl wrongly assume their system is stable coz every other app works without crashing... but when it comes to x264 it crashes...

Ezekeel
20th August 2010, 15:14
Thanks, seems to work now, after i raised the vcore a little bit. :D
Funny, that Prim95 or Orthos found no Errors after 10 hours of testing and x264 crashed in a few minutes. :-)

Chumbo
24th August 2010, 03:00
I'd like to request a feature please. Right now when you open a TS file and select File Indexer, when you choose FFMSIndex, you get the dialog warning "Please use a MKV, AVI, MP4 or FLV container to index files with the FFMS2 indexer." Since we can't use DGAVCIndex in 64 bit, would you please consider adding TS support since ffmsindex does index TS files.

I basically do this manually now, i.e., I index the source TS file, create the AVS script and then load into megui64. Thanks a lot for considering adding this.

Sharktooth
24th August 2010, 03:21
please post feature requests here: http://sourceforge.net/tracker/?group_id=156112&atid=798479

Zathor
24th August 2010, 19:09
I'd like to request a feature please. Right now when you open a TS file and select File Indexer, when you choose FFMSIndex, you get the dialog warning "Please use a MKV, AVI, MP4 or FLV container to index files with the FFMS2 indexer." Since we can't use DGAVCIndex in 64 bit, would you please consider adding TS support since ffmsindex does index TS files.

Indexing TS files is already supported. Just ignore the warning and proceed with the indexing process. The warning is there because of:
Compatibility
* AVI, MKV, MP4, FLV: Frame accurate
* WMV: Frame accurate(?) but avformat seems to pick keyframes relatively far away
* OGM: Frame accurate(?)
* VOB, MPG: Seeking seems to be off by one or two frames now and then
* M2TS, TS: Seeking seems to be off a few frames here and there
* Image files: Most formats can be opened if seekmode=-1 is set, no animation support

Sharktooth
25th August 2010, 14:41
new FFMS2 plugin for megui x64 dev (thanks to kemuri9).
now 32bit and 64bit versions of megui should be both able to manipulate MKVs with header compression enabled.

Chumbo
26th August 2010, 00:27
please post feature requests here: http://sourceforge.net/tracker/?group_id=156112&atid=798479
Thank you, will do.

rubinus
26th August 2010, 12:13
As of now the following x64 tools are available on the development update server:
x264, mediainfo, avisynthwrapper, dgindex/dgdecode, ffms, colormatrix, tdeint, tivtc, eedi2, leakkerneldeint, undot, mp4box, vsfilter, aften, ffmpeg, yadiff, nicaudio

These avisynth plugins need to be replaced with x64 builds:
convolution3dyv12, fluxsmooth, decomb, tomsmocomp, dgavcdec, dgindexnv
Until these plugins are updated it is not possible to use them. MeGUI may crash if using the old x86 dlls.

Sorry of my ignorance, but where to download these tools/plugins? I cant find the development server...

Thanks for info.:stupid:

Chumbo
28th August 2010, 16:03
Try using the Search and enter "megui development server" and you'll be amazed at what you'll find.

GRKNGLR
10th September 2010, 23:33
Hi,

I'm kind of a noob, so keep your patience please... Isn't it possible to run MeGUI on an x64 system without Avisynth64 and ffdshow-tryout x64? On my Win7 x64 system with 32-bit MeGUI, Avisynth and ffdshow-tryout, x264_64.exe and vfw4x264.exe works pretty well. Are the any side effects of using those like this?

Sharktooth
11th September 2010, 03:39
no. except the fact all 32 bit apps have a 2 GB memory barrier.
some times, when using heavy filtering and/or HD sources avisynth may require more than 2 GB and that obviously makes avisynth 32 crash.

blubberbirne
11th September 2010, 18:37
I need Another Update Server.
Fresh Install of MeGui x64


Trying server: http://megui.org/auto/stable/
Retrieving update file from server...
Error: Couldn't connect to server.
Trying server: http://megui.xvidvideo.ru/auto/stable/
Retrieving update file from server...
Error: Couldn't connect to server.
Error: Could not download XML file
Loading update data...
Error: Invalid XML file. Aborting.

EDIT: found the developer dir in setting.

GRKNGLR
12th September 2010, 14:29
no. except the fact all 32 bit apps have a 2 GB memory barrier.
some times, when using heavy filtering and/or HD sources avisynth may require more than 2 GB and that obviously makes avisynth 32 crash.

Thanks Sharktooth.

Whimick
12th September 2010, 17:33
Hello All,
I been having a play with MeGUI x64 and I get this error when I try to create a script:
Please see my Log below:
-------------------------------------------------------
[Error] Log
-[Information] Versions
--[Information] MeGUI Version : 0.3.5.11 x64
--[Information] OS : Windows Vista Premium Edition x64 SP2 (6.0.131072.6002)
--[Information] Latest .Net Framework installed : 4.0 (4.0.30319)
--[Information] Avisynth Version : 2.5.8.5
-[Information] Log for job1 (idx, Sample.ts -> Sample.ts.d2v)
--[Information] [12/09/2010 17:22:28] Started handling job
--[Information] [12/09/2010 17:22:28] Preprocessing
--[Information] Job commandline: "C:\Program Files\MEGUI 64\tools\dgindex\dgindex.exe" -SD=< -AIF=<C:\TEMP\Sample.ts< -OF=<C:\Users\Michael\Videos\MeGUI\Sample.ts< -FO=0 -exit -hide -OM=1 -TN=0
--[Information] [12/09/2010 17:22:28] Indexing started
--[Information] Standard output stream
--[Information] Standard error stream
--[Information] [12/09/2010 17:22:48] Running auto force film
---[Information] Film percentage: -1
--[Information] [12/09/2010 17:22:48] Postprocessing
---[Information] Deleting intermediate files
----[Information] [12/09/2010 17:22:49] Successfully deleted C:\TEMP\Sample.ts.log
--[Information] [12/09/2010 17:22:49] Job completed
-[Error] Unhandled error
--[Information] Exception message: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
--[Information] Stacktrace
---[NoImage] at MeGUI.AviSynthClip.dimzon_avs_getvframe(IntPtr avs, IntPtr buf, Int32 stride, Int32 frm)
---[NoImage] at MeGUI.AviSynthClip.ReadFrame(IntPtr addr, Int32 stride, Int32 frame)
---[NoImage] at MeGUI.AvsFile.AvsVideoReader.ReadFrameBitmap(Int32 position)
---[NoImage] at MeGUI.VideoPlayer.positionSlider_Scroll(Object sender, EventArgs e)
---[NoImage] at MeGUI.VideoPlayer.resize(Int32 targetWidth, Boolean PAR)
---[NoImage] at MeGUI.core.gui.StandardAndCustomComboBox.get_SelectedSCItem()
---[NoImage] at MeGUI.core.gui.StandardAndCustomComboBox.get_SelectedObject()
---[NoImage] at MeGUI.core.gui.ARChooser.get_Value()
---[NoImage] at MeGUI.VideoPlayer.get_DAR()
---[NoImage] at MeGUI.VideoEncodingComponent.player_Closed(Object sender, EventArgs e)
---[NoImage] at System.Windows.Forms.Form.OnClosed(EventArgs e)
---[NoImage] at System.Windows.Forms.Form.WmClose(Message& m)
---[NoImage] at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
---[NoImage] at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
--[Information] Inner exception: null

-------------------------------------------------

Can any one offer any advice.

Many Thanks

Whimick

Zathor
12th September 2010, 18:14
Can you open the avs file in other tools like VirtualDub or MPC-HC?

JoeH
12th September 2010, 19:01
I need Another Update Server.
Fresh Install of MeGui x64



EDIT: found the developer dir in setting.

How did you solve this? I am getting the same error.

Zathor
12th September 2010, 21:26
In the settings (extra config\auto update) you have to switch to the development server. MeGUI x64 is not available as stable build because a lot of external tools/filters are missing/unstable.

EDIT: I updated the link in the first posting to point to a recent x64 build. This build will automatically switch to the development server for a new instalation.

tormento
14th September 2010, 15:25
There must be something gone wrong with latest update. If I open the following script:

LoadPlugin("D:\eseguibili\media\dgdecnv\x64 binaries\DGDecodeNV.dll")
DGSource("E:\in\1_47 2 fast 2 furious\2fast.dgi")
Megui_x64 shows:

http://img695.imageshack.us/img695/6708/megui03512x64.jpg

Tried same script in VirtualDub_x64 and works. Tried to replace AviSynth with older version.

Same script works with x86 version (obviously different dll).

Ideas?

zanuda
14th September 2010, 22:35
error when try to open .mkv in file indexer
[Error] Log
-[Information] Versions
--[Information] MeGUI Version : 0.3.5.12 x64
--[Information] OS : Windows Seven Ultimate Edition x64 (6.1.0.7600)
--[Information] Latest .Net Framework installed : 4.0 (4.0.30319)
--[Information] Avisynth Version : 2.5.8.5
-[Error] Unhandled error
--[Information] Exception message: Была сделана попытка загрузить программу, имеющую неверный формат. (Исключение из HRESULT: 0x8007000B)
--[Information] Stacktrace
---[NoImage] в MediaInfoWrapper.MediaInfo.MediaInfo_New()
---[NoImage] в MediaInfoWrapper.MediaInfo..ctor(String path)
---[NoImage] в MeGUI.MediaInfoFile..ctor(String file)
---[NoImage] в MeGUI.FileIndexerWindow.openVideo(String fileName)
---[NoImage] в MeGUI.FileIndexerWindow.input_FileSelected(FileBar sender, FileBarEventArgs args)
---[NoImage] в MeGUI.FileBar.triggerEvent()
---[NoImage] в MeGUI.FileBar.setFilename(String filename)
---[NoImage] в System.Windows.Forms.Control.OnClick(EventArgs e)
---[NoImage] в System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
---[NoImage] в System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
---[NoImage] в System.Windows.Forms.Control.WndProc(Message& m)
---[NoImage] в System.Windows.Forms.ButtonBase.WndProc(Message& m)
---[NoImage] в System.Windows.Forms.Button.WndProc(Message& m)
---[NoImage] в System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
---[NoImage] в System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
--[Information] Inner exception: null

Zathor
14th September 2010, 23:16
Thanks for the reports. Please run the auto update and the problem should be fixed.

vitali5000
15th September 2010, 01:05
mediainfo_0_7_35-2_x64 buged

http://img835.imageshack.us/img835/4751/18874686.png
http://img23.imageshack.us/img23/2051/62994600.png
http://img33.imageshack.us/img33/2674/92885555.png

tormento
15th September 2010, 06:20
Not working, same error I reported before.

zanuda
15th September 2010, 09:36
works fine for me

Zathor
15th September 2010, 10:07
It is working for me with this dll, too. I think we have to wait for the official build of mediainfo. I will revert it back to 0.7.35.

vitali5000
15th September 2010, 10:20
It is working for me with this dll, too. I think we have to wait for the official build of mediainfo. I will revert it back to 0.7.35.

Please, upload old working version 0.7.35. Thanks.

Zathor
15th September 2010, 10:38
Yes, as said before. But at the moment I have no access to the server. Should be done in a few hours.
EDIT: done

vitali5000
15th September 2010, 13:42
Error again (((

http://img440.imageshack.us/img440/3342/37509060.png

With MeGUI - 32 bit works fine.

Zathor
15th September 2010, 14:28
Close MeGUI and then replace mediainfo.dll with another one from here:
http://megui.org/auto (files beginning with mediainfo and ending with x64.zip)
Report back which one fixes the problem.

Sharktooth
15th September 2010, 15:10
zathor, it could be a build problem since there 32bit version works as expected.
ill ask in the mediainfo thread.

vitali5000
15th September 2010, 17:19
Error again (((

http://img440.imageshack.us/img440/3342/37509060.png

It is a problem when I try to make resize with 1920x1080 to 720x400, there was no such problem earlier.
With 32 bit version resize to720x400 works fine.

tormento
15th September 2010, 18:54
Works ok for me now (x64, I mean).

Thanks..