Fooling Around // Software Production Line

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/:@

Read more »

Given a DirectShow filter graph, what media samples are being sent through particular graph point? DumpMediaSamples utility gives a fast answer to this question. It prints out connection media type details (with details of VIDEOINFOHEADER, VIDEOINFOHEADER2 and WAVEFORMATEX structures corresponding to FORMAT_VideoInfo, FORMAT_VideoInfo2 and FORMAT_WaveFormatEx format types) and IMediaSample details obtained through AM_SAMPLE2_PROPERTIES structure.

First of all, it is necessary to create a graph of interest using GraphEdit utility. At the point of interest it is necessary to insert [an uninitialized] Sample Grabber Filter with the filter name “SampleGrabber” (this is the default name but if you add second filter which will be given a different name and remove first filter then, the utility would fail).

The graph may look like this:

Read more »

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

Read more »

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.

Read more »

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.

Read more »

Previously on the topic:

• Part 1: Starting the Project
• Part 2: Video Processing
• Part 3: Persistence, Automation and Property Pages
• Part 4: Merit

Due to the nature of the brightness and constract correction processing, it would make sense to combine and simplify processing to apply correction “in-place”, that is without copying data from input to output buffer, but instead processing the same buffer before it is passed further downstream.

DMO API offers additional optional IMediaObjectInPlace interface to be implemented on the DMO which the hosting object might prefer to regular IMediaObject.

The interface itself is simple with basically the only Process method to actually handle the processing:

// IMediaObjectInPlace
	STDMETHOD(Process)(ULONG nSize, BYTE* pnData, REFERENCE_TIME nStartTime, DWORD nFlags)
	STDMETHOD(Clone)(IMediaObjectInPlace** ppMediaObject)
	STDMETHOD(GetLatency)(REFERENCE_TIME* pnLatencyTime)

Read more »

Previously on the topic:

• Part 1: Starting the Project
• Part 2: Video Processing
• Part 3: Persistence, Automation and Property Pages

The implemented so far filter/DMO shown a problem related to its unexpectedly high “importance” in the system with the symptom of “auto-insertion” the filter when it is not necessary. For example, let us render an AVI file through Infinite Tee Pin Filter:

The problem is that DirectShow auto-inserts our Brightness/Contrast filter into the graph while it is obviously not expected, wanted or necessary:

The problem is high filter/DMO merit value and a popular YUY2 video format the filter is advertised to accept on input during DMO registration.

Read more »