DGMVCSource

[Nico8583]

With pistacho's filter :
- With this script, it's OK, like your filter :
LoadPlugin("MVCsource.dll")

Interleaved = MVCsource("Combined.264", "", 4898, 2)

Right = SelectOdd(Interleaved)
Left = SelectEven(interleaved)

return StackHorizontal(HorizontalReduceBy2(Left), HorizontalReduceBy2(Right))

- With this filter (invert left and right for even/odd), I have got a black screen, no returned view :
LoadPlugin("MVCsource.dll")

Interleaved = MVCsource("Combined.264", "", 4898, 2)

Left = SelectOdd(Interleaved)
Right = SelectEven(interleaved)

return StackHorizontal(HorizontalReduceBy2(Left), HorizontalReduceBy2(Right))

- With this script (-2 instead of 2), views are inverted and all is OK :
LoadPlugin("MVCsource.dll")

Interleaved = MVCsource("Combined.264", "", 4898, -2)

Right = SelectOdd(Interleaved)
Left = SelectEven(interleaved)

return StackHorizontal(HorizontalReduceBy2(Left), HorizontalReduceBy2(Right))

[Guest]

r0lZ, when you try to swap by either of your methods, it results in requests to the filter being 1, 0, 3, 2, 5, 4, ... etc. But the filter ignores the request number and just returns the next decoded frame. So your analysis is correct. And thanks for the confirmation of the behavior, Nico8583.

I can handle it without a parameter. If I get a request number that is one beyond the linear (e.g., I expect 0 but get 1) then I know to use the swapping mode of delivery. The filter should act sensibly with selecteven()/selectodd() and not require extra parameters, IMHO.

I will prioritize as follows for now:

1. selecteven/selectodd behavior
2. accept separate streams
3. HW acceleration
4. SSIF support
5. library loading error messages, etc.
6. frame counting
7. Avisynth 2.6 and Avisynth+ support

Naming and stuff: As long as *this* filter accepts only MVC then it will be called DGMVCSource(). Speculations about future developments are OT in this thread and will be ignored. Patience guys, I am a fast coder but not *that* fast. :p

[Guest]

Here's pseudocode for GetFrame() to do this properly for interleaved delivery:

if (requested == expected + 1)
decode 2 frames, return the second, and save the first
else if (requested == expected - 1)
return the saved frame
else
decode one frame and return it

Off to try it now...

[r0lZ]

I see. Your method should be perfect. And the absence of an additional value for the view parameter is very elegant. :-)
I agree also with your order of priorities. It's perfect for me.

However, note that the SSIF support may not be as useful as supposed. Many movies are made of several (if not hundreds) SSIF files, and decoding only one of them doesn't make much sense. IMO, it's a support for MPLS that should be implemented later. In many cases, it will be (almost) equivalent to the SSIF support, but it will make it possible to decode all SSIF files referenced by the MPLS, thus the whole movie in one shot, in case of multi-angles movies. And the right left/right order of the views can be automatically retrieved from the MPLS, but not from the SSIF. Anyway, that's for later...

[Nico8583]

Is it more difficult do add a parameter for odd/even view ? Or your detection should allways be correct ? Perhaps there is one (or more) blu ray (with bad encoding for example) and you're detection will not work ? I don't know, it's only speculation :) but if we could delete this parameter it will be nice ;)

And OK, I'm sorry, I stop speculations about future developments in this thread :)

[r0lZ]

Nico, the detection of the frame order considered by Neuron2 doesn't depend of the BD. Only of the AVS script. If the even frame is requested before the odd, the order of the frames must be inverted. That's all. Of course, doing so requires to save the odd frame in a buffer, to serve it later without having to seek backward to decode it, but I suppose it's exactly the same thing with an "inverted view parameter".

[Nico8583]

OK, after reading again I've understand neuron2's pseudocode :)
Thanks r0lZ and thanks neuron2 for your work and your availability ;)

[Guest]

The auto detection of request order is working just fine. :D

I will upload a new beta shortly. Standby...

[Nico8583]

You're perfect :D

[Guest]

Here is beta 2:

http://neuron2.net/misc/dgmvcsource.zip

This fixes the inability to swap the views in your script. Please be aware that the filter name is now dgmvcsource().

On to separate stream input...

[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/fileadmin/file_uploads/theses/master/Master_Thesis_Hanjo_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 :D

[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? :p

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 :confused:

[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]

Ah, changing your perfect priorities now, eh? :pNot 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]

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.

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]

I agree. Other things are more important.
At this rate the "to do list" will quickly decrease :D

[LoRd_MuldeR]

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 :eek:

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.
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]

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() (http://msdn.microsoft.com/en-us/library/windows/desktop/ms683197%28v=vs.85%29.aspx) with hinstDLL (http://msdn.microsoft.com/en-us/library/windows/desktop/ms682583%28v=vs.85%29.aspx) :)

(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]

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.

[Guest]

OK, I'll fix that. Thanks for reporting it.

On the libmfxsw32.dll loading, the Intel Media SDK just will not load from a direct specified path, or using the method I described above. I'll put this on the back burner and maybe ask at the Intel forum about it later.

[r0lZ]

Pity. But thanks for having tried.

[Guest]

Never mind, I got it working to load libmfxsw32.dll from the plugin folder. :p

New beta coming shortly...

[r0lZ]

Great!
I will not test it today, because I go to a fiesta soon, but I will check it tomorrow...

[Guest]

Have fun at your fiesta. I wish I could join you!

Please re-download dgmvcsource.zip to get the new beta 3. It fixes jdobbs' reported problem and it loads the libmfxsw32 from the Avisynth plugin directory. It won't look elsewhere, so it has to be there.

http://neuron2.net/misc/dgmvcsource.zip

[Guest]

I've reverse engineered the muxing required to combine streams. Here is a schematic of how the muxing is done, showing all the NALUs and where they come from.

base combined dependent
------------------------------------------------------------------

---------------------------------
9 9
24
7 7
15 15
8 8
8 8
5 5
5 5
5 5
5 5
5 5
5 5
20 20
20 20
20 20
20 20
20 20
20 20
---------------------------------
repeat for all access units

Now I will write a stand-alone combiner to test this and then implement it in the filter.

[Guest]

I will make the first source code release when the separate stream support is complete.

[Reel.Deel]

Hi neuron2, just tried beta 3 with the included sample and everything seems good so far.
one very small thing, the examples in readme name the included sample as "combined_mvc.264" when it should be "combined.264".
Regardless good work! :)


P.S. looking forward to DGDecQS! :-D

[Guest]

P.S. looking forward to DGDecQS! You are very naughty. No dessert for you.

[LoRd_MuldeR]

Do you have working code that I can put in an Avisynth filter DLL that prints the path of that DLL file?

#include "targetver.h"

#define WIN32_LEAN_AND_MEAN
#include <windows.h>

HMODULE g_instance;

BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved)
{
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
g_instance = hModule;
case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}

/*Returns the directory where *this* DLL is located
__declspec(dllexport) int getDllDirectory(wchar_t *outBuffer, size_t len)
{
size_t i = GetModuleFileNameW(g_instance, outBuffer, len);

if((i < 1) || (i == ERROR_INSUFFICIENT_BUFFER))
{
return 0;
}

while(i > 0)
{
wchar_t c = outBuffer[i];
outBuffer[i--] = L'\0';
if((c == L'\\') || (c == L'/'))
{
return 1;
}
}

return 0;
}

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 think AddDllDirectory() would be a better choice than relying on "current" directory.

[Guest]

Too late, I already released a beta with my own implementation. But thank you anyway.

[jdobbs]

I like the way it works too... all I have to do is put the two dlls in the same folder and point to dgmvcsource.dll with LoadPlugin().

Thanks.

[Sharc]

The plugin or avisynth seems to report half frame rate only i.e. 11.988fps (12000/1001) for a 23.976 MVCcombined footage.
(It gets adjusted when I set --fps 23.976 in x264 for encoding).

If at all, I think it should actually report double the framerate because a stereo combo consists of the left and right picture or frame..... :confused:

[Guest]

The plugin or avisynth seems to report half frame rate only i.e. 11.988fps (12000/1001) for a 23.976 MVCcombined footage. I'm not seeing that. Please give me your script.

[Sharc]

I'm not seeing that. Please give me your script.
Script:
Video = DGMVCsource("c:\Users\Movies\Test_Movie\3-D samples\DG_combined.264",frames=1350,view=0)
V1 = SelectEven(video)
V2 = SelectOdd(video)
return StackHorizontal(horizontalreduceby2(V1),horizontalreduceby2(V2))

Command:
x264.exe "c:\Program Files Video\DGMVCSource_.avs" --bluray-compat --crf 20 --vbv-bufsize 15000 --vbv-maxrate 15000 --sar 1:1 --fps 23.976 --output "C:\temp\scratch\DGMVCsourceTox264.h264"

[Guest]

OK, I see. I will double the frame rate reported to Avisynth when delivering interleaved. Thank you for pointing it out.

[Sharc]

I think it should just be reported as 23.976fps - i.e. same as base view. What irritated me was the 11.988 fps.

[vivan]

I think it should just be reported as 23.976fps - i.e. same as base view. What irritated me was the 11.988 fps.If it will report 23.976 fps, then SelectOdd/SelectEven will halve it and resulting fps will be 11.988. That's exactly what's happening now.

[Sharc]

I see, thanks.

[jdobbs]

I see, thanks.I always add "AssumeFPS()" as the last line in the file when I know the source framerate.