Re: DirectShow Lua extension

[Valentin <vsl@...>]

Hi Thijs,

thanks a lot for the explanations. That creating a rock would mean
actual work was also my first impression when I looked at the LuaRocks
manual. That's why I thought I might first check out if there is any
real interest in the Lua community for multimedia features (which is
where I come from). I had noticed that there isn't really any module for
playing audio/midi/video etc. in the LuaRock repository. I also have
code that allows media support based on Apple's AVFoundation framework
on the mac platform, so I thought maybe both, DirectShow and
AVFoundation, could even be unified as a feature-rich "multimedia" Lua
module (and if some Linux head chimes in, even gStreamer under Linux
could be added). But my current impression is that media support is not
really something the Lua community has desperately waited for ;)

Concerning ffi: my current lua directshow implementation just links
statically to the DirectShow libs (strmiids.lib and strmbase.lib), so no
DLL dependancy at runtime (other than the MS VC++ runtime).

Concerning MinGW/gcc support: from what I found on the web supporting
DirectShow via MinGW/gcc is pretty tough. I couldn't find any project
that actually does this. Qt4's phonon uses directshow for media support
on windows (code found in /src/3rdparty/phonon/ds9), but I found posts
that claimed that this can't be compiled with MinGW on windows.

Anyway, thanks again for your support.

Cheers,
Valentin

> A rock spec would be great, as it’s the easiest way to distribute
> modules in Lua land. Having said that, it might not be trivial.
> LuaRocks can be used with both MinGW/gcc based toolchains as well as
> the Microsoft toolchains, so ideally it would use the LuaRocks
> “builtin” backend, which allows to use both toolchains transparently
> (from a ‘make’ perspective), but obviously the code must support it.
> 
> And yet another complexity is the runtimes used
> (msvcrt.dll/msvcrXX.dll) as all executable code must be using the
> same runtime (Lua interpreter, the binding, the ffi library in your
> case, and any other module a user might use). But obviously this is a
> user responsibility. Though this is also the main reason that a rock
> spec would really help, as users can then easily build the binaries
> for their system using a simple LuaRocks command as long as they
> build their entire Lua system using the same LuaRocks installation.