DGMVCSource

[Nico8583]

If I have found this if it can help you to understand how AVC + MVC could become an elementary stream :

The first NAL-Unit in the bytestream is preceded by a four byte sequence which is
0x00000001. Every other NAL-Unit is preceded by a three byte sequence which is
0x000001. In addition each NAL-Unit can be succeeded by one or more null bytes (0x00).
As explained before, the NAL-Unit header is one byte, but it can be three additional
octets for MVC NAL-Units. The first byte of the header consists of a zero bit (a bit
which is always zero), the next two bits indicate whether the data in the NAL-Unit is
used by upcoming frames or if it can be discarded after decoding. The five remaining bits
in the one byte NAL-Unit header is the NAL-Unit type. A value of 14 or 20 indicates
an extended header for MVC. That means that whenever a NAL-Unit header has one of
those two types that NAL-Unit can be ignored for decoding when only 2D-playback is
desired.
The resulting bytestream is a AVC/MVC Elementary Stream (ES). It needs to be
packetized and encapsulated once again into a Packetized Elementary Stream (PES) as
described in ISO/IEC 13818-1:2000

It is extracted from this : http://www.nt.uni-saarland.de/filead...o_Viets_01.pdf page 19 & 20

[Guest]

Thanks, but it is too light on details. Don't worry, I have adequate information sources.

[Nico8583]

I have tested beta 2, it works very well for left & right views inverted

[Guest]

Sweet. Thank you for your testing.

[r0lZ]

I confirm. Good job! :-)

However, the problem of the script freezing when libmfxsw32.dll is not in the system path is still present. Neuron2, can you do something to load it from the same directory than DGMVCDecode.dll, or at least issue a meaningful error message when it cannot be loaded? It's not urgent, but imo something must be done for the final version, as currently the situation is confusing for the new users, because there is nothing to inform them of the necessity to properly install the Intel DLL.

[Guest]

Ah, changing your perfect priorities now, eh?

I will look into it. Tell me, as I am new to all this Intel stuff, where does that DLL normally come from for users? Is it part of Windows, part of an Intel driver, part of the Media SDK, ...?

[Sharc]

It's part of the Intel Media SDK, AFAIK.
I am on Windows 7/64 and had to put it into the SysWOW64 folder in order to "forget" it.

[Nico8583]

This DLL must be in a path described in environment variable path like %SystemRoot%\system32,%SystemRoot%,etc...
When you install Intel Media SDK, it adds C:\Program Files (x86)\Intel\Media SDK 2013 R2\bin\x64 and C:\Program Files (x86)\Intel\Media SDK 2013 R2\bin\win32 to environment variable path
But I don't know if it must be register via regsvr32 or not

[Guest]

For now I have included libmfxsw32.dll in the ZIP file and in the instructions I say to copy it to your system directory. Maybe later I will do something more intelligent but I am not totally free because of the Intel restrictions.

"Copy the included libmfxsw32.dll to your c:\Windows\System32 directory for 32-bit Windows,
or your c:\Windows\SysWOW64 directory for 64-bit Windows."

[r0lZ]

Originally Posted by neuron2

Ah, changing your perfect priorities now, eh?

Not really. I just think that dealing with the intel DLL properly is important, and should be in the todo list, but not necessarily at the first position.

Indeed, I confirm that your filter works fine only if the Intel DLL is copied in syswow64, or if it is in the same directory than the AVS script. Of course, the second solution is not acceptable. I wonder if it is possible to locate it and pre-load it in memory if it is in the same directory than the plugin. That way, it will not be necessary to install the intel SDK the official way, and it will be sufficient to just copy the two DLLs somewhere. Honestly, I don't know if it's possible. (I know however that it's not possible with pistacho's DLL.)

Please forget it for the moment, and continue to implement the more important things...

[Guest]

Why two DLLs? I checked dependencies and it seems only libmfxsw32.dll is needed. What other one are you talking about?

I tried to load it directly from a path of my choosing but it failed unaccountably. The error was file not found but it is definitely there. Rather than get bogged down in this, let's move on and possibly revisit it, as you suggest.

[r0lZ]

Originally Posted by neuron2

Why two DLLs? I checked dependencies and it seems only libmfxsw32.dll is needed. What other one are you talking about?

Your DLL, the avisynth source. I would like to have the possibility to leave them grouped together, in the same directory. Unfortunately, usually, the avisynth plugins are not placed in the system PATH. It's why I suggest to try to find a way to pre-load the intel DLL. It seems that that doesn't work. Not a big deal.

Originally Posted by neuron2

Rather than get bogged down in this, let's move on and possibly revisit it, as you suggest.

I agree. Other things are more important.

[Nico8583]

Originally Posted by r0lZ

I agree. Other things are more important.

At this rate the "to do list" will quickly decrease

[LoRd_MuldeR]

Originally Posted by r0lZ

Indeed, I confirm that your filter works fine only if the Intel DLL is copied in syswow64, or if it is in the same directory than the AVS script. Of course, the second solution is not acceptable. I wonder if it is possible to locate it and pre-load it in memory if it is in the same directory than the plugin.

It's simply because of Windows DLL search order. If a DLL is not loaded explicitly via LoadLibrary() and with a full path, then the standard DLL search order applies!

This means Windows will look at those directories:

1. The directory where the current program's EXE file resides
2. The System32 directory (Syswow64 for 32-Bit programs running on Win64)
3. The Windows directory
4. The current directory (this one is skipped with "safe" DLL loading enabled)
5. The directories in your PATH environment variable

This means that if the application loads DLL X (e.g. the Avisynth plug-in) from some directory, and DLL X depends on another DLL Y (e.g. the Intel DLL), then Windows will not search for DLL Y in the directory where DLL X is located

But it will, eventually, look in the "current" directory - which probably is why it works if you put the Intel DLL into the folder where the Avisynth script is located (assuming that one becomes the application's "current" directory).

Of course it also works if you put DLL Y into the System directory or into the directory where the program's EXE file is located. One workaround would be modifying DLL X to not depend on DLL Y, but instead make DLL X load DLL Y at runtime.

When DLL X uses LoadLibrary() at runtime, it can load DLL Y from wherever it wants to. So it could, for example, determine it's own module path and then try to load DLL Y from exactly that directory.

[r0lZ]

Thanks for the clarification, Lord, although I did know that.
And, yes, it seems that avisynth changes its CD to the directory containing the AVS script. I use that feature often to test a new avisynth filter without having to install it in the avisynth plugins directory or type its full path. It works in the case of the DGMVCDecode and libmfxsw32 DLLs, but it's not a practical solution.

Originally Posted by LoRd_MuldeR

One workaround would be modifying DLL X to not depend on DLL Y, but instead make DLL X load DLL Y at runtime.

When DLL X uses LoadLibrary() at runtime, it can load DLL Y from wherever it wants to. So it could, for example, determine it's own module path and then try to load DLL Y from exactly that directory.

It's exactly what I suggested. But in our case, that means that DGMVCDecode.dll must know the path of the directory where it is located and from where it is loaded by avisynth, to search for libmfxsw32.dll in that location. I don't know if it's possible. And libmfxsw32.dll must also support to be loaded with LoadLibrary(). Is it the case of all libraries?

In the worse case, it will be necessary to copy the intel DLL in system32/syswow64. I don't like that much, as touching the system folders without a good reason is always a bad thing, and anyway, I prefer standalone or portable installations. Currently, my GUI builds a batch file that must be launched to compute the output file, and it adds its toolset folder to the PATH in that script. With that trick, it is possible to modify locally the system PATH variable to include the toolset, without having to modify it in the whole system. That works pretty well, but that means that the avs script cannot be encoded by another application (such as for example your Simple x264 Launcher), because it will not have the correct PATH. It's why I would like a solution for that problem.

Anyway, that DLL path problem is for later.

[LoRd_MuldeR]

Originally Posted by r0lZ

But in our case, that means that DGMVCDecode.dll must know the path of the directory where it is located and from where it is loaded by avisynth, to search for libmfxsw32.dll in that location. I don't know if it's possible.

Call GetModuleFileName() with hinstDLL

(Doen't give you the DLL's directory, but the full path of the DLL file itself. But extracting the desired path should be trivial)

[Guest]

Do you have working code that I can put in an Avisynth filter DLL that prints the path of that DLL file? If so, I can temporarily change the current directory for the IM SDK init to allow it to find the co-located libmfxsw32.dll.

[jdobbs]

Thanks for all the hard work DG. I'm setting up for testing... exciting stuff.

[Guest]

Originally Posted by neuron2

Do you have working code that I can put in an Avisynth filter DLL that prints the path of that DLL file? If so, I can temporarily change the current directory for the IM SDK init to allow it to find the co-located libmfxsw32.dll.

I made something that works:

char dllpath[1024];
HMODULE hm = NULL;
AVSValue __cdecl Create_AVCSource(AVSValue args, void*, IScriptEnvironment* env);

if (!GetModuleHandleExA(GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS | 
        GET_MODULE_HANDLE_EX_FLAG_UNCHANGED_REFCOUNT,
        (LPCSTR) &Create_AVCSource, 
        &hm))
{
    int ret = GetLastError();
    fprintf(stderr, "GetModuleHandle returned %d\n", ret);
}
GetModuleFileNameA(hm, dllpath, sizeof(dllpath));

Now I will try changing the current directory to there and see if the libmfxsw32.dll can be loaded from there.

@jdobbs

Thanks! It's always a pleasure to work with you.

[jdobbs]

It seems to work fine... I just created a test with a 3 minute "Road Runner" cartoon. All works as it should. One note, though, I noticed that if I try to open the AVS in MPC, and the source file name is misspelled, it hung and required me to kill it from Task Manager. But that's a minor thing.

Cool.