Thanks for the proposition. :-)
The current MVCSource takes 2 files as input: the AVC and the MVC demuxed streams. It has a third parameter to specify what it must return: the AVC frames (value of the parameter is 0), the MVC frames (value 1), or the AVC + MVC streams, interleaved (value 2 or -2, where 2 returns the AVC (odd frames) + MVC (even frames), and -2 returns the MVC (odd) +AVC (even). It is not possible to seek, and it's why it is important to have the possibility to select the order of the AVC and MVC frames. It doesn't use pipes, and calls the external Intel DLL.
Code:
MvcSource("AVC.h264", "MVC.h264", output)
Where output is:
0 : base view (AVC)
1 : dependent view (MVC)
2 : interleaved base-dependent (base first)
-2 : interleaved dependent-base (dependent first)
Of course, we don't need exactly this syntax. It is however much better to accept the 2 input streams instead of a single AVC+MVC combined stream, as combining the 2 streams would require an additional long pass, and more disc space. Of course, the best solution would be to accept a MPLS file as input, but I suppose it's too complex. Currently, I think the best option is to demux the 2 video streams with tsMuxeR or eac3to, and to use them directly in the Source command. I don't know if the Intel decoder requires a single combined file as input, but I suppose it can accept two streams, even if sample_decode.exe requires a single combined input.
Using the pipes to communicate the data to the decoder is of course possible, but since the decoder is open source and some examples exist, I wonder if it is much more difficult to integrate it completely in the avisynth plugin. Currently, the open source examples accept only plain files as input, but afaik the FRIM decoder accept pipes. Unfortunately, FRIM is currently closed source. It should be usable without modifications with the pipes, but I haven't studied how FIRM works, and I may be wrong.
Anyway, thanks again for considering to help us.