[liquidskin76]

http://pastebin.com/r9p072CU

Also got a crash this time... Error "ERROR: Exception caught on main loop. Exiting". Here's the crashlog's and stacktrace's...

Many thanks

Driver hangs. So try to install latest Beta driver https://downloadcenter.intel.com/downloa...1-10-15-40-

Thanks afedchin, those beta drivers have solved the black screen and crash. However the aspect ratio is squashed, like if you play a 3840x1080 file using non hardware based sbs 3D setting, or in 2D. Stereoscopic Player correctly plays it at correct usual 1920x1080 ratio.

I know I can edit the mkv header to display width 1080, but as per Stereoscopic Player i'm not sure this should be required with hardware based 3D. What do you think?

Many thanks

[liquidskin76]

Ah, just had a thought as well... what are the implications for mvc 3d files, like from MakeMKV and 3D Blu-ray, now that hardware based 3D has arrived? Guess still one for the future with lack of mvc decoder in ffmpeg, unless I've missed some development!? Is it something that's in the works with http://forum.kodi.tv/showthread.php?tid=226440?

Thanks

[afedchin]

I know I can edit the mkv header to display width 1080, but as per Stereoscopic Player i'm not sure this should be required with hardware based 3D. What do you think?

You can change aspect in video OSD settings. IIRC for full SBS it should be 0.5.

Ah, just had a thought as well... what are the implications for mvc 3d files, like from MakeMKV and 3D Blu-ray, now that hardware based 3D has arrived? Guess still one for the future with lack of mvc decoder in ffmpeg, unless I've missed some development!? Is it something that's in the works with http://forum.kodi.tv/showthread.php?tid=226440?

Thanks

FFMpeg still doesn't support decoding 3D MVC files. So, it's not possible to play these files correctly.

[liquidskin76]

I know I can edit the mkv header to display width 1080, but as per Stereoscopic Player i'm not sure this should be required with hardware based 3D. What do you think?

You can change aspect in video OSD settings. IIRC for full SBS it should be 0.5.

Would it not make sense to just play 3840x1080 full sbs files at 0.5 automatically (if possible from a code point of view)? I can't think of any reason why they would be viewed at 1.00 and squashed?

Many thanks

[bossanova808]

@afedchin

I think you're sort of right. The projector is connected via a 15m in wall cable and two short cables at either end of that (receiver to wall < 15m in wall cable > wall to projector). This works perfectly (and has done for over a year) with YCbCr (4:4:4) mode. I've tried alternate cables at either end but can't change the wall cable obviously. The 15m wall cable is a certified high quality HDMI 2 cable and I tested it extensively when the walls were off and never saw any issue with it, so I'm pretty confident in it - but it IS a long distance.

I suspect RGB mode uses higher bandwidth somehow, and/or for whatever reason the signal being output in RGB mode is weaker. (I've ordered a powered HDMI repeater box to see if that can help).

In any case, in YCbCr mode everything seems to work fine. I understand in theory that RGB mode is better to use due to less conversions, but I have today thrown a bunch of calibration tests at both the plasma and projector including grey ramps, colour and resolution tests etc, and I can't detect any visual difference). I won't say both modes are perfect - there is some minor lack of smoothness in the grey ramp - but the results are visually identical in YCbCr and RGB at least.

(For good measure I compared an OE 6.0 installation on the same hardware as well, and it shows the same display as DX11 Kodi. So I don't think I am losing anything by YCbCr mode and it sure beats weird flickering and purple/green stripe issues. I like OE for quick boot & simplicity but the sluggish remote speeds and lack of support for e.g. Steam streaming, and general state of Linux/AMD support is ... not awesome).

I believe (well, various forum postings cliam...) that AMD APUs are known for not outputting a massive amount of video signal (perhaps as a keep cool thing?)...but it seems I have a workable solution for Jarvis until I next upgrade hardware.

(One thing of note and theoretical advantage is the AMD drivers show 10 bit output with YCbCr and only 8 bit with RGB).

[givayt]

20151226 version's black level: 0.022 fL, same as v15.2! I thought this wasn't possible with my setup. What's changed?

[_Shorty]

Yeah, I'm still wondering about an explanation for that one.

20151226 version's black level: 0.022 fL, same as v15.2! I thought this wasn't possible with my setup. What's changed?

[_Shorty]

Is it feasible to set up a temporary test with a 2-3 m cable? Could help you figure out if that distance is an issue.

The 15m wall cable is a certified high quality HDMI 2 cable and I tested it extensively when the walls were off and never saw any issue with it, so I'm pretty confident in it - but it IS a long distance.

[afedchin]

20151226 version's black level: 0.022 fL, same as v15.2! I thought this wasn't possible with my setup. What's changed?

Yeah, I'm still wondering about an explanation for that one.

Now we using same technique for color range conversion as in UI and Pixel Shaders instead of using video processor for conversion.

[teepean]

I would like to test the DX11 build but the download seems to be missing.

[afedchin]

to test dx11 build use latest Jarvis beta http://kodi.tv/kodi-16-0-beta-4-jarvis-i...g-ready-4/

[Borge_30]

there they like as if with the last beta is doing better ( at least for me... )

[Ed76]

@afedchin

just tested latest kodi beta 5 but color room is not ok for me. i have to describe a little, hope you understand me because english is not my native language:

system: win 8.1, catalyst 15.7.1 whql
hardware: amd a6 richland apu
tv: philips led, needs limited color room

how i test?
1) with that "flashing lights" video, with that video i can see if the color room ist full or limited and i can adjust the "perfect" brightness of tv with that video.
2) i compare result of "flashing lights" testvideo with newest kodi, with kodi 15.2_dx9 and with mpc-hc+madvr(dx11)

what works?
setting in catalyst: pixel format: studio rgb + force limited color room within catalyst video settings.
settings kodi: full color room + dxva
setting madvr: limited color room (because madvr doesnt care about catalyst settings)
result: i get limited color with all 3 players. the "perfect" brightness is "39" for my tv. i get the same "perfect" brightness results with all 3 players. all is fine.

what doesnt work?
setting in catalyst: pixel format: full rgb + automatic choose color room for video
setting kodi: limited color room + dxva
setting madvr: limited color room

result:
kodi 16 beta 15: video is not limited, i get full color room.
kodi 15.2_dx9 and mpc-hc+madvr: i get limited color room with "perfect" brightnes "51" for tv with both player

there is another strange thing:
befor i updated to kodi beta 16.5 i had latest kodi 15.2_dx11 installed. with that kodi version 15.2dx11 i also get the wrong (full) color room (with the settings describet above). but i had a kind of "workaround" that worked good for me:
catalyst: pixelformat: full rgb + force limited color room for video
kodi: limited color room
with that setting the kodi gui looks ok to me and also video color room was ok. with all test players i get the same result, means limited color room and "perfect brightness" of tv = "51".

but with kodie 16 beta 5 that "workaround" does not work.
with the describet workaround-settings i get limited color room for videos but the kodi video is now much to bright, much brighter than mpc-hc+madvr or the old 15.2_dx11.

hope you understand me, let me know if you need a debug log

[afedchin]

Latest Kodi doesn't apply color corection in dxva processing it does that in post processing stage. But seems your drivers for dx11 ignores what Kodi requires don't touch color range during dxva processing. With enabled Use limited colors setting in Kodi this causes a double color correction in dxva processing (in drivers which is wrong) and then in post processing (in Kodi). If Use limited colors is disabled then drivers still apply color correction in dxva processing stage, but Kodi doesn't do color correction in post post-processing stage and you get correct video brightness. This bug doesn't affect Kodi 15.2 and madVR because both of them use DirectX9 API.

I'll try a last try to solve this driver bug. Stay tuned for news. But I'm promise nothing.

[Ed76]

Latest Kodi doesn't apply color corection in dxva processing it does that in post processing stage. But seems your drivers for dx11 ignores what Kodi requires don't touch color range during dxva processing. With enabled Use limited colors setting in Kodi this causes a double color correction in dxva processing (in drivers which is wrong) and then in post processing (in Kodi). If Use limited colors is disabled then drivers still apply color correction in dxva processing stage, but Kodi doesn't do color correction in post post-processing stage and you get correct video brightness. This bug doesn't affect Kodi 15.2 and madVR because both of them use DirectX9 API.

I'll try a last try to solve this driver bug. Stay tuned for news. But I'm promise nothing.

thanks very much!
but i have tested madvr with dx11 mode (you can choose within madvr dx9 or dx11).