Scythe42's fixes for 1.4.0 (5 Viewers)

[Vasilich]

is env var DXSDK_DIR defined ? check in cmdline
set DXSDK_DIR

 

[Scythe42]

DirextX side is fine...

Problem is this one: "error MSB6006: "CL.exe" exited with code -1073741515." when the project is set to be compiled by SDK 7.1. I somehow start to assume that with the recent changes, the C++ side is not compilable anymore with the SDK 7.1 installation but requires the full VS2010 tool chain. Must be something inside the projects settings itself, that is probably not needed.

 

[elliottmc]

You commit em. We'll compile em!

 

[Sebastiii]

Hey,
I think installing vc2010 express fix it (not 100% sure, but i think HomeY has see the same error/issue)
When i have tested win8 stuck on vm, all was working with msbuild (that i remember).
I suppose you follow the wiki, some files are needed available on ftp if i'm not wrong
I hope that help

 

[Sebastiii]

A quick fix would be to either comment the Call to LogOptions() in

WindowPlugins.GUITVSeries.TVSeriesPlugin.Init() in D:\svnroot\!PLUGINS\mptvseries - Master_BD\MP-TVSeries\TVSeriesPlugin.cs:line 475

or to swith the foreach statement to a for loop, which just minimizes the error condition.

So the only real solution would be, to make all Plugin Initializations Thread Safe

Thanks

Will ask dev to look on that

 

[high]

nstallation but requires the full VS2010 tool chain.

I set up a new botserver for vs2012 yesterday (on Server 2012) and had similar issues (just different msgs). Compiling filters was only possible when vs2010 was installed too.

 

[Scythe42]

I made some progress here finding out the root cause. Will continue tomorrow with it...

 

[Owlsroost]

Yes, that is what it's doing (correctly), the 'internal' window dimensions are in the correct 16:9 ratio (I've checked that it is 1280 x 720), it's the aspect ratio of the actual video playing that is wrong (it's squashed vertically when it shouldn't be).

Problem in g_player.cs. Not caused by this series of build. Just one more thing that needs attention. Probably comes all down to the same root cause that you guys identified and is still left in some parts of MP.

Just to be clear - fullscreen is OK with both 1.3.0 and the new version.

If MP is started in a window, 1.3.0 is OK, but new version appears to use the display instead of the window size/aspect ratio to work out the X/Y scaling (so the aspect ratio of the video is then incorrect). Haven't tried it yet, but I assume that if the display was 16:9 then it would look correct, since both window and fullscreen would be the same aspect ratio.

Not sure if this is a big enough issue to cause it to miss the train, given that fullscreen is the normal operating mode of MP ? (especially as this train was mostly intended to convey all your other great improvements to the world )

 

[Scythe42]

And I think I got it, at least part of it:

From VS2012's VCVarsQueryRegistry.bat

:GetWindowsSdkDirHelper32_35
@for /F "tokens=1,2*" %%i in ('reg query "%1\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v8.0A\WinSDK-NetFx35Tools" /v "InstallationFolder"') DO (
		@if "%%i"=="InstallationFolder" (
				@SET "WindowsSdkDir_35=%%k"
		)
)

Ah, it checks what SDK 8.0A has set for .NET 3.5. And if you check the registry keys you will see that they are set to

C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\

That directory does exists, but only has a limited set of binaries when neither SDK 7 or VS2010 were installed.

No check for SDK 7.1! For .NET 4 SDK 8 should be used. Seems perfectly right to me.

That means when using a VS2010 project inside VS2012, we will need to have SDK 7 installed as well or what is better is setting the tool chain to Windows SDK 7.1 if you do not want a compilation against SDK 7. VS2012 offers this. In fact it can be set under VS2010 as well!

And that is the root cause.

Our C++ projects are compiled against SDK 7.1 but using the toolchain of SDK 7.

Or is it the Wiki wrong that calls for SDK 7.1 installation and we compiled the C++ parts against SDK 7 anyway for a release?

Anyway, when moving to .NET 4 on the C# side we should sort this out. .NET 4 means we need to compile against SDK 8 to keep everything nice and consistent.

When you set the toolchain inside a project file to to SDK 7.1, it cannot find some DLLs for precompiled debug headers, like mspdb100.dll. And that is because it is not calling the batch for setting the environment variables of SDK 7.1 it seems. Have not verified it.

And regarding using SDK 8 and the changes that the DirectX SDK is now inside the Win SDK and D3DX not being officially part of it anymore (replaced by a new math helper lib). That is documented by MS and what you need to change in your project files (has no impact when not using SDK 8).

Only thing for SDK 8 left for me - yes, we do not rely on it yet - are some EVR things. There were some changes how IMFTrackedSample is defined:

It has beeen moved from evr.h to mfidl.h, which given its definition makes perfectly sense.

MIDL_INTERFACE("245BF8E9-0755-40f7-88A5-AE0F18D55E17")
IMFTrackedSample : public IUnknown
{
public:
	virtual HRESULT STDMETHODCALLTYPE SetAllocator(
		/* [annotation][in] */
		__in  IMFAsyncCallback *pSampleAllocator,
		/* [unique][in] */ IUnknown *pUnkState) = 0;
};

But VS2012 does not pick it up properly in __uuidof(IMFTrackedSample) very likelly because of the added type definition in midl.h. Not sure here, but the part of the code goes back to the EVR presenter example on MSDN and was probably not the best way to do it in the first place but was correct at the time.

Will continue in the evening on this before providing the next build.

 

[Scythe42]

If MP is started in a window, 1.3.0 is OK, but new version appears to use the display instead of the window size/aspect ratio to work out the X/Y scaling (so the aspect ratio of the video is then incorrect).

Mantis http://mantis.team-mediaportal.com/view.php?id=3991 - exist exactly for this reason.

The rendering backbuffer is setup by the screen dimensions of the display you start MP on. Resizing is then made safe to the aspect ratio of the skin in windowed mode. You might not have noticed, but a 16:9 skin looks a bit different on 16:10 when running in full screen. As the aspect ratio does not really match it will always. That's why you probably did not notice it.

With 16:9 content on a 16:10 screen you will have black bars on the top and bottom. And as MP is mainly designed for full screen no adjustments are made in windows mode here.

You will have the same with 4:3. You will have black bars on the left and right.

Will not fix for 1.4.0.

That will be done afterwards. Yes, 1.3.0 worked differently here, because it reset the device all the time when content changed (part of the initial problem).

This will be solved with 1.5.0 when the EVR presenter and therefore playback can have their own D3D device.

Also a reason why I am so after SDK 8: to allow the EVR content to be rendered inside Modern UI.

Yes, Modern UI does not support Direct Show. But currently the EVR presenter hands over the texture to the Skin Engine anyway, so it can render its GUI across it. Why not handing the texture over to a D3D device in a completly different app as well?

By allowing textures to be handed over between devices that is easily possible. In other words video will be visible in Modern UI was well if the app is active. Yes, more can be done here. But that is IMHO the most interesting first step.