3D Movie in 2D Problem

If it was working under older LE Generic releases you will prob. need to use the Generic-Legacy (X11) image as Generic now runs GBM which probably has no 3D support.

Most improvements to Intel and AMD drivers come from the vendors themselves. And because none of the TV manufacturers are creating new TVs with 3D capabilities now (the 3D fad has passed) there's no "business" demand for 3D features; only from end-user consumers who don't puchase silicon chips in volume quantities and so aren't important.

I'm curious. What is the format of your 3d videos? e.g.

half-SBS

half-TAB

full-SBS

full-TAB

MVC

This problem was already visible on the rpi4 which has been using GBM a lot longer. If you search for 3d and rpi 4 you'll get several posts about it. I ignore the 3D gui and just play the SBS and TAB files like normal 1080p videos and set the 3d mode on my tv as a workaround.

If the problem now exists on the generic build as well I believe it's either time to fix it or to disable the 3d features on GBM builds (at least temporary).

I understand that 3D MVC support is a driver issue and unlikely to ever be fixed.

3D output to a TV (making it switch to the correct 3d mode automatically) might be difficult as well.

On the other hand half or full TAB or SBS should be relatively easy to fix for a developer that is familiar with the GBM pipeline (sadly, I am not a programmer). It is clear that the kodi gui has support for 3d features and asks a left and right view from the video pipeline, but GBM provides an unsplit frame twice instead of a frame split in a left and right view. That is why in 2D mode with your half SBS file, you get a split view, and in 3d mode you get 4 views. To fix this someone needs to implement the 3D part in GBM so it can deliver a left and right view separately when it knows the 3D format of the source file. That would fix all problems with (H)TAB and (H)SBS encoded files and give users the same working output options as with the legacy builds. It would not work for MVC encoded files.

I know it's very low priority so I will be patient and use the workaround like I have been using for the past years.

The fix is not done "in GBM" .. the fix is done in the RPi video driver, and the Intel driver, and the AMD driver, and the Amlogic driver, and the Rockchip driver, and the Allwinner driver. That's rather a lot of very complicated low-level driver work and the reason why it hasn't already been done and isn't likely to happen. The possibility of an RPi4 only fix is marginally higher, because at least one of the RPi Foundation devs has a personal interest in 3D support. However, progress probably requires him to have lots of rainy-days with low workload in the office or a long convalesence at home with too much free time and an itch to scratch; neither scenario is that likely.

If we are not speaking about MVC encoded 3D or framepacked output, I don't understand why we need driver support. A HSBS encoded file is just a normal 1080p file where both views are shown at half width. Output would again be a normal 1080p output with a split gui on top. Why does a video driver need to support it?

chewitt That somehow doesn't sound right, but maybe it is.

Let me confirm:

- We have a video file which, by its metadata, is recognized as 3d.

- The file itself contains the two images in one of the common layouts, but is a plain video file apart from that.

- Based on the metadata, Kodi will automatically do "something" when the video starts.

- In my understanding, the only thing Kodi would actually have to do to make this usable (in a barebone form) is show the menu twice (depending on the format).

- Instead, and this might or might not be some driver problem, the full image gets duplicated.

So, even if the image duplication is a driver issue, there must be something that triggers this.

At the same time, I don't see what processing step exactly would be required that would trigger this, as "all we need" is the menu...