DGAVCDec not working on Vista64

[new2doom]

When I try to play my .avs file it will not play. Directshow .avs files play fine, but not dgavcdec. The raw video stream plays and I cam index it but the dgavcdec plugin seems not to load. Is this not possible in 64bit Vista, or am I missing something?

[G_M_C]

When I try to play my .avs file it will not play. Directshow .avs files play fine, but not dgavcdec. The raw video stream plays and I cam index it but the dgavcdec plugin seems not to load. Is this not possible in 64bit Vista, or am I missing something?

Tried putting the .dll in avisynth's plugin-directory (as stated in the readme/faq/manual) ?

Else: What error does AviSynth throw ?

[neuron2]

When I try to play my .avs file it will not play. Directshow .avs files play fine, but not dgavcdec. The raw video stream plays and I cam index it but the dgavcdec plugin seems not to load. Is this not possible in 64bit Vista, or am I missing something? You are missing to give me sufficient information. Post your script and tell me exactly what error message you get. An unprocessed source stream sample would be very useful as well.

[new2doom]

Tried putting the .dll in avisynth's plugin-directory (as stated in the readme/faq/manual) ?

Else: What error does AviSynth throw ?

I have copied the dll to the avisynth plugin directory. The error states "Your computer is running low on memory". This of course makes no sense at all.

[new2doom]

You are missing to give me sufficient information. Post your script and tell me exactly what error message you get. An unprocessed source stream sample would be very useful as well.

Script is pretty simple and works fine in 32bit vista.
I am running a dual boot, to test out the 64bit version, but if I can't get this to work it is a deal breaker on the 64bit version. In wmp the error says "your computer is out of memory".


LoadPlugin("E:\Tools\dgavcdec100a34\DGAVCDecode.dll")
AVCSource("E:\rips\video\movie.dga")

[neuron2]

Sorry, don't know. I don't have either 32-bit Vista or 64-bit Vista.

Maybe someone that does will chime in.

[squid_80]

new2doom: Try inserting "SetMemoryMax(256)" at the top of your script.

[kemuri-_9]

yes, you more than likely encountered the memory limit for the 32 bit applications.
(as avisynth is 32 bit, unless you managed to get 3.0 for x64 compiled...)
if you're on avisynth 2.5.7 or prior versions, it defaults to using 25% of your system's ram as the default max.
if on 2.5.8 or later, it then defaults to 50% - 64MB.

32bit apps are natively limited to 2GB of paging/ram usage on windows, if they get higher, they perform one of various "memory overflow" errors and crash.
using avisynth's SetMemoryMax() function to something reasonably low will allow the program using avisynth to have some breathing room to not hit the memory limit.
I've seen several cases of avisynth using large amounts of ram (hitting the ram limit with accompanying program) itself for even the simplest of scripts involving large files,
which i would dare declare it would be from buffering a large portion of the file into ram.

[Ranguvar]

Unless you're on a 64-bit OS, in which case 32-bit apps can 4GiB of RAM (or more, on some OSes). This even applies to 64-bit Windows :)

[squid_80]

Unless you're on a 64-bit OS, in which case 32-bit apps can 4GiB of RAM (or more, on some OSes). This even applies to 64-bit Windows :)That's not dependant on the OS, it depends if the application is large-address-aware (off the top of my head I can't think of any featured programs on this forum that are). The limit is upped from 2Gb to 3Gb.

[Ranguvar]

In 64-bit Windows, the memory address space is 16 TB. 8TB for user programs and 8TB for the operating system. 32-bit programs running in 64-bit Windows run in the WOW64 subsystem. Each 32-bit program is assigned a 4 GB virtual memory address space in the WOW64 subsystem - with no requirement for the OS which is still running in the 8 TB of virtual memory address space it gets.
So, if your 32-bit program is written to take advantage of >2GB of memory (using the LARGEMEMORYADDRESSAWARE compiler switch), it will automatically see a full 4GB.

So, the limit IS 4GiB (not 3) for 32-bit apps on a 64-bit OS, but also yes, they need to be aware of it.

[LoRd_MuldeR]

So, the limit IS 4GiB (not 3) for 32-bit apps on a 64-bit OS, but also yes, they need to be aware of it.

AFAIK the 32-Bit application only sees 4 GiB of Memory in theory. Because of Memory Mapped I/O some of the 4 GiB address space is not available for Memory...

[G_M_C]

I have copied the dll to the avisynth plugin directory. The error states "Your computer is running low on memory". This of course makes no sense at all.

I dont own or run Windows Vista64 or any other 64-bit OS (even though i own a C2D 6750 w. 4Gb mem). The reason for that I'm afraid of running into problems with apps I use (like avisynth).

But on the other hand, i do read up on this subject and try to keep my info up-to date. That way I know when i can safely decide to step over. So I'm not an expert, but i do know something about the way Vista64 handles 32-bits apps. And your problem reminded me about WOW64, the "emulator" Vista64 uses to run 32-bits apps (background, see here (http://en.wikipedia.org/wiki/WOW64)).

Based on my limited real knowledge i think there are 2 main things you can look at; WOW64 places 32-bit library's (DLL's) in a different directory for look-up. You can try putting the DLL there (see the section "Registry and file system" in the link i gave above).

Also you can try to read up about the way memory is appointed to apps. See this article on MSDN (http://msdn.microsoft.com/en-us/library/aa384219(VS.85).aspx); Apparently apps get only 2Gb of memory assined, when they dont invoke something called "IMAGE_FILE_LARGE_ADDRESS_AWARE" when you run a X64 CPU. I dont know if this applies to you, or if it applies at all; hopefully Neuron2 can give his ideas about that, cause i do not exactly know what it means.

But I still think the problem lies somewhere in this WOW64 handling of 32-bit apps. So you might want to look at the MSDN page about WOW64 (http://msdn.microsoft.com/en-us/library/aa384249(VS.85).aspx) anyway.

Sorry that i cant help you more, good luck. I'll be following this thread, to see if it gets solved :)

[kemuri-_9]

the wow64 'engine' which i have on my xp x64 OS as well, is an engine that emulates a 32bit environment on the 64bit one.

It's there for perfectly implementing 32bit applications on the 64bit OS:
everything in
%windir%\SysWOW64 and
\Program Files (x86)
are 32 bit applications and will undergo the WOW64 engine for use on x64.

%windir%\system32 and
\Program Files
are 64 bit applications and will not need the WOW64 engine to run.

i have had no problems running applications like avisynth, vdub x86, x264, or anything else for that matter on my XP x64.

due to the way the architecture of x86 is with signed addresses, the OS getting the negative portion and the apps each able to have a positive portion, apps only normally get 2GB.
But with the large address awareness, they can use the negative portion as well since they know it's not specifically reserved to the OS, increasing it up to 4GB.

this is what i understand and have experienced so far.

[new2doom]

I dont own or run Windows Vista64 or any other 64-bit OS (even though i own a C2D 6750 w. 4Gb mem). The reason for that I'm afraid of running into problems with apps I use (like avisynth).

But on the other hand, i do read up on this subject and try to keep my info up-to date. That way I know when i can safely decide to step over. So I'm not an expert, but i do know something about the way Vista64 handles 32-bits apps. And your problem reminded me about WOW64, the "emulator" Vista64 uses to run 32-bits apps (background, see here (http://en.wikipedia.org/wiki/WOW64)).

Based on my limited real knowledge i think there are 2 main things you can look at; WOW64 places 32-bit library's (DLL's) in a different directory for look-up. You can try putting the DLL there (see the section "Registry and file system" in the link i gave above).

Also you can try to read up about the way memory is appointed to apps. See this article on MSDN (http://msdn.microsoft.com/en-us/library/aa384219(VS.85).aspx); Apparently apps get only 2Gb of memory assined, when they dont invoke something called "IMAGE_FILE_LARGE_ADDRESS_AWARE" when you run a X64 CPU. I dont know if this applies to you, or if it applies at all; hopefully Neuron2 can give his ideas about that, cause i do not exactly know what it means.

But I still think the problem lies somewhere in this WOW64 handling of 32-bit apps. So you might want to look at the MSDN page about WOW64 (http://msdn.microsoft.com/en-us/library/aa384249(VS.85).aspx) anyway.

Sorry that i cant help you more, good luck. I'll be following this thread, to see if it gets solved :)

The dll is in the wow64 directory. I have also tried the setmemorymax option, without any impact on the problem. I am able to run directshow scripts with avisynth, just not dgavcdec scripts. DGIndex runs perfectly and creates the dga file. I just cannot load the dgavcdec.dll from my avs script. These same scripts do work from 32 bit o/s. I have tried to different source files as well and neither work.

[LigH]

With matching boot switches, it is possible to boot a (gaming-able!) Server 2003 system which supports more than 3.5 GB of the 4 GB RAM. Still, a part is reserved for PCI/AGP card memory access mappings.

Windows XP Professional is limited to max. 3 GB by design (Microsoft Marketing).

Fortunately, Video decoding and encoding alone does not need a lot of RAM. Extremely complex filtering may... but there are limits of processing power as well as sanity. ;)

[kemuri-_9]

new2doom: can you toss up a sample of what you're working on then, see if we can try and narrow it down with that in hand.

[new2doom]

new2doom: can you toss up a sample of what you're working on then, see if we can try and narrow it down with that in hand.

I have tried different sources. The easiest sample I can give you is an avc-hd home video shot with a Sony HD-SR1. I used eac3to to extract the raw avc stream and it indexed fine with DGindex. The raw stream plays fine in wmp. When I create the AVS, using dgavcdecode.dll, the avs file will not play. My goal would be to creat an avi from the avs file and then I am using Windows media encoder to create wmv-hd. I have created lots of WMV-HD files this way using all kinds of source material (on vista32). I am not at home right now, but if it will help i will upload a sample avc file from the camera later. Howver, the problem is not specific to this source.

[new2doom]

I am starting to think it is a 64bit codec issue. I can play the h264 raw stream in the 32bit media player, but the 64bit wmp will not play the same stream. Does anyone have avc/h264 video playing in Vista64 in the 64 bit player?

[kemuri-_9]

32bit software is not allowed to interact with 64bit software on (at least) windows machines.

if you need decoding for 64bit video applications, then get ffdshow x64:
http://sourceforge.net/project/showfiles.php?group_id=173941&package_id=214245&release_id=523000

or get MPC-HC x64 which has internal filters based on ffdshow
http://sourceforge.net/project/showfiles.php?group_id=170561

[new2doom]

I have ffdshow x64 installed. I still cannot play h264 in the 64bit player. In ffdshow, it show libavcodec as the decoder for h264 and avc. However, the streams will not play. I must have a problem with ffdshow and the libavcodec. I simply cannot play avc in the 64bit media player.

[kemuri-_9]

just as a reminder, my previous statement also applies to avisynth.
Since it is 32bit, it will not work for 64bit video players....
be sure not to hand avs scripts to a 64 bit player - it won't work.

[squid_80]

I have ffdshow x64 installed. I still cannot play h264 in the 64bit player. In ffdshow, it show libavcodec as the decoder for h264 and avc. However, the streams will not play. I must have a problem with ffdshow and the libavcodec. I simply cannot play avc in the 64bit media player.
ffdshow x64 by itself is not enough. You need a 64-bit splitter as well (or use MPC x64 which has internal splitters).

[new2doom]

ffdshow x64 by itself is not enough. You need a 64-bit splitter as well (or use MPC x64 which has internal splitters).

Ultimately I want to encode these avs scripts not watch them so mpc isn't an option. Is there a 64 bit splitter?

[Comatose]

Yup. The entire DS filterset has to be 64bit.

edit: I think you should give up on 64 bit. Avisynth would have to be 64bit as well, and well... yeah.

[squid_80]

All this talk of 64-bit splitters/codecs and wow64 is irrelevant anyway. OP is trying to play a script in a 32-bit media player using 32-bit avisynth and it's giving a weird error message. Nothing to imply the problem is at all 64-bit related - the fact that it works on vista32 means nothing, it may as well be a completely different pc.

new2doom: please clarify the exact locations of libavcodec.dll (the one the comes with dgavcindex, note that a different file with the same name is installed with ffdshow) and DGAVCDecode.dll. If DGAVCDecode.dll is in avisynth's plugin directory there is no need to load it explicitly in your script. libavcodec.dll should be in the same directory as DGAVCIndex.exe, not in the plugin directory/syswow64/system32. Also test if you can load the script into any other programs (i.e. MPC or virtualdub) to see if it is only WMP that generates the "out of memory" error message.

[SpAwN_gUy]

i'm sorry.. but.. i'm on Vista x64
http://www.ljplus.ru/img4/s/p/spawn_guy/test-avs-avcpart.jpg
.avs script is:
SetMemoryMax(64)
LoadPlugin("\\sc0151\x264farm\TEST\filters\DGAVCDecode.dll")
function h264() {
clip2=AVCSource(".\h264\hgttg-test.dga")

return clip2.AssumeFPS(25).ConvertToYV12().KillAudio.LanczosResize(640,480)
}
h264().Info.Overlay(Version, x=200, y=400)
.dga internals say
DGAVCIndexFile5

hgttg-test.h264
\\sc0151\x264farm\TEST\filters\libavcodec.dll
dga log says..
Stream Type: AVC Elementary
Profile: High
Level: 5.1
Frame Size: 1280x528
Aspect Ratio: Unspecified
Frame Rate: 23.976000 fps
Colorimetry: BT.709* [2]
Frame Structure: Frame
Frame Type: P
Coded Number: 3270
Playback Number: 3270
Frame Repeats: 0
Field Repeats: 0
Bitrate: 6.616
Bitrate (Avg): 5.413
Bitrate (Max): 8.904
Elapsed: 0:00:07
Remain: 0:00:00
FPS:
Info: Finished!
and this was.. something like an alpha15 (i'm not sure.. but the old one.. might be 18 or 22...)

aviSynth, DGAVC, and MPC-HC are x86...

what am i doing wrong? ;) i havent tried recent alpha's.. but.. i can try..

[neuron2]

what am i doing wrong? ;) i havent tried recent alpha's.. but.. i can try.. You haven't stated any problem or symptom.

Upgrade to the latest alpha and tell us what problem you are having. If it is the aspect ratio that is bothering you, the latest alpha will tell you the display size, which will be bigger than the frame size, therefore being indicative of a stretch that needs to be applied by a player, or in our situation, your Avisynch script.

[SpAwN_gUy]

You haven't stated any problem or symptom.

Upgrade to the latest alpha and tell us what problem you are having. If it is the aspect ratio that is bothering you, the latest alpha will tell you the display size, which will be bigger than the frame size, therefore being indicative of a stretch that needs to be applied by a player, or in our situation, your Avisynch script.
no, no, no... i;ve noticed this thread.. and.. well.. this is a "joke" or something..
everything is working just fine here :) ...
looking forward to future developement :)

[neuron2]

Please explain. You're saying your post was a joke? You haven't forgotten rules 3 and 11 have you?

What was the point of your post? To make me waste my time?

[nm]

Seems that SpAwN_gUy was simply answering to the first post or the thread as whole. DGAVCDec worked fine for him on 64-bit Vista, so he was asking what new2doom was doing differently to make it break.

[SpAwN_gUy]

Seems that SpAwN_gUy was simply answering to the first post or the thread as whole. DGAVCDec worked fine for him on 64-bit Vista, so he was asking what new2doom was doing differently to make it break.that is exactly what i was saying :)

[neuron2]

So silly sarcasm instead of just saying "working fine here"?

I see, very funny.