2022-04-10, 06:03
(2022-04-10, 03:25)rbmcgee Wrote: I followed your directions and got exactly what I got before (a seemingly 2d image but in fact a 3d image)
To summarize:
1) No doubt about it, the source is a ripped 1920x1080@23+ full 3D source (no copy protection to possibly screw with anything). For proof, you're going to have to trust me on this one.
2) Kodi believes the source is 3D and properly invokes Windows 3D setting and uses the intel graphics engine for acceleration. For proof, see one of the previous photos.
3) Kodi believes it is showing a 1920x1080@23+ 3D movie. For proof see the photo when pressing "O".
4) The projector believes it is receiving a frame-packed 3D 1920x1080@23+ image For proof, see one of the previous photos.
5) By looking at the movie without the glasses, it appears 2D. For proof, see one of the previous photos.
6) By looking at the movie through the glasses, you can see it is a frame-packed 3D image because the right eye has video and the left eye is black. For proof, you're going to have to trust me on this one.
All of the photos are actual photographs of the screen and not snips or captures.
I don't understand coding, but somewhere within the software the left-side video plane is not getting properly transmitted to the graphics engine. Perhaps it is getting properly transmitted but the graphics driver is fumbling the ball. I've now tried 2 different drivers to the exact same effect.
I am stumped how some people seem to have success with the following specs:
Kodi 3D fork 19.4
Frame-packed full 3D source
Frame-packed full 3D display
That I cannot explain.
What was your golden reference system where it worked? Meaning which major windows ver (8, 8.1, 10, 11) and most importantly kodi ver.
The steps i provided above rule all off most of my new additions so it leaves changes done on the kodi official releases and the changes i done to adapt the mvc patches for the official kodi code changes.
When working in stereoscopic mode kodi always attempts to write to both eyes before calling the render function that send it via directx to the display. If one of the eyes is too slow to render maybe its doing a framedrop on the backbuffer (frame queue per eye). Sadly framedrops are not logged in the official kodi code due to performance risks.
I will search for the place where it decide to do a framedrop and add a log entry. Please bear in mind that this is a part of the code that i had yet to visit so it might take a few days and it will be a test build that does not fix the issue, it only log framedrops on either eyes to verify if this is the case you encounter.
