Game streaming from Windows host to Tesla

Thanks to game streaming tech of Rainway and effort of Andrew Sampson, games get streamable to a new device now: Tesla onboard computer.

If P+R is park and ride, P+P will be park and play.

Irritating Direct3D 11/12 Shader Cache Exception

One annoying thing existing for a long time is an internal _com_error exception in Direct3D shader cache, coming from D3DSCache.dll during execution of innocent API calls like D3D11CreateDevice. Also related storage location for the cache files is %LOCALAPPDATA%\D3DSCache, one can try deleting it completely in the case annoying issue persists.

Many of us can afford writing code with random exceptions but given the impact of Direct3D API such exceptions are intolerable. The exception is handled internally and is not passed (even as failure code) through outer API interface, but this is not a sufficient excuse: exceptions are reserved for situations when something serious happens and situation requires attention. What effectively takes place is you start an app expecting debugger to break on exception and the debugger stupidly breaks in the middle of nowhere for no apparent reason.

In some other cases I am running self-debugging applications. For example, this face detecting Telegram bot runs unmanned as a Windows service on an Intel NUC box I might not even log into for weeks. To keep a track of unexpected conditions, the service, however, runs a debugging session against itself and records minidumps for all exceptions happening so that, if needed, they could be investigated retroactively. Why would I want to mess with shader cache exceptions if they are not real problems, and are triggered as early as when I just create a device?

The error codes are sometimes E_FAIL and at other times it is DXGI_ERROR_CACHE_CORRUPT. The exception object itself is _com_error and originates from D3DSCache.dll so I have to end up filtering this stuff with otherwise unnecessary code like this:

BOOL ShouldWriteExceptionMinidump(const ParentProcessDebug::ExceptionData& Exception)
{
	[...]
	if(_wcsicmp(PathFindFileNameW(Exception.m_ModulePath.c_str()), L"D3DSCache.dll") == 0)
	{
		if(Exception.m_TypeName.compare(".?AV_com_error@@") == 0 && (Exception.m_Value == E_FAIL || Exception.m_Value == DXGI_ERROR_CACHE_CORRUPT))
			return FALSE; // D3D11On12CreateDevice API related?
	}
	[...]
	return TRUE;
}

Microsoft “FaceTracker” Face Detection in form of Telegram bot

Microsoft Windows operating systems come with built-in API for face tracking in Windows.Media.FaceAnalysis Namespace. It is available since Windows 10 “Threshold 1” build 1507 even though it is probably not the most popular API for a few reasons but maybe most important is that like some other new additions, the API addresses UWP development.

Nonetheless, Microsoft even published a couple of samples (see Basic face tracking sample) and perhaps this feature is mostly known because of its use Windows Store Camera application: in Photo mode the application detects faces and the documentation suggests that the application might be involved in working cooperatively with hardware in auto-focusing on detected face. Overall, the face detection is of limited use and feature set even though it is quite nicely fitted to not only still image face detection, but also video and “tracking”: when faces are tracked through sequence of video frames.

UWP video APIs do not often mention the internals of implementation and the fact that on the internal side of things this class of functionality is implemented in integration with Media Foundation API. Even though it makes good sense overall since Media Foundation the is the current media API in Windows, the functionality is not advertised as available directly through Media Foundation: no documentation, no sample code: “this area is restricted to personnel, stay well clear of”.

So I just made a quick journey into this restricted territory and plugged FaceTracker into classic desktop Media Foundation pipeline, which in turn is plugged into Telegram Bot template (in next turn, just running as a Windows Service on some Internet connected box: this way Telegram is convertible into cheap cloud service).

The demo is highlighting detected faces in a user provided clip, like this:

That is, in a conversation with a bot one supplies his or her own video clip and the bot runs it against face detector, overlaying frames for found faces, then sends back the re-encoded video. Since Media Foundation is involved and given that face detector is well interfaced to media pipeline, the process is taking place on GPU to extent possible: DXVA, Direct3D 11, hardware encoder ASIC.

All in all, meet @FaceDetectionDemoBot:

I guess next time the bot will also extract face detection information from those clips recorded by iPhones. If I get it right, the recent fruity products do face detection automatically and embed the information right into clip helping cloud storage processing since edge devices already invests its horsepower into resource consuming number crunching.

In closing,

I have a container element, but I will not give it to you…

A few weeks ago I posted a problem with AMF SDK about a property included into enumeration and triggering a failure in a followup request for value. It appeared to be “internal property” to intentionally tease the caller and report error by design, unlike all other dozens of SDK properties. And of course to raise an error in an unexpected place for those naive ones who trust third party packages from reputable vendors too much.

So I am happy to report that another vendor, NVIDIA, is catching up in the competition.

uint32_t nPresetCount = 0;
NvCheck(NvEncGetEncodePresetCount(Identifier, nPresetCount));
// nPresetCount is 17 now even though it's been 10 for a long time
if(nPresetCount)
{
	[...]
	NvCheck(NvEncGetEncodePresetGUIDs(Identifier, pPresetIdentifiers, nPresetCount, nPresetCount));
	// Success
	for(uint32_t nPresetIndex = 0; nPresetIndex < nPresetCount; nPresetIndex++)
	{
		[...]
		NV_ENC_PRESET_CONFIG Configuration { NV_ENC_PRESET_CONFIG_VER };
		Configuration.presetCfg.version = NV_ENC_CONFIG_VER;
		// Argument for 11th item discovered above
		NvCheck(NvEncGetEncodePresetConfig(Identifier, PresetIdentifier, Configuration));
		// NV_ENC_ERR_UNSUPPORTED_PARAM

If this is behavior by design, it is not an innovation, we’d need something new.