Got back testing Full-SBS 3D mkv vom BD3D2MKV3D playing back to Projector via frame packed output.
On my Vero 4k+, last supported kodi image from beginning of this year, Full-SBS video does work “fine”. You do need to configure vertical shift to -1, else the picture is shifted down, and you partially see the other eye image and separator lines on top. Here:
On the Vero 5k, this config mucking is not necessary, but the icons of the GUI are compressed. Quite noticeable, and it looks a lot worse with skins that are more elaborate. The GUI text is not affected. Here:
Two things come to mind, but I’m not absolutely sure they’re really related:
we use fixed positioning of controls everywhere in the skin (Estuary does use some relative positioning IIRC) and we do sometimes scale image controls (like the OSD button images) differently
the OSMC Skin features 3D playback related depth tags for all controls
Just to be clear i’ve explained the issue correctly:
Estuary icons on bottom left (play, stop, etc).
Play back on Vero V full-sbs video with “side-by-side” 3D output mode. Icons look fine.
Play back on Vero V full-sbs video with “hardware-based” 3D output mode. Icons are horizontally compressed by factor 2.
Play back half-side-by-side video on Vero V, and whether i pick “side-by-side” or “hardware-based”, icons look fine either way.
If there is a problem with Estuary, then that sounds as if it implements some one-off code specifically for half-side-by-side case - and that approach then doesn’t work for full-sbs.
I think this conversion from full-sbs to hardware-based may be unique to Vero V5. Not sure if any other device supported it (haven’t played with windows MVC builds for a long time though, those may have also supported it, can’t remember). And not much use to check Kodi 18 on RPI3 ;-).
So, if this is indeed a skin responsibility, then i think it would be very useful if you folks could take a look and create a diff for estuary, so that that diff can be used as a template for any other skin developer to fix up their skin. Unless you have a diff for this full-SBS/frame-packed fixup for the OSMC skin.
Without a diff it may be very difficult to find all the necessary places where this new display option may need to be explicitly supported ???
Check out the Chicken Run 2 Full-SBS video on the Kodi Samples Wiki. I am assuming the metadata on that one is correct, so it should play back correctly (3840x1080 pixel resolution, 1920x1080 display resolution, side-by side 3D, …).
When i play this back on Vero 5 with 3D side-by-side output everything is fine (except loosing half resolution of course).
When i play this back on Vero 5 with hardware-based, then i have to change the Pixel ratio to 2 so that it will show correct. Else the video is horizontally compressed.
Would be lovely if it would not be necessary to muck around with pixel aspect ratio just because one selects a different rendering mode. AFAIK is was never necessary to do this in before.
This can lead to weird effects when the resolution the skin is rendered at effectively changes with this special type of output (without a reload of the skin). Other Estuary controls look fine because they don’t use relative dimension tags.
The OSMC Skin doesn’t use relative dimension anywhere for exactly this reason. So, nothing we can do from our side really - it’s a basic coding decision by every skinner how to approach this (with all consequences each decision has).
I wouldn’t even know how to describe whats broken, and if the designer of the skin has no 3D TV, he wouldn’t know how to reproduce it. You folks are the only folks who could at least explain why that’s not working, and a diff would be the most useful way to do such an explanation.
Why e.g.: does the 100% work for half-sbs with both side-by-side output and frame-packed output , but not full-sbs ? And what 100% ? 100% of what ? the pixel width of the icon ??
I’ve tried explaining this issue to someone at Team Kodi before (although related to a different scenario than this) and it’s such an edge case that nobody really cared. It is an issue so basic in the design of the Kodi skin engine and how scaling as well as dimensional rendering of skin elements relative to the output resolution work that there’s no easy fix.
A workaround just for this specific case and just for one skin - Estuary - won’t be a simple one as it changes the basic paradigm of what the skinner who made and maintains Estuary over at TK chose. So, not just one diff necessary here at one single place, but you’d have to change the basic coding of the entire skin to look right after the change under all circumstances… And for that to happen, someone who knows Estuary in and out would have to care enough about this issue to do something about it in the first place. As explained, this didn’t happen before either and it wasn’t related to such a small edge case, but rather a much bigger issue.
I’m sorry to say, but I believe there’s not much we can do here. You could switch to a skin like the OSMC Skin that handles width dimensions differently though.
3D doesn’t have a future from Team Kodi’s perspective, from discussions in Tirana at DevCon in April.
We’ll support it downstream where we can, but I don’t think Kodi skins can be expected to support it fully.
Fortunately there is another skin (OSMC) that supports things as expected.
You could raise an issue with the maintainer of Estuary but I’m not sure that things will get fixed.
We’re grateful to @Chillbo for maintaining the OSMC Skin and a solid 3D implementation. He has made a lot of considerations in supporting 3D, and to be honest, it isn’t bloody easy.
Understood. As you know, i think that if there i any hope for future 3D, then it is in Full-SBS being used for AR/VR/Smart-Glasses, but i admit that this is, if anything ,slowly moving. And if at all its happening on the piracy side, which is not surprising given the stupid business processes of the Industry. There are also glasses free 3D monitors available now, of course mostly for gaming, but the Samsung model works astoundingly well for 3D movies and Kodi (on windows).
I don’t think any of these new display types are core targets for Vero V though, so i am not even asking for the non-working rendering to e.g.: those glasses. But i still hope the Vero V can stay the prime media player for 3D to traditional (HDMI) 3D displays. Just with also supporting the Full-SBS format which may become more interesting. Which it does very well!
The desinterest in 3D in the team Kodi is kinda frustrating, because I think Kodi could easily do a better job than VLC for 3D with Smart Glasses connected to an Android Smart Phone. But when i had opened a thread against that on the kodi forum, nobody showed interest. Oh well sob But luckily, VLC works reasonably well (just no subtitles of course). And on Windows, PotPlayer is a useful replacement for Kodi for 3D. Too bad if 3D’s software future has to be outside Kodi.
Wrt skin: I guess i am wondering how difficult it would be to fix up a skin myself, but admittedly, i wouldn’t have much time anyhow to learn that stuff sigh.
Adjusting the pixel aspect ratio in Vero V for FullSBS would be lovely though. Obviously just a nicety.
Other than that thanks a lot for your ongoing commitment to the 3D format and all the work you have and are putting into it!
Agreed, and we have discussed this (OSMC). It’s not a job for Team Kodi. Because a 3D approach like you describe would be deployed with something like Bluetooth’s 3DSP specification. Kodi does not touch Bluetooth directly.
After NVIDIA discontinued 3D vision, I feel the specification and compatible glasses may be an uphill battle at this time.
Yes, “normal” TV, frame sequential, and unless you use a DLP projector the best 3D glasses choice is Bluetooth. Ebay is actually full of them. Not sure if they do follow the 3DSP spec. And of course, there is no current mass market demand for this, so no guarantee how long supply would last if this would become a thing.
I played around a bit with non-3D-certified monitor and my old NVidia 3D gaming gear, and as folks on MTBS report, the biggest issue is to actually get good L/R separation. The dedicated 3D displays did use backlight pulsing or some internal BFI.
With non-3D monitors i think you would need to create a frame sequence like the following to emulate what classical 3D displays did:
L B R B L B R B
Aka: for every frame, repeat L and R twice with black frames in between. 192 frames/sec effectively. And if one can set up such a pipeline via OpenGL or so, then the optimization would be to use VRR to shorten the black frames so as to not loose too much light.
I think the issue would be sourcing reliable glasses. There’s probably a small glut of them somewhere but since NVIDIA threw in the towel I suspect things are diminishing on that level of supply. This was a consideration when looking in to things.
bluez has some plumbing for 3DSP, but I don’t know how extensive it was. It’s also a userland application, so would need adjusting to work with hardware based video acceleration.
GLES in our case, but not the worst idea I’ve heard…
Well, the bluetooth glasses on ebay/aliexpress look more like leftovers from 3D capable TV sets such as Samsung, Sony and the like from before 2018. So there could be some good numbers available.
