Riddle Me This

[pbd22]

What really stumps me is that (remember) this melting
pot of varying technologies in my window service """"works""""
in Debug mode from the IDE. I compile, it runs - external
exe and all. But, when I use installutil and make it an proper
windows service, the external exe breaks. This feels like a
security problem but that is just a gut hunch.

Thanks again.

 

[Willy Denoyette [MVP]]

Willy,

I sent you relevant code to your email over the weekend.
Please tell me what I have to do to "get it right". This
has been a royal headache and I am really stumped.

Peter

Never got this email.

Anyway, what you should do is, ask yourself whether this must be driven by
a service, if the answer is YES then you should get rid of all
features/technologies that really aren't designed to be used from a service.
Basically you have three possible options, but be warned, none of them are
trivial.
1)
The most important thing is, that you should get rid of the VB exe, it
doesn't solve anything, if you can successfully access the COM interfaces
(implemented in the C/C++ DLL's) from VB6, then they should be directly
accessible from a WS as well.
Keep in mind, that the COM components (the DLL's that call into DirectShow)
must be accessed from an STA thread, and that STA threads *must* pump a
message queue, that is, they should not block. This is especially true
running managed code, blocking STA's may block the finalizer thread, and
this is a big NO NO in managed code.
So, your service thread you should fire off a thread that gets initialized
to enter a STA, this thread should run a message queue, that is, you should
create an empty form, create an instance of the COM object(s) and call
Application.Run().
The service thread could (should) use Windows messages to pass command to
the STA/pumping thread. That means that you must define and register private
Windows message ID's for each command that corresponds to a COM method call
(you could also define one single message and pass the command as message
parameter), you must handle these messages in your WndProc override.
To communicate back with the service thread, you can use a
SynchronizationContext, the service thread must register a delegate to get
called when an event is fired by the pumping STA thread.
The STA pumping thread must implement the callbacks required by the COM
object(s).

2) Get rid of the VB6 exe and of the C/C++ DLL's. This requires a rewrite of
the code in the C dll's in C#. The CS code must declare/implement the COM
interfaces and call into DirectShow just like was done in the C/C++ code.
Note that you can also call into the Media Format API's, but it everything
depends on what exactly you are doing in the C/C++ COM dll's.

3) Write a C++/CLI wrapper that wraps the existing COM dll's, note that this
wrapper must run his own message queue exactly like explained in 1).

Willy.

 

[pbd22]

Thanks Willy.

"not trivial" indeed. Non-the-less, I am all for a new learning
experience.
I am going to try to open door number 1 and see where that gets me.
In preparation, do you know of any good and related online examples
that
can give me a sense of things? If not, no worries. I am "googling".

Thanks again,
Peter

 

[Willy Denoyette [MVP]]

Thanks again Willy.

I sent you the windows service code to your private email address.
You will see the calling method there (I sent a description in my
email).

Feel free to continue the thread by responding here.

THanks again for all your help!
Peter

Ok, I noticed in another reply that the only thing that gets done by the COM
components, is retrieving the metadata from Windows media files (video) and
dumping this data to a text file. If this is what you are doing, then there
is no reason to use VB6 and COM stuff any longer.
All you should do is declare the IWMHeaderInfo3 and the IWMMetadataEditor
COM interfaces (search wmsdkidl.idl in the platform sdk headers) and declare
the WMCreateEditor function exported by the WMVCore.dll.

Here the PInvoke declaration and part of the COM interface definitions to
get you started.

[DllImport("WMVCore.dll",SetLastError=true,
CharSet=CharSet.Unicode, SuppressUnmanagedCodeSecurity)]
public static extern uint WMCreateEditor(
[Out, MarshalAs(UnmanagedType.Interface)] out IWMMetadataEditor
ppMetadataEditor );

// COM interfaces IWMMetadataEditor and IWMHeaderInfo3 (check wmsdkidl.idl
in the Platform or the Media SDK headers).
[Guid("96406BD9-2B2B-11d3-B36B-00C04F6108FF"),
InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
public interface IWMMetadataEditor
{
uint Open( [In,MarshalAs(UnmanagedType.LPWStr)] string pwszFilename );
uint Close();
uint Flush();
}


[Guid("15CC68E3-27CC-4ecd-B222-3F5D02D80BD5"),
InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
public interface IWMHeaderInfo3
{
uint GetAttributeCount(
[In] ushort wStreamNum,
[Out] out ushort pcAttributes );

// other IWMHeaderInfo3 methods
.....



Basically what you should do is call the WMCreateEditor API to get a pointer
to the IWMMetadataEditor interface.
Once you have this interface, you can call it's Open method to open a media
file.
When you cast the IWMMetadataEditor to an IWMHeaderInfo3 interface, you can
get the metadata. Methods to call are GetAttributeCountEx and
GetAttributeByIndexEx.
When done with the file, you call IWMMetadataEditor Close and quit.
The media API's and COM interfaces can be used from MTA threads, so there is
nothing to worry about when used from Service threads.

Willy.

Willy.

 

[pbd22]

Thanks Willy!

That last hope provided some hope.
Just to be certain, this particular COM DLL takes
MPEG files, extracts metadata, and writes
that metadata to text files.

Is this COM no longer necessary? Does your
code do this? Does it do it for both MPG and WMV files?

Thanks again.

 

[pbd22]

Can you confirm that this approach works for both WMV and MPG files?

Thanks.

 

[Willy Denoyette [MVP]]

Thanks Willy!

That last hope provided some hope.
Just to be certain, this particular COM DLL takes
MPEG files, extracts metadata, and writes
that metadata to text files.

Is this COM no longer necessary? Does your
code do this? Does it do it for both MPG and WMV files?

Thanks again.

It supports all Advanced Systems Format (ASF) formats, mpeg is not an ASF
container and can not contain MetaData, WMV and WMA are AFS container, so
you will have to transcode the mpeg file into an ASF container using an ASF
Write filter, this is all possible with the Windows Media Format SDK. Please
search the Platform SDK for "Direct Show and Windows Media".

I will try to find some time to build a small sample using above.
Note that DirectShow and Windows Media are exposing their functionality (DS
uses Windows Media) via COM interfaces
These are pure COM interfaces, designed to be used from Service applications
like streaming media services, they are "free threaded" so a perfect fit
when used from Windows Services MTA threads.

Willy.

 

[pbd22]

Thanks a ton Willy.

This sounds like the way to go.

So, what you are telling me is that that MPG file has to be transcoded
into an ASF container before
metadata can be inserted and extracted? I know we can currently
extract metadata from MPEG files
(using the pesky COM DLL) and, since I am only coding the extraction
if metadata (not the insertion),
I'll need to find out what method was used to insert metadata into the
MPEG files. I think the consultant
used DirectShow for this method.

Yes! I would really appreciate any and all code examples of that could
set me off down this new path.
I would be seriously indebted.

Thanks,
Peter

 

[pbd22]

Hey Willy,

Any chance of seeing some examples?

Thanks,
Peter

 

[Willy Denoyette [MVP]]

Hey Willy,

Any chance of seeing some examples?

Thanks,
Peter

Sent to your private mail alias.

Willy.