|
|
Hi All,
I am new to programming the API of WMP. I have been browsing the
documentation for about an hour to learn how one would write a plug-in
for a custom stream that is not based on HTTP.
We have an old protocol that is like TCP/IP in principle, but is not
TCP/IP, so it does not support HTTP. We have a server computer that
needs to act as the source node of streaming audio/video data while
several client computers will act as target nodes and render the data
using WMP. Obviously, a URL beginning with:
"NotHTTPButSomethingElse://server17.ourcompany.com."
will not be recognized by HTTP and will be rejected by WMP.
So our goal is to make it so that such URL's are not rejected. We must
be able to supply WMP with a "URL-like" string that represents an
incoming stream of AV data.
I read that WMP has the capability of ascertaining the format of the
data from stream itself, which is good. I have also been looking at
IWMReaderAdvanced2::OpenStream, which seems to rely on standard COM
IStreams, which is great. The problems is that I do not yet know how
to program the WMP api to accept non HTTP URL strings.
However, not long ago, we encountered a similar problem with IE, where
we needed to induce IE to render a web page located on the same server
without using HTTP, so we wrote an asynchronous pluggable protocol
(APP) for IE and that fetches the web pages from the server when
given...
"NotHTTPButSomethingElse://server17.ourcompany.com."
Two questions:
1. What must we do to get WMP to accept an HTTP-like URL encoded as a
string?
2. Might it be the case that our APP can be reused to provide data to
WMP as it does for IE?
We are only concerneed with streaming and not progressive downloads.
Much thanks,
-Le Chaud Lapin-
|
|
From: "Le Chaud Lapin"
[...]
[Quoted Text] > 1. What must we do to get WMP to accept an HTTP-like URL
> encoded as a string?
> 2. Might it be the case that our APP can be reused to
> provide data to WMP as it does for IE?
Does your protocol work like a download&play or a live
streaming?
What's the format of your data?
--
// Alessandro Angeli
// MVP :: DirectShow / MediaFoundation
// mvpnews at riseoftheants dot com
// http://www.riseoftheants.com/mmx/faq.htm
|
|
On Nov 21, 10:42 pm, "Alessandro Angeli" <nob...[ at ]nowhere.in.the.net>
wrote:
[Quoted Text] > From: "Le Chaud Lapin"
Hi,
> > 1. What must we do to get WMP to accept an HTTP-like URL
> > encoded as a string?
> > 2. Might it be the case that our APP can be reused to
> > provide data to WMP as it does for IE?
>
> Does your protocol work like a download&play or a live
> streaming?
Live streaming. It's very much like TCP with small layer on top.
> What's the format of your data?
We can accomodate whatever format the player desires, within reason,
meaning we would simply take open-source format encoders and integrate
them into a server and provide chosen format dynamically.
I was hoping that:
1. WMP can ascertain format directly from stream.
2. There is a way of telling WMP to let our plug-in parse URL,
returning an IStream to it so that it might rely on us to supply data.
Also, I am an electrical engineer, and I understand codec's, etc., but
there seems to be massive number of coding formats and layouts for the
data. It would seem that, as time passes, a steady-state format or
pseudo-format would be found, not so much with the codecs, but with
certain fundamental principles that have found to be good, in general,
like per-frame acquire/render over stateless protocol like UDP for
instance. Is this true?
Is FLV the predominant video rendering format on WWW?
Is it possible that I might have seem customer FOO://aaa.bbb.com URL
schemes for streaming in the past? I thought I did. Not sure.
-Le Chaud Lapin-
|
|
On Nov 22, 12:24 am, Le Chaud Lapin <jaibudu...[ at ]gmail.com> wrote:
[Quoted Text] > On Nov 21, 10:42 pm, "Alessandro Angeli" <nob...[ at ]nowhere.in.the.net>
> wrote:
>
> > From: "Le Chaud Lapin"
>
> Hi,
[snip]
For other newbies who come across this thread and want to do
essentially the same thing:
The thing I was looking for is called a "Data Source Plugin".
In plain English:
1. The "Meat" of WMP, as often case with Microsoft technologies, has
been ripped out and put in COM DLL's. A nice-looking GUI has been
wrapped around the meat.
2. These DLL's are simply called "Windows Media Services" (WMS). This
is not to be confused with Windows Media Server, a server application
that typically runs on different computer than those upon with WMP
runs [Microsoft's way of earning money for their media-related
development.]
3. WMS, as installed on OS, comes with DLLs to handle HTTP://, RTSP://,
etc.
4. If you want to handle FOO://, you have to write a Data Source
Plugin mentioned as mentioned above (DSP) to go into action when end-
user types "FOO:// into File/Open, etc..
http://msdn.microsoft.com/en-us/library/ms743876(VS.85).aspx
5. DSP will need to be registered with WMS so that WMS will know what
to do when it encounters FOO:// as specified by end-user.
6. DSP can be either byte-based or packet based, meaning that it will
feed data to WMS when asked by letting WMS do a "read" specifying
buffer and sizeof(buffer) where bytes are put, or letting WMS do a
"give me a chunk", where a whole packet is supplied. If you think long
enough about various streaming scenarios, it will become apparent
that both modes of operation are desirable.
7. A DSP that allows handling of SAMPLE:// is included in Platform
SDK. See MSDN link above.
8. You can actually see the specification of the word "SAMPLE" in
the .rgs file for source files of DSP Sample:
In sdksamplestoragesystem.rgs file...
ForceRemove Properties
{
val Author = s 'Microsoft Corporation'
val Name = s 'WMS SDK Sample Data Source Plugin'
val Copyright = s 'Copyright (c) Microsoft
Corporation. All rights reserved.'
RIGHT THERE---->>>> val 'URL Prefix' = s 'sample://'
val 'URL Suffix' = s ''
val Description = s 'Sample Data Source Plugin to
access playlist and media files that are stored on a FAT, FAT32, NTFS,
or CIFS file system.'
}
9. Since WMS relies almost entirely on the DSP to fetch data that end-
user wants to see/hear, your DSP can supply to WMS essentially any
music or video you want. This means that DSP could grab streaming
music/video off internet, or even superpose two streams...whatever, so
long as it finally conforms to some format that WMS will understand.
10. I *think* WMS is able to tell from the first few bytes of stream
what is actually in the stream so that it knows what module should do
the rendering. Not sure. If true, then it is highly likely that there
will be open-source components somewhere, or even in the SDK's, that
allow you to quickly grab video from web cam and audio from a
microphone in a format that is undoubtedly interpreted by WMS. I
think this is what DirectShow is . At that point, it's just a matter
of taking whatever grabber code grabs on server, packaging it up,
sending over network to target where WMP and your DSP is running. DSP
unpacks data, hands off to WMS.
Here is the sample to get started:
http://msdn.microsoft.com/en-us/library/ms743878(VS.85).aspx
*Note that "DSP" means "Data Source Protocol" and is completely
unrelated to "Digitial Signal Processing" techniques that might be
used inside of a "Data Source Protocol" to supply data to WMS.
-Le Chaud Lapin-
|
|
On Nov 22, 12:52 pm, Le Chaud Lapin <jaibudu...[ at ]gmail.com> wrote:
[Quoted Text] > On Nov 22, 12:24 am, Le Chaud Lapin <jaibudu...[ at ]gmail.com> wrote:
>
[snip]
It appears that the schemed described for data source plug-ins has
been superseded by:
WMCreateStreamForURL():
http://msdn.microsoft.com/en-us/library/aa391572(VS.85).aspx
Note the bug regarding using HKLM instead of HKCU in the MSDN
documenation.
-Le Chaud Lapin-
|
|
On Nov 22, 3:55 pm, Le Chaud Lapin <jaibudu...[ at ]gmail.com> wrote:
[Quoted Text] > On Nov 22, 12:52 pm, Le Chaud Lapin <jaibudu...[ at ]gmail.com> wrote: > > > On Nov 22, 12:24 am, Le Chaud Lapin <jaibudu...[ at ]gmail.com> wrote: > > [snip] > > It appears that the schemed described for data source plug-ins has > been superseded by: > > WMCreateStreamForURL(): > > http://msdn.microsoft.com/en-us/library/aa391572(VS.85).aspx> > Note the bug regarding using HKLM instead of HKCU in the MSDN > documenation.
Also note the bug in the specification of the function prototype:
HRESULT WMCreateStreamForURL(
LPCWSTR* pwszURL,
BOOL* pfCorrectSource,
IStream** ppStream
);
....should be...
HRESULT WMCreateStreamForURL(
LPCWSTR pwszURL,
BOOL* pfCorrectSource,
IStream** ppStream
);
Microsoft engineer who wrote this (and left it as it is) should be
ashamed. The whole thing is barely 30 lines, and there are two glaring
errors in it.
Sigh.
-Le Chaud Lapin-
|
|
From: "Le Chaud Lapin"
[Quoted Text] > 2. These DLL's are simply called "Windows Media Services"
> (WMS). This is not to be confused with Windows Media
> Server, a server application that typically runs on
> different computer than those upon with WMP runs
You're making a mistake. WindowsMediaServices and
WindowsMediaServer are exactly one and the same and they
have nothing in common with WMP. Data source plug-ins only
work in WMS and they are essentially ASF file readers, not
live sources of arbitrary formats.
> It appears that the schemed described for data source
> plug-ins has been superseded by:
>
> WMCreateStreamForURL():
Another mistake: WindowsMediaFormat (WMF) source plug-ins
are in no way related to WMS's data source plug-ins. Again,
WMF source plug-ins are essentially ASF file readers and not
live sources. Also, WMF source plug-ins have been deprecated
for years (but they are still supported, at least up to
WinXP, not sure about Vista).
> 9. Since WMS relies almost entirely on the DSP to fetch
> data that end- user wants to see/hear, your DSP can
> supply to WMS essentially any music or video you want.
[...]
> 10. I *think* WMS is able to tell from the first few
> bytes of stream what is actually in the stream so that it
> knows what module should do the rendering. Not sure. If
Wrong and wrong. A WMS data source plug-ins must fetch an
ASF system stream (since media parser for other formats can
not be plugged in) and WMS doesn't have to guess anything,
since the system stream will always be ASF and WMS does not
have to decode the contained audio/video streams.
WMP's equivalent of IE's pluggable protocol handlers are
DirectShow source filters. To support a live stream, you
will need to write a live push source (which is similar to a
capture source) that outputs the elementary audio/video
streams, tagged with the corresponding media types.
http://msdn.microsoft.com/en-us/library/ms787558(VS.85).aspx
http://msdn.microsoft.com/en-us/library/ms787518(VS.85).aspx
http://msdn.microsoft.com/en-us/library/ms787249(VS.85).aspx
and so on...
If your protocol delivers packets asynchronously, you should
base your filter on CBaseFilter/CBaseOutputPin:
http://msdn.microsoft.com/en-us/library/ms780191(VS.85).aspx
If you protocol delivers packets on demand, you should base
your filter on CSource/CSourceStream:
http://msdn.microsoft.com/en-us/library/ms782806(VS.85).aspx
The Ball, PushSource and Synth samples in the SDK use
CSource to produce audio and video.
You filter will need 2 pins, instead of 1, and you will need
to also add support for IFileSourceFilter (to know what URL
to Load()) and any other required interface.
Notice that you will need to output separate audio and
video, you can not output a muxed transport stream (unless
it's an MPEG-2 TS), because the stock parsers expect an
IAsyncReader-based pull-mode source instead of an
IMemInputPin-based push-mode source (while decoders work in
push mode).
If, instead, your protocol worked like a download&play, you
could have used a WMF source plug-in (if the system stream
were an ASF file) or an async reader source (IAsyncReader is
similar to IStream), which can output a system stream to be
demuxed by a stock or custom parser, or even an IE's
pluggable protocol handler, since the stock URLReader filter
(which is an async reader) should be able to wrap those
automatically.
--
// Alessandro Angeli
// MVP :: DirectShow / MediaFoundation
// mvpnews at riseoftheants dot com
// http://www.riseoftheants.com/mmx/faq.htm
|
|
On Nov 22, 8:31 pm, "Alessandro Angeli" <nob...[ at ]nowhere.in.the.net>
wrote:
[Quoted Text] > WMP's equivalent of IE's pluggable protocol handlers are
> DirectShow source filters. To support a live stream, you
> will need to write a live push source (which is similar to a
> capture source) that outputs the elementary audio/video
> streams, tagged with the corresponding media types.
Thanks for correcting me and getting me on the right track. I read all
the links that you posted, as well as a brief introduction to the
Audio & Video section of MSDN docs. I have also experiemented with
some of the samples for playback, etc.
Since we are doing this for research purposes, to test an experimental
protocol that runs in parallel to TCP/IP on our LAN, I was thinking
about using two of the samples and tweaking them to change the part
that uses TCP/IP (or TCP/UDP) to our protocol on both ends.
My guess is that you already have in mind two samples that would be
most suitable for this scenario. Is that the case, or will I have to
start from scratch?
GraphEdit is very cool, btw. :)
-Le Chaud Lapin-
|
|
From: "Le Chaud Lapin"
[...]
[Quoted Text] > our LAN, I was thinking about using two of the samples
> and tweaking them to change the part that uses TCP/IP (or
> TCP/UDP) to our protocol on both ends.
>
> My guess is that you already have in mind two samples
> that would be most suitable for this scenario. Is that
> the case, or will I have to start from scratch?
There are no networking samples. All you have is what I
wrote about in my previous message.
--
// Alessandro Angeli
// MVP :: DirectShow / MediaFoundation
// mvpnews at riseoftheants dot com
// http://www.riseoftheants.com/mmx/faq.htm
|
|
On Nov 24, 9:07 am, "Alessandro Angeli" <nob...[ at ]nowhere.in.the.net>
wrote:
[Quoted Text] > From: "Le Chaud Lapin"
> > our LAN, I was thinking about using two of the samples
> > and tweaking them to change the part that uses TCP/IP (or
> > TCP/UDP) to our protocol on both ends.
>
> > My guess is that you already have in mind two samples
> > that would be most suitable for this scenario. Is that
> > the case, or will I have to start from scratch?
>
> There are no networking samples. All you have is what I
> wrote about in my previous message.
Hi Again,
I think I am nearing the point where I can stream data over our
experimental protocol using DirectShow filter, but I am having
problems with actually registering the COM control.
GraphEdt is refusing to load the COM object when I do Render URL
against "FUBAR://...":
---------------------------
GraphEdit
---------------------------
Could not construct a graph from this file.
- Have you installed all necessary filters?
- Note that the 'Render File' menu option cannot render *.GRF files.
(Return code: 0x800c000d)
---------------------------
OK
---------------------------
I have checked to see I am complying with the MSDN instructions. I can
see the typical COM registration taking place under the appropriate
CLSID. I can see the protocol being installed per DllRegisterServer
and AMovieDllRegisterServer2. The CLSID's match up as they should. I
do not have any particular file extensions specified for the protocol,
nor do I do the extra registration seemingly required for WMP.
What am I doing wrong?
-Le Chaud Lapin-
|
|
|