Posts Tagged ‘Source’
How To: Take care of DirectShow filters that impose unreasonable requirements
Although I personally have no experience with tricky DirectShow filters that decide on possibility of connection not only looking at media type and other capabilities, there has been a number of cases mentioned that certain video decoders will only connect to renderers or video renderers in order to avoid interception of decoded data.
It was recently mentioned that one of such filters checked Misc Flags obtained through IAMFilterMiscFlags interface to make sure it is connected to renderer downstream. Before we proceed, let us make it clear that it is silly and can only protect from beginner, a complete newbie. At the very least it should have checked peer filter’s CLSID and compare against white list of stock video renderer: Video Renderer, Video Mixing Rendeder 7, Video Mixing Rendeder 9, Enhanced Video Renderer. A custom video renderer or even just a transformation filter with a renderer flag would be able to receive decoded data and make it available for any further processing.
What I am going to do is to take Sample Grabber Filter as a base and make a new filter from it which will only connect to renderer (it will check the flags as described above). Then another filter, which will also use Sample Grabber Filter base, will accurately fool the first one and connect to output of the first filter and will render video to complete the graph.
WinHTTP escaping problem
WinHttpCrackUrl and WinHttpCreateUrl API functions are breaking URL string into components and recompose back to string. There was a mess with passwords and security issues since when putting password into URL is no more acceptable. Experienced users might remember the times when URL could embed password, e.g. ftp://john:mysecretpassword@host.com/path. Password is lo longer accepted by major applications in a typed in string and no more allowed by updated RFC 3986 “Uniform Resource Identifier (URI): Generic Syntax”:
3.2.1. User Information
The userinfo subcomponent may consist of a user name and, optionally,
scheme-specific information about how to gain authorization to access
the resource. The user information, if present, is followed by a
commercial at-sign ("@") that delimits it from the host.
userinfo = *( unreserved / pct-encoded / sub-delims / ":" )
Use of the format "user:password" in the userinfo field is
deprecated. Applications should not render as clear text any data
after the first colon (":") character found within a userinfo
subcomponent unless the data after the colon is the empty string
(indicating no password).
What if we don’t have URLs typed in? But it still convenient to keep password as a part of URL? Luckily there is such thing as compatibility, so we can rely on WinHTTP subsystem to process passwords for us. The problem however is escapement. The most tricky is that it is not a bug, it is documented but is unintuitive. The cracking part would unescape all components if ICU_DECODE flag is provided. The composing part however will only escape (ICU_ESCAPE) the part to the right from port number (whether it is specified or expected to be)!
For example (see source code below):
g_ppszUrls[3] http://user:pa%40ss@site.com/path?name=value%20%2F%3A%40 .lpszScheme http .nScheme 1 .lpszHostName site.com .nPort 80 .lpszUserName user .lpszPassword pa@ss .lpszUrlPath /path .lpszExtraInfo ?name=value /:@ pszUrl http://user:pa@ss@site.com/path?name=value /:@ pszUrl (ICU_ESCAPE) http://user:pa@ss@site.com/path?name=value%20/:@
An effect of excessive RGB conversion onto video streaming perofrmance (continued)
This continues the topic raised by previous post. As fairly noticed by The March Hare, video renderer is using hardware overlay and the benchmark is incorrect if we are to extrapolate the performance to scenario with multiple video renderers.
So, an updated test application creates 16 video renderers with 16 threads pumping two meida samples through each of the 16 filter graphs.
The screen shot shows that there is only one video overlay in use (which image was not captured and blackness is shown instead), so results may be inaccurate for one of the graph among 16. In this simple test I disregard this.
Here go the results (in all tests CPU usage is maxed out):
- YUY2 Source -> VMR: 3,480 fps
- YUY2 Source -> AVI Decompressor (converts to 24-bit RGB) -> Sample Grabber (without processing) -> Color Space Converter (converts to 32-bit RGB) -> VMR: 560 fps
- YUY2 Source -> AVI Decompressor (converts to 32-bit RGB) -> Color Space Converter -> VMR: 390 fps
An effect of excessive RGB conversion onto video streaming perofrmance
Started here: How can I overlay timestamp on the image? on microsoft.public.win32.programmer.directx.video
Let us see if RGB conversion adds any noticeable effect on streaming YUY2 video, typical output of video decompressor.
As a reference I am taking a simple YUY2 source -> Video Mixing Render Filter (VMR) graph, where source filter streams the same pre-allocated and pre-initialized data in an infinite loop:
while(WaitForSingleObject(TerminationEvent, 0) == WAIT_TIMEOUT)
{
ATLENSURE_SUCCEEDED(m_pSourceFilter->InjectMediaSample(m_pnData, m_nDataSize));
CRoCriticalSectionLock DataLock(m_DataCriticalSection);
m_pnInjectedFrameCounts[0]++;
}
Video resolution is 640×480 pixels.
What is actually consuming CPU resources here is data copy into VMR’s media sample buffer and actually streaming. VMR might be blocking control waiting on rendering completion, I am leaving this for default VMR to decide (it might be hardware dependent etc).
Running at full pace, the application is rendering 510 frames per second consuming virtually no CPU. That is VMR is waiting until meida sample is rendered, this only allows streaming mentioned number of media samples per second, however rendering process does not take CPU resource, just waiting for video hardware to complete.
How To: Wrap an existing DirectShow filter with a private video source filter (COM aggregation)
See beginning in microsoft.public.win32.programmer.directx.video newsgroup.
This sample is demonstrating COM aggregation to embed an existing filter an re-expose it as a new filter having inner filter pre-initialized.
The Visual Studio C++.NET 2008 projects contains a DirectShow filter class that registers itself under Video Capture Sources category and embeds File Source (Async) Filter inside initialized to stream clock.avi file from Windows directory.
Ffdshow is getting more annoying
Surprisingly fast I got new problems having ffdshow installed as a part of K-Lite Codec Pack. No wonder though because let us take a look at registration information:
Display Name: @device:sw:{083863F1-70DE-11D0-BD40-00A0C911CE86}\{0F40E1E5-4F79-4988-B1A9-CC98794E6B55}
CLSID: {0F40E1E5-4F79-4988-B1A9-CC98794E6B55}
Friendly Name: ffdshow Audio Decoder
Path: C:\Program Files\K-Lite Codec Pack\ffdshow\ffdshow.ax
Merit: 0×3fffffff
Nice merit, ain’t it? What is merit anyway? Let us check at MSDN:
MERIT_PREFERRED = 0×800000,
MERIT_NORMAL = 0×600000,
…
MERIT_HW_COMPRESSOR = 0×100050
The highest defined value is 0×00800000, while ffdshow is registered with 0×3FFFFFFF, that is on top of everything. No doubt the developers read Guidelines for Registering Filters and decided to get rid of the rest of installed software as unnecessary crap.
Anyway back to the problem: I had an A-law wave file (WAVE_FORMAT_ALAW) to play and make sure its data is valid and quite unexpectedly there was a silence while playing. A quick check confirmed that the sustem has CCITT A-law codec installed, however GraphEdit shown ffdshow Audio Decoder intercepting decoding. Obviously it spoiled the thing!
Finally I decided it was a right time to take an advantage of IAMGraphBuilderCallback interface to detect and reject the bastard.
ATL’s CenterWindow
It appears that ATL does not center window correctly on multi-monitor systems. ATL code checks screen work area coordinates in CWindow::CenterWindow to ensure new position is within visible area, however since SystemParametersInfo/SPI_GETWORKAREA is used target rectangle is always on a primary monitor.
This hotfix works the problem around:

Subscribe to the comments for this post

